Re: new architecture of the key-event processing pipeline

This looks very interesting.  I've only had time to have a quick read
through the patch so far.  I'll reply further later.

Regarding the BlockHandler changes, maybe it would be better to add a new
registration function for handlers that need the current time as a
parameter.  Perhaps this new type of block handler could get passed a
pointer to an extendable structure which would include pReadmask and the
current time.

David

On Sun, Jun 05, 2005 at 11:44:45AM +0200, Michal Maru?ka wrote:
>Once again (see my previous 2 messages to this ML), all code (patches & new
>functions) is provided to the xfree86 project to be distributed under the
>xfree86 version 1.1 licence.
>
>This is the last part, which should make clear why medved driver was so designed.
>
>This time i will try to explain concepts behind the code inserted, by included
>patches.  into the XKB and DIX parts (and also the input processing in
>hw/xfre86/common) of the X server
>
>
>Let me start with an explanation of the "upper half" of key event processing:
>
>
>events are taken from xf86EventQueue
>
>and take one of these routes:
>
>A:  keyboard is "frozen":
>     the event is put in a queue syncEvents
>
>B:
>
>1/ XKB scans them to detect special sequences (to invoke AccessX functions)
>
>2/ XKB rewrites keycodes into XKB actions: updates XKB state, turns key events
> into mouse events etc.
>
>3/  the "core" processing: focused window (& its ancestors) is checked for a
>grab and the event is sent to some client(s).
>
>
>If the grabbing client requests some more events (XAllowEvents, or Ungrab),
>events in the syncEvents are re-routed onto the route B.
>
>Steps on the route B register some timers, which in case keyboard is frozen need
>to be canceled. This may be complicated, and cause unpleasant buggy behaviour.
>2 years ago i found such a timer (auto-repeat, registered in the step 1/) which
>was not getting canceled on route A.
>
>
>
>
>I devised a different approach: events take just 1 route, but there is some
>communication in both directions:
>
>The unique route, which i call pipeline, can even be made modular:
>
>We have a (doubly) linked list of "processors". The original term which i used
>for such processors was "plugin", since i worked on just one such, and it could
>be reloaded with dlopen.
>
> Events taken from xf86EventQueue are pushed to the first processor.
>
>Each processor can decide when to hand over events to the next one.
>
>Now, since time (event without any events) is crucial to auto-repeat, and other
>functionality, "time elapsed without any key" needs to be processed as well.
>
>
>So, each processor, can call 2 methods of its next neighbour: to hand over time, or
>hand over an event.
>
>To address the need to freeze the processing (think syncronous grab) each
>processor can signal the previous neighbour, that it cannot accept key events
>nor time, temporarily.
>
>When it resumes processing it will signal again the previous neighbour.
>
>
>
>event      +--------+   stop
>---------->|        |<------
>           |proce   |
>time       |   ssor |   resume
>---------->|(plugin)|<------
>           +--------+
>
>To connect this pipeline into the current X code, i made 2 processors for the
>extremes of the pipeline, called "core", which hands over event to the
>dix/events.c code, and "stack", which accepts events from xf86EventQueue and
>never freezes (it replaces syncEvents), and of course i changed the interfacing
>functions a little.
>
>Thus, for example,
>
>realInputProc &  enqueueInputProc (processInputProc) point at my custom functions,
>which invoke the pipeline ("event" in the schema).
>
>On the opposite end,  PlayReleasedEvents is combined with invoking the "resume"
>of the pipeline.
>
>
>As i said, the pipeline wants also time as input, so
>
>all the way from WaitForSomething (which gets the current time before calling
>Select)
>time is passed on to all functions, through wakeupHandlers to ProcessInputEvents.
>
>otoh, the pipeline, instead of using timers, registers a BlockHandler and wants
>to set the timeout for Select. To do so, it needs to know the current time, so
>i had to change BlockHandlers to accept an additional parameter, current time.
>
>
>Hence, a large part of the patches is related to adding TIME argument to many function
>signatures.
> 
>I changed the signatures unconditionally. W/o #ifdev MMC_PIPELINE !
>This might result in breaking ABI with 3rd party drivers?
>
>
>I also added 2 new methods (for devices)
>    dev->public.thawProc
>    dev->public.pushTimeProc
>
>
>
>The  second part (of patches) is an alternative implementation of auto-repeat.
>    programs/Xserver/xkb/xkbAccessX.c
>    
>I have NOT implemented a pipeline version of other functionality in that file:
>slowKey, StickyKeys.   I think it's easy to do, though.
>
>My auto-repeat can AR more keys! 
>
>
>
>3rd part of this patch is related to my original aim: inserting a plugin, which
>changes keycodes.
>So it includes code necessary for:
>Clients can request to insert/remove plugin (on the pipeline) and set & read
>configuration.  This is inserted into the XKB code.
>
>
>What needs to be done is the code to send events (to clients) of different
>devices in time order.
>
>
>* How to build:
>
>- the new pipeline is compiled conditionally #if MMC_PIPELINE.
>
>- GetTimeInMillis  needs change:
>  either return gettimeofday, which is compatible with official evdev device
>  timestamp, but can be cause disastre if you shift the clock: if you move clock
>  2 seconds ahead, auto-repeat will generate events for 2 seconds (if some key
>  was pressed). This may be acceptable only for short testing.
>
>alternatively, i suggest using my kernel patch, to get the kernel's monotonic
>  time, and have evdev provide that in the events' timestamps.
>       http://maruska.dyndns.org/wiki/kernel.html
>  
>
>- you need the medved driver.
>  
>patch  (to be applied over the previous 2 patches):
>            http://maruska.dyndns.org/comp/x/plugin.patch
>
>
>there are some problems with this patch:
>  programs/xfs/  uses BlockHandler 
>
>
>This is all info I can provide now. I will write more next week-end. My job
>calls now.
>_______________________________________________
>Devel mailing list
>[email protected]
>http://XFree86.Org/mailman/listinfo/devel
>