I have been collecting a few (more than a few) usability bugs and UI
suggestions, which will hopefully be compiled to a list next month.
In the meanwhile, I would like to share a couple of ideas regarding the
mapping of the gamepad keys [which I hope won't state the obvious too much].
Currently, the UP/DOWN/LEFT/RIGHT keys have a fixed functionality
regardless of the screen orientation. This isn't a correct logic, as the
expected functionality changes according to the current orientation. I
guess the easiest way to implement this kind of behavior would be using
a smart key mapping mechanism in X.
Another thought -- the current input method treats those keys as
direction keys. However, a better input method may be emulating the
functionality of the mouse (touch pad) using the gamepad keys. In tablet
mode this can really improve the user experience.
Just my $0.04.
Zvi
Don Hopkins wrote:
> Goal for improving the eBook reader user interface:
>
> I've been doing some exploratory programming with GTK and Sugar,
> trying to improve the user interface of the eBook reader, and make
> it useable in book mode with the gamepad.
>
> + Support the game keypads in eBook mode.
>
> + Low level game keypad support
>
> Need to remap low level keyboard scan codes to Linux keyboard codes.
>
> The setolpckeys.c program remaps the keys and gamepad buttons.
>
> Currently it maps both gamepads to the numeric keypad keys (KEY_KP8,
> etc),
> which the X server and GDK translates to directional keys (GDK_Up, etc).
>
> I tried to map them to buttons (BTN_A, etc), but the X server seems
> to ignore keycodes in that range.
>
> The xorg.conf file has a keycode mask that looked like it might help,
> but I couldn't get it to work.
>
> Need to have unique keycodes reported for each of the two gamepads,
> which are not the same as any keyboard keys, without any predefined
> meanings
> like arrow keys have.
>
> Need to define special purpose keycodes just for the OLPC gamepad,
> instead of trying to reuse existing but not appropriate keycodes.
>
> What is the process for defining new keycodes in <linux/input.h>?
>
> Here's my strawman proposal for some new keycodes.
>
> Use keys ("KEY_*") instead of buttons ("BTN_*"), since they
> seem to work better.
>
> The 0x1b* range seems to be unused in <linux/input.h>,
> and it's between other groups of keycodes, so I'll
> propose using that range for the OLPC.
>
> The UP/DOWN/LEFT/RIGHT keys correspond to the directional
> keypad.
>
> #define KEY_XO_GAMEPAD_UP 0x1b0
> #define KEY_XO_GAMEPAD_DOWN 0x1b1
> #define KEY_XO_GAMEPAD_LEFT 0x1b2
> #define KEY_XO_GAMEPAD_RIGHT 0x1b3
>
> The NORTH/SOUTH/EAST/WEST keys correspond to the other
> buttons. Those names are agnostic to the button labels,
> which may change from the current Playstation buttons
> (X/O/Triangle/Square). Can anyone suggest better names for
> the four buttons on the right?
>
> #define KEY_XO_GAMEPAD_NORTH 0x1b4
> #define KEY_XO_GAMEPAD_SOUTH 0x1b5
> #define KEY_XO_GAMEPAD_EAST 0x1b6
> #define KEY_XO_GAMEPAD_WEST 0x1b7
>
> While we're at it, we could define keycodes for the other
> OLPC buttons and switches on the screen. I think there are
> some other sensor switches that could generate keycodes,
> like opening the screen, rotating it around, and putting it
> into book mode, so I will make some guesses at names for
> them, just to get the discussion rolling.
>
> #define KEY_XO_SCREEN_ROTATE 0x1b8
> #define KEY_XO_SCREEN_POWER 0x1b9
> #define KEY_XO_SCREEN_OPEN 0x1ba
> #define KEY_XO_SCREEN_CLOSE 0x1bb
> #define KEY_XO_SCREEN_IN 0x1bc
> #define KEY_XO_SCREEN_OUT 0x1bd
>
> Is there an exhaustive list of all buttons and switches and
> events on the OLPC? Are any more planned? Which ones should
> be assigned keycodes?
>
> Rewrote setolpckeys.c code in Python (just uses ioctl, but needs to
> know keycodes).
> Writing utilities like that in Python instead of C makes it easier to
> reconfigure the keys on the OLPC without a C compiler.
>
_______________________________________________
Devel mailing list
[email protected]
http://lists.laptop.org/listinfo/devel
