-
-
Notifications
You must be signed in to change notification settings - Fork 47
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
[Contribution] qubes-system76-dkms (hardware enablement for System76 laptops) #5621
Comments
Assigning to @marmarek for review or other disposition. |
R4.0's dom0 (fc25) has too old rpm. But R4.1 (fc31) should be ok. |
Review as of strugee/qubes-system76-dkms@ddc7503: spec file and related files looks file. But please clearly separate upstream project from the packaging, otherwise it will be hard to update in the future. Two options:
I'm fine with either. Brief instruction for the first option
Brief instruction for the second option
|
@marmarek wonderful, thanks for the review! 🎉 So, the repository is actually a clone of upstream. As such the only thing that'll be needed for updating is |
The issue with the current approach is, looking at the repository you can't tell which file is qubes-specific and which not. And if someone modify upstream file, you'll get merge conflicts sooner or later. In fact, it is already the case for packaging related files - if upstream modify anything in |
The problem you're addressing (if any)
A number of System76 laptops come with LED keyboards which can be controlled via the keyboard in the out-of-the-box Linux distribution (Pop!_OS). However, this functionality does not work in Qubes because it lacks the out-of-tree kernel module used to control the LEDs.
Describe the solution you'd like
I have packaged the upstream System76 DKMS module as a Qubes Builder package. See https://github.com/strugee/qubes-system76-dkms. It's a little unclear from https://www.qubes-os.org/doc/package-contributions/ but AFAICT the idea is that if accepted as an official "QubesOS-contrib" module, the Qubes developers would distribute binary packages of this. Is that correct? That would be ideal since obviously Qubes OS-distributed binary packages can be trusted by users, but my distributing binary packages is much less useful because it's harder to trust me.
Where is the value to a user, and who might that user be?
The primary benefit of this is hardware enablement on these laptops. A secondary idea that I had that this packaging enables is changing the keyboard LED color to indicate security status; for example, the keyboard could turn red when the user put a window fullscreen (preventing a qube from faking the entire desktop since the keyboard color would be trusted). Or maybe the keyboard could just match the color of the currently selected window or something; there are a bunch of options here.
Describe alternatives you've considered
N/A
Additional context
I know the developers are getting pretty close to an initial testing release of Qubes 4.1, so if there's no time to review this I totally understand. Please let me know though so I know what the status is :-)
That being said it should be pretty quick to review. Upstream's source code isn't terribly complicated or anything like that. I just read through the code to check there wasn't anything overtly suspicious in there and called it a day.
Some notes, some from https://www.qubes-os.org/doc/package-contributions/#inclusion-criteria and some generally:
Relevant documentation you've consulted
N/A
Related, non-duplicate issues
None
The text was updated successfully, but these errors were encountered: