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

> Alle 17:23, venerdì 4 agosto 2006, Giorgio Padrin ha scritto:
>> Hi Paul,
>>
>> I add my 2¢ to the discussion.
>>
>> iPAQs are keyboardless devices, but we can attach bluetooth keyboards or
>> keypads with funny keys, maybe for music or else. So maybe it's better
>> to
>> not invade sets of keys with an expected behaviour.
>>
>> The natural choice would be dedicated keys as KEY_HOME, KEY_CONTACTS.
>> But, as you noted, some keycodes are 16bits and they're not well
>> supported
>> by current code in Opie and GPE.
>>
>> So a map into the FN set may seem a second best solution, leaving free
>> the
>> lower and commonly used subset. From F9 up?
>>
>> I noted in Opie odevice.h there's a default map, that older iPAQs adhere
>> to
>> (in odevice_ipaq.cpp).
>> h2200 could adhere to it also.
>>
>> But, what exactly is the limitation in xserver-kdrive: 7 or 8bits?
>> If it's 8 bits, it's ok.
>> But if it's 7bits, we cannot use FN keys above 12, so there's little
>> room
>> for a common map among machines.
>>
>> If a common map is not feasible, I'd simply map in the F9-F12 range, in
>> the
>> order in which buttons are on the device, so someone knows visually what
>> the map is.
>
> I forgot.
> For Power button KEY_POWER should be safe to use.
>
>>
>> Giorgio
>>
>> Alle 22:21, mercoledì 2 agosto 2006, Paul Sokolovsky ha scritto:
>> > 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.

if you look into opie code power button is handled by Key_SysReq for other
ipaqs, but that key doesn't work on h1910. i don't know why, i never
checked in opie source code. i used F6 key to keep all keys together with
other Fx mappings. i don't remember if i tried KEY_POWER. but if it fits 7
bits dosn't mean it will work for sure. it might be filtered in other
source code place.

>> > 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,
> _______________________________________________
> Kernel-discuss mailing list
> Kernel-discuss_at_handhelds.org
> https://handhelds.org/mailman/listinfo/kernel-discuss
>
>
Received on Fri Aug 04 2006 - 12:25:37 EDT