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_DOWN0x1b1
#define KEY_XO_GAMEPAD_LEFT0x1b2
#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_EAST0x1b6
#define KEY_XO_GAMEPAD_WEST0x1b7
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_POWER0x1b9
#define KEY_XO_SCREEN_OPEN 0x1ba
#define KEY_XO_SCREEN_CLOSE0x1bb
#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
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
