Implement keyboard LEDs #549
No reviewers
Labels
No labels
A: maintenance
A: question
B: not applicable
B: not reproducible
B: resolved
C: multi-DPI
C: protocols
C: rendering
C: XWayland
Kind/Bug
Kind/Feature
Reviewed
Duplicate
Reviewed
Won't Fix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
dwl/dwl!549
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "thanatos/dwl:keyboard_leds"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR implements keyboard LEDs to indicate caps lock, num lock, and scroll lock.
Haven't checked, but what's wlr_keyboard.name for virtual devices?, NULL?
The name is part of wlr_input_device rather than wlr_keyboard (that's why I'm keeping track of it separately in the Keyboard struct), so it's not applicable to virtual devices as far as I'm aware.
I asked in #wlroots and turns out that the correct way to handle this is using
wlr_keyboard_group, are you interested in implement itSure, I'll take a crack at implementing that.
OK, that commit has the keyboard groups implemented. All keypresses are now handled through groups rather than individual devices, and virtual keyboards are each being placed in a group by themselves. This saves us having to handle both groups and individual device key events, since everything is grouped. The LEDs work out of the box when the keyboards are grouped, so I removed the LED logic I had added.
Is
Keyboardused at all?, if not we can remove it (the data field for wlr_input_device.destroy is the input device itself)The virtual keyboards need to be in a exclusive group?
What about having a global KeyboardGroup?
To be more specific, we have Keyboard to handle key presses for different keyboards, now that all is managed by wlr_keyboard_group we don't have to distinguish between different keyboards thus making it useless, for example, pointer events are managed by wlr_cursor and not for each different pointer
On further inspection, the stuff I put in cleanupkeyboard is redundant, so we can remove the Keyboard struct.
That would be a good one to ask in the wlroots IRC. I did it that way based on what the implementations I was looking at did, but I don't know if there's a specific reason for sectioning them off. I tested adding a virtual keyboard (wf-osk) to the group with my physical boards, and it works just fine as far as I can tell, but I can't say definitively one way or the other.
That would be possible, and it would simplify things, as long as virtual keyboards are OK to include.
I can't find any reason for virtual keyboards to need to be kept separate, so I went ahead and changed to using a global KeyboardGroup instance for everything.
ad10902ed3to55f7c8b52cI fixed a typo and deleted a extra blank line.
I'll be testing a few days before merging.
We could probably also remove KeyboardGroup but I'll leave that for another time.
Also, I feel like we could squash all the commits, or at least the first and second ones
I think we should squash them all, personally, unless there's some benefit to keeping the 2nd around (the 1st and 2nd should probably be squashed regardless, since the 1st was entirely replaced)
Ah, almost forgot, please also update the docs for keypressmod and remove the calls to wlr_seat_set_keyboard() leaving only one call when creating the group (you'll need to move the seat creation above it)
Which docs are you referring to? I'm removing the block comment about the seat only being able to have one keyboard, as that's no longer relevant, is there something else related to keypressmod that needs an update?
Hm
Only that, I wanna keep the comment about only one keyboard, but I'm not quite sure where put it, remove it and I'll re-add it later
I could add one about the limitation where I'm assigning the group keyboard to the seat in setup, if that would be a good place to document it.
Sounds good
Just these little things and everything is done
@ -1437,3 +1397,1 @@* wlr_seat handles this transparently.*/wlr_seat_set_keyboard(seat, kb->wlr_keyboard);* pressed. We simply communicate this to the client.*/Missing space before
*/@ -2337,0 +2331,4 @@*/wlr_seat_set_keyboard(seat, &kb_group.wlr_group->keyboard);Extra blank line
0bba6420f1to023efce6ebFixed another typo and squashed all the commits
Do you want to add more details to the commit message?
No, I think that commit message covers it.