Re: More about XKB

[Marcus Brinkmann]

On Tue, Nov 12, 2002 at 11:06:32PM +0100, M. Gerards wrote:
> Before you can understand what it does you first have to know what it
> is. This plugin is no driver (as it is now), but it is an additional layer 
> between
> the console-client and the driver. XKB is the X Keyboard Extention,
> the X way to have amlost full control over your keyboard. It's more
> than a keyboard map. It has many accesibility features and actions
> that can be bound to keys. 

I think there are two ways to split it up: Either you can have an xkb input
driver, that uses lower level drivers to retrieve the keycodes.

Or you can make each lower level driver a proper input driver, and make it
use a libxkb library that does the shared work.

There is virtually no difference between the two approaches, but the latter
would make it easier for users: They just need to load one driver, the xkb
module would be loaded by ld automatically through the library dependency.
Also, as the low level driver needs to do the initialization of the
hardware, and start the reader thread, I guess it would be quite natural to
use the input driver interface for that, instead passing the requests down
from a common xkb driver.  But I don't really care, it can go either way. 

The important thing is that the xkb part is the shared part, and the low
level driver is the part that is different for each specific set of
hardware.

> XKB has more features than just determining symbols. It is possible to
> bind actions to keys. These actions can change modifiers (Set, Clear, Lock or
> Latch), switch (virtual) consoles, etc. 
> 
> Another cool feature of XKB is Xaccess, a set of accesibility features
> for XKB.

These actions are very important.  We need extensions over what X has,
probably, or map the existing ones to what we need.  I guess we will need
some extensions.  For example, we have scroll up and down in history, but
by line and by page.  Those are four different actions, which probably are
not defined by X unless you can generate mouse events with the keyboard
(which you should be able to do).  We definitely also want to support
keyboard mouse, for example.  Other actions are invocation of easter eggs ;)
and whatever else we come up with.

> What I have done
> ================
> 
> There are two ways to store XKB configuration files: In a human
> readable way and in a machine readable way. The last method, the
> compiled keymap is the one I use. These files (XKM files) can be
> generated from the human readable ones. Currently this has to be done
> manually.I've implemented routines that can read and parse a great
> amount of available sections. 

I hope the binary format will be extensible for our needs, esp the action
part.  The problem is that we really need the human readable configuration
files, and we also need to be able to specify our extensions in the human
readable file.  I think that the human readable file is much more important
for us; if you also think that a compiled intermediate format is useful,
then that's a cost we can live with.  I think it's unnecessary.  The reason
X has this is that it uses that compiled format to upload keymaps to a
remote X server, and then it is easier if all the interpretation of the
configuration files has already happened.

> - Scancode->Keycode convertion is far from perfect.

I'd say it's close to perfect, even if it is hardcoded.  Hard coded mappings
don't support new keys that come on new keyboards (like the "make myself a
coffee button" and "start emacs button"), but that is a small issue.

>   Currently this
>   translation is hardcoded and only set 1 is supported. I want to have a
>   configuration file in which new sets can be added or changed. I have
>   seen some mails in which users complain about the XKB solution
>   (hardcoded). This should be done right from the beginning IMHO. To
>   support this we need a data format for the configuration files that is
>   compatible with all possible sets. 

I think this is very low priority.  The separation in low level keycode
driver and the generic xkb driver makes it painless to add such a feature
later, if it is truly desired.  I really think this can wait.

> - The code still doesn't behave *exactly* as XKB does. The wanted
>   behaviour of XKB is described in "The X Keyboard Extension: Protocol
>   Specification". This is important to fix because of compatibility. I
>   can fix most of these behaviour problems very quickly.

We don't really need to be compatible to the compiled format, as we can not
use their compiler anyway if we need Hurd specific extensions (more actions,
bindings to strings etc).  We should be able to read in all their
human readable configuration files.

> - Deadkey support. See what the problems are in my previous mails to the
>   list, or ask me.

I don't see a problem with dead key support.  Doesn't XKB define how dead
keys operate on other keys via a level or whatever?  I think the issues for
dead keys are exactly the same as for compose keys.  I mean we are not
talking about a fully fledged generic input device for unicode compose
characters, but only about a fixed table ' + a = á etc.

> - Many small features are not implemented yet. I'm talking about
>   things like Overlays, etc. If someone uses a feature that I didn't
>   descibe in this mail, please tell me, otherwise I'll consider them
>   as low priority.

I don't know what Overlays are.  Important for now is only to support the
hardware people actually use, but it would be nice to not worry about the
xkb driver in the future when we support more hardware.
 
> - Implementing AccessX. This can be a real problem. I think we have to
>   implement auto repeat of keys ourselves before this can be
>   supported. I'm not 100% sure and hope someone has a solution to
>   problems like:
> 
>   Slow keys, an AccessX control that will only accept a key when it is
>   pressed for x milliseconds, is activated. When the used hold the key
>   down both XKB and the keyboard will record how long. After Slowkeys
>   has accepted the key the keyboard will not wait long before more
>   keypresses are generated by the keyboard. Much faster than normal
>   because the first symbol is delayed.
> 
>   I expect other AccessX controls will have simular problems.

Mmh, for accessibility that would be really nice.  However, that is an issue
of the low level driver.  Switching off repeat and doing it ourselves with a
timer is not hard.  I already added a generic timer module to the console,
so it's there and ready to use.  It would suck for very fast repeat rates,
but nobody needs them anyway.

> - Latching of modifiers isn't supported at all yet, but adding this
>   feature should be very easy.

If latching means you can toggle alt and shift like numlock, then yes, this
is very important for accessibility.
 
> - A userspace driver. I think the XKB part and the driver should be
>   seperate.

The driver for what?  If you mean the thing that reads out a device and
generates keycodes from scancodes or whatever, then yes, I agree they should
be separate.  I also wonder how exactly you want to do the interface between
xkb and the low level driver.  I think the right thing is probably a call
back "enter_keycode" from the low level driver to xkb whenever something
interesting happens.
 
> - The console and X. Because I have never tried X on GNU/Hurd I'm
>   asking: is switching from the console to X and back currently
>   supported? 

No, not yet, and this is something I will have to work out.

>   This is how it is done for GNU/Linux:
> 
>       ioctl(xf86Info.consoleFd, VT_ACTIVATE, specialkey - KEY_F1 + 1);
> 
>   This isn't really XKB stuff, but I think it is a nice feature to
>   have.

It's not nice:  It's essential.  The console and X share the same hardware
resources, and at some time there might not be any other "real" console
anymore.

>   Another thing that is important for X is access to the
>   keyboard. Marcus suggested using a repeater for X. I assume this
>   repeater will be a translator

It will be a translated node.  The console client itself will provide it.

>   that will be readable and writable and
>   that the reader (X) will get everything a writer (the
>   console-client) has written to it. (I'm describing this to make sure
>   we are talking about the same thing).
> 
>   I wonder: what kinds of information can X read from this repeater?
>   Scancodes or keycodes? I think Keycodes is the best solution
>   because in that case X doesn't have to worry about the hardware at
>   all and because the current code to convert scancodes to keycodes in
>   X IMHO sucks. A problem with this repeater can be the commands X
>   wants to pass to the keyboard (Like setting the LEDs), right?

I think that makes sense.  Just sending X keycodes down the repeater is a
good idea.  About commands back to the kbd device:  It's a translated node,
so it can just write bytes to it in any format we feel comfortable and
handle the writes in the client.  Can you provide a full list of things X
wants to do with the keyboard?  Setting LEDs, setting the repeat rate (up to
switching it off for accessibility code etc), what else?  For writing, we
can actually expect it to write the direct commands for the controller and
just pass them through, or we can just make up any convenient format.

Good job,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus@gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/