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

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?

  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?).

2. Thus many ports use othet keycodes to encode appbuttons, mostly
F1, etc. One exception is #define KEY_POWER 116, which clearly fits in
7bits. Surprisingly, h1910 (and thus h4000) still uses F6 for power.
When I asked Pawel Kolodziejski, h1910 maintainer, why he did it so,
while h2200/hx4700 use KEY_POWER, he's response was - "well, do those
port support suspend via button in Opie". According to the latest
comments on h2200, it seems that not. Well, I don't think the code is
really matters. What matters is that some of devices solved the
problem, and the other still drag it along. Resume: if we have one
common Power key code for all devices, we *will* solve the Opie (and
any other) issue, and it *will* be solved for all devices at once.

3. We really should consider if we want adhoc codes for appbuttons.
Maybe it's really good idea to assign to them codes out of standard PC
keyboard set? The benefit: it will allow us to have (development) builds
for x86 or some emulator and still "press" the appbuttons by hitting
corresponding Fn key instead. That's pretty good for debugging,
actually. Drawbacks: I don't really see any except that such image
won't allow to use corresponding keys if run on keyboardful devices.
Well, that's accepted - keyboardless and keyboardful devices guaranteedly
will require different buttons/keys configuration. Issue we try to
solve is having common support for keyboardless devices. And if it
will even let us debug images on desktop box, that's only pro,

> Giorgio

Sorry for long mail, but teh issue is worth consideration and solving.

Hope to get your comments,

-- 
Best regards,
 Paul                            mailto:pmiscml_at_gmail.com