Skip to content
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

Discover battery from sysfs #185

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jetomit
Copy link

@jetomit jetomit commented Aug 8, 2021

Hi,

this patch discovers battery status directory in sysfs based on the type attribute, avoiding the need to specify driver names for different models / firmware versions.

Some background: I’m using postmarketOS with the (close to) mainline kernel on Kobo Clara HD. I’ve been able to compile and run Plato on it, and it works beautifully. Some changes to the code are needed though; one is addressed by this PR.

The upstreamed battery driver has been renamed to rn5t618-battery. With this patch the same code should work on all devices and kernels, even if a new driver name is used in the future (I don’t have other devices to test with though). The only downside is a couple more syscalls at start.

Some other tweaks are needed to run Plato on a mainline kernel and a non-glibc distribution. I’m submitting this first because avoiding hardcoded names (and a dependency on environment values) seems useful in itself. If you agree, I’d like to send further patches to improve compatibility with mainline, at least where it’s possible to do so without affecting the current use cases.

Thanks!

Instead of hardcoding driver name based on firmware version, search
for directory with type “Battery” under /sys/class/power_supply.
ticky added a commit to ticky/plato that referenced this pull request Jun 3, 2022
fixes baskerville#237 (though baskerville#185 is possibly a more robust solution!)
Copy link
Contributor

@puffnfresh puffnfresh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks really good to me. This approach makes a lot more sense than hardcoding a bunch of paths. This would help me out since I run mainline Linux on Kobo Clara 2e.

@puffnfresh
Copy link
Contributor

@jetomit I'm interested in your other patches. Would you be willing to push whatever you've got to a branch? I've been modifying Plato independently to function better on my mainline Linux Kobo Clara 2e.

@jetomit
Copy link
Author

jetomit commented Feb 26, 2023

I'm interested in your other patches. Would you be willing to push whatever you've got to a branch?

I rebased and cleaned up my patches a bit, and pushed them to https://github.com/jetomit/plato/tree/pmos-mainline. Commits are ordered from mostly harmless to horrifying. The first three commits should not break anything, but I only tested with my setup (Kobo Clara HD running postmarketOS with mainline kernel).

The next commit fixes multitouch event handling. IIRC this was necessary because the new version of the touchscreen driver updated the protocol, so this might not work with older Kobo kernels. The code is somewhat convoluted so it might be good to check it again.

I added a build.sh native command to use the native compiler and link against system libraries. In this configuration, the #cfg macros for mupdf selected the wrong symbol names, so I just removed those, and also updated the symbols for the new version of mupdf.

The final two commits switch to the DRM-backed framebuffer in the mainline kernel. This handles refreshes based on changed screen areas and works pretty well. Framebuffer rotation isn’t supported yet, so I fix the coordinates manually in set_pixel. Because of this the display is slow, or at least slower than stock interface, though still usable for reading.

In some cases the display gets messed up and needs a full refresh. I suspect some more tweaks are needed for Plato to work with a simple (non-eink interface) framebuffer. I also tried SDL with the kmsdrm driver, but it was extremely slow. It might however be a better option in general since it uses the DRM device directly without framebuffer emulation.

When running the modified version, the files in scripts/ should be edited as well, particularly for switching wifi and suspending. With that it works at least well enough that I haven’t touched the code in over a year. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants