Re: new architecture of the key-event processing pipeline (& Medved) + How to build.

I think that it's better to consider the pipeline & medved driver  patches
together.

Patch & medved driver can be found here, to be used with the xfree86 1.1 licence:
http://maruska.dyndns.org/comp/packages/medved.tar.gz
http://maruska.dyndns.org/comp/packages/medved-plugin.patch


Regarding medved:

David Dawes writes:
> On Thu, Jun 02, 2005 at 09:06:35PM +0200, Michal Maruska wrote:
>> 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 have prefixed with xf86_. In Medved I don't use KbdDevRec as pInfo->private,
so it's not easy to adapt to what you suggest. And it's all #ifdef __linux__.


> 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.

Implemented: RegisterTimeBlockAndWakeupHandlers. To store the function
pointers, I wanted to make a C union, something like:

typedef struct _BlockHandler {
   union 
   {
      BlockHandlerProcPtr simple;
      TimeBlockHandlerProcPtr full;
   } BlockHandler;

... but that needs time.




I would like to explain, how to build a server with this new pipeline.


** Compiling

lndir ../xc/

patch -b  -p0  <  medved-pipeline.patch 
tar -xzpvf     medved.tar.gz 


put in config/cf/host.def:

#define ExtraXInputDrivers medved

/* Use the new key-processing architecture: */
#define BuildXKBPlugin   YES


/* for this a kernel patch is needed, see http://maruska.dyndns.org/wiki/kernel-time.html */
/* #define HasMonotonicTime NO */

/* This will bite if you settimeofday, auto-repeat for example might notice a
   very long key-down.  But you can use it with vanilla kernel! */

#define UseTimeOfDay YES





** Run-time Configuration:

add in the XF86Config file:

Section "InputDevice"
    Identifier  "Keyboard-medved"
    Driver      "medved"
    Option "Core"  "yes"

# It is better to specify an XKB keymap (in one of the several ways).  And have that
# keymap contain all 255 keycodes, even if not on the keyboard (geometry).
# Otherwise XKB unaware programs will see a limited keycodes interval.
# Once the server (medved driver) is started, there's no way to change it.

   #    Option "XkbKeymap"  "test.mmc"
EndSection



Section "ServerLayout"
...
    InputDevice "Keyboard-medved" "CoreKeyboard"
EndSection 



** Running:
Make sure, that you have "evdev" kernel module loaded, and the keyboard is
detected:
   ls -l /dev/input/event*

If evdev module is not loaded, running X would leave you without keyboard,
with not even possibility to switch VT. You could ssh and modprobe evdev,
and after ~ 10seconds X should start using the keyboard.


Now, how to see the usefulness of this massive redesign, from user standpoint?

- auto-repeat during sync. grab:

  I have worked on improving Sawfish window manager
  http://maruska.dyndns.org/wiki/sawfish-key-events.html  where I use  sync
  grabbing continuously. Now, if during such sync grab (more precisely during
  "keyboard freeze") i press a key, the XKB auto-repeat will not work.
  The hardware AutoRepeat works, though, but that's inflexible. (easily seen
  when a window is resized in steps)

  With this patch it will work as expected: at the rate configured, for the
  time the key was pressed.

- one can insert plugins, which transform keycodes, and even _delay_ them, and doesn't
  have to bother with all timing issues (of other functionality).

  To explain better: if such code wanted to wait a bit of time, before pushing a
  keycode, the auto-repeat would have to wait as well, instead of generating
  events during the pause. Instead by not pushing time to the next plugin, we
  easily stop the time on the entire pipeline.

In another email, i will maybe explain my "fork" plugin.



** Client side API:
Related to the plugin are 2 new client side calls. I was unable to compile them
conditionally: what is the equivalent of ServerDefines for the client
library(libX11)?

These new cals are:

XkbSetPlugin  which inserts/removes a plugin in the pipeline (at a position given
by a neighbour named plugin).

XkbPluginConfig sends a message to a named plugin and maybe waits for a reply.




Lastly, I want to stress the need for code which orders correctly
the input events.

I have noticed, that "eloinput" uses the evdev devices too. (not that i have
access to those devices, though).  So, I think a 1-1 driver is needed (1 evdev
devices -> 1 X devices, unlike medved) for mouse (maybe combined w/ eloinput),
which passes the time to higher levels. Then the DIX part (the final plugin on
pipelines), should act as the "merger" of the streams.


Without that, if i press a modifier, and drag with mouse in a rapid
sequence, my intended order is occasioannly (ignored and) inversed.