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.
> > 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,
Received on Fri Aug 04 2006 - 11:30:26 EDT