Koreader on H2O Edition 2 (H2O2)

[gilali]

Originally Posted by Frenzie

Btw, have you tried one of the latest nightlies like http://build.koreader.rocks/download...1406-gaa7d4f9/
If I understand correctly that should kind of work?

Here's my test on youtube
And its crash.log attached
As you can see, multitouch works better than unitouch

Build 1406 out of the box, + upside down patch + "-d" argument

[Frenzie]

Nice video! Does the device and/or the kernel driver support actual multitouch? If so then an evtest with multitouches and multitouch gestures would probably be helpful to have. In principle that should work out of the box too but maybe one of the non-standard Kobo workarounds is getting in the way.

[gilali]

Here's the multitouch log.
I suppose is't not possible to put ksm's touch driver into Koreader. Because in pbchess, touching works nice. And Koreader not need multitouch, isn't it ?

[geekraver]

Tried the one at that link; display is upside down and it doesn't respond to any touch presses.

[gilali]

@geekraver
Yes, according to #31, your result is as expected.

Build 1406 out of the box, + upside down patch

Upside down patch
For touch presses, it's expected too. You have to use multitouch for better response like this

[geekraver]

Doesn't seem practical.

I'm struggling to understand why pbChess and KSM are working but KOReader not? Do they all use completely different mechanisms for touch?

[Frenzie]

@gilali
KOReader supports multitouch gestures, which can make some user interactions easier but of course it doesn't depend on them. It may not be supported on any Kobos atm (hardware-wise) but don't quote me on that. It shouldn't need special support if it's standard in any case. There's definitely multitouch on Kindle and Android, presumably also on PocketBook and Ubuntu Touch.

@geekraver
It's some of the Kobos that use non-standard mechanisms for touch instead of the standard Linux kernel events. They emit something that's close to it, but not quite. This is contrary to the kernel principle that user-space applications shouldn't have to worry about this kind of thing. Linus Torvalds would firmly reject whatever kernel patches they applied, probably coupled with some profanity.

Anyway, you can see KOReader's Lua implementation of the Linux single touch and multi touch protocols here, including a reverse-engineered implementation of what was dubbed the Phoenix protocol (because it's the first device where that particular creature showed up).

KSM/vlasovsoftlauncher depends on something similar written in C or C++ instead. Possibly just a few Kobo-specific workarounds on top of something straight from Qt.

Anyway, I guess Sergey can just look at some evtest output and immediately translate it to some relevant code without needing to take a good hour or two to really wrap his head around it. But he probably wrote that code, whereas I didn't implement any of KOReader's stuff so that I only have a passing knowledge of it. I almost got started for the H2O when I noticed that it reused the Phoenix protocol.

You could say I could've used the time I spent writing this post parsing the events and the code instead but it's already 22:26 and trust me, that's a lot more exhausting.

[gilali]

Hello,
Happy new year

Is it usefull for you to share ssh access to my kobo over internet ?
I'm ok with this.

[Frenzie]

Happy New Year. I'm afraid not. It's more a matter of time.

[geekraver]

Couldn't koReader leverage the driver code from Sergey that KSM uses? It's been years since I wrote Lua code but IIRC it was quite easy to wrap native code. Or does KSM have a Qt dependency too?

[tshering]

Originally Posted by geekraver

Couldn't koReader leverage the driver code from Sergey that KSM uses? It's been years since I wrote Lua code but IIRC it was quite easy to wrap native code. Or does KSM have a Qt dependency too?

Yes KSM has a Qt dependence.

[Frenzie]

Originally Posted by geekraver

Couldn't koReader leverage the driver code from Sergey that KSM uses? It's been years since I wrote Lua code but IIRC it was quite easy to wrap native code. Or does KSM have a Qt dependency too?

Wrapping C code would be very easy (well, dunno about that specific C code but in principle; much easier even through LuaJIT FFI than in plain Lua C bindings) but adding an extra layer of complexity and uncertainty is almost certainly not easier by any stretch of the imagination.

This is the standard stuff:

https://github.com/koreader/koreader....lua#L366-L426

And here is the Phoenix Protocol:

https://github.com/koreader/koreader....lua#L427-L491

You can imagine a C library that translates all odd Kobo deviations into standard events to simplify things ever so slightly, but there isn't that much going on in the first place.

I'm sure you can do it with some strategic debug statements and tweaks. You just need an SSH connection so you can quickly iterate tests.

[geekraver]

I looked at the kernel code at https://github.com/kobolabs/Kobo-Reader

I compared the auraonetwo kernel code with h202. Apart from adding a couple of additional low level touch drivers (Parade Truetouch and Focaltech), I didn't see anything different at a higher level related to input.

[Frenzie]

Haha, you find reading kernel code easier than Lua?

I would imagine duplicating the Kobo Aura One definition is the first thing we tried (unless I forgot to explicitly state somewhere that same gen is likely to share a bunch of hardware), but did you double check just to be sure?

-- Kobo Aura One:
local KoboDaylight = Kobo:new{
    model = "Kobo_daylight",
    hasFrontlight = yes,
    touch_probe_ev_epoch_time = true,
    touch_phoenix_protocol = true,
    display_dpi = 300,
    hasNaturalLight = yes,
}

-- Kobo Aura H2O2:
local KoboSnow = Kobo:new{
    model = "Kobo_snow",
    hasFrontlight = yes,
-- started with phoenix, was changed to alyssum
    touch_alyssum_protocol = true,
-- this almost certainly must've been tried together with phoenix already, but…
    touch_probe_ev_epoch_time = true,
    display_dpi = 265,
    -- the bezel covers the top 11 pixels:
    viewport = Geom:new{x=0, y=11, w=1080, h=1429},
}

[cola]

Hi, I'm having a similar problem with koreader on a Kobo Aura H2O2, but I'm consistently able to generate single touch events by holding down one finger, and then tapping horizontally next to it with a second finger.

The touch event seems to occur at the place where the first finger touched, except horizontally mirrored. So for example if I want to select the text size icon at the bottom of koreader, i.e. the fourth of six evenly spaced icons, here's how I can do it: first, I hold down one finger near the bottom, slide a second finger up next to it, and finally release first finger. This brings up the lower panel. Then I hold down a finger on the 3rd icon, then tap the 2nd icon. This procedure selects the 4th icon, since that's what's under the horizontal reflection of the 3rd icon.

It's pretty weird, but still usable I think. Also I just tried swiping down with a thumb and it crashed koreader ("koreader has exited irregularly" or something like that) but I've just tried it again and it did nothing.