Re: More about XKB

[M. Gerards]

> Why discuss this with the X people?  The need to be able to reuse the Hurd
> extensions to keymaps in X is absolutely zero.  The Hurd driver should
> (internally) preload the default Hurd extensions (like Alt+F1 sitch to VC1),
> and allow users to specify their own mappings, which can be in separate
> files from the X configuration.  This way, the common things can be shared
> while the Hurd extensions are kept outside of X.

It would be nice to be able to share configuration files, if we will have our
own parser we can stop this will be solved automaticly. Let's talk about this
later because it isn't important ATM :).

> 
> You have many good ideas, but I think that you need to take a step back and
> look at what we expect from this driver, so you can set the right
> priorities.

Please don't assume what my priorities are after reading my mail. I'm just
discussing all possibilities, nothing more. There is no need for me to discuss
the features you will expect because there is no need to. I think we have the
same priorities so please don't worry about that :).

> It's not a nice feature to have, it's absolutely essential, even if that
> just means running the right standard commands internally.  I want to repeat
> this: The reason to have a compiled format for XFree86 is not a valid reason
> to have one in the Hurd console[1].  The user interface is the human
> readable
> format, and the compiled format should not be visible at all, even if it is
> used internally.  If a compiled format helps you writing a working
> implementation because it makes it easier for you to load a keymap from
> disk, then that's fine.  But eventually I expect that the driver reads the
> human readable files directly at least from the user's perspective.

I agree.

> Look into /etc/X11/xkb.  That is the primary source for the keymaps, this is
> where the user will edit files and just expect the changes to take effect.

Like I don't know that ;)

> Can you give more detail?  Is there a keycode for ?, or how do compose key
> and dead key work?  If what you get in the end is a keycode for ?, or a key
> code for a combining ' and a keycode for "a", then it's easy to map this to
> unicode and apply normalization.

There is a symbol for ?, it can also be defined without using deadkeys (was this
what you wanted to know?). I should read about normalization too I assume :). 

Please have a look at this file:
(/usr)/X11R6/lib/X11/locale/iso8859-15/Compose

One problem is that symbol names are used here.... I think. I definately should
think more about deadkeys.

> > 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.
> 
> I think I meant that things like switching off keyboard repeat is part of
> the low level driver.  But I am not sure anymore.

Yes, that is a part of the low level driver.

> You mean calling back into the low level driver to poll the next keycode. 
> Yes, that's ok.  You will have to put the event loop (the reader
> thread) into the xkb driver.

Yes.

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

I don't worry about it, I just think about it.

> > I didn't know this is possible. I thought translators have to be set with 
> > settrans.
> 
> No, why.  Any program can execute the functions that settrans is using to
> attach an object to a filesystem node.

Ok.

> Of course, the advantage is that a user just configures the virtualization
> layer and then doesn't need to do the same configuration in X.  There is
> always a tradeoff.  Virtualization is nice but harder to get right.

It isn't too difficult.

Thanks,

Marco Gerards