Wezterm windows hang when launched under chromeos's crostini

[dberlin]

What Operating System(s) are you seeing this problem on?

Linux Wayland

Which Wayland compositor or X11 Window manager(s) are you using?

ChromeOS implements a wayland proxy compositor known as somellier

WezTerm version

latest

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

So when launched under chromeos's linux containers, most wayland apps work fine. However, wezterm hangs.

What is happening under the covers is that it is waiting for a configure event after creating the window, but the event never comes. This is true regardless of backend (Software, OpenGL, WebGpu). This is true regardless of window decorations between server or client or none. enable_wayland = false works fine.

I actually implemented support for wayland's activation protocol (since it was like 5 lines of code) but it turns out the proxy compositor doesn't use it.

I also played around with where commit is called, no luck.

Note that all of the smithay client toolkit examples work fine and happily show windows.

Logs at the trace level show nothing interesting. Happy to debug on my own, produce logs, etc, if anyone has any ideas on where this might be going wrong.

To Reproduce

No response

Configuration

no config

Expected Behavior

Wezterm is visible

Logs

No response

Anything else?

No response

[dberlin]

So this is caused by the get_keyboard call in the seat state handling. As soon as that happens, everything stops. If i move it to happen after window creation, we get the configure, but everything still stops after the get_keyboard call.

The toolkit examples use the keyboard functionality of the toolkit, and work.

Once we receive the keymap and repeat info, everything dies :)

0.8206 A: [email protected](format=1:xkb_v1, fd=fd 23, size=47395) ↲ 0.8206 A: [email protected]_info(rate=20, delay=500) ↲

When we try to read the keymap, we think it's a pipe but it's not, and get stuck forever.

What is happening is that later versions of the protocol require that we mmap the file descriptor, so neither read_at nor treating it like a pipe work.

I have working versions of two fixes:

1. We move to using they smithay toolkit's keyboardhandler (under the covers it uses xkbcommon::xkb::new_from_fd which mmap's the file), and get rid of the low level handling we use. This is a big hammer, and just moves the problem of keeping up with whatever we have to do here to the toolkit, and we will never see it again. There is a pretty darn close mapping between the handler events and what we need. The only slightly annoying thing is dealing with modifiers (we don't get the masks, so we have to move to using xkb's update_key)

or

2. We use the xkbcommon::xkb::new_from_fd on the keymap we get ourselves, and change nothing else. This works now but who knows what the protocol will do next.

(Of course, i can submit PR's for both and we could just start with #2 and move to #1 later or whatever)

[github-actions[bot]]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.