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
boot: A few updates to LVGUI #285
boot: A few updates to LVGUI #285
Conversation
b1057be
to
f239ac3
Compare
Tested on I would hazard a guess that an updated GPU driver from a specific kernel fork I was using to test early was needed. That is, because it was confirmed to work with that kernel fork. Though, supporting To be clear: with that updated GPU driver it works as expected, and works just fine. |
Where more generic one-off helpers will be added
This probably should not have been added straight onto LVGL bindings, but that's where they're the easiest to implement safely. This allows a widget to take control of the focus group, while allowing the previous content to be re-added properly.
It was found, through some debugging, that we were adding a non-invisible dummy object for focus group handling. With this change we have a common dummy object to use for this purpose.
This way it's easy to just colour an element when visualizing its metrics.
A bit like a "drop down" select
This way it's trivial to *check* what is actually running on the device.
It breaks the DRM-based app, and anyway was bad on the fbdev app
Useless for this kind of system.
This does help finding weirdness in things being collected when they shouldn't
And also add notes when in simulator mode...
f239ac3
to
db56f5e
Compare
First, to the lvgui project itself:
libinput
as an input sourceDRM
before falling back tofbdev
Then, in LVGUI
libinput
supportCompared to
evdev
, really there shouldn't be any differences. Except in practice there is. One difference is that there is no need for a hack to detect the input type (touchscreen vs. mouse).Another is that
libinput
supports calibration matrices. It's not been needed for any in-tree devices, but an x86 tablet I own requires it (per-device though). While the support isn't in Mobile NixOS yet, it should be possible to add handle this.Additionally, working with libinput feels much better, as it does things like translate touchpad events to relative movements for you (me).
DRM
supportThis is a big one!
SDM845
devices, like the Pixel 3 family andrazer-cheryl2
don't have a workingfbdev
backend. Luckily, it seems Android works with DRM, and we also can. Furthermoreasus-dumo
actually has bad behaviours withfbdev
available, where the display cannot suspend/resume and gets into a bad place.It might not actually work as implemented right now. I still need to test on SDM845, but for
asus-dumo
it does work as expected.For SDM845 it might still require page flipping or something similar to be added. Though known working DRM sample programs exist, and were used as a basis for the reworked DRM driver.
toggle switch
The description is configured by the user. It does not automatically mirror the value, but it is trivial enough for the user to handle it by themselves.
It's meant to describe a boolean state (duh).
It will soon be used to optionally disable
kexec
ing into a generation's kernel from stage-0.select
It is meant to allow choosing one option among a list. It shows up as an overlay.
A few uses are thought of, but nothing concrete planned. It just felt right to implement it at this moment while working on this. It might be used in target disk mode to select a partition or disk to export.
TODO
razer-cheryl2