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

Wayland platform issue when using WAYLAND_SOCKET #728

Open
colin-pm opened this issue Aug 22, 2024 · 1 comment
Open

Wayland platform issue when using WAYLAND_SOCKET #728

colin-pm opened this issue Aug 22, 2024 · 1 comment
Assignees
Labels
bug Something isn't working

Comments

@colin-pm
Copy link

I noticed in the cog 0.11.1 that using cog with a Wayland socket specified via the environment variable WAYLAND_SOCKET, cog no longer displays the loaded page. Using WAYLAND_SOCKET was confirmed to be working in 0.10.1. I've also verified that this problem exists up to cog 0.18.2.

I did some investigation into this and tracked down the regression to #320, specifically commit a7a65f1. My understanding is check_supported, added to platform/fdo/cog-platform-fdo.c, will call init_wayland, which will bind to the socket passed via environment variable. I believe the problem is when clear_wayland, or wl_registry_destroy/wl_display_disconnect, is called, the socket is closed when the display is destroyed/disconnected.

I've patched this issue downstream for now by adding a simple check at the beginning of check_supported to return true if WAYLAND_SOCKET is in the environment. This is probably not the most elegant fix, so I was hoping to report this issue upstream to see if anyone has any better ideas how to solve this problem.

@aperezdc aperezdc added the bug Something isn't working label Aug 26, 2024
@aperezdc aperezdc self-assigned this Aug 26, 2024
@aperezdc
Copy link
Member

@colin-pm Good find! I have to check if there's some way of avoiding that wl_display_destroy() would close the socket, but I am afraid it may not possible. Maybe calling dup() on the socket when WAYLAND_SOCKET is defined, and using the duplicated descriptor for the connection test would be a reasonable workaround.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants