MobileRead Forums - View Single Post - Kindle input event device file names can CHANGE.

geekmaster · 03-12-2012, 01:58 PM

I am currently getting the path to the zforce events this way:

T=$(for i in /dev/input/event*;do evtest info $i|grep zforce>/dev/null&&echo $i&&break;done)

If I change it to use your suggestion, it makes the command line longer, but no longer requires calling the built-in evtest program:

T=$(for i in /sys/class/input/event*;do grep zforce $i/device/name>/dev/null&&echo $i&&break;done)

I then use it like this:

script -c "hexdump $T" /dev/null | while...

The script command forces unbuffered STDOUT so I can sense touches immediately instead of waiting for enough extra touch data to trigger a full buffer. It is annoying to need to press an onscreen keyboard button multiple times to get any action, then have those multiple touches come out in a batch.

The complication is things in a piped while loop run in a separate process, and when my "Exit" button is touched in the inner do loop, an "exit" or "return" command only acts like a break, exiting only to the done. Setting DONE=1 to break the while (while [[ $DONE -ne 1 ]]; do) still waits for more output from hexdump before checking the flag, and you need to touch the screen to create that output. So I ended up doing the "self-terminating script" thing, by parsing "ps a" and killing the first "hexdump $T" process. If you kill the "script -c" your terminal goes bonkers, but it dies cleanly by killing its child process.

My "solution" may be crude but it will work until I find something better.

In my previous incarnation of my "onscreen keyboard" program, I just grabbed 64 bytes of touch event data (minimum guaranteed size), but that was (infrequently) missing the Y coordinate if a "sync" packet got squeezed in there, resulting in a lost keypress.

Now I do all processing inside the inner subprocess loop, but I wanted to exit without needed two touches, and hence the "ps kill" hack.

Anyway, when people suggest that I try things that don't actually work in the environment I described (diags bootmode), it wastes my time after I try it and find out I just wasted my time, and I have very little of that to spare.

03-12-2012, 01:58 PM	#21
geekmaster Carpe diem, c'est la vie. Posts: 6,433 Karma: 10773670 Join Date: Nov 2011 Location: Multiverse 6627A Device: K1 to PW3	I am currently getting the path to the zforce events this way: *T=$(for i in /dev/input/event;do evtest info $i\|grep zforce>/dev/null&&echo $i&&break;done) If I change it to use your suggestion, it makes the command line longer, but no longer requires calling the built-in evtest program: T=$(for i in /sys/class/input/event;do grep zforce $i/device/name>/dev/null&&echo $i&&break;done)* I then use it like this: script -c "hexdump $T" /dev/null \| while... The script command forces unbuffered STDOUT so I can sense touches immediately instead of waiting for enough extra touch data to trigger a full buffer. It is annoying to need to press an onscreen keyboard button multiple times to get any action, then have those multiple touches come out in a batch. The complication is things in a piped while loop run in a separate process, and when my "Exit" button is touched in the inner do loop, an "exit" or "return" command only acts like a break, exiting only to the done. Setting DONE=1 to break the while (while [[ $DONE -ne 1 ]]; do) still waits for more output from hexdump before checking the flag, and you need to touch the screen to create that output. So I ended up doing the "self-terminating script" thing, by parsing "ps a" and killing the first "hexdump $T" process. If you kill the "script -c" your terminal goes bonkers, but it dies cleanly by killing its child process. My "solution" may be crude but it will work until I find something better. In my previous incarnation of my "onscreen keyboard" program, I just grabbed 64 bytes of touch event data (minimum guaranteed size), but that was (infrequently) missing the Y coordinate if a "sync" packet got squeezed in there, resulting in a lost keypress. Now I do all processing inside the inner subprocess loop, but I wanted to exit without needed two touches, and hence the "ps kill" hack. Anyway, when people suggest that I try things that don't actually work in the environment I described (diags bootmode), it wastes my time after I try it and find out I just wasted my time, and I have very little of that to spare.