riverwm
Input: Enable/disable numlock per keyboard
e.g. riverctl input keyboard-1-1-foo numlock enabled
This is a per keyboard config, adjusting InputConfig a bit to also accommodate keyboard stuff.
I could also imagine to separate the keyboard config from the pointer config with a separate command and type.
Addresses #407
[18:05:31]<[leon-p]> hmm... I don't think numlock state fits into the InputConfig abstraction...
[18:06:16] [pkap] has quit
[18:06:22] <[leon-p]> for one, InputConfig was designed for libinput configuration, where "not configured and has arbitrary default" is a valid state (that's what the null is for)
[18:06:56] <[leon-p]> that doesn't make sense for numlock though, as it's always either on or off and we definitely know the state
[18:08:27] <[leon-p]> also I personally don't consider numlock state an input device configuration; Changing numlock state is a normal operation during keyboard usage; Just as Shift or Control aren't really configurations.
Yeah I agree that it is not really fitting together with the libinput configurations.
But I would consider it an input device configuration, because of the people who want numlock enabled on plugging a keyboard in.
What do you think about the following? Hook into the keyboard initialization only and do not change the current state. This way it'd be a "pure" configuration state. And I think it would cover the more important use case, because people who want numlock enabled somewhen later can just hit the numlock key.
What do you think about the following? Hook into the keyboard initialization only and do not change the current state. This way it'd be a "pure" configuration state. And I think it would cover the more important use case, because people who want numlock enabled somewhen later can just hit the numlock key.
Do not forget that there is no guarantee your init will enable numlock before river detects all keyboards. I believe enabling numlock on startup is your main focus here.
Do not forget that there is no guarantee your init will enable numlock before river detects all keyboards. I believe enabling numlock on startup is your main focus here.
Ah yeah, I didn't think about that. The inputs are already initialized when the init file is executed.
Actually my comment was not critiquing the feature, I was just arguing that it doesn't fit into InputConfig. For the reasons listed as well as because for libinput input devices (which is basically everything except keyboards, game controllers and super abstract / niche things), configuration is per device, while for keyboards configuration is per wl_keyboard, meaning per seat.
So instead of making the feature fit the abstraction, I think it might make a little more sense to just not use InputConfig for this.
What do you think about the following? Hook into the keyboard initialization only and do not change the current state. This way it'd be a "pure" configuration state. And I think it would cover the more important use case, because people who want numlock enabled somewhen later can just hit the numlock key.
Not a fan, TBH.
Here is how I see it:
Rather than treating numlock as a per-device configuration, we should treat it like what it actually is: a per seat state, since a seat has a single wl_keyboard all physical keyboard devices attached to the seat are combined into. With this model, the command here is actually just a single logical action: Enabling / disabling numlock for a seat, which will affect all keyboards currently and future-ly attached to it. Effectively the option would just do the same as a user pressing the physical numlock key. This also has the advantage, that the numlock keys behaviour is expectable. This is what I meant with "I personally don't consider numlock state an input device configuration"; It's a state, not a configuration.
In other words, the command should not be described as "enable numlock for all current keyboards and set it as the default for all future keyboards", instead it is better described as "enable/disable numlock for this seat, which simply happens to apply to all current and future keyboards per definition".
As an aside, maybe we should have a riverctl seat [...] toplevel command for all seat related configuration, which would include the numlock thing as well as other keyboard configs, like repeat rate, and general seat related things.
Ah I see what you mean. Thanks for the detailed explanation!
I like the idea of a per-seat configuration. However I'm not sure if we should completely rule out the use case where you want different configs for each keyboard.
Am 3. Mai 2022 06:53:59 MESZ schrieb Peter Kaplan @.***>:
However I'm not sure if we should completely rule out the use case where you want different configs for each keyboard.
Per device config for keyboards isn't really a thing. Sway does it by constantly reconfiguring their wl_seat, but I consider that to be a bit of a hack and honestly not worth the effort.
friendly greetings, Leon Henrik Plickat
Wouldn't the keyboard configuration we need be done with xkbcommon and is this not per keyboard? (Except repeat rate/delay).
I"m thinking here that we wouldn't need all the layout stuff that sway has because we can define layouts with XKB_DEFAULT environment variables.
Am 3. Mai 2022 16:54:38 MESZ schrieb Peter Kaplan @.***>:
I"m thinking here that we wouldn't need all the layout stuff that sway has because we can define layouts with XKB_DEFAULT environment variables.
The env vars aren't ideal, i'd rather replace them with config options
Am 3. Mai 2022 16:54:38 MESZ schrieb Peter Kaplan @.***>:
Wouldn't the keyboard configuration we need be done with xkbcommon and is this not per keyboard? (Except repeat rate/delay).
Clients do not know anything about physical keyboards, only wl_keyboard instances, of which there are (at most) one per wl_seat. So the xkbcommon configuration is in fact not per device, but per wl_seat (technically per client, but that is pedantic and not particularly useful).