-
-
Notifications
You must be signed in to change notification settings - Fork 6.3k
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] black screen when starting fullscreen #20629
Comments
the very first configure event doesn't necessarily include a size nor acknowledged our fullscreen request. Keep handling configure events synchronously until we get an event that has either. We have to do this because otherwise events are queued, and queued events are only processed when a frame has been committed -- but if nothing is configured yet we'll never get that commit event either, thus never process the precious configure event that does have useful information we need to act on. Fixes: xbmc#20629
the very first configure event doesn't necessarily include a size nor acknowledged our fullscreen request. Keep handling configure events synchronously until we get an event that has either. We have to do this because otherwise events are queued, and queued events are only processed when a frame has been committed -- but if nothing is configured yet we'll never get that commit event either, thus never process the precious configure event that does have useful information we need to act on. Fixes: xbmc#20629
the very first configure event doesn't necessarily include a size nor acknowledged our fullscreen request. Keep handling configure events synchronously until we get an event that has either. We have to do this because otherwise events are queued, and queued events are only processed when a frame has been committed -- but if nothing is configured yet we'll never get that commit event either, thus never process the precious configure event that does have useful information we need to act on. Fixes: xbmc#20629
the very first configure event doesn't necessarily include a size nor acknowledged our fullscreen request. Keep handling configure events synchronously until we get an event that has either. We have to do this because otherwise events are queued, and queued events are only processed when a frame has been committed -- but if nothing is configured yet we'll never get that commit event either, thus never process the precious configure event that does have useful information we need to act on. Fixes: xbmc#20629
the very first configure event doesn't necessarily include a size nor acknowledged our fullscreen request. Keep handling configure events synchronously until we get an event that has either. We have to do this because otherwise events are queued, and queued events are only processed when a frame has been committed -- but if nothing is configured yet we'll never get that commit event either, thus never process the precious configure event that does have useful information we need to act on. Fixes: xbmc#20629
on wayland, the compositor can ignore fullscreen requests, so even if application's InitWindow created a window with res >= DESKTOP we have no guarantee that the actual window created is actually fullscreen. CreateNewWindow will fill GetResolutionInfo(res) so we can check that for bFullScreen and use this information... in theory. wayland was inconditionally setting it to the requested fullscreen state, so also make sure it's set based on the real state by keeping m_bFullScreen up to date and using that instead. Fixes: xbmc#20629
Can confirm the issue. It was driving me crazy from today's morning after compiling Sway from git. |
thank you for posting this, I was chasing this for hours |
Also seeing this. No error in kodi log with The blank window has decorations which can be interacted with. |
my work around is to disable env WAYLAND_DISPLAY and use X |
Thanks I'll try that. After more digging through various tickets it seems this issue might be specific to sway swaywm/sway#2176 |
This applies to the android version as well on Moto G30. Loads but all is displayed is black screen. Running Android 11 or 12 same issue. |
This has nothing to do with Android. The android issue is anything greater than 60hz doesnt work in v19. Sideload a nightly/alpha |
Ok I sent an e-mail to [email protected]. |
Start with the forums. Once again, v19 is limited to 60hz screen. If you wish to run v19, change your screen to 60hz. If you dont, or cant, do that, you can either try a nightly/alpha of v20, or wait until v20 is released. |
Ok will do. |
Any updates on this issue? I am getting the same issue. Black screen but I can hear audio in the background. |
Doesn't occur on fedora 37 with gnome 43 for me. |
@lrusak Ignore my comment, this was due to something else :) |
Just got this error with arch in both native and Flatpak packages, and blocking access to Wayland socket using Flatpak "fixed" this issue for me. |
This issue is now marked stale because it has been open over a year without activity. Remove the stale label or add a comment to reset the stale state. |
Bug report
Describe the bug
Here is a clear and concise description of what the problem is:
Kodi starts as a black screen when starting kodi (wayland backend) in fullscreen mode in sway master branch (or riverwm, and probably other wlroots based compositors, but not sway latest release some behaviour changed).
controls etc still work (there's sound when moving arrows), just nothing displayed.
Expected Behavior
Here is a clear and concise description of what was expected to happen:
Kodi should display it screen properly
Actual Behavior
Nothing is displayed.
Possible Fix
There's details about the bug in https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3199#note_1177470 and https://github.com/riverwm/river/issues/480
Basically it looks like when kodi is configured to start as fullscreen, it sends a fullscreen request too early (before the surface has been mapped). This much is fine, that request is just ignored. But then kodi doesn't handle the fact that the request got ignored well and stops replying to configure requests, which leads to the surface having no actual size, and nothing is actually drawn.
The fix could be to just delay the fullscreen request, but there is no guarantee fullscreen requests are honored in the protocol so we should also make the wayland code more robust when or if one is ignored.
I've just finished building kodi from sources and will start having a look at the code itself, I don't see why we would start misbehaving just because fullscreen request has been ignored.
Workaround: start in windowed mode, then entering fullscreen works.
To Reproduce
Steps to reproduce the behavior:
Debuglog
The debuglog can be found here:
https://gaia.codewreck.org/local/tmp/kodi.log
This is the messages from WAYLAND_DEBUG=1 of the same session:
https://gaia.codewreck.org/local/tmp/kodi.wayland_debug.log
Screenshots
Here are some links or screenshots to help explain the problem:
https://gaia.codewreck.org/local/tmp/kodi-black.png
Your Environment
Used Operating system:
Android
iOS
tvOS
Linux
OSX
Windows
Windows UWP
Operating system version/name:
Kodi version: initially noticed on 19.3 (19.3.0) Git:20211024; reproduced on today's master 9e99541
The text was updated successfully, but these errors were encountered: