[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: More about XKB
Re: More about XKB
Wed, 13 Nov 2002 11:07:21 +0100
On Wed, Nov 13, 2002 at 10:28:08AM +0100, M. Gerards wrote:
> We have to discuss the features we want to add with the X people. I think
> won't be a problem for some features like scrolling, but actions thast
> strings require bigger changes. The problems with such changes it that it
> breaks compatibility with X.
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.
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
> > 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.
Definitely. We have to convince ourself that we don't put stones in our
> > > - 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.
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. 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.
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.
 XFree86 uses a compiled format for client - server communication when
loading keymaps at runtime.
> > > - 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.
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.
> > 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.
I think I meant that things like switching off keyboard repeat is part of
the low level driver. But I am not sure anymore.
> > > - 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.
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.
> > > - 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 :).
Don't worry about this right now.
> > > 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
No, why. Any program can execute the functions that settrans is using to
attach an object to a filesystem node.
> > 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
> them. By doing this all keyboards will work the same.
They could all be virtual PC keyboards :P
> I think it would be
> useless to support hardware directly in X and on the Hurd, and this way is
> cleaner. To do this X needs to be changed, but its worth it IMHO.
Virtualization is nice. It also puts the burden on us, though. The
advantage to provide direct raw access to the underlying device is that we
don't need to care about doing anything. Like, I wouldn't want to write a
framebuffer abstraction that X can use. I prefer to just give X control
over the graphic card while I am not using it, and ask it to restore it when
it is switching back. Now, a graphic card is a zillion times more complex
than a keyboard or a mouse, but the fundamental issue applies: If there is
a fancy feature in some keyboard or input device, and we don't virtualize it
properly, X will not get to it. For example, we are likely to virtualize
the mouse like we do now (/dev/mouse is providing the same output for all
types of mice it supports). However, I worry about graphics tablets and
other more complex input devices.
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.
`Rhubarb is no Egyptian god.' GNU http://www.gnu.org firstname.lastname@example.org
Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/