-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for warmth control on Tolino Shine 4 #410
Comments
Please follow instructions in koreader/koreader#8482 |
Thanks @pazos, for pointing me to that issue. I tried the steps there but unfortunately couldn't get the warmth control to work with any of the drivers. I had to run the ActivityTest using ADB, since the menu item wasn't available, so it seems like KOReader doesn't recognize my device as Android? The tolino drivers (NTK and "Root") manipulate brightness well, but no warmth. Here is my device info, and I've attached the log file test.log
Additional device info: Happy to do whatever I can to try and make this work. Not too good with Java or C though. But easy edits I can try myself. Testing in any case. |
@pazos I would be happy to have another go at this, since I love the little device and koreader, but the lack of full dim (koreader/koreader#11013), and the missing warmth control are a bit annoying. From the log above, and further testing on a rooted device, the crux seems to lie in
Let me know what I can do to help here. Happy to put in some time coding and testing |
I can never keep track of the Tolino boards, but it looks like a Clara 2E, so try with Basically, check the Kobo code, find the closest matching board, and poke at the sysfs until you find the right one. NTX thankfully hasn't used that many different PWM controllers, so it shouldn't take long. |
I'll give that a try. How would I best test the different files? Do I need to rebuild Koreader every time I want to do that? Or is there some way for me to hotfix using a config? |
Err, just poke at it in a shell to begin with, KOReader doesn't have to enter the equation until you've got the right paths ;). At which point, you also don't need to rebuild anything, it's Lua, since you're root, you can just replace the affected files in place, wherever they are on Android (/data/something, IIRC). |
Hm, I'm finding the right file (it is indeed I would like to avoid breaking things for users that do not have a rooted device, so I think I should add a switch for that somewhere in the lightsfactory — do you have a way for me to easily test for root? Finally, I was also testing the ntx controller, and it fails because of |
Not needed. The class is called TolinoRoot for a reason :) |
That ID seems to be "stable" (as EDIT: Especially since your device is not using that controller ;p. (On Kobo, warmth is always handled via sysfs). |
Hm, maybe I am a bit dense here, but I am trying. @NiLuJe, I am trying to replace the lua file that contains the RootController, but I can't seem to find that one in the apk (so I can hotfix it to test any changes). I think I am missing something/am misunderstanding you @pazos so I should just set TolinoRootcontroller as the controller for Tolino Shine 4 (independent if the user is root)? As far as I can tell, changes need to be made to DeviceInfo and LightsFactory — any other obvious place I am missing? (along with the changes to TolinoRootController, of course) |
KOReader on Android debugging a little rough. You need to build new apk with these changes to test. Let me know if I can help you set up the build :D |
You can just overwrite Lua files directly (e.g., over adb), since you're root. No need to build a full APK just to tweak a few Lua scripts ;). I don't have access to adb right now, but once you've got the right app folder in /data or whatever, the directory tree is nothing special. |
It is Lua files can be edited there. When making edits (like I do in WinSCP) keep in mind that some files might change their owner and group after edits. KOReader doesn't like this so you need to restore them. All files have the same owner/group for KOReader files. LightsFactory.kt and the rest related to android-luajit are not there though. |
Oh, right, for some reason I was stuck in powerd-land in my head. Yeah, if you're tweaking actual Kotlin sources, you'll need a full build ;). |
Too much noise in here :) There's no lua code to tweak here. What needs to be done is
Since both @mergen3107 and @hugleo are quite active lately and both have a working KO/android environment on their machines feel free to submit a PR (and an APK for OP to test) Otherwise we will wait for @robintschoetschel work. |
Thanks for the summary. I'll wait for a bit to see if either of the two reply. If they aren't keen on this task, I'll have a crack at it |
@robintschoetschel |
https://disk.yandex.com/d/SFeGytllDxZwdQ |
Thanks for the quick attempt. The device is marked as supported, but unfortunately, neither lights nor refresh works (on the second file you posted). See the attached log. I think it sill uses the wrong color file, which should be Using the first file, the device is still shown as unsupported, and the dimming works; warmth does not |
Does your device is rooted? Is as permission problem. Check these two new versions if you will get better logs: |
I have root, KoReader asks for it, and I have granted it. Your link is broken, it seems. |
Oh, maybe they deleted already :(. I'll upload again later. |
Looks like a letter was missing. I try all the letter possibilities at the end and guess the correct link :) |
Sorry, no dice. There still are some permission problems. I checked to ensure I have root and can open all system files in KoReader's built-in text editor... |
Can you also check on shell if there is anything related to selinux? getenforce for test if needed: |
I'm using the built-in terminal emulator. I get "permission denied" errors following these commands. However, I can punch in After closing the shell, I can adjust warmth in the compatibility test. Dim doesn't work, nor refresh. And warmth doesn't work in normal use (outside of the compatibility testing environment). |
It should be this new one: |
For the brightness current is using the file: /sys/class/backlight/mxc_msp430_fl.0/actual_brightness |
Also good to see the logs from my V1, V2 again after the selinux change. |
Here are the two logs (V2 is the same as above). |
And the brightness files are |
cat /sys/class/backlight/mxc_msp430.0/brightness |
Yeah, they always have the same value. If I try to set "brightness" above 100, both get corrected to 70. Yes, the brightness file can be used for dimming |
Try this first: |
and for the /sys/class/leds/aw99703-bl_FL1/color the max value is 10, correct? |
Yes, correct. Here is a log from V3: test_permissive_V3.log I'm not sure what you mean by "see the correct dimming value" — but the slider doesn't reflect the value I set by changing the file (via adb) |
Try this: https://we.tl/t-EXAV1JQHH6 |
New log: The brightness seemed to be moving in the opposite direction? Setting it to 100 is 0 in the file, setting it to 1 is 69 |
That's odd. Was a quick coding, maybe I've missed something :) Then we finally have a drive skeleton. What I have so far:
@mergen3107 @pazos I think is better create a new driver or this can be refactored somehow? |
Thank you for your work! It's already a big improvement. Anybody an idea about how to get around the setenforce thing? I can write a little shell script to be run on boot, but it'd be more elegant without. The manual refresh doesn't work still; just to document that. |
One is technically wo (brightness), and one is ro (actual_brightness). i.e., there's a getter and a setter ;). (You might be able to read from As a historical note, |
In #410 (comment) OP stated that both drivers are OK for changing brightness, so no changes are required. Please keep it simple :) Also, no driver that requires disabling selinux will be commited. At that point please consider other routes, including noop. Because there're no reason for a particular app to request their users to harm themselves without any purpose. Better to avoid the feature completely, since it can be changed elsewhere.
That was also expected and won't be fixed here. Please keep this ticket focused on warmth. |
That's weird because the V1 from the message here #410 (comment) is the same @mergen3107 with some logs. @robintschoetschel Now with de sle permissive, can you test again the @mergen3107 from yesterday? #410 (comment) EDIT: As selinux stuff is not allowed, another path must be found :) |
Ok, back to the drawing board. No problem. I won't report on the refresh anymore, though. @hugleo the version in the comment you linked by @mergen3107 has neither warmth nor lights working... Here is the log: test_TOLINO_SHINE4_457_Version2_koreader-android-arm-debug-v2023.10-75-gc12b4f2e1_2023-12-27.log — I guess something broke already there? In stable/Ovis I can still dim without problems. And here is a log of your V4 with selinux back to default: |
@robintschoetschel: just do a build from master with #457 merged in. And start the test activity again from the new application. Then tell us if the test activity says "device supported" and which eink/light drivers are being used. |
I'm travelling and a bit busy with work, but will follow up on this later next week, thanks @pazos |
No activity, closing |
I saw you managed to get illumination color/temperature support working on the Tolino Shine 3: #400
As far as I can tell it could be done by adding a device tag here: https://github.com/koreader/android-luajit-launcher/blob/17901da600ec85b02d3f7dc0bd0ce0fc55a6aaec/app/src/main/java/org/koreader/launcher/device/DeviceInfo.kt
Let me know if I can help. I have the device.
Thank you!
And many additional thanks for an awesome app!
The text was updated successfully, but these errors were encountered: