eBook Reader user interface

[Zephaniah E. Hull]

A few notations, due to the issues involved with xf86-input-evdev (and
xorg/linux input in general).

On Fri, May 04, 2007 at 11:08:55PM -0700, Don Hopkins wrote:
...
>       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. 

Correct, we just don't handle those well at the moment, and would show
up as mouse buttons if we did.

(This may actually be preferable if done right, but.)

...

> 	  Use keys ("KEY_*") instead of buttons ("BTN_*"), since they
> 	  seem to work better.

See above, ask if you'd like more details on the use of non-core-pointer
button devices and how we might use those here.

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

NAK.  Until we move to the input-hotplug xserver, and the
xf86-input-evdev for that (for former has not been released, the latter
doesn't have much of this done yet) there is simply not support for keys
above 247 or 248 (I forget which, but 0x100 - 8 or - 9).

This is due to X11 protocol restrictions which simply don't allow keys
above 255, and the fact that the first 8 keys are not valid.

In the input-hotplug xserver we have some ways we can hack around that,
but nothing that can be easily back ported.

There is simply not room below 255 that we are going to get allocated to
XO specific keys either, so in the short to medium term we're going to
have to find another solution.

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

Alternatively, a simple tool that takes arguments, or a config file with
comments, would also be a good choice.  But I have nothing to say
against Python for this usage if it's clean enough.


That's all that I have to say as far as input stuff goes, I may comment
on the ebook specific side of things in another email or forum though.

Zephaniah E. Hull.

-- 
	  1024D/E65A7801 Zephaniah E. Hull <warp at aehallh.com>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

I've always taken the position that if you can't find anything bad to
say about a language or an operating system then you don't understand
it. I also agree with you about the advocacy. AHS. ASS.
  -- Shmuel (Seymour J.) Metz in the Scary Devil Monastery.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.laptop.org/pipermail/devel/attachments/20070505/5bef0069/attachment.sig>