OTG Keyboard Support - in progress

[glasnost]

Objective

*Full USB OTG keyboard support so that my kindle can be used as a long-lasting outdoor writing device.

Status

Solution (inelegant, kludged together, but working for now):
lucida's usb otg kindlet (start otg service, then plug in hub/keyboard)
coplate's makexconfig copied to /var/local/kindlekbd per knc1 and:

# mntroot rw
# mount -o bind /var/local/kindlekbd /etc/upstart/makexconfig
# mntroot ro
# restart x

*work in progress

Current (known) problems & Next Steps

* external battery does not power the hub, so writing time will be shortened
* automate all this in a KUAL extension (probably just modifying lucida's scripts)
* learn more about why my earlier attempts failed in such an odd manner

Hardware/software

Kindle PW3, FW 5.8.1
Jailbroken following knc1's post
KUAL
USB OTG Mouse support by lucida and team
uGreen Powered USB OTG hub
Storm Quickfire Rapid non-LED keyboard
10000mA battery

Earlier aspects of post, put in spoiler b/c I can't seem to format a strikethrough font ;-)

Spoiler:

Setup

Installing lucida's Kindlet was simple and straightforward - put the decompressed files in /mnt/us/extensions/

From the KUAL extension, I started the OTG module/service

Checking that the modules were added to recognize the device:

#lsmod
...
mousedev                9072  1
usbhid                 18029  0
hid                    67608  1 usbhid

I plug the power into the hub & turn it on; plug the hub into the kindle & see the blue led light up; and plug the keyboard into the hub.

Next to verify that the OS sees the device:

#dmesg | grep -i input
[  263.772366] input: CM Storm QuickFire Rapid keyboard as /devices/platform/fsl-ehci.0/usb1/1-1/1-1.4/1-1.4:1.0/input/input2
[  263.773820] generic-usb 0003:2516:0004.0001: input: USB HID v1.10 Keyboard [CM Storm QuickFire Rapid keyboard] on usb-fsl-ehci.0-1.4/input0
[  263.819798] input: CM Storm QuickFire Rapid keyboard as /devices/platform/fsl-ehci.0/usb1/1-1/1-1.4/1-1.4:1.1/input/input3
[  263.828242] generic-usb 0003:2516:0004.0002: input: USB HID v1.10 Device [CM Storm QuickFire Rapid keyboard] on usb-fsl-ehci.0-1.4/input1

everything is registered properly, so I verify that input will work:

#evtest /dev/input/input2

List of supported events i.e. keys I can press
Testing ... (interrupt to exit) 
Q
Event: time 1472263694.041622, type 4 (Misc), code 4 (ScanCode), value 70014
Event: time 1472263694.041639, type 1 (Key), code 16 (Q), value 1
Event: time 1472263694.041647, -------------- Report Sync ------------
Event: time 1472263694.138610, type 4 (Misc), code 4 (ScanCode), value 70014
Event: time 1472263694.138623, type 1 (Key), code 16 (Q), value 0
Event: time 1472263694.138629, -------------- Report Sync ------------
ctrl C

Looks good.

Next Steps

I suspect the easiest path is to simply create a custom xorg.conf file that defines this input device as a keyboard.
*But, will that function in xterm? Presumably yes, but I'm not entirely positive

So, following in the path of coplate, but with further instructions from knc1 I:

#cat /etc/xorg.conf > /var/local/xorg.conf.project

and added the appropriate input device sections to my new xorg.conf.

Next:

# mount -o bind /var/local/xorg.conf.project /etc/xorg.conf
#killall -s KILL Xorg
#restart x

And my shiny new xorg? Well, the bind mount didn't stick, and the device reverted to the old code.

Also, the external battery doesn't stay on when just the keyboard is connected to the hub, so there is a slightly higher drain on my kindle battery than I'd like. Not sure where to start with that one. I've tried two different hubs, same thing happens with both. The external battery does not shut off when directly charging the kindle, so I suspect it is some sort of a 'very low amperage' shutoff mechanism.

Any thoughts are welcome and appreciated as I continue to tinker on this. I created a separate thread, as I didn't want to hijack lucida's (which seems to have a different end goal), but I'll merge this if that's the etiquette/most useful idea here here.

[knc1]

you missed making the root filesystem rw

mntroot rw ; mount --bind whatever ; mntroot ro

Although I am surprised that 'mount' did not give you a failure/warning of the mount point being read-only.

[glasnost]

Originally Posted by knc1

you missed making the root filesystem rw

mntroot rw ; mount --bind whatever ; mntroot ro

Although I am surprised that 'mount' did not give you a failure/warning of the mount point being read-only.

If I make /etc/ rw, doesn't that defeat the purpose of the bindmount? At that point, why not just cp /etc/xorg.conf to another location and edit the base file?

I'll give it a shot :-)

[coplate]

Originally Posted by glasnost

And my shiny new xorg? Well, the bind mount didn't stick, and the device reverted to the old code.

Don't bind '/etc/xorg.conf', copy and bind '/etc/upstart/makexconfig', when X is restarted, it runs this script to delete and recreate /etc/xorg.conf. You can have teh makexconfig make all the same changes that you did to your xorg.conf.

Or bind both of them, and make makexconfig just an empty script, so it doesn't delete the other file.

If you upload your makexconfig, I can add all the changes needed for your device, the only real difference between mine and yours should have been the /dev/input/exentXXX number of the keyboard


You also shouldnt need a 'kill x' and a 'restart x', I would think you can pick 1 or the other, through I recommend 'restart x'

[coplate]

I wrote a makexxconfig that will automatically detect keyboard and mouse, that are NOT the touchscreen.

the keyboard checks for key 'F4', and the mouse checks for "relative movement in the X direction" which the touchscreen does not have.

It also comments out the 5 way keypad, so if someone accidentally runs on the device with that, it wont break.


I also attached a copy of the xorg.conf that it generates.


The part to compare to the original in the makexconf is the loop where it checks all the devices:

# Scan for input device and call associate output function
do_input()

[knc1]

Originally Posted by glasnost

If I make /etc/ rw, doesn't that defeat the purpose of the bindmount? At that point, why not just cp /etc/xorg.conf to another location and edit the base file?

I'll give it a shot :-)

It depends on what your true purpose is.

If you wish to give the user a chance to escape from a bad file or other incompatible change with a simple re-boot . . .
Then use a bind mount.
Making sure it is not automatically created by the start-up code, only by the menu entry to enable it.

If neither you nor the computer never makes an in-compatible file change that someone might need to escape from, then change the system file.

[zxczxc]

Keep up the good work, this is very cool, fantastic. Great for ssh-ing into remote servers to perform some tasks. Although funny the keyboard will be by far the biggest thing!

[glasnost]

Originally Posted by coplate

I wrote a makexxconfig that will automatically detect keyboard and mouse, that are NOT the touchscreen.

the keyboard checks for key 'F4', and the mouse checks for "relative movement in the X direction" which the touchscreen does not have.

The part to compare to the original in the makexconf is the loop where it checks all the devices:

# Scan for input device and call associate output function
do_input()

coplate - I've tried tailoring your makexxconfig & and mouse.sh script to simply echo in all of my information, as well as using them exactly as you wrote 'em. The xorg.conf that is generated is always incomplete and crashes the xserver. :-( Here is a tails -f of my log (upon connecting the hub) & the xorg.conf that is generated.

* I've tried with both a mouse and keyboard, as well as just a keyboard. Ideally, I'd like just the keyboard (and to use the touchscreen for pointer, so no need for the cursor, though I can always edit that later)

knc1 - when I do a bind mount of xorg.conf directly, it seems to get overwritten by the makexconfig (like coplate has found). I must be missing a step, or need to do the makexconfig phase like coplate.

[glasnost]

Originally Posted by knc1

It depends on what your true purpose is.

If you wish to give the user a chance to escape from a bad file or other incompatible change with a simple re-boot . . .
Then use a bind mount.
Making sure it is not automatically created by the start-up code, only by the menu entry to enable it.

If neither you nor the computer never makes an in-compatible file change that someone might need to escape from, then change the system file.

Hmm. I think that either I don't understand the situation well enough, or I'm not articulating my problem well enough. Let me try again:

Situation:

#mount -bind /var/local/xorg.conf /etc/xorg.conf
#restart X

/Etc/xorg.conf is overwritten by makexconfig

If / was mounted rw, then bound, then ro - /etc/xorg.conf would still be overwritten by makexconfig because makexconfig would need rw privs in order to write xorg.conf in the first place, no?

And if not, then wouldn't a reboot leave you with the edited xorg.conf? I think this is why coplate is suggesting the 'mount bind and edit makexconfig route.'

Or I'm completely wrong and confusing the situation.

[knc1]

What are you trying to do with this statement?

InputDevice \"keyboard"\ \"CoreKeyboard"

[knc1]

Originally Posted by glasnost

Hmm. I think that either I don't understand the situation well enough, or I'm not articulating my problem well enough. Let me try again:

Situation:

#mount -bind /var/local/xorg.conf /etc/xorg.conf
[1]#restart X

[2] /Etc/xorg.conf is overwritten by makexconfig

If / was mounted rw, then bound, then ro - /etc/xorg.conf would still be overwritten by makexconfig because makexconfig would need rw privs in order to write xorg.conf in the first place, no?

And if not, then wouldn't a reboot leave you with the edited xorg.conf? I think this is why coplate is suggesting the 'mount bind and edit makexconfig route.'

Or I'm completely wrong and confusing the situation.

[2] is caused by [1] - I.E: it was over-written because you told it to (the writing is part of the upstart, start process).

You can't mount to a ro mount point, at least not in Linux, which this is.

The "mount --bind" operation will not persist across re-boots, unless you write code to make it happen as part of the boot process.

The directory name is /etc not /Etc

/var/local is the file system on partition #3, the / file sytem is on partition #1.

The Kindle script provided by Lab126 changes the rw/ro status of the file system mounted as /
The script does not affect any other partitions / file systems.
The change of status of / is not reflected in /var/local (because the file systems are independent backing stores).

In analogy, in some operating systems you can change the rw/ro status of the B:\ drive (backing store) without affecting the A:\ drive (backing store).
Typical of a multi-rooted file tree.

Linux (and all other *nix) uses a single rooted file tree and a backing store(s) per mount point.

X11 is compiled to look at only one place for its configuration file, /etc/xorg.conf

That must be set before X11 starts or re-starts, you can change it while X11 is running because it is only read during X11 start-up.

= = = = = =

Now consider the sequencing of operations all that above implies -

Kindle is running normally, un-modified.

Your scripting is triggered (called) either by a KUAL menu entry or a u-dev rule (however/wherever you program it).

Make the root file system writable (so the mount command does not fail)

Do the bind mount with the custom file.

Return the root file system to ro

Restart X11 without calling upstart -
send: ctrl-alt-backspace to X11 on X11's keyboard input.
(or maybe it also has a restart signal (interrupt), I forget)

I just looked for it, but my google foo is failing today, try sending SIGINT to X11.

You can try the last on your desktop - X11 is X11 is X11 etc
You probably want to bring up an alternate session (ctrl-alt-function-key, other than F7 - which is usually what X11 is running on) before sending SIGINT to the X11 session running your GUI. ;

[glasnost]

Originally Posted by knc1

[2] is caused by [1] - I.E: it was over-written because you told it to (the writing is part of the upstart, start process).

You can't mount to a ro mount point, at least not in Linux, which this is.

The "mount --bind" operation will not persist across re-boots, unless you write code to make it happen as part of the boot process.

The directory name is /etc not /Etc

Sorry, was writing on a mobile device (not my kindle with a keyboard ;-) ) damn autocorrect.

[root@kindle root]# cd /mnt/us/MyProject/
[root@kindle MyProject]# echo "blahblahblah" > ./badxorg.conf
[root@kindle MyProject]# ls
Installbinaries    Keyboard           Uninstallbinaries  badxorg.conf       iptables.log
[root@kindle MyProject]# mount -o bind /mnt/us/MyProject/badxorg.conf /etc/xorg.conf
[root@kindle MyProject]# cat /etc/xorg.conf
blahblahblah
[root@kindle MyProject]#

But:

[root@kindle MyProject]# mount | grep -i etc
/dev/loop/4 on /etc/kdb.src type cramfs (ro,noatime,nodiratime)
/dev/loop/4 on /chroot/etc/kdb.src type cramfs (ro,noatime,nodiratime)
/dev/root on /chroot/etc/fonts type ext3 (ro,noatime,nodiratime,barrier=0,data=writeback)
/dev/root on /chroot/etc/gtk-2.0 type ext3 (ro,noatime,nodiratime,barrier=0,data=writeback)
/dev/root on /chroot/etc/pango type ext3 (ro,noatime,nodiratime,barrier=0,data=writeback)
/dev/root on /chroot/etc/resolv.d type ext3 (ro,noatime,nodiratime,barrier=0,data=writeback)

This is why I was so confused! It looks like it is bind mounted, but clearly that is not the case. So where is my #cat /etc/xorg.conf getting the blahblahblah statement from? Oddities

InputDevice \"keyboard"\ \"CoreKeyboard"

That was automatically generated by coplate's makexconfig script.

Let me try again with a custom xorg (just adding the keyboard to the core script) and I'll (hopefully) be able to report back that it works. Thank you for bearing with me, knc1!

[knc1]

Check if the 'mount' command is being provided by busybox or if it is a standalone binary.

It could be you are using the BB 'mount' command and that minimized version is missing the error message about the mount point being on a read-only file system.

Because it certainly failed in the example you give.

Another thing to check - -
Although /etc/xorg.conf is only read once, on start-up - -
It may still be held open by X11 -

So run a listing of open files, see if it is being held open.
Because if it is, it will not matter if it is over-written or even deleted, the /etc directory is on an inode file system, the original data will still be read.

- - - -

If you pause the framework, does that shutdown X11?

I.E: There should be a nice clean way to get upstart to help you, rather than fight you.

[glasnost]

OMG: lucida, coplate, knc1 - I <3 you all!




Between the three of you, my machine is alive!

problem 1 - #mount -o bind wasn't working b/c mntroot was not rw. Busybox wasn't reporting anything and files appeared to be altered, but it wasn't working.

As such, nothing stuck.

That said, xorg.conf is a forced symbolic link from /var/local/xorg.conf and var/local/xorg.conf is always rewritten by upstart when doing 'restart x'

Problem 2 - broken xorg.conf from makexconfig - honestly, I don't know what happened. I do not understand the file interactions well enough to figure out why I was generating those weird conf files using @coplate's cursor2 scripts. Especially because root was not mounted rw when I tried the bind mount.

Solution (inelegant, kludged together, but working for now):
lucida's usb otg kindlet (start otg service, then plug in hub/keyboard)
coplate's makexconfig copied to /var/local/kindlekbd per knc1 and:

# mntroot rw
# mount -o bind /var/local/kindlekbd /etc/upstart/makexconfig
# mntroot ro
# restart x

And now I can write in vim to my heart's delight :-) Thank you all!!!

[knc1]

The mount point can be a device, a directory or a file -
It can not be a symbolic link.

Sorry, it didn't occur to me to ask you to check for that condition.

I just assumed that the up-start script was changing the rw/ro status of /etc before it generated the config file.

That, and the lack of proper messages from the busybox version of the 'mount' command made this a lot more difficult than it has to be.

- - - - - -

{rant}
Why didn't Lab126 re-configure X11 to get its configure file from /var/local/etc/x11.conf to begin with?

After all, they are doing a custom build-from-source for every firmware release.
{/rant}
Hmm...
that is a rhetorical question, there may be a very good reason that escapes me at the moment.