Re: keyboard autodetection
>
>
>Hi,
>
>> > > * Is there a way to autodetect (based on hardware IDs) the keyboard t>ype
>> > > (eg., when you install Debian, you have to select keyboard layout and
>> > > country/ type).
>> > Hmm. What you're asking, I think, is whether the hardware ID implies a
>> > layout. (It's not really autodetection; it's a lookup.) I don't know.>
Its hard to do keyboard detection based on hardware ID because
of the cheap way keyboard manufacturers build keyboards:
they do not want to build key layout into the keyboard electronics, but rather
just build 'local' keyboards by
sticking the keycaps on at the last minute.
E.g. it is easy for a manufacturer to assign different USB
IDs to different models, so that keymap type could be
autodetected in software. But if they eg. make
boards for 1000 French azerty keyboards, with a French
ID in the 'firmware', they can't just make these into
German 'qwertz' keyboards (if they get a demand for German
keyboards), by putting different keycaps on them
before packaging, which is what they like to do right now.
This is irritating as it means kbd-chooser, etc. can't
completely autoconfigure the keyboard.
For non-AT keyboards, e.g. Sparc, Apple, etc. the
prospects are better; see code in kbd-chooser source for
reading keyboard type from these from the input layer in 2.6
kernels. (Hint, hint: please move to 2.6 kernels where possible...)
>I've thought about this extensively at this year's DebConf, however I've
>been unable to implement a real solution. I had to install Debian on one
>box in Brazil, which of course had a Brazilian keyboard. As there are
>two different variants of "Brazilian" keyboards available, I could not
>decide for myself which one was appropriate.
>
>The idea I have in mind is to generate a "decision tree" from the
>available keymap files (flat tree being optimal) and have the user press
>different keys in turn to see what keycode they give. The greatest
>hinderance is the fact that I'm not allowed to read data from the
>keyboard when using DebConf, which is why I have no real idea how to
>implement it in a compatible way for d-i, short of adding a new template
>type "single-keycode" (which would probably work on the console, but
>require additional work if it is supposed to work together with bterm,
>which the installer currently uses, or X, which the installer might use
>in the future).
Agreed; a much better widget, specifically for X use,
should be designed for sarge+1.
> Simon
>
- Alastair
Reply to: