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

boot/gui: Use libffi rather than bespoke bindings #149

Merged
merged 11 commits into from May 24, 2020

Conversation

@samueldr
Copy link
Member

samueldr commented May 23, 2020

This is a mostly transparent change.

This uses the updated mruby-lvgui that uses mruby-fiddle, which uses libffi rather than writing bespoke bindings for LVGL.

Why make this change if it changes nothing? To reduce the surface of mistakes. I am not a C developer. Probably always be uneasy writing C. Some bits of the bindings already were iffy.

The only bit I'm not happy with, but I am satisfied with, is the struct bindings. Fiddle does not have a way to describe nested structs. (Neither does the ruby mainline Fiddle.) LVGL uses nested structs for styles. To work around the issue, accessor functions in C have been generated. It's not clean, but it's working in a correct manner, which for the best.

It already was an issue with the previous bindings, and still is with the Fiddle-based bindings, there is no proper deallocation / destruction for LVGL objects. Not much of an issue for what can be called "short lived applications", but still something to get fixed for correctness in the future.

But still, why? The code worked, and seemingly was right. Let's gloss over "seemingly", and go to a more useful reason. Using FFI bindings, rather than relying on a spaghetti mess of generated code for bespoke bindings, should allow us to more easily implement the missing functionality from LVGL, and doing it correctly.

Furthermore, having everything prepared for FFI bindings gives us freedom for non-LVGL related things. The key-held applet should be retooled to use FFI bindings on evdev, rather than rely on a hack using the evtest command.


Other notable changes

Bloat?

The initrd doesn't use pkgsStatic anymore. Fiddle uses dlsym to discover symbols by name, and this doesn't work with a static musl libc.

This doesn't bloat the initrd, compressed or not. The compressed boot image for asus-z00t is now smaller.

before: 16148480
now:    16140288
saved:      8192

The main space consumer is systemd libraries, used by udev, which already were using "normal" glibc builds, so this is why there is no bloating; everything pretty much already was in there.

samueldr added 6 commits May 19, 2020
Thus re-using buildInputs from gems, thus closing the circle.
Bindings to libffi, with (approximatively) the same API as the Ruby
Fiddle stdlib.

This uses a fork with fixes, and hopefully improvements and
maintainership in the future.
Otherwise we lose dependency management on transitive dependencies.
@samueldr samueldr force-pushed the samueldr-wip:feature/lvgui-ffi branch from 31f368a to 98b06a8 May 23, 2020
samueldr added 2 commits May 22, 2020
Can be launched with `DEBUGGER="gdb --args" ./result/bin/simulator`.
@samueldr samueldr force-pushed the samueldr-wip:feature/lvgui-ffi branch from 98b06a8 to 01a2488 May 23, 2020
samueldr added 3 commits May 22, 2020
This ends up saving ~100KiB. Not much, but we're already 1MiB over the
~7-8 MiB budget.

Though, in reality, it's not for the space saving, but because
dlopen/dlsym will be needed for ffi-based bindings.
Main changes are:

 * Dynamic build support
 * Minimal introspection
 * "better" makefile which handles the .pc file
@samueldr samueldr force-pushed the samueldr-wip:feature/lvgui-ffi branch from 01a2488 to cebc037 May 23, 2020
@samueldr samueldr merged commit 4db9f2a into NixOS:master May 24, 2020
3 checks passed
3 checks passed
Parse_nix
Details
Documentation
Details
Instantiation
Details
@samueldr samueldr deleted the samueldr-wip:feature/lvgui-ffi branch May 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

1 participant
You can’t perform that action at this time.