Allow using deckbd for password entry during boot #382
Conversation
hacker1024
force-pushed
the
feature/deckbd
branch
from
d76969b
to
97492c9
Compare
hacker1024
changed the title
|
Amazing - I myself wanted this feature from the moment that I had steam deck in my hands. |
hacker1024
force-pushed
the
feature/deckbd
branch
from
b4e4cfd
to
7b3acee
Compare
|
Rebased to resolve merge conflicts. |
# Conflicts: # overlay.nix # Conflicts: # overlay.nix
hacker1024
force-pushed
the
feature/deckbd
branch
from
7b3acee
to
377912d
Compare
|
[last push seems to be a mostly uneventful rebase on development] |
|
As a courtesy I wanted to ping |
samueldr
added
2. priority: 2. normal
2. topic: system integration
| jovian.devices.steamdeck = { | ||
| fde = { | ||
| deckbd = { |
There was a problem hiding this comment.
Hmmm... not sure about the jovian.devices.steamdeck.fde.deckbd namespace...
I don't have a suggestion at the exact moment, but it's less directly about FDE, but about a device-specific tool and integration to make FDE work, so maybe it should be categorized as such. 🤔 Any thoughts?
There was a problem hiding this comment.
My reasoning was that the launch is directly tied to FDE-related password prompting services. I too can't really think of a better name - I'm open to suggestions.
There was a problem hiding this comment.
(You don't need to do anything. I'll handle moving the option[s].)
So I've spent a few more minutes thinking about it. I think I know why I found the namespacing off. No options in NixOS uses the fde wording, even the word “encryption” isn't used by the NixOS docs around that. (And uuuuh... that's another issue to solve, just an observation.)
Now, couple that with this being a device-specific "service". We have a single one at the moment (jovian.devices.steamdeck.enableGyroDsuService), and it too I think is somewhat miscategorized. (Side-note, this other option was moved since its inception, and was "grandfathered-in" into the steamdeck namespace instead of being globally awkwardly available...)
So, what I want is thoughts about my thought:
Let's have jovian.devices.*.[some word].[tool name].[options]. I'm not sure if .services or .tools or what would be appropriate. Though I think it should encompass things like sdgyrodsu and other device-specific services.
My train of thoughts here is that being for FDE is an implementation detail; it's an input device "interceptor" service that is intended for usage in stage-1 for passphrase input. And it's not strictly limited to being a stage-1 tool. While there's no use-case yet, it could be used in the booted system, too, right?.
So I suppose the enable option might be better described as enableStage1 or /*...*/.deckbd.initrd.enable or something like that?
Sorry if that's a lot of useless stuff to consider / think of, and I know it's pedantry, but I don't want to just declare my pedantry as the way forward, I want to know if I'm missing something, or even if you think I'm wrong :).
There was a problem hiding this comment.
(side-note: I'll try to get this tested and verified on my system soon, and make it so the last issues are those tiny little details so it can be merged)
Until I reinstall once Jovian-Experiments/Jovian-NixOS#382 is merged.
|
I have made the button instructions more clear. |
| default = cfg.enable; | ||
| defaultText = lib.literalExpression "config.jovian.devices.steamdeck.enable"; |
There was a problem hiding this comment.
Oh, good thing I'm testing on my system, I missed this.
This can't be enabled by default. It should be considered an opt-in option from the end-user. Especially since it changes the existing semantics of the gamepad during boot.
| default = cfg.enable; | |
| defaultText = lib.literalExpression "config.jovian.devices.steamdeck.enable"; | |
| default = false; |
(And also because it will cause a sudden assertion failure when not already using systemd stage-1.)
| # Note: The lizard_mode parameter does not work as intended. The | ||
| # Steam Deck must also be manually put into gamepad mode by holding | ||
| # the menu button (≡) for a second. | ||
| preStart = "echo 0 > /sys/module/hid_steam/parameters/lizard_mode"; | ||
| script = "deckbd"; | ||
| postStop = "echo 1 > /sys/module/hid_steam/parameters/lizard_mode"; |
There was a problem hiding this comment.
I've dived into trying to understand why it wouldn't work "as expected".
First, here's what the lizard_mode parameter is documented to do:
This driver will disable the lizard mode when the input device is opened
and re-enable it when the input device is closed, so as not to break user
mode behaviour. The lizard_mode parameter can be used to change that.
This comment has aged poorly... That's only true for the original Steam controller... But still has interesting hints as to what is happening.
So, here's one reason why it "doesn't work" for the Steam Deck controller:
... Except that this is only about automatically enabling/disabling lizard mode on open. And that's why things gets kinda confusing fast.
When the parameter is changed live, this happens:
See how there's no check for the hardware in use? So, as long as the device is not opened, the switch will happen... EXCEPT it's not that easy...
If the device has been “forced” into gamepad mode, attempting to set it to lizard mode won't work.
In turn this is what the (≡) button does; it flips that flag:
(Though also notice how if lizard_mode is disabled, it will not be put into lizard_mode...)
So, to recap, for a steam deck, when the device is registered to the driver, if it was not already opened, it will be out into the mode set by the kernel module parameter:
If the device is not opened, changing the kernel module parameter will change the mode of the controller...
... unless it's been “put” into gamepad mode (via the ≡ button)
And the last situation where the lizard_mode parameter takes effect on the Steam Deck is when the hid_ll_driver interface for it is closed (which is of no importance for us here):
Did you get all that? :) (I'm still somewhat confused.)
|
Hmmm... This is awkward: {
specialisation = {
deckbd = {
configuration = {
samueldr.use-case.stage-1.chosen = "systemd";
jovian.devices.steamdeck.fde.deckbd = {
debug = true;
enable = true;
};
# XXX testing
samueldr.use-case.graphical-boot.flickerFree.enable = lib.mkForce false;
samueldr.use-case.graphical-boot.enable = lib.mkForce false;
boot.plymouth.enable = lib.mkForce false;
};
};
};
}My options there that are the one that enables systemd stage-1 without fuss, and then undoing some fanciness at boot to make debugging easier. So it should be relatively stock systemd stage-1 semantics here. |
There are a few options available when it comes to using an encrypted system partition on the Steam Deck.
For password-based solutions in particular, we have unl0kr for an on-screen keyboard during boot (works well, though runs in portrait, and does not work with Plymouth), as well as deckbd and deckrypt for mapping controller keys to keyboard input.
This PR allows using deckbd for password entry at boot. When the encryption password is requested, various buttons map to numbers ranging from 0-9, with L2 and R2 mapping to backspace and enter respectively. It runs nicely, though there are a few hiccups:
boot.initrd.systemd.enableare supported (it is possible to do it in another way, but systemd allows us to integrate more nicely with udev and the boot process in general).hid_steam'slizard_modeparameter cannot properly disable lizard mode on its own. The option button must be held for a second before password entry to truly enable gamepad input.deckbd is currently unlicensed.