Kobo Forma support #4291
Comments
|
In frontend/device/kobo/device.lua, you could try adding a definition: Here's an example: koreader/frontend/device/kobo/device.lua Lines 185 to 199 in c01d105 Sorry for the brevity, but I have to be off now. :-) |
|
Thanks, Frenzie. I've made two changes in /front/device/kobo/device.lua file:
Then I tried to launch Koreader, my Kobo Forma restarted then see following:
|
|
When a Kobo asks you to re-login, that wipes the DB, IIRC. Which means you may need to plug/unplug or reboot it for it to process stuff again, provided it hasn't done a bonus factory reset, which would explain 3., as that reinstalls the factory FW, but not 2., because I think that wipes the user partition, too. If it actually did a factory reset, that's a fairly visible process, though, so you'd have noticed the process happening on screen. On the other hand, if that was a simple reboot and it just asked you to re-login just after that, that was simply a trashed database, which can happen (or the whole process can sometimes be misdetected as "useful" and almost forced on you, even when it isn't actually useful, and the db isn't actually damaged), after bad crashes. Sidebar: starting with the extremely old "stable" release was also a fairly bad idea ;). |
|
In the meantime, if you got another crash.log from the hard crash, that might be useful, too ;). |
|
@NiLuJe it seems a simple reboot, but something weired because other than a home without any book I also see the settings missing "accounts" submenu. I forced to restart again, everything is back, including colletion settings. It was my bad. I forgot to metion when I made the above metioned changes, I actually used the latest beta version and copied the code for daylight ( which I blieve is Kobo Aura One) for my Kobo Forma. So seems those same code for Aura One not working for Kobo Forma. What else information I can collect? Would like to fix this with help from you guys. The PDF reading with Kobo Forma is rally bad, plus there is one PDF I need to read keeps crashing the device. |
|
Might have been a botched Nickel restart after a KOReader crash then... The crash.log from that might help, to begin with ;). But it's probably going to take someone with shell access to get this right, because I'm expecting the gyro/rotation handling to be wonderfully annoying to deal with. |
|
The One is an older device, you'll probably have less terrible results if you start from a Clara, that's what's gotten the most testing out of that generation of devices ;). |
|
@NiLuJe How can I find out correct viewport setting for this device? I don't quit understand: no matter how I switched the numbers for the width and height, the error still showing same height and width. Same even after I commented out or removed the viewport lines. |
|
@patrick-tang The viewport setting is just for KOReader to draw further from the edge of the actual panel, like on the H2O where ~10-11 px are covered up by the bezel. The full framebuffer will always be the same size, in your case 1920x1440. The viewport is a smaller area within that framebuffer. The simplest means of quickly testing is to start from scratch on touch workarounds. Getting rid of that If the touch is mirrored in some way, set mirrored to false: koreader/frontend/device/kobo/device.lua Lines 29 to 32 in c01d105 What do you mean by "cannot tap menu items properly"? Is there any response? |
|
According to the latest news from the KSM thread, you might want to try phoenix + probe_ev ;) |
|
@Frenzie @NiLuJe |
|
So touch is working, just off by a few pixels? That's very weird, but also very easy to work around. Potentially even with viewport instead of event adjustment. Sorry, on my phone atm. But please try Niluje's suggestion first. Hold works too? |
|
A wrong touch protocol is unlikely to cause anything worse than broken
touch input...
|
|
And, nope, my bad, skimmed stuff too rapidly, Might need some extra shenanigans, like Stuff might be affected by the rotation you were in before starting KOReader, so I'd keep it simple: Portrait, buttons on the right (or the left?). And, yeah, as @Frenzie said, knowing if hold/swipes work right would be helpful. |
|
@NiLuJe Just want to confirm that hold/swipes work (but buttons don't work). Other problems I notice with current status:
For above two problems, what should I look at? |
|
Buttons are really simple, but you need to switch to debug mode, ideally combined with using Telnet or SSH. Isn't there a guide about that on Mobileread somewhere? Then you simply get output like this: tl;dr Buttons are the easiest problem to solve. :-) Unfortunately the closest thing to a basic debugging for dummies guide we've currently got is the one for Android for which I supplied most of the materials, but that one presupposes you already know the basics. |
|
Not really, as there's a bunch of different ways you can actually get in. In this specific instance, using the built-in one (i.e., enabling Nickel's debug features, which enables telnet) is probably a no-go, since Nickel won't be up ;). That leaves a telnet/SSH package. @frostschutz has one, too, which you'll just need to package yourself. And there's the good old and venerable package from KevinShort. Among a few others, but that'd be my top three, OTOH ;). |
|
I think the last one there might be the one I first used to start hacking my H2O. |
|
NO. NOPE. NOPE NOPE NOPE. |
|
That's why I put mine & frostchutz's first: we both go out of our way to actively not mess with any default system files. That's both neater, the right thing to do, and allows us to survive FW updates ;). (i.e.: if we liked the inittab method, which the third package does use, we'd have been using it ourselves, too ;p). |
|
Actually, mine totally does modify the inittab :-) and still uses the hwclock hack too. For other mods I just use udev rule to get things started, but I think I made the telnet one before I learned how to do that... oi should update it, I guess |
|
@frostschutz: heretic! :D |
|
@NiLuJe inittab does survive firmware upgrades, as far as I remember. /etc/init.d/on-animator.sh does not survive. I remember when I was using a script launched from inittab to restore on-animator.sh from on-animator-fmon.sh each time I updated the FW and worked. |
|
I vaguely recall seeing it pop up in some FW updates, but that was a loooong while ago. Or something :D. |
|
You're right about mirrored tapping another day. The tapping was kind of mirrored: it was actually due to the inconsistency of display and tapping. The display followed screen rotation (rotation status before launching Koreader) but tapping was still expecting coordinates in non-rotated state (original orietation as device just started). What's your suggestion of the fix? |
|
For the light issue, I got following information. It seems there are two files for the light control:
ls -lah /sys/class/backlight/ ls -alh /sys/class/backlight/mxc_msp430.0/ ls -alh /sys/class/backlight/tlc5947_bl/ |
|
Eh, that might be enough for us once Nickel's gone, thanks! I'll post a test koreader.sh script (much) later tonight. |
|
There, check if this version of the koreader.sh startup script allows you to start properly, no matter the orientation. |
|
I'm not sure if warm light control is supposed to work with this initial support, but it doesn't on my device. Both sliders seem to be controlling regular light. |
@NiLuJe added support based on this thread feedback and @patrick-tang said that it worked for him. If you have shell access you can try #4291 (comment). Also please post the output of Current sysfs interface write on bl_power & brightness. Newer devices may need to write to color instead. |
|
@pazos
Nickel doesn't allow fine-grained control over natural light (at least on Forma), instead the slider has 11 steps going from 10 to 0, which gives 10 color presets (10 is whitest, 0 reddest), and sets the "out" attribute via some combination with the backlight brightness (I'm guessing color presets are just scalars). Fine-grained control can probably be achieved by modifiying the "out" attribute directly, though I'm not sure such functionality is wanted. Keeping sync with Nickel seems like a more reasonable approach. I personally don't find such fine-grained control useful. |
|
As I said earlier, the output of |
|
@pickx: for the record, on a BQ Cervantes 4: This device has both the "classic" interface (being lm3630a_ledb for white leds and lm3630a_leda for red leds) and the newer color mixer interface (lm3630a_led is the color mixer and mxc_msp430_fl.0 is for controlling the brightness). It seems that the Kobo Forma doesn't have the "classic" interface. Other recent models, like the Clara, happen to have both interfaces (and the classic is used https://github.com/koreader/koreader/blob/master/frontend/device/kobo/device.lua#L192-L198) Color mixerbl_power and brightness attributes of the color mixer are taken from mxc_msp430_fl.0 and you can not write directly to lm3630a_led/bl_power or lm3630a_led/brightness. In shortWith the frontlight/naturalLight turned off the following commands will turn on both with maximum values |
NiLuJe
changed the title
|
@patrick-tang: Could you please give us feedback about natural(orange) light? Does it works? About key mapping: in nickel key mapping depends on orientation, right? |
|
@pazos The key mapping follows orientation, meaning the two keys will switch accordingly with orientation. |
|
This replacement for the function It seems to be unnecessary to set |
|
@cairnsh: good work. Did you test if sync with nickel still works? I guess we can add a new var named frontlight_mixer in https://github.com/koreader/koreader/blob/master/frontend/device/sysfs_light.lua#L11 and check if current device has frontlight_mixer with |
|
This diff against master should work for the forma. The same aproach should work for other devices too diff --git a/frontend/device/kobo/device.lua b/frontend/device/kobo/device.lua
index fd19a7cd..0512dc19 100644
--- a/frontend/device/kobo/device.lua
+++ b/frontend/device/kobo/device.lua
@@ -215,7 +215,7 @@ local KoboFrost = Kobo:new{
hasNaturalLight = yes,
frontlight_settings = {
frontlight_white = "/sys/class/backlight/mxc_msp430.0",
- frontlight_red = "/sys/class/backlight/tlc5947_bl",
+ frontlight_mixer = "/sys/class/backlight/tlc5947_bl",
}
}
diff --git a/frontend/device/sysfs_light.lua b/frontend/device/sysfs_light.lua
index 0252741e..cdb40559 100644
--- a/frontend/device/sysfs_light.lua
+++ b/frontend/device/sysfs_light.lua
@@ -9,6 +9,7 @@ local SysfsLight = {
frontlight_white = nil,
frontlight_red = nil,
frontlight_green = nil,
+ frontlight_mixer = nil,
current_brightness = 0,
current_warmth = 0,
white_gain = 25,
@@ -56,29 +57,36 @@ function SysfsLight:setNaturalBrightness(brightness, warmth)
warmth = self.current_warmth
end
- local red = 0
- local green = 0
- local white = 0
- if brightness > 0 then
- -- On Nickel, the values for white/red/green are roughly linearly dependent
- -- on the 4th root of brightness and warmth.
- white = math.min(self.white_gain * math.pow(brightness, self.exponent) *
+ -- Newer devices use a mixer instead of writting values per color.
+ if self.frontlight_mixer then
+ warmth = math.floor(warmth/10)
+ self:_write_value(self.frontlight_white, brightness)
+ self:_write_value(self.frontlight_mixer, 10 - warmth)
+ else
+ local red = 0
+ local green = 0
+ local white = 0
+ if brightness > 0 then
+ -- On Nickel, the values for white/red/green are roughly linearly dependent
+ -- on the 4th root of brightness and warmth.
+ white = math.min(self.white_gain * math.pow(brightness, self.exponent) *
math.pow(100 - warmth, self.exponent) + self.white_offset, 255)
- end
- if warmth > 0 then
- red = math.min(self.red_gain * math.pow(brightness, self.exponent) *
+ end
+ if warmth > 0 then
+ red = math.min(self.red_gain * math.pow(brightness, self.exponent) *
math.pow(warmth, self.exponent) + self.red_offset, 255)
- green = math.min(self.green_gain * math.pow(brightness, self.exponent) *
+ green = math.min(self.green_gain * math.pow(brightness, self.exponent) *
math.pow(warmth, self.exponent) + self.green_offset, 255)
- end
+ end
- white = math.max(white, 0)
- red = math.max(red, 0)
- green = math.max(green, 0)
+ white = math.max(white, 0)
+ red = math.max(red, 0)
+ green = math.max(green, 0)
- self:_set_light_value(self.frontlight_white, math.floor(white))
- self:_set_light_value(self.frontlight_green, math.floor(green))
- self:_set_light_value(self.frontlight_red, math.floor(red))
+ self:_set_light_value(self.frontlight_white, math.floor(white))
+ self:_set_light_value(self.frontlight_green, math.floor(green))
+ self:_set_light_value(self.frontlight_red, math.floor(red))
+ end
self.current_brightness = brightness
self.current_warmth = warmth |
|
You get syntax highlighting with or lua/python/bash/etc. depending on what's in there ;-) The diff looks good. |
|
I should be getting my hands on a Forma tomorrow, so I'll be able to join in on the fun ;). |
|
On Nickel's side, ColorSetting is still [1500 ... 6400], so I'll have to check how the normalization fares, because it's now only 10 steps on Nickel's side, while we're doing 100 in (Also, brightness seems to be written to actual_brightness [0 ...100] @ mxc_msp430.0, but I haven't checked what our code does on that front). |
|
And before anyone asks: yes, that weird strip of brighter/colder light near the LEDs is real, and either a pretty serious design defect, or Kobo's QA team is entirely composed of blind monkeys. At least I knew what I was getting, so, my expectations were suitably lowered ;). |
koreader-kobo-arm-linux-gnueabihf-v2015.11-stable
(launch with KFMon-v1.2.6-1-g9ab7d3a)
Kobo Forma
(firmware version: N782890001425,4.1.15,4.11.11911,4.1.15,4.1.15,00000000-0000-0000-0000-000000000377)
Issue
In new released Kobo Forma, when launching Koreader, it crashed right away, reporting "unrecognized Kobo model frost".
Complete detailed log:
crash.log
Steps to reproduce
After installed, try to launch Koread, it will crash with above crash log.
crash.log(if applicable)./luajit: frontend/device/kobo/device.lua:177: unrecognized Kobo model frost
stack traceback:
[C]: in function 'error'
frontend/device/kobo/device.lua:177: in main chunk
[C]: in function 'probeDevice'
frontend/device.lua:37: in main chunk
[C]: in function 'require'
frontend/ui/uimanager.lua:1: in main chunk
[C]: in function 'require'
./reader.lua:92: in main chunk
[C]: at 0x0000bea5
The text was updated successfully, but these errors were encountered: