Kobo Aura One is not supported (unrecognised model)

[MMihelic]

• KOReader version: latest beta
• Device: Kobo Aura One

Issue

./luajit: frontend/device/kobo/device.lua:309: unrecognized Kobo model daylight
stack traceback:
[C]: in function 'error'
frontend/device/kobo/device.lua:309: in main chunk
[C]: in function 'probeDevice'
frontend/device.lua:38: in main chunk
[C]: in function 'require'
frontend/ui/uimanager.lua:1: in main chunk
[C]: in function 'require'
./reader.lua:99: in main chunk
[C]: at 0x0000bea5

Steps to reproduce

[houqp]

Yup, I don't think any of the developers has this device yet. Did you order it online? I am actually temping to buy one...

[Frenzie]

I'd love one because it's bigger and has a higher DPI than my H2O but the cost is definitely unjustifiable. Maybe I could try pandering the old one to see how much people are willing to pay. :-P

[MMihelic]

Yes, I did order it on-line from a French retailer FNAC.

I am afraid there are more differences in the device than I thought initially.
I tried to define a new device in the LUA files, but I was not successful:

• as soon as I try to set the viewport size and bezel (using Aura H2O as an example) I get error that viewport was invalid.
• without viewport definition in the device setup the KOReader starts up but the touch interface is messed up. In file manager when I touch an entry it is apparently triggered, however, the menu for rename/cut/delete comes on instead of opening the folder I touched. At this point, the device freezes.
  I need to correct myself: the device doesn't freeze, at least not immediately. The dialog shown does not respond to touches but the device and interface did respond to the power button which brought up the "poweroff dialog". The "poweroff dialog" was also not responding to touches.
• if I turn off the phoenix touch interface the behavior changes slightly, but it doesn't solve the problem.
• KSM08 did install but usb storage doesn't work and usbnet, which does work, is useless because of the build in firewall preventing access. Of course, I am only guessing about the firewall - it could be that the Dropbear SSHD is not working correctly.

[Markismus]

Still, it shouldn't crash on it. Just saw the function error.

Am I gonna buy, am I not gonna buy...
@Frenzie How is the processor of the One compared to the H2O, think it will be slower than the H2O?

@MMihelic Is there an internal SD-card slot like the H2O or is there flash memory like the Aura? About the viewport definition: shouldn't you first try to define the screen dimensions properly, or did you already do that? You could look at the discussion for the Kobo Aura to see what has been done when the Phoenix introduced a new touch screen protocol. I would really like to see your ev.log (this is generated when you enable debugging by reader.lua -d iirc. If you want I can sent you the excel sheet I used to convert the ev.log data in human readable form.

[KenMaltby]

As I understand it, it has no internal SD card.

KSM gets its Dropbear from the Vlasovsoft install.

[MMihelic]

I'll definitely try to help as much as I can. The Aura One is completely useless for PDF reading with supplied software. I have Aura HD and I know how bad it is there, but it is a lot worse with the One because of the higher pixel count - at least I suppose this is the reason for extreme slowness of a page turn.

Please, send me the Excel sheet. However, do take a look at my comment about the USBNET and the SSHD. It's possible that I will not be able to get shell access. I hope I'll manage to add logging to a file if necessary. I've never worked with LUA before.

Now about...

• the viewport: I did try to use the Aura H2O definition as an example. Unfortunately, I had no success. I get an error if I define the viewport with an exact number of pixels as given in the specification, or if I decrease the y axis by one as in Aura H2O definition. It does seem to work if I don't specify anything. Could it be that the specification contains an error? Is there a way for me to directly detect the screen dimensions from a LUA script?
  On a side note: Vlastovsoft launcher does seem to work correctly! I haven't tested it much though.
• the touch interface: I find it weird that it does seem to work correctly for a first touch in the file manager (it seems to respond to the correct coordinates). It could be that it is detecting a wrong kind of event. We will see when and if I manage to capture events.
  Here it is also worth noting that the touch (and screen dimensions) seems to be correctly interpreted by the KSM and by the Vlastovsoft launcher.

-- Regards, Matej.

[Markismus]

Just enable telnet and access it over WiFi. The howto is on MobileRead.org and I think I posted the link somewhere in koreaders issues.
EDIT:This is the link: http://www.mobileread.com/forums/showthread.php?p=2681553#post2681553

EDIT2: Event log.xlsx.zip
The sheet makes use of text data files (ev.log files, especially) So click the Data tab in excel and look at the data connections. Modify those to connect the sheet to your ev,log file.

[MMihelic]

Step 1.: Capture logs - two logs: one is an attempt to get min&max values - visible screen/touch area and the second ones tries gestures in order given in the excel sheet.

Step 2.: Excel analysis (not yet done)

Perhaps of an interest:
Recorded values:

Recorded values:            
min-x   9   min-y   1
max-x   1870    max-y   1402

AuraOne-ev-logs.zip

Ok, I managed to find the debug instructions at the "#1525".
Give me a couple of minutes to make a proper log.

[Markismus]

Excel analysis is not useful anymore. The format of the ev.log has changed drastically into something human readable. Event codes 53-54 also show Max values of 1872 and 1404. Are those your screen dimensions?

[MMihelic]

It looks like the firmware update to v4 actually solved some of the problems! I didn't expect that. ;)
Dropbear SSHD over USBNET is now working.

The koreader still crashes in FileManager on touch but I've managed to capture full debug logs. I hope it will help.

With regard to your ev.log format comment: this was not the koreader output. It was output of evtest utility. Were you referring to the output of the evtest?

In the attached file you will find full debug logs from koreader (./reader.lua -d /mnt/onboard > koreader.log.date +%s 2>&1) including the ev.log in the expected format.

What I did was start koreader from shell in KSM and touch one of the directory names in the FileManager. Wen the touch interface stopped responding I then pressed briefly the poweroff button which was correctly interpreted as suspend command. I unsuspended the device by pressing it again and then killed the luajit.

This was the definition of the kobo_Daylite device during the test:
-- Kobo Aura One:
local KoboDaylight = Kobo:new{
model = "Kobo_daylight",
hasFrontlight = yes,
touch_phoenix_protocol = true,
display_dpi = 300,
-- the bezel covers the top 11 pixels:
viewport = Geom:new{x=0, y=0, w=1404, h=1872},
}

koreader-ev-crash.zip

[MMihelic]

Good news!
After disabling the phoenix protocol I managed to start koreader and open the book!
The problem is in the reaction time for touch. It seems to be extremely sensitive and a "normal" length touch is interpreted as long touch or perhaps a double touch!
If i touch an entry just briefly (really short touch) it works.

I am even able to read the PDF file normally. You have no idea how much I am grateful to you and the entire team!

[Markismus]

Very nice! The "normal" length touch is interpreted as a "hold" gesture, that's why you originally got the rename-move-etc-dialog in filemanager.
Speculating further: You fiddle around with the "time delay" for the hold gesture to make it a bit less sensitive. I am speculating that due to increased polling speed (whether it is the touch screen or the processor) the delay for an ordinary tap gesture to go over into a hold gesture is not realistic anymore.

Found it: here:

local GestureDetector = {
    -- must be initialized with the Input singleton class
    input = nil,
    -- all the time parameters are in us
    DOUBLE_TAP_INTERVAL = 300 * 1000,
    TWO_FINGER_TAP_DURATION = 300 * 1000,
    HOLD_INTERVAL = 500 * 1000,
    SWIPE_INTERVAL = 900 * 1000,
.....
    },
.......
.....
}

Twittle with these numbers to get the response that you like!

You could also start playing around with this bit of code:

 if self.rate then
        -- This filed restraints the upper limit rate(matches per second).
        -- It's most useful for e-ink devices with less powerfull CPUs and
        -- screens that cannot handle gesture events that otherwise will be
        -- generated
        local last_time = self.last_time or TimeVal:new{}
        if gs.time - last_time > TimeVal:new{usec = 1000000 / self.rate} then
            self.last_time = gs.time
        else
            return false
        end
end

Although it is meant for too slow screens&processors it seems hackable to do the same for too fast ones. Still, I hope others will chip in, because the code has changed dramatically since last I looked into this part. (Kind of stumbled on it while searching for the gesture detection lua-file.)

[MMihelic]

I think that the "touch_probe_ev_epoch_time = true" is required. I've tried playing with the tap time delay and it didn't help.

This is my now, more or less, working configuration:

-- 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,
    -- the bezel covers the top 11 pixels:
    viewport = Geom:new{x=0, y=0, w=1404, h=1872},
}

I am unable to verify the viewport dimensions. Do you have a test image or something that would serve as a ruler to verify that the entire viewport is indeed visible?

[Markismus]

Quick&Dirty: Turn on nightmode, flip to an near empty page, do you see the edges of the black?

There used to be is a testing script that alloweds you to draw a grid on screen, but it seems to be removed from the code. (At least I can't find it anymore!)

[KenMaltby]

Tshering added a function/script to KSM that let you find the proper screen dimensions for display, in response to the Aura, I think.