What is driverSwapMethod = DRI_HIDE_X_CONTEXT?

Jon Smirl jonsmirl at gmail.com
Wed Oct 13 09:53:40 PDT 2004

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
<keith at tungstengraphics.com> wrote:
> Jon Smirl wrote:
> > On Wed, 13 Oct 2004 10:13:50 +0100, Keith Whitwell
> > <keith at tungstengraphics.com> 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
jonsmirl at gmail.com

More information about the xorg mailing list