USBMS Shenanigans...

sherman · 09-21-2018, 03:42 AM

So, I may have been playing a bit the past several days...

I've been trying to see what I can get away with behind Nickel's back, without actually having to kill Nickel. This was born from ideas from kobo-rclone, but I wanted to push things further.

So after some experimentation, getting sidetracked and creating an onscreen keyboard using FBInk (oops...), and many device reboots, I'm finally starting to get something that is faintly approaching stability. I will note that my H2O has carried on like a trooper, although it's probably wondering if there is a Union to join...

Where I'm at currently is I can switch into USBMS mode, remount the internal memory partition (to a different mountpoint, just in case), and crucially, enable WiFi.

Once there, one can do what one wishes to do without having to kill Nickel. Touch input even becomes viable (I may have written a touch driver to go along with the onscreen keyboard). I finally figured out today, that Nickel appears to kill the touch screen after a few seconds in USBMS mode. HOWEVER, not if the Wifi gets re-enabled, which makes me wonder if there is a link somewhere.

This was all done in Go.

Here's a screenshot of what I currently have:

Click image for larger version

Name: usbms.png
Views: 420
Size: 49.0 KB
ID: 166418

I just thought you folks might be interested. I've got plans for this. PLANS I say

patrik · 09-21-2018, 08:27 AM

Nice

boriar · 09-21-2018, 12:09 PM

Very interesting!

NiLuJe · 09-21-2018, 12:21 PM

.

The touch input status in USBMS mode *might* be H2O and/or zforce specific: I know I've had to forcibly re-enable it on wakeup in KOReader, because it sometimes failed to wake-up on its own.

On the off-chance you don't actually need WiFi, you can check if the same trick works there:

Code:

echo "a" > /sys/devices/virtual/input/input1/neocmd

pazos · 09-21-2018, 03:50 PM

Nice work sherman, Did you modified stock shell scripts or found a way to hook your code inside nickel?

sherman · 09-21-2018, 04:31 PM

Quote:

Originally Posted by pazos

Nice work sherman, Did you modified stock shell scripts or found a way to hook your code inside nickel?

Currently launching via SSH/telnet. Programs that will be distributed could be launched via KFMON.

As far as bringing up Wifi, am currently replicating what the Koreader folks have done in their enable/disable wifi shell scripts.

The screenshot in the OP was just an example test program to bring the three parts, or libraries together. That is the entering/leaving USBMS mode, the on-screen keyboard, and the touch stuff.

The idea is that potential devs can pick and choose the required components.

The goal is not to create a complete GUI toolkit, or anything like that. Rather, to provide a simple means of say letting the user input a password or some other info that might be required.

The original question really was, how much can I get away with without killing Nickel?

pazos · 09-21-2018, 04:49 PM

Quote:

Originally Posted by sherman

The original question really was, how much can I get away with without killing Nickel?

On the good old days you can pause/resume nickel with killall -STOP/killall -CONT, at some point on FW3.x the trick didn't work (nickel kept polling for events and other programs can't see these inputs)

I am really interested on your research

NiLuJe · 09-21-2018, 04:54 PM

@pazos: Good point, I can't actually remember on which FW I was the last time I tried that, but I did indeed resort to that for a while when debugging both KFMon & KOReader

.

EDIT: Apparently quite a while ago

. According to the FW grid that was 3.19 at the very latest. I remember committing that patch some time (possible quite a bit, actually) after having last used it, so, take that with a grain of salt...

sherman · 09-21-2018, 05:09 PM

I'm probably not going to do much more "research" on capabilities so to speak, I think I've figured out enough that I can do what I want now.

The drive for all of this is for applications which download ebook content. In this situation, doing stuff in USBMS mode means that Nickel will import your content when you leave USBMS mode.

And with the additions NiLuJe has added to FBInk, one can detect when Nickel has finished importing content too. Which opens up further possibilities.

All of this would not have been possible without the prior work done by the Koreader team, and other Kobo devs. All credit goes to them really.

Ace33 · 09-25-2018, 12:26 PM

Is the code anywhere on GitHub, I'm really interested to see how this was implemented in Go

sherman · 09-25-2018, 05:00 PM

Quote:

Originally Posted by Ace33

Is the code anywhere on GitHub, I'm really interested to see how this was implemented in Go

Not yet, but it will be!

I'm still not sure how stable it really is, and won't really know until I integrate it into a project (which I have such a project in the works). When I'm a bit more sure it's not going to corrupt things, I will be releasing it.

Basically, all three components (USBMS, touch input handling, onscreen-keyboard) are very much still alpha level.

pazos · 09-25-2018, 06:37 PM

Quote:

Originally Posted by sherman

Basically, all three components (USBMS, touch input handling, onscreen-keyboard) are very much still alpha level.

I want to know how are you able to read the touchscreen with nickel running.

About alpha quality, I have a couple of "tethered" devices available for testing.

sherman · 09-25-2018, 07:43 PM

Quote:

Originally Posted by pazos

I want to know how are you able to read the touchscreen with nickel running.

About alpha quality, I have a couple of "tethered" devices available for testing.

When waiting for a touch event, I simply open '/dev/input/event1' and read whatever it spits out (a Linux 'input_event' struct). It's then just a matter of decoding the "event packets" into a set of usable coordinates. No guaranteeing I have that final bit completely correct, as each Kobo device does it different...

This works especially well in USBMS mode (so long as you can keep the touch screen awake), as there are no on-screen Nickel controls to interfere with.

If you folk are happy with alpha level software, I'll upload what I have to Github. Beware, the USBMS stuff is a hot mess of C, mixed with Go (using cgo), and a few calls to external programs for good measure. It ain't pretty, but sorta seems to work. I welcome any help in refining it.

sherman · 09-28-2018, 04:01 AM

Ok, finally got around to putting this all up on Github. The projects are the following:

kobo-sim-usb
go-kobo-input
go-osk

Not the most memorable of names, but hey...

[EDIT: and sorry it's all a bit bare-bones. I just wanted to get something uploaded for you folks]

elinkser · 11-16-2023, 08:35 PM

Quote:

Originally Posted by sherman

Ok, finally got around to putting this all up on Github. The projects are the following:

kobo-sim-usb
go-kobo-input
go-osk

Not the most memorable of names, but hey...

[EDIT: and sorry it's all a bit bare-bones. I just wanted to get something uploaded for you folks]

This software was much appreciated Sherman, forming the basis of a slick new keyboard I have renamed "oskansi". (That way my kludges shall not sully the original good name!)
https://www.mobileread.com/forums/sh...0&postcount=10

09-21-2018, 03:42 AM	#1
sherman Guru Posts: 877 Karma: 2676800 Join Date: Aug 2008 Location: Taranaki - NZ Device: Kobo Aura H2O, Kobo Forma	USBMS Shenanigans... So, I may have been playing a bit the past several days... I've been trying to see what I can get away with behind Nickel's back, without actually having to kill Nickel. This was born from ideas from kobo-rclone, but I wanted to push things further. So after some experimentation, getting sidetracked and creating an onscreen keyboard using FBInk (oops...), and many device reboots, I'm finally starting to get something that is faintly approaching stability. I will note that my H2O has carried on like a trooper, although it's probably wondering if there is a Union to join... Where I'm at currently is I can switch into USBMS mode, remount the internal memory partition (to a different mountpoint, just in case), and crucially, enable WiFi. Once there, one can do what one wishes to do without having to kill Nickel. Touch input even becomes viable (I may have written a touch driver to go along with the onscreen keyboard). I finally figured out today, that Nickel appears to kill the touch screen after a few seconds in USBMS mode. HOWEVER, not if the Wifi gets re-enabled, which makes me wonder if there is a link somewhere. This was all done in Go. Here's a screenshot of what I currently have: I just thought you folks might be interested. I've got plans for this. PLANS I say

09-21-2018, 12:21 PM	#4
NiLuJe BLAM! Posts: 13,506 Karma: 26047202 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	. The touch input status in USBMS mode might be H2O and/or zforce specific: I know I've had to forcibly re-enable it on wakeup in KOReader, because it sometimes failed to wake-up on its own. On the off-chance you don't actually need WiFi, you can check if the same trick works there: Code: echo "a" > /sys/devices/virtual/input/input1/neocmd Last edited by NiLuJe; 09-21-2018 at 12:27 PM.

09-21-2018, 04:54 PM	#8
NiLuJe BLAM! Posts: 13,506 Karma: 26047202 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	@pazos: Good point, I can't actually remember on which FW I was the last time I tried that, but I did indeed resort to that for a while when debugging both KFMon & KOReader . EDIT: Apparently quite a while ago . According to the FW grid that was 3.19 at the very latest. I remember committing that patch some time (possible quite a bit, actually) after having last used it, so, take that with a grain of salt... Last edited by NiLuJe; 09-21-2018 at 05:00 PM.

09-28-2018, 04:01 AM	#14
sherman Guru Posts: 877 Karma: 2676800 Join Date: Aug 2008 Location: Taranaki - NZ Device: Kobo Aura H2O, Kobo Forma	Ok, finally got around to putting this all up on Github. The projects are the following: kobo-sim-usb go-kobo-input go-osk Not the most memorable of names, but hey... [EDIT: and sorry it's all a bit bare-bones. I just wanted to get something uploaded for you folks] Last edited by sherman; 09-28-2018 at 04:07 AM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Firmware Update New Kindle UI: Amazon back with their aggressive obnoxious shenanigans	Indigo121	Amazon Kindle	7	03-24-2016 10:43 AM

09-21-2018, 08:27 AM	#2
patrik Guru Posts: 684 Karma: 4568205 Join Date: Jan 2010 Location: Sweden Device: Kobo Forma	Nice

09-21-2018, 12:09 PM	#3
boriar Evangelist Posts: 407 Karma: 314204 Join Date: Jan 2015 Device: bq Avant XL, Kobo Aura H2O, Onyx Boox M96C Plus	Very interesting!

09-21-2018, 03:50 PM	#5
pazos cosiñeiro Posts: 1,406 Karma: 2451781 Join Date: Apr 2014 Device: BQ Cervantes 4	Nice work sherman, Did you modified stock shell scripts or found a way to hook your code inside nickel?

09-21-2018, 05:09 PM	#9
sherman Guru Posts: 877 Karma: 2676800 Join Date: Aug 2008 Location: Taranaki - NZ Device: Kobo Aura H2O, Kobo Forma	I'm probably not going to do much more "research" on capabilities so to speak, I think I've figured out enough that I can do what I want now. The drive for all of this is for applications which download ebook content. In this situation, doing stuff in USBMS mode means that Nickel will import your content when you leave USBMS mode. And with the additions NiLuJe has added to FBInk, one can detect when Nickel has finished importing content too. Which opens up further possibilities. All of this would not have been possible without the prior work done by the Koreader team, and other Kobo devs. All credit goes to them really.

09-25-2018, 12:26 PM	#10
Ace33 Junior Member Posts: 1 Karma: 10 Join Date: Mar 2018 Device: Kobo Aura One	Is the code anywhere on GitHub, I'm really interested to see how this was implemented in Go