bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Console-client xkb keyboard plugin


From: Marcus Brinkmann
Subject: Re: Console-client xkb keyboard plugin
Date: Tue, 12 Nov 2002 01:36:08 +0100
User-agent: Mutt/1.4i

On Mon, Nov 11, 2002 at 02:49:33PM +0100, M. Gerards wrote:
> The first problem is the scancode to keycod translation. At the moment I've 
> hardcoded this translation (XKB also works like this.). I'm not happy with 
> this 
> because this will cause problems for exotic keyboards. I'm thinking abut a 
> configuration file for this so set 1 and set 2 can be used and even some 
> other 
> sets I don't know.

How does X do it?  Does it expect the keycodes from a low level driver?  If
that is the case, we can add low level drivers too (imagine modules which
just load a single conversion routine, which you are expected to load before
the xkb driver).

> Another XKB limitation is the Action structure. It is only 7 bytes big, so 
> it's 
> can't be used for strings like I hoped.

If you are not going to use the XKB code from X (are you?), you can just
support arbitrary long action bytes.  Or is there a need to be compatible to
their binary data structures?  I guess the question is if you support xkb or
the compiled format.
 
> Another thing that confuses me are the symbols. Does someone know if the 
> symbols are already in unicode or if they need to be converted. (The only 
> unicode symbol I know is the EuroSign, I checked that one and it's symbol is 
> also the unicode character).

The input driver is expected to output UTF-8.  So if X defines them in
UTF-32, you need to convert.  I surely hope XKB files agree on a shared
format or at least specify it.
 
> The last problem are deadkeys. Deadkeys depend on the current locale, like 
> many 
> XKB options do. Most of these things are solved by glibc :)). I wonder if 
> deadkeys are the same as unicode nonspacing characters. 

No, deakeys are input methods.  unicode characters are separate from the
input method, but related to them (see the discussion with Niels here how to
input composed characters).  There is no problem depending on the current
locale, in Glibc we can set it at run time to whatever we need.
 
> Yeah.. I know, I should study unicode (Especially non-spacing characters) 
> because it still confuses me sometimes :). 

It's good to ask questions, but the questions should be specific.  Unicode
is about encoding a character or a string.  Deadkeys are about inputting
accented characters.  If you press ' on a  dead key layout, it should be
recorded internally, and if "a" is pressed next, á should be emitted (or
rather: the UTF-8 encoding for á).  If we emit the encoding for á or '+a is
a different matter, I would say this depends only on the configuration file
(and the driver should not have any specific knowledge about this).
 
Thanks,
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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]