Skip to content
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

Add update_keymap method that's called when server provides keymap #299

Merged
merged 1 commit into from
Nov 9, 2022

Conversation

ids1024
Copy link
Member

@ids1024 ids1024 commented Sep 19, 2022

This is meant to provide a way to address
pop-os/xdg-shell-wrapper#8, in combination with Smithay/smithay#750.

This is currently potentially unsound due to the
unsafe impl Send for KeyboardData {}. xdg::Keymap uses non-thread-safe ref-counting, but sctk assumes it is only used from one thread. This is difficult to address.

ids1024 added a commit to pop-os/xdg-shell-wrapper that referenced this pull request Sep 19, 2022
Fix for #8, though due
to #10, changes to the
selected layout group aren't forwarded from the server.

Requires Smithay/client-toolkit#299 and
Smithay/smithay#750.

I believe this results in unregistering the `wl_keyboard` and creating a
new one. Having a way in smithay to alter the existing `wl_keyboard` may
work better.

The above PRs also have soundness issues due to the non-thread-safe
ref-counting in xdgcommon, and how smithay/sctk assume they
hold the only references.
This is meant to provide a way to address
pop-os/xdg-shell-wrapper#8, in combination
with Smithay/smithay#750.

For soundness reasons, and to avoid allocating when unused (in most
clients), this has an awkward API that provides a way to get the keymap
as a string.
Copy link
Member

@i509VCB i509VCB left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks fine to me. Is this still a draft for a reason?

@ids1024
Copy link
Member Author

ids1024 commented Oct 6, 2022

The API isn't great here, but I don't know if anything better is really possible. Otherwise this should work fine. (While I think Smithay/smithay#750 isn't quite right.)

@ids1024 ids1024 marked this pull request as ready for review October 6, 2022 01:40
@i509VCB
Copy link
Member

i509VCB commented Nov 7, 2022

I don't see anything else that would need to be done, @ids1024 are you fine with this being merged or do you have some new idea to handle this.

@ids1024
Copy link
Member Author

ids1024 commented Nov 8, 2022

Merging it seems good to me, given it's useful to support and I can't really think of a better way to do so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants