On Thu, Jun 02, 2005 at 09:06:35PM +0200, Michal Maru?ka wrote: > >hello fellow _xfree86_ hackers! > >This is a second email in a series aimed at getting code into the X server >needed to use a more sophisticated way of typing --- exploiting the time >information: key semantics changes according to the duration of the key press. > >I am providing the code to be distributed under the xfree86 version 1.1 >licence. > > > >Linux provides an alternative way to read keyboard input: >/dev/input/eventXXX device, provided by the "evdev" driver/module. > >This source provides 2 new features: > >1/ every event has a timestamp, which is more precise that calling (inside X >server) GetTimeInMillis > > Playing with the time of key events is the core point of my "rewriting > plugin", so i had to make several changes to all parts of X server which > handle key events. > > >2/ distinct hardware devices (keyboard) are reported in distinct devices/files > /dev/input/event0 /dev/input/event1 ... > > >The driver, called Medved, wraps/represents the set of evdev devices >(keyboards) >as 1 X keyboard. I.e. X clients see 1 _core_ keyboard --- no need to play >with XInput: > >The driver is quite unusual, b/c it handles more file descriptors, and >therefore >it cannot use a higher level > xf86AddInputDriver and xf86Wakeup > >but i have to use lower level RegisterBlockAndWakeupHandlers. > >and look directly at the select mask to see which of managed files/devices has >input ready. > > > >While coding this driver, i realized the cause of several bugs in other >drivers. > >I had previously communicated in > http://www.mail-archive.com/devel%40xfree86.org/msg06818.html > >the conflict between "current state" of the 2 halves of key handling code, >"separated" by xf86EventQueue. > >In that message, i talked about "down" bit-array, now i add, that keyc->state >is >impossible to use in the lower half. > >This (incorrect use of upper half's state in the lower half, which runs ahead >in > time) explain 2 bugs: > >1/ XF86Config options: > Option "AllowDeactivateGrabs" "yes" # C-M kp-/ steal > the grab > Option "AllowClosedownGrabs" "yes" # C-M kp-* kill > the grabbing client >simply didn't work (in situations i needed them) > >situation: > an application stopped accepting key events (i.e. holds a synchro grab & > doesn't call XAllowEvent) -> therefore keys accumulate in syncEvents > (dix/events.c) w/o effecting the XKB state > > XKB state is not "meta & control modifiers" > > >now, you want to steal the grab, so you press 3 keys Contol Meta kp-/ > >-> the first 2 events enter the queue, and the keyboard driver > when processing the 3rd (kp-/) will look at the XKB state which is not > "meta & control modifiers", hence it will not trigger any special function. > >Same applies to C-M-Fn to switch VTs (during such frozen situation). > > >2/ C-M-Fn occasionally leaked the Fn key into applications. > When the Fn was processed before the the upper part picked C M from > xf86EventQueue and changed the XKB state. This is possible when X server > reads all 3 key events at once. > >Solution is not very flexible, though. I just look if the fixed keys (say >Alt_L, >Ctrl_L) are down. > > > >(Since i play a lot with the time,) medved does not use HW autorepeat. This >will >be explained in the next email. > >More hw keyboards are used in the OR mode: a key is down, if and only if it is >down >on any of the hw keyboards. > >Hotplug is handled by polling, sorry. > > >I had to pull some functionality from the linux specific part of the "kbd" >driver (lnx_kbd.c) into a shared part.
If these functions are needed, I'd suggest naming them with an "xf86" prefix and providing dummy versions for other platforms, or, if more appropriate, adding them as new fields to KbdDevRec (xf86OSKbd.h). >I enclose these preparative changes as a patch. > >The driver itself is at http://maruska.dyndns.org/comp/packages/medved.tar.gz > > > >If you build xfree86 server with this patch & driver, you should notice that: > >- auto-repeat does not work > >- X mixes its monotonic time (GetTimeInMillis) with the timestamp coming from > evdev devices (gettimeofday) ... with various consequences (keyboard grabbing > stops working, iirc) > > >I don't bother providing fix for this, because in the next messages i will >provide > >- patch for linux kernel & GetTimeInMillis: > preversion http://maruska.dyndns.org/wiki/kernel.html > >- and an alternative method of generating auto-repeat events: at last >a reasonable auto-repeat, which i found lacking 2 years ago, when i started >fixing (hacking around) the key-event processing in X server. > > > > David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com _______________________________________________ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
