<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
print "Hello world!"<br>
<br>
I have made a version of the Read activity that supports navigation and
control with the gamepad, and has a few new features and improvements. <br>
The main problem is getting the two gamepads to send unique keycodes
that are not the numeric keypad arrow keys it currently sends (because
those are already bound to functions that don't do the appropriate
thing). <br>
The problem right now is that somebody needs to run the command "chmod
a+rwx /dev/input/event1" to give Python the permission to perform the
ioctl that remaps the keys. <br>
The solution to that problem is to decide on a standard set of keycodes
and have the operating system set them when it boots. <br>
I have tried several sets of keycodes, unsuccessfully. The higher
keycodes with numbers >512 never seem to make it to the X server. <br>
I tried using the keycodes for the higher numbered function keys
(KEY_F13 [183] - KEY_F20 [190]), which made it to the X server, but all
report X keycodes 0. <br>
There may be some magic that needs to be done in the /etc/X11/xorg.conf
file to admit those keycodes, or maybe some other arcane X server
configuration. <br>
So for now I am mapping to the letters "esdx" and "ijkm" to test out
the gamepad code until the OLPC has a fixed set of distinguishable
keypad keycodes. <br>
It will be very nice to have a gamepad text input method like
triggerfinger or dasher, to input real text in book mode! <br>
<br>
The next issue is rotation. I have made the activity respond to top
level window resize events by running "xrandr" to figure out which
direction the screen is rotated. <br>
Then it remaps the behaviors it assigns to the gamepads according to
the screen rotation. <br>
I think screen rotation should be handled by the application, not the
operating system, because in some cases the application might want to
associate commands with the LABELS of the gamepad keys instead of the
DIRECTIONS of the keys, so it would not want to rotate their meaning. <br>
For example, a tic-tac-toe game that wanted to use X for X and O for O
would not want to remap the keys on screen rotation! (Admittedly
contrived, but hey it's a popular game!) c(-;<br>
It would be great if there were a way to find out the screen rotation
via dbus. Maybe there is but I just haven't figured it out yet. Could
we add that, if it's not yet supported, please? <br>
<br>
Also, I wrote some stuff in the comments of the bug about the screen
rotation button: it's waaaaay too easy to rotate the screen
accidentally (not to mention turn the machine off accidentally,
ESPECIALLY when the screen is upside down and you reach for what you
think is the rotation button!!!)... <br>
I propose that both the screen rotation button and the power button
simply pop up big fat obvious dialogs that pop down and do nothing if
you press the button again, but require you to either press and hold
the button, or press another button (like the arrow keys) to actually
rotate the screen or power the system down.<br>
That will let users rotate the screen absolutely in one shot with the
arrow keys without going through all the intermediate rotations. <br>
Rotating is extremely expensive because it laboriously repaints the
entire screen, requiring the application to do all kinds of memory
allocation of giant page sized double buffers. So it should be very
hard to do it accidentally, while right now it's very hard not to do it
accidentally. <br>
Of course the consequences of accidentally shutting the system down
with a mere press of the button are much worse, so the same thing goes
tenfold for the power button! <br>
Kids will naturally go straight for the buttons on the screen and press
them many times in a row, so that should not cause any harm, delay or
distress. <br>
<br>
See: Rotating in reverse and/or better feedback for the rotate button<br>
<a class="moz-txt-link-freetext" href="http://dev.laptop.org/ticket/1049">http://dev.laptop.org/ticket/1049</a><br>
<br>
Also: Rotate handheld keys with screen<br>
<a class="moz-txt-link-freetext" href="http://dev.laptop.org/ticket/1443">http://dev.laptop.org/ticket/1443</a><br>
<br>
I decided to use the directional arrows for scrolling withing the page
selected, for when the entire page doesn't fit on the screen, or when
you're in continuous mode. <br>
That is because it's possible to press the directional arrows
diagonally, sending two keycodes at once, which makes sense for
directional scrolling commands but not for discrete commands. <br>
I used the other 4 button gamepad for discrete user interface
navigation commands. The left one and the right one move to the
previous and next selected button, in the same direction as they appear
on the screen.<br>
The bottom one activates the selected button. The top one goes to the
first button. These button mappings rotate with the screen
appropriately. <br>
<br>
I added a couple buttons for "first page" and "last page", and I also
added another toolbar of "View" commands, including sizing: fit width,
best fit, zoom in, zoom out; rotating: rotate left, rotate right; and
toggle buttons for display mode: dual page, continuous. <br>
When you use the gamepad to navigate between user interface buttons, it
wraps back and forth from end of one toolbar to the beginning of the
other. <br>
Gamepad navigation ignores the "activity" toolbar (for now). <br>
When you navigate with the gamepad, it warps the mouse cursor so it's
in the upper right corner of the button.<br>
I was hoping that warping the mouse into the button would be enough to
trigger the tooltip, but apparently not. <br>
I have been looking into how to pop up and tear down the tooltip under
program control without resorting to ugly hacks like faking events, but
I can't figure out a way to do it short of hacking the C code. <br>
Any suggestions? The other approach is not to use GTK tooltips at all,
and implement some nice Sugar tooltips that do the right thing, and
allow us to add more features like internationalized text (if that's
not already supported -- I dunno) and icons and animation and nice
stuff like that. <br>
The tooltips in gamepad mode should be smart enough to pop up when you
navigate to a button, then go away after a few seconds or after you use
the button.<br>
If you try to use a button that's "not allowed" (my alternative to
gtk's broken "not sensitive" which unfortunately disallows tooltips and
keyboard navigation), a tooltip should pop up explaining why the
operation is not allowed and what you can do to allow it. <br>
I have written all the code to set the tooltip to the most important
explanation when buttons are not allowed (i.e. the "back page" button
says "you need to load a document first" if no doc is loaded, or
"you're already at the first page" if you do havea doc but you're on
the first page [duh]). <br>
It's just that the tooltips don't display when I want them to, and
currently there is no visual indication that the button is not allowed.
I suppose the "not allowed" state should look just like the "not
sensitive" state, except that they let you navigate to the button with
the gamepad and display tooltips. <br>
<br>
I made a mixin class for widgets that includes intrinsics for gamepad
navigation, as well as some other useful stuff (like tooltips, and
disabling them without breaking keyboard navigation and tooltips). <br>
It also lets (no, requires!) you to associate an "info" dictionary with
each widget, that tells the system useful stuff about the widget,
including the icon, default tooltip, and whether or not it's accessible
via the game controller keypad. <br>
The toolbars have a method that returns a list of their navigable
widgets, and the application concatenates the widget lists of all
toolbars, handles keyboard events, and manages to navigate between
them. <br>
(This gamepad navigation is in place of the standard GTK tab/arrow key
navigation, which I consider flawed and too hard-wired to fix, so I
just programmed around it. For example, on top of the focus and tooltip
problems, when you arrow to a text field, you're stuck and can't arrow
out!) <br>
I made the search text field as well as the find next / previous
buttons inaccessibly from the game controllers, because currently there
is no way to input text when the keyboard is hidden. <br>
Once we have a gamepad based text input method we can hook that up to
the search field and enable it for navigation. <br>
<br>
I put in placeholder "programmer art" with text labels for the buttons
I added, which are ugly enough to remind everyone that we need real
icons, but I'm not a good enough artist to come up with appropriate
icons. <br>
<br>
One usability problem I noticed is with the toggle buttons: the "mouse
over" highlighting obscures (overrides, conflates, is the same as) the
highlighting that tells you
if the button is selected or not, so once you're pointing at the button
you have no idea about its current state, and no feedback after you
click it to change the state, that the state was actually changed
(modulo the actual effect of the button toggle on the application of
course). The "mouse over" highlighting should be orthogonal to and
composeable with the "checked" highlighting. Moving over the toggle
should activate the "mouse over" highlighting but not change the
"checked" highlighting. Pressing down and holding should keep the
"mouse over" highlighting and toggle the "selected" highlighing to
feedback that it will enter that state iff you release while still in
the button. If you move out of the button while holding down the mouse,
the "mouse over" should de-highlight and the "checked" should go back
to the previous state, to feedback that pressing down and moving out is
a no-op that cancels the toggle action, and nothing should change when
you release the button to toggle (but of course you should be able to
slide back in to resume the "mouse over" and "check toggled" state,
then release to toggle it. <br>
<br>
I heard a rumor that somebody had decided on some unique keycodes for
the gamepad. Is that true? What are they? Once I know, I'll put them
into the reader and put up a copy for people to try out. (Right now it
requires opening a shell and running chmod as root to get it to work,
which is kinda clumsy, but a great way to force kids to learn Linux,
you gotta admit.) <br>
<br>
-Don<br>
<br>
<br>
Zvi Devir wrote:
<blockquote cite="mid46477BBF.4090707@cs.technion.ac.il" type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
Devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Devel@lists.laptop.org">Devel@lists.laptop.org</a>
<a class="moz-txt-link-freetext" href="http://lists.laptop.org/listinfo/devel">http://lists.laptop.org/listinfo/devel</a>
</pre>
</blockquote>
<br>
</body>
</html>