I just changed DRM to alternative between zero and POLLIN.... This
will make the DRM poll() function work like the kernel expects it to
and still work with existing X servers. Can someone please get this
incorrect code out of the X server?

On Wed, 13 Oct 2004 16:39:27 +0100, Keith Whitwell
<[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
> > On Wed, 13 Oct 2004 10:13:50 +0100, Keith Whitwell
> > <[EMAIL PROTECTED]> wrote:
> >
> >>Felix K�hling wrote:
> >>I think the reason that you are experiencing failures is because the X server
> >>is trying to read or poll the drm filehandle, but Jon has recently changed the
> >>behaviour of that filehandle to return an error on those operations, rather
> >>than indicating that no bytes are pending.
> >>
> >>Let me stress that in most drivers there is no need for the X server to be
> >>looking at this filehandle at all, but the code which does so is widely
> >>distributed and this change to the DRM will break it.
> >
> >
> > Is it the poll() call that is the problem? I can set it back to
> > returning zero. The kernel people are saying this is wrong and are
> > pushing me to have it return (POLLIN | POLLOUT | POLLRDNORM |
> > POLLWRNORM) which is the correct return for an unimplemented poll
> > function.
> 
> In the very beginning, shared code in the X server listened to this fd, and
> shared code in the DRM existed to write to this fd, at the possible request of
> device-dependent DRM code.  The first DRM driver, the gamma, used this
> mechanism for context switching.  But no other DRM driver except perhaps ffb
> ever has.
> 
> About 18 months ago, I recognized this and pushed the shared code into the
> gamma driver, and removed the poll() and read() functions from drm_fops.h.
> Within the day I recognized that the X server continued to examine the fd, and
> that there was a need to restore empty poll() and read() functions.  Now that
> the gamma driver is dead, maybe we can go about pulling that behaviour out of
> the X server shared code as well.  But right now, you have a situation where
> everybody running a DRI-enabled X server is dependent on the poll() (and maybe
> read()) function behaving in the way it always has.
> 
> So, it's not really an unimplemented poll() function, but the
> backwards-compatible ghost of a real communications channel which is still
> polled, but never written to.
> 
> Keith
> 


-- 
Jon Smirl
[EMAIL PROTECTED]


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to