Mobileread
Where can i report bugs ?
#1  BloodRagg 03-05-2019, 10:30 AM
Where can i report bugs ? My kobo has no wifi and i have no github account.

the sftp-server is hardcoded in the dropbear binary as /mnt/onboard/.adds/koreader/sftp-server instead of ./sftp-server.

Reply 

#2  NiLuJe 03-05-2019, 11:20 AM
By design for... (annoying) reasons.
Reply 

#3  BloodRagg 03-05-2019, 02:20 PM
Ahh.. too bad...its the only file left in my .adds folder.

Some other bugs i found
Other than that, I'm really enjoying it
Reply 

#4  NiLuJe 03-05-2019, 03:16 PM
Running without Nickel or pickel or ntx_hwconfig is not a supported configuration. There's okreader for that .

(Handling those issues on our own would be fragile, error-prone, and basically reinventing the wheel for, again, an unsupported setup. Incidentally, that's why okreader's hardware support is limited).

As far as CPU schedulers go, it probably doesn't ship with interactive, that's to be expected, but it *should* offer ondemand, though.
In any case, on that front, the startup script is designed to do nothing if nothing sensible is possible on the current HW. Which might indeed be the case on <= Mk.5 devices, given how defensively I coded that after a few rounds of tests on various older models.
Reply 

#5  BloodRagg 03-06-2019, 05:47 AM
Quote NiLuJe
Running without Nickel or pickel or ntx_hwconfig is not a supported configuration. There's okreader for that .
OKreader ... Ohh nice
Im still using ntx_hwconfig and the koreader.sh suggests otherwise (see reboot clause), but ill take your word for it . BTW this support isn't for me, i just wanted to contribute something back. I will setup a github account and do some PR's if i can find the time.

What is do not understand though is why one would use the variables from rcS instead of relying solely on ntx_config. Because when i look at the default rcS

Quote NiLuJe
(Handling those issues on our own would be fragile, error-prone, and basically reinventing the wheel for, again, an unsupported setup. Incidentally, that's why okreader's hardware support is limited).
I always reinvent the wheel, then you have something to bring to the table later on

Quote NiLuJe
As far as CPU schedulers go, it probably doesn't ship with interactive, that's to be expected, but it *should* offer ondemand, though.
In any case, on that front, the startup script is designed to do nothing if nothing sensible is possible on the current HW. Which might indeed be the case on <= Mk.5 devices, given how defensively I coded that after a few rounds of tests on various older models.
Yeah that is weird isnt it, but ill give you the ouput
[root@(none)]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
conservative powersave userspace performance

Reply 

#6  pazos 03-06-2019, 07:54 AM
Quote BloodRagg
OKreader ... Ohh nice
Im still using ntx_hwconfig and the koreader.sh suggests otherwise (see reboot clause), but ill take your word for it
Running KOReader by using other launcher is supported (ie: launching KOReader via telnet/ssh) but KOReader expects a working Kobo filesystem (including their "weird" drivers path and their binaries)

Quote BloodRagg
What is do not understand though is why one would use the variables from rcS instead of relying solely on ntx_config. Because when i look at the default rcS
Repurposing system environment variables is a good thing on a device which should retain compatibility with stock firmware and other 3rd party software.

If you want to make KOReader available on other kind of systems you can create a "koreader-standalone.sh", like we do on BQ Cervantes devices: https://github.com/koreader/koreader/blob/master/platform/cervantes/koreader-standalone.sh and get your environment variables there.
Reply 

#7  Frenzie 03-06-2019, 09:26 AM
Quote BloodRagg
Ahh.. too bad...its the only file left in my .adds folder.

Some other bugs i found
Some of those may be easy to fix (especially the first one strikes me as most likely a complete non-issue), but you'd have to do it through a PR and/or giving us a backtrace. (Read: I'm not going to strip my device of Nickel stuff, even if this particular change could probably be tested with a quick rename. )

PRODUCT and to a lesser extent WIFI_MODULE seem to located more in the realm of fundamental necessities. I have considered implementing a "generic fallback Kobo" with a warning message instead of erroring out (so that in some cases a new device could work out of the box) but that'd still depend on the presence some Kobo stuff regardless.

Screen upside down might well be an issue in KSM at the moment with NiLuJe's latest 8-bit change, see here.
Reply 

#8  NiLuJe 03-06-2019, 12:29 PM
(Nope, upside down is because pickel/Nickel hasn't been run and as thus the device is in the boot rota, which we never expect/support).
Reply 

#9  Frenzie 03-06-2019, 12:53 PM
KOReader isn't upside down, but it turns KSM upside down on exit due to fbset.

This line here also needs to restore rotation afterward due to the issue I linked:
https://github.com/koreader/koreader/blob/dc829d02236d104b43011b77b258e73739b06238/platform/kobo/koreader.sh#L211-L214
Reply 

#10  NiLuJe 03-06-2019, 01:03 PM
Ha, that's another thing entirely, I missed the gitter link, and was talking about the OP's report only .

Unlike fbset, fbdepth tries *really hard* to keep the rotation as-is, kernel shenanigans included (easier said than done ;p). I'd be curious to have a look at the crash.log on an affected system (since fbdepth will log everything in there)!

EDIT: Ah, and the messed up FBInk prints quite possible make sense in that context, I overlooked that, I'll have to think about how to handle that...
Reply 

  Next »  Last »  (1/4)
Today's Posts | Search this Thread | Login | Register