eBook Reader user interface

[Zvi Devir]

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. 
>