On Thu, Apr 09, 2009 at 09:13:46AM -0700, bugzilla-daemon@freedesktop.org wrote:
> Recent attempts to run recent xserver 1.6.99.+ of Fedora or GIT build 
> under Linux kernels 2.6.28..29-rc8+ fail because the file descriptors
> for which SIGIO notification is received do not trigger interruption 
> of the dix dispatch() select() loop .

I'm confused. They don't need to, the input is handled in the SIGIO handler.
Are you not getting an signals? are they not handled properly or are they just
ignored?

> Then the keyboard works only with the evdev driver ; use of the kbd driver
> does work, but it repeats each character three times, regardless of the
> auto-repeat settings.
that's because unless you use AutoAddDevices off, the keyboard is picked up by
the evdev driver too, so each keystroke looks as two devices hitting a key to
the server. with key repeat (faking a release), that's 3 symbols.
> 
> P.S - what happened to the XKB and XINPUT #define's in xorg-server.h ?
>       The xserver definitely seems to compile its internal XKB and XINPUT
>       extensions, but does not advertise that it contains them. 

xkb and xinput are mandatory, so the #defines are removed. 

RE: Comment  #1 From Peter Hutterer  2009-04-11 22:10:59 PST  [reply] ---:
On Thu, Apr 09, 2009 at 09:13:46AM -0700, bugzilla-daemon@freedesktop.org
wrote:
> > Recent attempts to run recent xserver 1.6.99.+ of Fedora or GIT build 
> > under Linux kernels 2.6.28..29-rc8+ fail because the file descriptors
> > for which SIGIO notification is received do not trigger interruption 
> > of the dix dispatch() select() loop .
>
> I'm confused. They don't need to, the input is handled in the SIGIO handler.
> Are you not getting an signals? 
> are they not handled properly or are they just ignored ?

No, it seems that when Xorg or emacs linked with the latest libxcb 
+ libX11 + mesa libGL* libraries speaks to the latest 1.6.99? Xorg
(20090412 git) server, both emacs and Xorg expect to get SIGIO signals, 
but do not receive them nor break from their select(3) loops.

Also, an strace of the default Xorg server compiled from GIT also shows NO SIGIO
signals ; perhaps this is more stringent enforcement of pselect(3) POSIX rules,
which when read more strictly, might suggest that without setting up a signal 
mask with a 'sigset_t*' parameter to pselect(3) , then  select(3) is REALLY 
blocking - ie. it is not interrupted by signals;
X hasn't done anything silly like enable the SA_RESTART flag for SIGIO has it ?
If so, then select() (not pselect()) will not return on receipt of a SIGIO. 
So how is Xorg expecting to handle events from SIGIOs outside the select()
loop when the select() loop is not broken ?

The 'AutoAddDevices="off"/"on"' and 'AutoEnableDevices="off"/"on"' settings 
in the xorg.conf ServerLayout seem to have no effect on this problem - still
neither mouse nor keyboard events are enabled unless I add the mouse 
and keyboard FDs to select()'s read FD set.

> > Then the keyboard works only with the evdev driver ; use of the kbd driver
> > does work, but it repeats each character three times, regardless of the
> > auto-repeat settings.
> that's because unless you use AutoAddDevices off, the keyboard is picked up by
> the evdev driver too, so each keystroke looks as two devices hitting a key to
> the server. with key repeat (faking a release), that's 3 symbols.

Then why bother allowing users to configure the "Keyboard" input device at all?
Why not tell them NOT to configure the keyboard in xorg.conf and that 
evdev will automatically be used ?

Also, Xorg refused to allow the Synaptics Touchpad driver to control the 
mouse - if the "Mouse" Input Device is not "mouse", then another 
double-driver is pushed onto the mouse device, and both drivers
get really confused.

It is really broken and confusing behavior to allow more than one driver
to control the same device as another driver in the first place -
why doesn't X detect and complain about this ? - but this is compounded
by ignoring the user's specification of 'driver = "kbd"' in xorg.conf .

This IMHO is a bug.

When I add the FDs for the mouse and keyboard to the read/write FD sets
via my crude AddEnabledDevice() patch, then the new Xorg 1.6.99 server
works really great - thanks!  but I'm still left with the emacs problem; 
recompiling emacs against the new X libraries leaves it stuck in a
select loop not getting any SIGIOs . Running the emacs under FC10 or RHEL5
chroot works fine when running against the new 1.6.99 server, and,
paradoxically, the new 22.3 emacs linked against the new X libraries runs 
fine in a chroot under the old FC10 or RHEL5 kernel and 1.5 X server . 
Full strace logs & config files available on request.

PLEASE FIX X-Server 1.[67] SIGIO handling for x86_64 2.6.29+ Linux kernels! 

> > 
> > P.S - what happened to the XKB and XINPUT #define's in xorg-server.h ?
> >     The xserver definitely seems to compile its internal XKB and XINPUT
> >     extensions, but does not advertise that it contains them. 
> >
> xkb and xinput are mandatory, so the #defines are removed. 

Wow, that really makes sense ! A feature is now mandatory / builtin, so we'll
act like it is removed.

Why not let users know that XKB and XINPUT are now built in extensions, with
something like this for example in xorg-server.h :

#ifndef XINPUT
#define __XINPUT__=_builtin_
#define XINPUT=__XINPUT__
#endif
#ifndef XKB
#define __XKB__=_builtin_
#define XKB=__XKB__
#endif

It seems that recent changes to ./hw/xfree86/os-support/shared/sigio.c
and hw/xfree86/common/xf86Xinput.c have fixed this problem - the 
Xserver and emacs now get SIGIOs.
Thanks!