Bug 21145

> 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.

*** Bug 21262 has been marked as a duplicate of this bug. ***

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

(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

re-opening as radeon bug

bug 21262 has additional trace / version info etc. (if needed)

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.

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.

...so, i'm just curious, in light of this how come xbmc worked with previous versions of the radeon driver?

regards,
Carlos

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

(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?

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

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.

(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.

Closing as NOTOURBUG. XBMC fixed it on their side, so there's no reason to keep this open any longer.