Re: Re[2]: [H2200-port] keboard, brightness with opie on h2200

On Aug 2, 2006, at 1:21 PM, Paul Sokolovsky wrote:

> Hello Giorgio,
>
> Wednesday, August 2, 2006, 11:45:15 AM, you wrote:
>
>> Alle 02:20, mercoledi 2 agosto 2006, Michal Panczyk ha scritto:
>>> It still behaves like "numlock" was on
>
>> In h2200 kernel the 4 special buttons are mapped to F9, F10,
>> NumLock and
>> ScrollLock. Maybe it's better to map instead to F10-F12 range and
>> stay away
>> from keys of predefined meaning. Likewise all other machines do.
>> What do you
>> say?
>
>> Is there anything in favour of the current mapping? or is it just
>> the keycodes
>> are in sequence, 67-70?
>
> As far as I understand, button code mappings used my different port
> are mostly pretty arbitrary. And that's causes unneeded difficulties
> for distros (need to supply per-device button maps, etc.) and new
> ports.
>
> It's not new idea to have a common map for all 2.6 ports ( see for
> example http://handhelds.org/hypermail/gpe/53/5378.html ,
> http://handhelds.org/hypermail/gpe/53/5379.html ), so I wonder if it's
> a good time for us to discuss and decide on this matter?

Yes, this is a good time. The sooner, the better.

> We can have two approaches to this:
>
> 1) One port just gives up its own map in favor of another port, known
> good. As an example, h4000 just follows h1910 map. And I'd be willing
> to follow any other such common effort, if it will make more than 2
> devices have common mapping,
>
> 2) We can re-enumerate what constraints we have on the mapping, and
> what benefit we'd have using some type of mapping vs another. Then,
> decide on standard mapping, implement it in all ports, and make distro
> support just it.
>
> Choice #2 would be better, of course, but would need initial effort
> of deciding on common map, plus cooperation of ports and distro
> maintainers. As initial seed to that approach, here's dumb of my
> knowledge (which may be incomplete and even skewed):
>
> 1. There may be "first-class" defines for at least some of "PocketPC"
> appbuttons in linux/input.h (like #define KEY_CALENDAR 0x18d). But due
> to xserver-kdrive's bugs/misfeatures we cannot use them - it limit
> leycodes to 8bits (or just 7bits?).

Yes, there's a problem with xserver-kdrive not accepting keycodes >
127 (or is it 255?). An xorg server using the evdev driver may not
have this problem. Also, I notice that somewhere between the console
layer and X, 8 gets added to the value emitted by the driver.

Matt
Received on Wed Aug 02 2006 - 16:38:12 EDT