Re: Re: h2200_kbd: Remapping all 4 special keys to F9-F12 (Was: [H2200-port] keboard, brightness with opie on h2200)

Hi,

On 8/7/06, Paul Sokolovsky <pmiscml-Re5JQEeQqe8AvxtiuMwx3w@xxxxxxxxxxxxxxxx> 
wrote:
> Hello Giorgio,
>
> [cc: to kernel-discuss, as it really belongs there]
>
> Monday, August 7, 2006, 10:38:16 AM, you wrote:
>
> > Hi,
>
> > If nothing against it, In two days I'm going to remap all 4 special keys to
> > F9-F12 set in h2200_kbd.
> > I'll provide the patches for Opie and Xmodmap.
>
> > Alle 17:23, venerdì 4 agosto 2006, Giorgio Padrin ha scritto:
> >> 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.
>
>   Sorry for not responding earlier, but there doesn't seem to be need
> to haste with this. Such a change unlikely will get into Familiar
> 0.8.4, and so, let's better invest some pondering and discussion into
> it, and do that right.
>
>   So, yes, it's feasible and important to have common map. That's
> common problem and deserves common solution.
>
> > 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.
>
>   Well, you're right with this. But again, it doesn't really important
> what exact mapping is used, what's important that it was common.

But as there's no need to haste, we can as well also think about the mapping.

> That way, one device won't be worse than another, and any fix and
> improvement will benefit all devices. So, as you say, we have little
> option now than to use Fn keys. After all, problem we face now is that
> *builtin* buttons doesn't work over wide range of handhelds, so let's
> solve that problem first, and leave external keyboards for after that -
> it will be much easier to fix if there's common ground.

I don't think that a central include file is needed at all, if we can just
agree on common keycodes.

>   Ok, so let's consider what we have/may have:
>
> 1. First of all, no matter what we mapping we have, we should add
> proper level of indirection, so once we converted to common mapping,
> it can be tweaked in one place. So, let there be <linux/input-pda.h>
> which define constants with suitable prefix (like BTN_ or KEY_PDA_).

Again, I think this is overkill for up to four buttons in most cases.

> 2. The least common denominator we haev is 6 buttons which *almost*
> all devices has. These are:
>
> - Power button (a must)

That is KEY_POWER on most devices already (and should be).

> - Record (most have; well, h2200 is one of the few exceptions)

Can we use all codes from linux/input.h? There is a KEY_RECORD.
The magician also as
- a camera key (KEY_CAMERA)
- a volume slider (KEY_VOLUMEUP/DOWN)

> - 4 app buttons

Yes, but with wildly different labels...
For example the hx4700 has contacts, calendar, email and task manager buttons,
the magician has only contacts and calendar (and the two phone buttons).

> 3. But, appbuttons mapping will be funky for many devices. If you'd be
> asked what 4 appbuttons do, what be your answer? For me, it's
> Contacts, Calendar, Tasks, Memos. Old good Palm times, where is it?..
> Looking carefully at what button assignments are in PocketPCs produced
> over years, gives a bit of shock - unorderdness and mess, each device
> tries to invent its own pattern. After first shock fades out, some
> pattern does appear still: it seems like there's 5 most common
> functions - assigned to 4 keys. Order of buttons is arbitrary however
> (i.e. buttons with same functions may be in different positions
> spatially). So, what we have:
>
> - Almost all devices have Contacts and Calendar

ack. There is a KEY_CALENDAR, but nothing for contacts.

> - There're also Tasks, Mail(Internet, Sync, ...), and Home
>   (Taskman,...)
> - Phone edition dveices have Answer/Hangup buttons and 2 app buttons

There is a KEY_PHONE in input.h, but nothing about answer/hangup.

> 4. Phone edition devices usually have even more buttons, like Volume
> Up/Down. Some devices have jogdial.
>
>
>   So, based on this, I propose:
>
> 1. We define mapping in terms of both button's position and function.
> Position is rather a fallback method, for funky devices which have
> just mad mappings.

I prefer the mapping by function where possible. Unfortunately there are
quite some buttons that still don't have a keycode defined in the input layer.

> 2. Let the default correspondence between positional and functional to
> be that of "golden age" iPaqs, i.e. h1900, h2200, h4000, hx4700. These
> get F9-F12 keys.

No, please don't use keys that can be found on a common bluetooth keyboard.
Can't we use KEY_PROG1-4 for that or something like this?

> 3. Need to fugure out mapping for other keys.

Definitely.

>   All in all, that gives following draft <input-pda.h>

I don't like this. Can't we just extend linux/input.h officially?
I don't see how it makes sense to redefine KEY_POWER as KEY_PDA_POWER,
for example.

> #define KEY_PDA_RECORD /* There's KEY_RECORD, but it's >127. Well,
>                           h6300 uses it. Does it work? h6300.xmodmap
>                           has keycode 8 = XF86AudioRecord  ??? */

What is it exactly about the keycodes > 127 that makes problems?

> #define KEY_PDA_APP1 KEY_F9
> #define KEY_PDA_APP2 KEY_F10
> #define KEY_PDA_APP3 KEY_F11
> #define KEY_PDA_APP4 KEY_F12

This doesn't work too well if you use a bluetooth keyboard.

> /* Default functional mapping is those of h1900/h2000/h4000/hx4700
> iPaqs */
> #define KEY_PDA_CALENDAR KEY_PDA_APP1

or KEY_CALENDAR?

> #define KEY_PDA_CONTACTS KEY_PDA_APP2
> #define KEY_PDA_MAIL     KEY_PDA_APP3

or KEY_MAIL?

> #define KEY_PDA_HOME     KEY_PDA_APP4

This sounds a lot like KEY_HOME. Is there a better name?

> #define KEY_PDA_TASKS  /* assign */
> #define KEY_PDA_ANSWER /* assign */
> #define KEY_PDA_HANGUP /* assign */

Hm. I wish there was a KEY_PHONE_HANGUP in addition to the already
existing KEY_PHONE.

> #define KEY_PDA_VOLUMEDOWN KEY_VOLUMEDOWN
> #define KEY_PDA_VOLUMEUP   KEY_VOLUMEUP

Again, I don't see how this renaming improves anything.
Just use KEY_VOLUMEUP/DOWN.

> #define KEY_PDA_JOGUP /* assign, perhaps KEY_PAGEUP? */
> #define KEY_PDA_JOGDOWN /* assign, perhaps KEY_PAGEDOWN? */
> #define KEY_PDA_JOGACTION /* assign, perhaps KEY_KPENTER? */

There is a KEY_SCROLLUP and KEY_SCROLLDOWN. Not sure what the
jog wheels are used for, usually.

To sum it up, I wish I could use the following mappings:

hx4700
KEY_POWER
KEY_RECORD
KEY_CONTACTS
KEY_CALENDAR
KEY_MAIL
the task key...

magician
KEY_POWER
KEY_CAMERA
KEY_VOLUMEUP
KEY_VOLUMEDOWN
KEY_RECORD
KEY_PHONE
KEY_PHONE_HANGUP
KEY_CONTACTS
KEY_CALENDAR

Of those, KEY_CONTACTS and KEY_PHONE_HANGUP don't exist.
The phone hangup keys could be mapped to KEY_CANCEL, at least
that's what it is used for on some phones, too.
The ipaq task manager key could be mapped to some KEY_TASK or to
KEY_MENU for all I care.. I never use it except for starting the bootloader :-)

cheers
Philipp