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

Update wayland keymap handling for protocol 7+. #5397

Merged
merged 1 commit into from
May 10, 2024
Merged

Conversation

dberlin
Copy link
Contributor

@dberlin dberlin commented May 9, 2024

Newer wayland protocol expects us to mmap the keymap file
descriptor (and do so with certain mmap flags).

The current code tries to handle both normal files and pipes,
but neither will work in some cases.

This updates the code to use xkbcommon's new_from_fd,
which is what the toolkit uses, and mmap's the file.

This fixes #5393, which was caused by hanging when
trying to read the file as if it was a pipe.

@dberlin
Copy link
Contributor Author

dberlin commented May 9, 2024

I'm also happy to add new_from_fd to Keyboard/KeyboardWithFallback instead of converting to string and back if we want.

I'm just about to submit a PR to rewrite the keyboard handling to use the toolkit, so i didn't bother.

(The API guarantees that converting it to a string will result in a valid keymap, so it either fails during new_from_fd, or it will successfully convert to a string and back)

Copy link
Owner

@wez wez left a comment

Choose a reason for hiding this comment

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

Thanks for diving in!

I'm just about to submit a PR to rewrite the keyboard handling to use the toolkit, so i didn't bother.

Let's talk about that before you put in any significant effort on it, as we are deliberately not using sctk's handling because it, once upon a time, had significant issues with repeat handling.

Otherwise, this PR looks OK to me; just one minor comment about preserving more context in an error message.

Err(err) => {
log::error!("Error processing keymap change: {:#}", err);
log::error!("{}", err);
Copy link
Owner

Choose a reason for hiding this comment

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

Please restore the original error formatting here; the additional context is useful and error messages tend to render better as {err:#}.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Whoops, though i reverted that, but must not have staged it, will fix again and push.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Should be fixed now

@dberlin
Copy link
Contributor Author

dberlin commented May 10, 2024

Thanks for diving in!

I'm just about to submit a PR to rewrite the keyboard handling to use the toolkit, so i didn't bother.

Let's talk about that before you put in any significant effort on it, as we are deliberately not using sctk's handling because it, once upon a time, had significant issues with repeat handling.

Sure. It was like 1-2 hours of work, and was a good intro to the wayland internals of both anyway, so if it ends up not being usable, that's fine - it was a good learning experience.

Newer wayland protocol expects us to mmap the keymap file
descriptor (and do so with certain mmap flags).

The current code tries to handle both normal files and pipes,
but neither will work in some cases.

This updates the code to use xkbcommon's new_from_fd,
which is what the toolkit uses, and mmap's the file.

This fixes wez#5393, which was caused by hanging when
trying to read the file as if it was a pipe.
@wez wez merged commit 5b0b657 into wez:main May 10, 2024
14 of 15 checks passed
@wez
Copy link
Owner

wez commented May 10, 2024

Thanks!

@wez
Copy link
Owner

wez commented May 10, 2024

re: toolkit keyboard, if you think that it has some advantages over what we're doing currently and already have something we can discuss in a PR, that's great. Otherwise, I'd like to discuss what you think the advantages are before you spend too much time on it--I don't want you to feel like you've wasted your own time!

Thank you!

@dberlin
Copy link
Contributor Author

dberlin commented May 10, 2024

re: toolkit keyboard, if you think that it has some advantages over what we're doing currently and already have something we can discuss in a PR, that's great. Otherwise, I'd like to discuss what you think the advantages are before you spend too much time on it--I don't want you to feel like you've wasted your own time!

Thank you!

I'll create a PR and we can discuss. I did it more to try to see what was going on than anything else, so if we decide it's not worth it, or won't support what we need, it really is no big thing.

If I was going to spend days on it, I would have started a discussion beforehand so i didn't throw away a lot of work :)

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.

Wezterm windows hang when launched under chromeos's crostini
2 participants