Button Reassignment?

[anathema]

Just wondering if there is any way to repurpose the buttons on a K2i.

Just got mine, and I really like it so far, but the way I normally read in bed it is actually fairly uncomfortable.

I normally read laying on my right side with the ebook's flat right edge laying on the bed.

On my old Sony, the page buttons were on the bottom right and left, so I didn't have to have my hands underneath the reader holding/balancing it while I read, which I have to with the kindle.

Is there a way to repurpose the 'SYM' button or another in the area as another 'next page' button? This would basically solve the only gripe I have with it. I could swap it with the left 'next page' button (next page on the left is really weird to me anyways).

Or any other suggestions? Thanks.

[eboyhan]

Not at present. There is a KDK devkit currently in closed beta. Based on my reading of the documentation thus released, capturing button pushes and repurposing them should be possible for developers using the KDK.

[NiLuJe]

Right now you can send button event from a shell via usbnet. Pretty sure capturing/remapping might be too much to ask without the SDK though .

[pgf]

Originally Posted by NiLuJe

Right now you can send button event from a shell via usbnet. Pretty sure capturing/remapping might be too much to ask without the SDK though .

this is excellent news, to me, since my whole reason for wanting to jailbreak and run usbnet is to remotely trigger "next page" events. how does the script work? (i spotted uinput in someone's post with a list of loaded modules, so it was going to be the first thing i tried.)

[NiLuJe]

Can't remember the exact correct string, check the power test scripts somewhere in /test, there's multiple next/forward loop scripts.

EDIT: Huh. Terminal backlog FTW.

NextPage:

echo "send 124" > /proc/keypad

[pgf]

Originally Posted by NiLuJe

EDIT: Huh. Terminal backlog FTW.

NextPage:

echo "send 124" > /proc/keypad

thanks! perfect. just what i needed. between helping me find the right usbnetwork hack, and this, you've been very helpful. i appreciate it.

btw, poking around, i'm not convinced that remapping the keys wouldn't be possible. the keypad and 5-way both appear as /dev/input/event[01] devices. for some reason (not sure why) the uinput module is also present. /dev/input/uinput can be used to create a new /dev/input/eventN device and inject events to it.

so, it's possible to write a program which opens the /dev/input/event[01] devices, grabs them so no one else gets their input, massages the data, and reinjects into the input subsystem via uinput. the trick will then be getting whoever is watching /dev/input/event[01] currently to watch the new device(s) instead. depending on how those clients open the input devices, it might Just Work -- for instance, they might just enumerate and watch all button devices. (this is likely the case, since the keypad and 5way devices seem identical, other than name.)

the next problem is getting the new remapping program to run before whatever it is that reads the input devices, so that the devices are reinitialized before it starts. but i'm guessing that's possible as well.

i can point someone at code which does much of the above, for a quite different purpose, if they're interested.

[NiLuJe]

Good to know (I'm not familiar with the uinput module)!

If the framework itself is the only thing handling input events in the end, that shouldn't be too hard to implement. (That's what we do with fonts/ss, we setup things before the framework). If it's handled earlier/by low-level stuff, we'd have to dig a little bit deeper.

(If the code is looking for the input event devices file specifically by name, we can always tweak the udev rules).

If something's grabbing the input devices in userland, lsof will tell what process is handling things.

[pgf]

in the meantime, do you happen to know if it's possible to inject multi-key keypad combinations via /proc/keypad? e.g., "alt-shift-G"? i can get a shift with an echo of 42 before the echo of the G code, but i can't seem to get an Alt.

[NiLuJe]

No idea, sorry, I got the NextPage/PreviousPage from the power test scripts.

And I'm not familiar enough with the Linux event input interface to know if you could somehow get the correct code by shutting down the framework (or whatever actually grabs the event device), and listening to it yourself.

Also not sure if the keyCode reported in the logs when using ;debugOn would actually help:

D TextField:DebugInfo::KEY:java.awt.event.KeyEvent[KEY_PRESSED,keyCode=16,keyChar='ï¿¿',modifiers=Shift,extModifiers=Shift] on com.lab126.mario.DisplayServiceImpl$1[null]

(That's supposed to be a SHIFT keypress).

[pgf]

thanks. hadn't seen that log info yet.

fyi -- if you do "hexdump -C /dev/input/event0" while pressing keys, they keycode that you pass to "send DDD >/proc/keypad) appears in hex as byte 10 (counting from 0). NextPage is the 7c value in the following, where the first line is the press, and the second is the release:

00000000 aa de 4d 4c 9f 24 0a 00 01 00 7c 00 01 00 00 00 |..ML.$....|.....|
00000010 aa de 4d 4c ba 31 0d 00 01 00 7c 00 00 00 00 00 |..ML.1....|.....|

(earlier bytes in the lines are timestamp and type information -- see linux/input.h)

in any case, i realized i don't need to inject those keytrokes, because one can grab a raw copy of the screen directly from /proc/eink_fb/virtual_fb.

[isotherm]

Originally Posted by NiLuJe

NextPage:

echo "send 124" > /proc/keypad

Don't forget if you want to press a button from the direction pad, output to /proc/fiveway instead of /proc/keypad.

You can get the keycodes by running waitforkey with noparameters from shell. Once a key is pressed, it will output two numbers. The first is the key number (e.g. 124 for next page); the second is the key state (0 = released, 1 = pressed, 2 = held). If you want, you can run waitforkey with a key number as the parameter (e.g. waitforkey 124) and it will keep waiting until that specific key is pressed. This doesn't help with remapping, but one can add new keyboard shortcuts...

[isotherm]

Sorry, edit time is already lapsed...

Actually, the original poster's question could be solved this way, since the SYM key doesn't do anything in plain reader mode. All you need is a script which executes the following in a continuous loop:

waitforkey 94
echo "send 124" > /proc/keypad

The problem with this is that it always converts the SYM key into NEXT PAGE, even when you are trying to type symbols into the search field. A more elegant solution would need to provide a hotkey to enable/disable this feature on demand (or a way to detect what the current UI action is)...

[drauger]

Could anybody advice a solution to bind custom script launch to key or key combination on K4? It wold be quite comfortable to rotate screen via long kepress or pressing 2 buttons simultaneously...

[Rom1]

How could we get the touch screen "tap" information and send it as a next page ?

[geekmaster]

Originally Posted by pgf

thanks. hadn't seen that log info yet.

fyi -- if you do "hexdump -C /dev/input/event0" while pressing keys, they keycode that you pass to "send DDD >/proc/keypad) appears in hex as byte 10 (counting from 0). NextPage is the 7c value in the following, where the first line is the press, and the second is the release:

(earlier bytes in the lines are timestamp and type information -- see linux/input.h)

in any case, i realized i don't need to inject those keytrokes, because one can grab a raw copy of the screen directly from /proc/eink_fb/virtual_fb.

You can also do "waitforkey". I do that in a "while" loop to get a bunch of keys. Simpler output.