Kindle input event device file names can CHANGE.

[geekmaster]

I have been doing most of my native mode program and script testing in diags SSH recently, because on the k4 and touch, there is a "Lock to HOME Button" menu item, and I can safely test touchscreen events there without accidentally pressing active buttons or menu items on the window hidden below my app.

I discovered that when I boot my touch to main and launch SSH using yifanlu's launcher menu, the touchscreen events are at /dev/input/event4 like I documented some time ago in mobileread posts.

But when I boot diags and run SSH from the "Enable USBnet" menu, the touchscreen events are at /dev/input/event3 like I have been using in my recent scripts: touchpaint (touchscreen ascii paint), and oskb (onscreen keyboard).

This means that even on a single device, we cannot trust input device filenames. We must follow the examples for linux event processing shown elsewhere on the net, where those examples scan ALL input devices, looking for one with PROPERTIES that match the device that we want to use.

The "correct" way to open an input event device must first FIND that device, making no assumptions as we have been doing here (including other event processing such as in the myts onscreen terminal).

We must NOT just ASSUME that a device has a fixed file name, even on a kindle touch.

And while discussing linux devices, perhaps a native mode app can easily control framework menus and kindlets with this gizmo daemon:

http://gizmod.sourceforge.net/

[ixtab]

Some of the event devices (unfortunately not all, and probably not those that you want ) also have symbolic names:

[root@kindle input]# ls -la
drwxr-xr-x    3 root     root           160 Mar 10 18:15 .
drwxr-xr-x   16 root     root          1120 Mar 11 15:15 ..
drwxr-xr-x    2 root     root           100 Mar 10 18:15 by-path
crw-r-----    1 root     root       13,  64 Mar 10 18:15 event0
crw-r-----    1 root     root       13,  65 Mar 10 18:15 event1
crw-r-----    1 root     root       13,  66 Mar 10 18:15 event2
crw-r-----    1 root     root       13,  67 Mar 10 18:15 event3
crw-r-----    1 root     root       13,  68 Mar 10 18:15 event4
[root@kindle input]# ls -la by-path/
drwxr-xr-x    2 root     root           100 Mar 10 18:15 .
drwxr-xr-x    3 root     root           160 Mar 10 18:15 ..
lrwxrwxrwx    1 root     root             9 Mar 10 18:15 platform-soc-audio.1-event -> ../event1
lrwxrwxrwx    1 root     root             9 Mar 10 18:15 platform-whitney-button-event -> ../event2
lrwxrwxrwx    1 root     root             9 Mar 10 18:15 platform-zforce.0-event -> ../event4

Still, that would mean only figuring out what the remaining two are, instead of guessing what all 5 are.

[hawhill]

Edit: the following was directed at OP, was too slow to type :-)

Quite right, but, err, *cough*, you can just open every input device that comes across. In most cases, that is. You get input events, and frankly probably don't care if that's from the touchscreen or an USB digitizer tablet that some mad-minded hacker managed to connect to the kindle...

There would however be reasons from a security standpoint against this. But there are much, much bigger security flaws to fix first (thinking of my K3 running everything and the kitchen sink as root, probably just because system integrators were lazy).

[geekmaster]

Originally Posted by ixtab

Some of the event devices (unfortunately not all, and probably not those that you want ) also have symbolic names:

[root@kindle input]# ls -la
drwxr-xr-x    3 root     root           160 Mar 10 18:15 .
drwxr-xr-x   16 root     root          1120 Mar 11 15:15 ..
drwxr-xr-x    2 root     root           100 Mar 10 18:15 by-path
crw-r-----    1 root     root       13,  64 Mar 10 18:15 event0
crw-r-----    1 root     root       13,  65 Mar 10 18:15 event1
crw-r-----    1 root     root       13,  66 Mar 10 18:15 event2
crw-r-----    1 root     root       13,  67 Mar 10 18:15 event3
crw-r-----    1 root     root       13,  68 Mar 10 18:15 event4
[root@kindle input]# ls -la by-path/
drwxr-xr-x    2 root     root           100 Mar 10 18:15 .
drwxr-xr-x    3 root     root           160 Mar 10 18:15 ..
lrwxrwxrwx    1 root     root             9 Mar 10 18:15 platform-soc-audio.1-event -> ../event1
lrwxrwxrwx    1 root     root             9 Mar 10 18:15 platform-whitney-button-event -> ../event2
lrwxrwxrwx    1 root     root             9 Mar 10 18:15 platform-zforce.0-event -> ../event4

Still, that would mean only figuring out what the remaining two are, instead of guessing what all 5 are.

I want my code to work on different firmware versions, booted from either partition, on any eInk-based kindle.

Those "by-path" names (such as "whitney") look rather device-specific. For all we *should* care, that HOME button on a touch is just a keyboard button.

I am a firm believer in the KISS principle:
http://en.wikipedia.org/wiki/KISS_principle

But we also need to follow the Einstein principle too:
http://c2.com/cgi/wiki?EinsteinPrinciple

Perhaps I just want my code to be TOO simple.

[ixtab]

Originally Posted by geekmaster

And while discussing linux devices, perhaps a native mode app can easily control framework menus and kindlets with this gizmo daemon:

http://gizmod.sourceforge.net/

I found a use case for the z-force input device in conjunction with gizmod: "Violently shake the device to reboot".

[geekmaster]

Originally Posted by hawhill

...
Quite right, but, err, *cough*, you can just open every input device that comes across. In most cases, that is. You get input events, and frankly probably don't care if that's from the touchscreen or an USB digitizer tablet that some mad-minded hacker managed to connect to the kindle...
...

But is it safe to ASSUME that device event codes will be "globally unique" across devices, so we can pool our device events and process them in a generic event handler? (...or, did I misinterpret where you were going with this?)

Although we may WANT to process all device events (including the "headphone insertion and removal" events at the "headphone jack" device), I do not believe that it is a safe to assume that we can identify an event as coming from a device without knowing WHICH device that event came from.

Here is what I mean about the "correct" way to find a device with the properties we want:
http://www.linuxjournal.com/article/6429?page=0,1

[geekmaster]

Originally Posted by ixtab

I found a use case for the z-force input device in conjunction with gizmod: "Violently shake the device to reboot".

z-force? That is what I meant when I suggested that these device-specific names might not be trustworthy. You might think that having "force" in the name makes it the accelerometer, but it turns out that this is the name of the touchscreen device.

The accelerometer is a different device (which CAN detect violent shaking, by the way, so your IDEA is sound).

We just need a reliable method of detecting a device REGARDLESS of its specific device file name, or its descriptive name either. Only its PROPERTIES are important.

EDIT: Without actually doing the research, I think we can guess why they called the touchscreen device "z-force"... When you apply force, your finger tip deforms, blocking more light, so you CAN indirectly determine the amount of force being applied to the touchscreen.

There is a nifty little toy built into the touch that will demonstrate this (and what I used to prove that you can determine the diameter of a coin placed on the touchscreen):

mount /dev/mmcblk0p2 /mnt/mmc
/mnt/mmc/usr/local/bin/zforcediag

This cool little tool shows how much light your finger is blocking from the X and Y light sensors. It also demonstrates that you can interpolate much higher resolution than expected by comparing the ratio of light blockage from the outer partially blocked sensors. You can see in the kindle touch teardown photos that there are not many LEDs or photosensors on the touch PCB, so analog interpolation is needed to get the 4096x4096 high resolution we get from this device. Also, it is interesting to see that we can read the touchscreen at a lower level (individual LEDs) than is provided by input device events.

[geekmaster]

A bit off-topic, but while looking for the code I saw before that scans devices to find the one you want, I think I discovered why I respond defensively when certain people in this forum question the accuracy of my facts, without supplying any of their own facts or references:

http://c2.com/cgi/wiki?AggressiveListening

I think that some replies to my posts in other threads fall into the "aggressive listening" category, which tends to irritate me in ways that I cannot easily describe.

You may have seen posts where I went a bit overboard on my self-defensive replies (then later removed a lot of the "self-justification" content). For me, "false accusations" have always been a "hot button". Sorry... At least now I know why (read the above link).


EDIT: Amazing what you find accidentally, while looking for something else, isn't it? I think Google found that one because it contains "we pass the contents of the event with the notification".

[geekmaster]

Originally Posted by hawhill

But there are much, much bigger security flaws to fix first (thinking of my K3 running everything and the kitchen sink as root, probably just because system integrators were lazy).

The real flaws are PEBKAC related, and software security does not matter if you have physical access, even for a brief moment: http://hakshop.myshopify.com/products/usb-rubber-ducky

When you plug a "USB Rubber Ducky" into a USB port on a "victim" computer, the computer OS thinks it is a new "USB keyboard", so even without permission, it just starts "typing stuff" for you...

[geekmaster]

cat /proc/bus/input/devices

Interestingly, when in diags bootmode, the contents of /etc/xorg.conf are not correct...

[geekmaster]

Here is some "evtest" output from touch diags SSH:

PHP Code:

# for i in /dev/input/*;do evtest info $i;echo =============================;done
Input driver version is 1.0.0
Input device ID: bus 0x18 vendor 0x0 product 0x0 version 0x0
Input device name: "WM8962 Beep Generator"
Supported events:
  Event type 0 (Sync)
  Event type 18 (Sound)
    Event code 1 (Bell)
    Event code 2 (Tone)
=============================
Input driver version is 1.0.0
Input device ID: bus 0x0 vendor 0x0 product 0x0 version 0x0
Input device name: "imx-yoshi Headset"
Supported events:
  Event type 0 (Sync)
  Event type 1 (Key)
    Event code 256 (Btn0)
  Event type 5 (?)
    Event code 4 (?)
=============================
Input driver version is 1.0.0
Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100
Input device name: "whitney-button"
Supported events:
  Event type 0 (Sync)
  Event type 1 (Key)
    Event code 102 (Home)
=============================
Input driver version is 1.0.0
Input device ID: bus 0x0 vendor 0x0 product 0x0 version 0x0
Input device name: "zforce"
Supported events:
  Event type 0 (Sync)
  Event type 1 (Key)
    Event code 0 (Reserved)
    Event code 1 (Esc)
    Event code 325 (ToolFinger)
    Event code 330 (Touch)
    Event code 333 (Tool Doubletap)
    Event code 334 (Tool Tripletap)
  Event type 3 (Absolute)
    Event code 0 (X)
      Value      0
      Min        0
      Max     4095
    Event code 1 (Y)
      Value      0
      Min        0
      Max     4095
    Event code 47 (MT Slot)
      Value      0
      Min        0
      Max        1
    Event code 53 (MT X)
      Value      0
      Min        0
      Max     4095
    Event code 54 (MT Y)
      Value      0
      Min        0
      Max     4095
    Event code 57 (MT Tracking ID)
      Value      0
      Min        0
      Max      255
=============================
Input driver version is 1.0.0
Input device ID: bus 0x19 vendor 0x0 product 0x0 version 0x0
Input device name: "mxckpd"
Supported events:
  Event type 0 (Sync)
  Event type 1 (Key)
    Event code 0 (Reserved)
    Event code 2 (1)
    Event code 3 (2)
    Event code 4 (3)
    Event code 5 (4)
    Event code 6 (5)
    Event code 7 (6)
    Event code 8 (7)
    Event code 9 (8)
    Event code 10 (9)
    Event code 11 (0)
    Event code 14 (Backspace)
    Event code 16 (Q)
    Event code 17 (W)
    Event code 18 (E)
    Event code 19 (R)
    Event code 20 (T)
    Event code 21 (Y)
    Event code 22 (U)
    Event code 23 (I)
    Event code 24 (O)
    Event code 25 (P)
    Event code 28 (Enter)
    Event code 30 (A)
    Event code 31 (S)
    Event code 32 (D)
    Event code 33 (F)
    Event code 34 (G)
    Event code 35 (H)
    Event code 36 (J)
    Event code 37 (K)
    Event code 38 (L)
    Event code 42 (LeftShift)
    Event code 44 (Z)
    Event code 45 (X)
    Event code 46 (C)
    Event code 47 (V)
    Event code 48 (B)
    Event code 49 (N)
    Event code 50 (M)
    Event code 52 (Dot)
    Event code 56 (LeftAlt)
    Event code 57 (Space)
    Event code 102 (Home)
    Event code 104 (PageUp)
    Event code 109 (PageDown)
    Event code 126 (RightMeta)
    Event code 139 (Menu)
    Event code 158 (Back)
    Event code 190 (F20)
    Event code 191 (F21)
    Event code 193 (F23)
  Event type 20 (Repeat)
=============================
Input driver version is 1.0.0
Input device ID: bus 0x18 vendor 0x0 product 0x0 version 0x0
Input device name: "mma8453"
Supported events:
  Event type 0 (Sync)
  Event type 1 (Key)
    Event code 59 (F1)
    Event code 60 (F2)
    Event code 61 (F3)
    Event code 62 (F4)
=============================
# 


Now I am curious about that "mxckpd" device driver that they bothered to load on the touch.

[hawhill]

Originally Posted by geekmaster

Now I am curious about that "mxckpd" device driver that they bothered to load on the touch.

I think it's a userland interface to re-insert key events into kernel space. But just guessing here. Depending on preferences, it is the easiest approach to implement a software-keyboard that ought to be working on a not-yet-fully-determined target framework. It won't even be X-specific then, you could implement the software keyboard as a raw-framebuffer application and generate events for all UI things on the device.

What I meant above, BTW, is to listen for all events (on all devices) and then handle the events you care about. E.g. keypresses, touchscreen events etc. Trust them to generate certain key codes/event values, don't bother with addressing.

Of course you're right that physical access is always the biggest threat to the security of a computer. Well, but the physical access path isn't something I would worry about on my Kindle. If someone took it from me, I'm not trusting it anymore as a computing platform anyway. And don't think you could lure me into soldering a connection cable to a 1V8 TTL controlled rubberduck on my ebook reader :-P

[geekmaster]

Originally Posted by hawhill

And don't think you could lure me into soldering a connection cable to a 1V8 TTL controlled rubberduck on my ebook reader :-P

Yeah, well how about a "jailbreak" or "recovery" program that installs a "rubber ducky" USB gadget on your kindle, to hijack any host PC that falls victim to the kindle USB cable?

Beware kindle hacks you did not compile from your own source code.

[ixtab]

Originally Posted by geekmaster

Yeah, well how about a "jailbreak" or "recovery" program that installs a "rubber ducky" USB gadget on your kindle, to hijack any host PC that falls victim to the kindle USB cable?

Beware kindle hacks you did not compile from your own source code.

Well, guess why I'm releasing only .bin files







... just kidding. But it sure is a valid point.

[geekmaster]

Originally Posted by ixtab

Well, guess why I'm releasing only .bin files
... just kidding. But it sure is a valid point.

Well, along with the "fully loaded" binary, you *could* release the source code for a version *without* the extra payload goodies, just to lure people into *thinking* it is safe and no need to recompile themselves.

Some years ago, the US military discovered that the standard C compiler distributed with Unix systems contained binary code that was NOT in its source code, even after compiling it yourself. Further study showed that the C compiler recognized when it compiled itself, and injected that extra payload into the next version. It had been this way since the early days. But the *real* payload was that it ALSO recognized when it was compiling the login application, and it inserted a secret backdoor login account and password that was not in the passwd file.

Some of the well-known "big names" in the Unix world had to appologize to the US military and promise to never do it again.