Kodi Community Forum

Full Version: [Linux] VDPAU white screen bug
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Let me start by saying i'm not sure whether it's a skin bug or a VDPAU bug, but this issue only occurs with certain skins and only when VDPAU is used.

Bringing up the video osd when playing a movie that uses VDPAU will result in a white screen. The issue was first mentioned in the Transparency! forum (http://forum.xbmc.org/showthread.php?tid=57460)
so i initially thought there must be some wacky code in the skin that triggers this bug, but today i stumbled upon this post where someone mentioned the same bug happening in Project Mayhem III.

steps to reproduce:
- select Project Mayhem III skin
- restart xbmc
- play any movie that uses VDPAU
- bring up video osd

result:
Image

this bug can also be triggered by bringing up the fullscreen info window, adjusting the volume or pausing the movie...in fact everything that brings up a dialog window when playing a movie.

affected skins:
- Project Mayhem III
- Transparency! v2.00

the bug does not appear with these skins:
- PM3.HD
- MiniMedia
- MediaStream Redux
- Transparency! v1.00

system:
Ubuntu Karmic 9.10
xbmc r22528 and r22928
Nvidia: 185.18.36

logs:
Debug Log r22528
Debug Log r22928
Not sure why skin would make a difference here - did you have debugging on for those other skins?

I'm thinking it might be if a label is rendered last rather than an image?
jmarshall Wrote:Not sure why skin would make a difference here - did you have debugging on for those other skins?
yes, i had debugging enabled all of the time when testing those skins.
(of course the bug also happens when debugging is disabled)
if you or anyone needs a Debug Log of any of the other skins to compare them, just let me know.

jmarshall Wrote:I'm thinking it might be if a label is rendered last rather than an image?

i'm leaving that one up to the pro's to answer.

the only thing i can add and it probably doesn't make any sense is this:
in Transparency! v2.00 there's a hidden button in Home.xml that's used for running the recently added script. the button control didn't have a <font> definition.
after adding a <font>-<font> line to this button, the white screen bug went away.

again, i have no clue how a button on the Home screen can trigger a bug in the fullscreen video window, but i guess some bugs just don't make sense.

there's also another way to somewhat get rid of the bug, it was to remove the 'system time' label from the VideoOSD and DialogFullscreenInfo...that would fix it for either of those.
but the bug would still happen when adjusting the volume. i haven't tested if removing some parts of DialogVolumeBar.xml could get rid of the bug.

i've been troubleshooting this for hours and hours, but it seems i can't put my finger on it, especially with the button in Home.xml
jmarshall Wrote:I'm thinking it might be if a label is rendered last rather than an image?

if i move the volume icon image control to the end of DialogVolumeBar.xml the bug is indeed gone when adjusting the volume.
And it doesn't happen with non-vdpau, right?

I suspect it's the shader setup we use for font rendering.
jmarshall Wrote:And it doesn't happen with non-vdpau, right?

I suspect it's the shader setup we use for font rendering.

correct, it it doesn't happen with non-vdpau.
I don't have a VDPAU capable machine, so can't test, but try changing line 1910 of xbmc/cores/VideoRenderers/LinuxRendererGL.cpp from this:
Code:
glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
to this:
Code:
glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_COMBINE);
  glTexEnvf(GL_TEXTURE_ENV, GL_COMBINE_RGB, GL_MODULATE);
  glTexEnvf(GL_TEXTURE_ENV, GL_SOURCE0_RGB, GL_TEXTURE0);
  glTexEnvf(GL_TEXTURE_ENV, GL_OPERAND0_RGB, GL_SRC_COLOR);
  glTexEnvf(GL_TEXTURE_ENV, GL_SOURCE1_RGB, GL_PRIMARY_COLOR);
  glTexEnvf(GL_TEXTURE_ENV, GL_OPERAND1_RGB, GL_SRC_COLOR);

We may also need to set the glColor here as well. If the above works, see what happens if the last label to render is a different color than white (eg red) - you'll need to turn off the debug logging ofcourse!

Cheers,
Jonathan
well that definitely got rid of the white screen....although i still think we have a slight problem here, the screen turns black instead:
Image

this is with Project Mayhem III, no debug logging and all font colors set to green.
same happens with white fonts btw.

after this i've enabled debuglogging in advancedsettings (level1, so not visible onscreen)
to create a Debug Log: http://pastebin.com/m694f38f9
FWIW I haven't seen the white out since downgrading the Nvidia drivers to 190.18 not sure which version but was having problems with suspend/shutdown not working with latest beta drivers.
ronie Wrote:the bug does not appear with these skins:
- PM3.HD
- MiniMedia
- MediaStream Redux
- Transparency! v1.00

For me at least is just the same with MediaStream Redux... getting white screens sometimes when using vdpau.

One of this days, i will update kernel, nvidia drivers, etc.. and test again.
gott_sei_dank Wrote:FWIW I haven't seen the white out since downgrading the Nvidia drivers to 190.18 not sure which version but was having problems with suspend/shutdown not working with latest beta drivers.

Scratch that I've had it once since downgrading, it was far more frequent with the latest betas but seems mainly to affect web streams.
So these arent related? Note that I am running the Win32 version and also mediastream redux (with mods).

http://forum.xbmc.org/showthread.php?tid...menu+white
as far as i can tell the white screen bug is fixed in svn r23193

but at the same time a new issue is introduced. if you escape back to the home menu while playing a video, playback of the video gets a bit choppy.
it also influences navigating the skin...also choppy.

ubuntu jaunty
nvidia 180.44
xbmc r23196

Debug Log
That commit ups the driver requirement to 185.xx i'm afraid. You'll probably find X is pegging your CPU whilst playing video if you're using 180.xx, hence the UI slowdown.
motd2k Wrote:That commit ups the driver requirement to 185.xx i'm afraid. You'll probably find X is pegging your CPU whilst playing video if you're using 180.xx, hence the UI slowdown.

thanx.....my karmic install (with the 185.xx driver) is a bit borked after last weeks ubuntu updates, so i had to revert back to jaunty.
i'll test again when karmic stabilises again.
Pages: 1 2