Bug 21145 - xbmc not working with opensource radeon driver due to framebuffer reporting issue?
Summary: xbmc not working with opensource radeon driver due to framebuffer reporting i...
Status: RESOLVED NOTOURBUG
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: 7.4 (2008.09)
Hardware: All Linux (All)
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
: 21262 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-04-13 04:31 UTC by Carlos Bessa
Modified: 2010-03-26 18:22 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Carlos Bessa 2009-04-13 04:31:12 UTC
Hi.
I'm using openSUSE11.1 with radeon driver 6.9 and xbmc works fine with this configuration. However, after updating to driver 9.12 and mesa 7.4 i get the following error:

X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  1 (X_CreateWindow)
  Serial number of failed request:  29
  Current serial number in output stream:  30

I have searched the web and it seems that this is happening since radeon 9.11. According to this topic it worked with version 9.10:
http://forum.boxee.tv/showthread.php?t=6794
(boxee is a fork of xbmc it seems)

xbmc linux forum as a couple of ubuntu 9.04 users with the same problem but no other info. This could be a problem as new distros use more up to date radeon driver and fglrx support has been droped for all cards up to and including R500.

regards,
Carlos
Comment 1 Michel Dänzer 2009-04-15 10:10:41 UTC
> X Error of failed request:  BadMatch (invalid parameter attributes)
>   Major opcode of failed request:  1 (X_CreateWindow)
>   Serial number of failed request:  29
>   Current serial number in output stream:  30

This is most likely an application / toolkit bug.

> I have searched the web and it seems that this is happening since radeon 9.11.
> According to this topic it worked with version 9.10:

If the xbmc developers have trouble fixing the problem, this information should help narrow down the radeon driver change which supposedly exposed the client side bug, e.g. using git bisect.

> http://forum.boxee.tv/showthread.php?t=6794

In the future, please provide all relevant information in a bug report directly, not linked externally.
Comment 2 Alex Deucher 2009-04-17 16:56:48 UTC
*** Bug 21262 has been marked as a duplicate of this bug. ***
Comment 3 Andreas Setterlind 2009-04-19 03:04:14 UTC
FYI; XBMC not working with  the open source radeon driver is not a bug in the XBMC application software; the fact is that XBMC just requires full 3D OpenGL 1.4 with GLSL and ARB support, to this date the open source radeon driver does simply not support that yet.

Read:
http://xbmc.org/wiki/?title=XBMC_for_Linux_specific_FAQ#XBMC_for_Linux_minimum_requirements
and:
http://xbmc.org/wiki/?title=XBMC_for_Linux_specific_FAQ#Why_is_a_OpenGL_2.0_compatible_graphic-controller_the_recommended_minimum_for_XBMC.3F
as well as:
http://xbmc.org/wiki/?title=XBMC_for_Linux_specific_FAQ#Currently_OpenGL_2.0_hardware_is_only_needed_for.../

So until the open source radeon driver supports full 3D OpenGL 1.4 with GLSL and ARB support, you need to use the latest ATI restricted driver (meaning the closed source binary driver from ATI). You can follow these instructions for help on installing the latest restricted drivers:
http://xbmc.org/wiki/?title=XBMC_for_Linux_specific_FAQ#How_can_I_sort_out_graphic.2Fvideo_issues_in_XBMC_for_Linux
Comment 4 Corbin Simpson 2009-04-19 11:35:47 UTC
(In reply to comment #3)
> FYI; XBMC not working with  the open source radeon driver is not a bug in the
> XBMC application software; the fact is that XBMC just requires full 3D OpenGL
> 1.4 with GLSL and ARB support, to this date the open source radeon driver does
> simply not support that yet.
> 
> Read:
> http://xbmc.org/wiki/?title=XBMC_for_Linux_specific_FAQ#XBMC_for_Linux_minimum_requirements
> and:
> http://xbmc.org/wiki/?title=XBMC_for_Linux_specific_FAQ#Why_is_a_OpenGL_2.0_compatible_graphic-controller_the_recommended_minimum_for_XBMC.3F
> as well as:
> http://xbmc.org/wiki/?title=XBMC_for_Linux_specific_FAQ#Currently_OpenGL_2.0_hardware_is_only_needed_for.../
> 
> So until the open source radeon driver supports full 3D OpenGL 1.4 with GLSL
> and ARB support, you need to use the latest ATI restricted driver (meaning the
> closed source binary driver from ATI). You can follow these instructions for
> help on installing the latest restricted drivers:
> http://xbmc.org/wiki/?title=XBMC_for_Linux_specific_FAQ#How_can_I_sort_out_graphic.2Fvideo_issues_in_XBMC_for_Linux
> 

Please use the OGL extensions and versioning system to correctly detect OGL capabilities and fallback or exit gracefully as needed.

On a personal note, please don't recommend Envy; it makes everybody sad. :C
Comment 5 Dominic Evans 2009-04-19 14:05:05 UTC
re-opening as radeon bug
Comment 6 Dominic Evans 2009-04-19 14:07:51 UTC
bug 21262 has additional trace / version info etc. (if needed)
Comment 7 Alex Deucher 2009-04-19 15:29:44 UTC
This is not a radeon bug.  xbmc apparently requires GLSL which is not supported in the open source radeon 3D drivers yet.  However, xbmc should, as Corbin noted, use the GL extensions and versioning system to correctly detect the supported GL capabilities and fallback or exit gracefully rather than doing what it currently does.
Comment 8 Michel Dänzer 2009-04-27 08:30:39 UTC
Indeed, however note for the record that the error from this report can't really be directly related to the version or any extension of OpenGL itself but is more likely related to GLX visuals or something like that.
Comment 9 Carlos Bessa 2009-04-27 11:00:45 UTC
...so, i'm just curious, in light of this how come xbmc worked with previous versions of the radeon driver?

regards,
Carlos
Comment 10 Dominic Evans 2009-04-27 12:18:48 UTC
Comment 16 on the XBMC trac seems to suggest its a framebuffer bpp reporting issue and nothing to do with GLSL at all. A simple XBMC patch fixes the problem, but is this a regression in Driver/Radeon or has some incorrect behaviour been fixed, and XBMC breakage is just a side effect?

http://trac.xbmc.org/ticket/6382#comment:16

Comment 11 Michel Dänzer 2009-04-28 01:16:11 UTC
(In reply to comment #10)
> A simple XBMC patch fixes the problem,

Without the patch, does running xbmc with XLIB_SKIP_ARGB_VISUALS=1 work around the problem?
Comment 12 Dominic Evans 2009-04-28 01:24:13 UTC
Sadly not. I tried that in my original bug 21262.

$ XLIB_SKIP_ARGB_VISUALS=1 gdb /usr/share/xbmc/xbmc.bin
...
(gdb) bt
#0 0xb777ce26 in glClearColor () from /usr/lib/libGL.so.1
#1 0x0821075b in CGraphicContext::SetVideoResolution (this=0x8bea680,
res=@0x8beb7a0, NeedZ=1, forceClear=true) at GraphicContext.cpp:792
#2 0x082e4a05 in CApplication::Create (this=0x8bec4a0, hWnd=0x0) at
Application.cpp:849
#3 0x0853e5ee in main (argc=1, argv=0xbfd7a8d4) at xbmc.cpp:125

full xbmc debug log is here http://paste.ubuntu.com/152489/

nothing much interesting in it though apart from these lines:

01:31:38 T:3066156912 M:1433460736 INFO: XRANDR: /usr/share/xbmc/xbmc-xrandr
--output LVDS --mode 0x4e
01:31:38 T:3066156912 M:1434112000 DEBUG: Constructing surface 1280x720,
shared=(nil), fullscreen=0
01:31:38 T:3066156912 M:1434112000 INFO: GLX Info: NOT Using destination window
01:31:38 T:3066156912 M:1433858048 INFO: GLX Info: Using parent window
01:31:38 T:3066156912 M:1433513984 ERROR: (pthread_mutex_destroy(&m_mutex)):
[XCriticalSection.cpp:86] 16
Comment 13 Dominic Evans 2009-04-28 23:42:52 UTC
OK. XBMC team have implemented a workaround in preparation for their forthcoming release. The upstream patch svn changeset that was committed is browsable here:

http://xbmc.org/trac/changeset/19781

They consider this to be a temporary workaround for the release, and are expecting the xorg-driver-ati team to 'fix' the change in behaviour that caused this problem.
Comment 14 Michel Dänzer 2009-04-29 08:43:16 UTC
(In reply to comment #13)
> OK. XBMC team have implemented a workaround in preparation for their
> forthcoming release. The upstream patch svn changeset that was committed is
> browsable here:
> 
> http://xbmc.org/trac/changeset/19781
> 
> They consider this to be a temporary workaround for the release, and are
> expecting the xorg-driver-ati team to 'fix' the change in behaviour that caused
> this problem.

I do think something like that is the correct solution however, although I wouldn't check for depth == 24 (probably won't work for X servers running in depth 16) but for depth == (red + green + blue) (so there's no alpha).

Anyway, the X video driver no longer has any influence on the GLX visuals or fbconfigs, it's all between the X server and the Mesa driver now. As this problem was probably triggered by an X server change I'm reassigning there, but be prepared for a NOTOURBUG resolution.
Comment 15 Corbin Simpson 2010-03-26 18:22:11 UTC
Closing as NOTOURBUG. XBMC fixed it on their side, so there's no reason to keep this open any longer.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.