Maybe a script that finds every brightness in /sys, and set it to brightness_max? I don't know whether it would be useful to have that, as compared to manual testing. Plus it could turn on the flashlight. But maybe we could add an interactive approach (or even a menu) that tries different things?
maybe we could add an interactive approach (or even a menu) that tries different things?
Just in case you have a UI on the screen in mind: we assume that the screen may not be working at this point. The user is connected via telnet and can execute debugging tools that way.
So for now I would recommend to keep the commands separate without any menu), and once we have a few tools, and good workflows for debugging, we could put that into scripts which do more hand-holding to make it easier for users.
I think adding the msm-fb-refresher into the debug-shell hook is problematic because we will need to install the package in the chroot and it will enable the service.
Instead I suggest to add a simply flag in the fbdebug tool to perform the same ioctl pan operation, it will be just few lines of code and no additional package dependencies
Actually the service gets enabled in postmarketos-base right now (which means, postmarketos-base depends on the deviceinfo to be present for that other issue, we can't simply make the device package depend on the pmOS-base package that way, unless we change this!).
But I agree with you, we could add these few lines into fbdebug to make packaging simpler.
@ollieparanoid I've tried adding the fbdebug package to the dependencies of the postmarketos-mkinitfs-hook-debug-shell, but when I run pmbootstrap initfs hook_del debug-shell it doesn't uninstall the fbdebug package from the chroot.
I think we might need a file in the chroot, where the hook writes the additional files he want to add and the mkinitfs reads them.
Or do you have other ideas?
I've played with the idea at a very early state of the project to have a build() and run() function inside each hook, and the build() function would add the files to the mkinitfs while the run() function would be the one that gets executed when the hook runs in the initramfs. That approach would have the benefit of having only one file per hook.
But as it stands now, almost none of the hooks require any custom files, and we would need to refactor all existing hooks / support a second format etc.
I don't think my approach would be worth it and I would implement it like Alpine does it.
@ollieparanoid I've tried adding the fbdebug package to the dependencies of the postmarketos-mkinitfs-hook-debug-shell again, but with the changes in the PR #1247 and when the hook is removed both the packages are removed.
What you think, should we go for the ".files" solution anyway?
I think if we don't use the .files approach, we need to add logic to postmarketos-mkinitfs to include the fbdebug binary. But we need to add even more code for the .files apprach, and it will take us longer to test everything.
My recommendation would be doing it without the .files solution now, and maybe adding the .files idea after refactoring the initramfs code to make it easier to maintain (#1134 (closed)).