Summary: | SIGIO mouse + keyboard events NOT select()-ed - no AddEnabledDevice() - NO SIGIOs received + XKB? XINPUT? | ||
---|---|---|---|
Product: | xorg | Reporter: | Jason Vas Dias <jason.vas.dias> |
Component: | Server/General | Assignee: | Xorg Project Team <xorg-team> |
Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> |
Severity: | major | ||
Priority: | medium | ||
Version: | git | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Jason Vas Dias
2009-04-09 09:13:44 UTC
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! |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.