Re: More about XKB

[M. Gerards]

Citeren Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>:

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

I think I will write a XKB plugin that will read from the low level drivers.
By doing this the user can choose to use another keymap format. It's also
easier for me to code.
 
 
> > 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.

If we want to define this actions the same way as all other actions are defined 
we have to define this as a single function instead of four. I was thinking 
about scrolling per line, page and in percents. Scrolling can be done asolutely 
and relatively (x=10 or x=5). 

Mousekeys are already supported by XKB. This feature will be easy to add I 
think (I'm talking about the mouse keys feature, not the mouse itself :)).

I think actions are VERY important. I won't use the hardcoded stuff that is 
currently used (like Alt+F1) with only one exception: CTRL+Alt+Backspace.

Having string support in actions is a must I think. When strigns are supported 
actions like InsertString or RunCommand (which can be bound to CTRL+Alt+delete 
to reboot the system) can be added.

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

We have to discuss the features we want to add with the X people. I think this 
won't be a problem for some features like scrolling, but actions thast require 
strings require bigger changes. The problems with such changes it that it 
breaks compatibility with X.
 
> > - 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.

I think many hackers won't agree with you when you say "make myself a coffee 
button 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.

It is low priority, I only mentioned it because it is the right thing to do. 
It's good to think about such things from the beginning.

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

Parsing the uncompiled format is difficult but a nice feature to have. I 
already have support the compiled keymaps. I think this should be added when 
the compiled keymap is fully supported.

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

What characters should be generated isn't supported by the XKB configuration 
file and it depends on the current locale. This just isn't as easy to add as 
all other features.

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

An overlay defines some keycodes that should be mapped to other keycodes when 
it is active. This can be used to add a keypad to a laptop keyboard using 
alpabethic keys. I think noone uses this feature because it is defined by the 
hardware. I could be mistaken because I have not much experience with laptops.

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

I forgot to mention the following webpage:

http://www.sun.com/access/general/accessx.html

It's worth the time reading it because it isn't much text and contains all you 
want to know about AccessX. (And if you want toknow more, ask).

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

What do you mean with "that is an issue of the low level driver"? These 
features are defined by XKB and should be handled by XKB.

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

No, what you mean is locking. Latching is almost the same, but the modifier is 
consumed when it is used. For example:

The action LatchMods is bound to Shift. When the keys Shift, A, A are pressed 
the string "Aa" will be generated.

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

I thought about reading from the device. I think this is easier to do.

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

The keyboard driver needs to know about this. Keys shouldn't be passed to X 
when X isn't active :).

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

I didn't know this is possible. I thought translators have to be set with 
settrans.
 
> >   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.

I think we shouldn't support keyboard commands directly but need to virtualize 
them. By doing this all keyboards will work the same. I think it would be 
useless to support hardware directly in X and on the Hurd, and this way is much 
cleaner. To do this X needs to be changed, but its worth it IMHO.

Thanks,

Marco Gerards