Pandora Pandora Button Mappings

[dflemstr]

I read the following:

Does the Dpad still double up as the cursor keys?

yes, and game buttons also trigger as keypad 1-4, select/start as ctrl/alt, L/R as additional mouse buttons (not sure about those 2, DjWillis is doing keymap for them).

...and thought: Those mappings are OK, I guess, but they'll give me problems (and probably others as well).

Situation:

• I'm trying to create a simple app in GTK/Qt.
• I do NOT have access to the SDL_input API so I can't use the macros defined in SDL (...or can I? What, then, is the joystick ID and can the buttons be mapped to custom keys?)
• I create a text field of some sort or another (It could happen once or twice..., right?)
• I want to put that text field in a dialog box that should close with accepted status when the primary selection button is pressed on the Pandora (Which button is that per default BTW? The top one or the right one?)
• I set a "key trigger" (name depends on API) on the window to do what I want when the "Keypad 1" key is pressed.
• I run my brand new application, and lo and behold, a "1" appears in the text field once I press the select button.

Now, before you tell me; yes it is of course possible to work around this behavior, but not all of the time, and not if you want to avoid to subclass (in the case of C++) every darn text box you use just to intercept that keypad press.

So, I propose that we change those mappings pronto. Everyone who's using some kind of widget toolkit will be very happy, and those who don't (aka use SDL) won't notice the change.

Here's what I had in mind:

• Top button: The Yes key (0x01010001 in Qt) OR the Context1 key (0x01100000)
• Right button: No (0x01010002) OR Context2 (0x01100001)
• Bottom button: Context3 (0x01100002) (change this and the next key if Yes/No is chosen above)
• Left button: Context4 (0x01100003)

Is this possible?

 

[Pickle]

The index of the joystick is 0, but like notaz said the buttons are double mapped. So if you can use SDL to get the joystick, then why cant you get it for keyboard.
Another option is get events through X
And even lower than that is the kernel event interface.

 

[dflemstr]

The index of the joystick is 0, but like notaz said the buttons are double mapped. So if you can use SDL to get the joystick, then why cant you get it for keyboard.
Another option is get events through X
And even lower than that is the kernel event interface.

Point is that I *can't* get access to SDL joysticks or keyboards, nor joysticks by any other means (Qt and GTK don't support joysticks for normal UIs)...
Did you read the post 'til the end?

And if I want to write portable code and want to avoid hacking Qt, my only real option is the keyboard, and as I said, the keyboard mappings are unusable in practice.

 

[Pickle]

I did read it quick. ;-)
your basically saying you get both actions when you press select right

 

[dflemstr]

I did read it quick. ;-)
your basically saying you get both actions when you press select right

No, when I press the top button (The X button?) on my fictional Pandora, the text box in my window handles the key press and displays a "1" (because the top button is mapped to KeyPad_1 and text box widgets in GTK, Qt, Wx etc are built so that they display a "1" when the user presses the 1-key), and my window never receives the key event as an effect of that.

As I said, I could change this by changing the text box widget (by blocking 1-key-events to the text box, which would have the effect that the user wouldn't be able to enter digits into it), but it would be easier if the keypad driver guys would just decide to map the buttons to something more sensible.

EDIT: s/0/1/; I read notaz's post wrong.

 

[skeezix]

You mean you don't want to read /dev/events[0-9] to look for key (and other) events? pshah!

jeff

 

[dflemstr]

You mean you don't want to read /dev/events[0-9] to look for key (and other) events? pshah!

jeff

Well, sure, I could read those files, but QLineEdit won't, for sure. It will always show that "1" whatever I do.

Starting to see my problem?

 

[notaz]

Why do you want to use game buttons for stuff like text input? If user is supposed to enter something there using keypad, (s)he will likely press return/esc to finish/cancel as this is part of keypad (s)he used to enter text. Let's just leave game buttons for well, games.

 

[dflemstr]

Why do you want to use game buttons for stuff like text input? If user is supposed to enter something there using keypad, (s)he will likely press return/esc to finish/cancel as this is part of keypad (s)he used to enter text. Let's just leave game buttons for well, games.

If you say so... but it seems counter productive to artificially limit the use of the game buttons, especially since changing the mappings would be as easy as changing 4 lines of code, literally.

Oh well, I'll have to do the hacking then I guess. Thanks for your efforts so far, everyone!

 

[notaz]

Those context keys you suggest are not something kernel can return, maybe this can be configured in Qt itself or something. What are they mapped to on PC?

 

[dflemstr]

Those context keys you suggest are not something kernel can return, maybe this can be configured in Qt itself or something. What are they mapped to on PC?

They aren't mapped at all on a PC. I didn't know that they weren't standard keys, actually; I've used them on lots of (portable) devices and they were always just...there, without a custom Qt build (they normally map to those generic selection keys on smartphones below the display).

Feel free to map them to something else if context keys aren't available; the problem is that the way the buttons are now, they are mapped to actual character keys, so that they trigger text echos; any mapping that uses non-printing keys would thus make me content.

E.g. F20-F23 (The Pandora does only have F1-F12 as physical keys so these are usable)
or Key_Super_L, Key_Super_R, Key_Hyper_L, Key_Hyper_R (These are the Qt names again but there are scancodes for these for sure, since they were part of standard terminals a while ago at least in BSD)
or the Launch0-Launch3 keys (those "launch" keys for application shortcuts on PCs)
or Key_Hangup Key_No Key_Select Key_Yes (in any order, but these might have the same problems as the Qt context keys)

If none of the above work for some reason, then if anyone can direct me to a list of accepted scancodes I'll suggest some more.

EDIT: Oh, right, there's "include/linux/input.h", durr
Here's a patch for you that uses the F20-F23 keys

 

[Creature XL]

Just want to ask what is the rational behind making the action buttons the numbers 1-4? (or 0-3)?
Are these number used often in any application?

I think it would be more sensable to make them send F13-F16, or F20-F23) Or what about MultiMedia-keys you find on almost all normal keyboards?
the RIGHT and LEFT could be forward and backward, the UP button could be eject and DOWN button could be pause/play.

Anyways, if they would send such events they can be easily remapped with xmodmap, if I am not mistaken.

 

[dflemstr]

Just want to ask what is the rational behind making the action buttons the numbers 1-4? (or 0-3)?
Are these number used often in any application?

I think it would be more sensable to make them send F13-F16, or F20-F23) Or what about MultiMedia-keys you find on almost all normal keyboards?
the RIGHT and LEFT could be forward and backward, the UP button could be eject and DOWN button could be pause/play.

Anyways, if they would send such events they can be easily remapped with xmodmap, if I am not mistaken.

Yes, but sadly, if I deploy an application as a PND, that PND has no possibility of invoking xmodmap...

Also, yeah, F13-F16 would make sense but it would be a PITA to remember ("What number did the bottom button have again?...")

F20-F23 doesn't make as much sense since there isn't a F0 key.

 

[notaz]

EDIT: Oh, right, there's "include/linux/input.h", durr
Here's a patch for you that uses the F20-F23 keys

I think it would be more sensable to make them send F13-F16, or F20-F23)

Those are already used by kernel Fn hadling:
http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-kernel.git;a=commitdiff;h=fc359f9dd7efd346c070950320dda62ae671519f
This is not in main git because I can't test this properly without mat and case.

or Key_Super_L, Key_Super_R, Key_Hyper_L, Key_Hyper_R (These are the Qt names again but there are scancodes for these for sure, since they were part of standard terminals a while ago at least in BSD)
or the Launch0-Launch3 keys (those "launch" keys for application shortcuts on PCs)
or Key_Hangup Key_No Key_Select Key_Yes (in any order, but these might have the same problems as the Qt context keys)

The question is, are any of those keys picked up by default SDL? I somehow feel they aren't. We want this to work on stock SDL so that people could use custom distributions without having to bother with patching their SDL libs.

Just want to ask what is the rational behind making the action buttons the numbers 1-4? (or 0-3)?
Are these number used often in any application?

No real reason, just random keys not used by keypad.
I do agree non-printing keys would probably be better, but we need them to be picked by as many apps possible, so that things work without patching.

 

[Pickle]

I do agree non-printing keys would probably be better, but we need them to be picked by as many apps possible, so that things work without patching.

What about pageup, pagedown, home, end?

 

[dflemstr]

I do agree non-printing keys would probably be better, but we need them to be picked by as many apps possible, so that things work without patching.

What about pageup, pagedown, home, end?

Those are also picked up by various widgets, especially text fields as you might imagine.

*However*, if you combine those with e.g. Meta, it should work (but if we use modifier keys, Meta+F21-F24 could work as well).
SDL defines Meta as SDLK_LMETA or SDLK_RMETA respectively.
Heck, with Meta, an option would be to use Meta+1-3 or Meta+ABXY...
Is Meta ("Windows key") already allocated or can it be used?

Also, sorry for spamming this thread but it turns out that I've stumbled into exactly this problem (which was only theoretical at first) in an application I've written and I'd like to move on.

 

[Sphinxter]

Yes, but sadly, if I deploy an application as a PND, that PND has no possibility of invoking xmodmap...

I would have to blow my brains out if I wasn't clever enough to work around that. A user is launching your program, think hard, doesn't matter where it's stored or how they came to execute it. Hint; The user has no clue whatsoever if he's launching an elf or a script wrapping one or several.

 

[dflemstr]

Yes, but sadly, if I deploy an application as a PND, that PND has no possibility of invoking xmodmap...

I would have to blow my brains out if I wasn't clever enough to work around that. A user is launching your program, think hard, doesn't matter where it's stored or how they came to execute it. Hint; The user has no clue whatsoever if he's launching an elf or a script wrapping one or several.

You're assuming that you can limit the effects of xmodmap to only one application, which I'm not assuming since that's simply not the case.

I can't, via the usual PND invocation mechanism, change the key map for only my own application. If I had had more power, like being able to change the PND mount location and to redirect some X messages, it *would* be possible with an emulated nested X server...

But the simple solution will always be to change the default key mappings to something better, so that everybody can use them.

Now stop trolling

 

[notaz]

*However*, if you combine those with e.g. Meta, it should work (but if we use modifier keys, Meta+F21-F24 could work as well).
SDL defines Meta as SDLK_LMETA or SDLK_RMETA respectively.
Heck, with Meta, an option would be to use Meta+1-3 or Meta+ABXY...
Is Meta ("Windows key") already allocated or can it be used?

You can't return combos from kernel, although maybe that could be set in default userspace map. Meta keys are free, but they modify behavior of other keys, which isn't something everyone would expect from ABXY.