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] black screen when starting fullscreen #20629

Open
1 of 7 tasks
martinetd opened this issue Dec 5, 2021 · 15 comments · May be fixed by #20632
Open
1 of 7 tasks

[wayland] black screen when starting fullscreen #20629

martinetd opened this issue Dec 5, 2021 · 15 comments · May be fixed by #20632
Assignees
Labels

Comments

@martinetd
Copy link

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:

  1. build and run sway master
  2. run kodi wayland with an empty config (defaults to fullscreen)

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

martinetd added a commit to martinetd/xbmc that referenced this issue Dec 5, 2021
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
martinetd added a commit to martinetd/xbmc that referenced this issue Dec 5, 2021
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
martinetd added a commit to martinetd/xbmc that referenced this issue Dec 5, 2021
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
martinetd added a commit to martinetd/xbmc that referenced this issue Dec 5, 2021
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
martinetd added a commit to martinetd/xbmc that referenced this issue Dec 5, 2021
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
martinetd added a commit to martinetd/xbmc that referenced this issue Dec 5, 2021
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
@heppix
Copy link

heppix commented Dec 5, 2021

Can confirm the issue. It was driving me crazy from today's morning after compiling Sway from git.
Starting kodi with --windowing=x11 also fixes the issue but then it won't go fullscreen by pressing \ key.

@oniGino
Copy link

oniGino commented Jan 30, 2022

thank you for posting this, I was chasing this for hours

@jackinloadup
Copy link

Also seeing this. No error in kodi log with --debug and vainfo shows like graphics are working. Using nixos running nixpkgs-unstable with kodi 19.4

The blank window has decorations which can be interacted with.

@oniGino
Copy link

oniGino commented May 26, 2022

my work around is to disable env WAYLAND_DISPLAY and use X

@jackinloadup
Copy link

jackinloadup commented May 26, 2022

Thanks I'll try that. After more digging through various tickets it seems this issue might be specific to sway swaywm/sway#2176

@SJK55
Copy link

SJK55 commented Sep 14, 2022

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.

@fuzzard
Copy link
Contributor

fuzzard commented Sep 14, 2022

This has nothing to do with Android. The android issue is anything greater than 60hz doesnt work in v19. Sideload a nightly/alpha

@SJK55
Copy link

SJK55 commented Sep 14, 2022

Ok I sent an e-mail to [email protected].
The e-mail I got back was a link to black screen. I searched GitHub and saw it here and added my comment.
Where is the appropriate area to add my fault?

@fuzzard
Copy link
Contributor

fuzzard commented Sep 14, 2022

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.

@SJK55
Copy link

SJK55 commented Sep 14, 2022

Ok will do.

@csdougliss
Copy link
Contributor

Any updates on this issue? I am getting the same issue. Black screen but I can hear audio in the background.

@lrusak
Copy link
Contributor

lrusak commented Feb 6, 2023

Doesn't occur on fedora 37 with gnome 43 for me.

@csdougliss
Copy link
Contributor

@lrusak Ignore my comment, this was due to something else :)

@kalebealvs
Copy link

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 can be easily done with Flatseal by unchecking the "Wayland window system" option under the socket session.
Somehow using --windowing=x11 without blocking access to the Wayland socket crashed Kodi at boot.

Copy link

github-actions bot commented Aug 5, 2024

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.

@github-actions github-actions bot added the Stale label Aug 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
10 participants