[Bug 1626] New: Fix X's use of poll() to be correct

[bugzilla-daemon at freedesktop.org]

Please do not reply to this email: if you want to comment on the bug, go to          
the URL shown below and enter yourcomments there.   
 
https://freedesktop.org/bugzilla/show_bug.cgi?id=1626        
   
           Summary: Fix X's use of poll() to be correct
           Product: xorg
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Server/general
        AssignedTo: xorg-bugzilla-noise at freedesktop.org
        ReportedBy: jonsmirl at gmail.com


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:
- Hide quoted text -
> 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
>

Am Mi, den 13.10.2004 schrieb Jon Smirl um 18:53:
> 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?

As I mentioned earlier, setting driverSwapMethod to DRI_KERNEL_SWAP
seems to work for the savage driver. I bet it works for many others too.
AFAICT this tells the common DRI code not to use the DRM file handle.
Once this is proven to work with all drivers we could axe the code for
the other methods.        
   
   
--         
Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email       
   
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.