[PATCH] glamor: Make glamor_name_from_pixmap work without DRI3

Michel Dänzer michel at daenzer.net
Tue Nov 17 17:32:40 PST 2015


On 18.11.2015 05:59, Mark Kettenis wrote:
>> From: =?UTF-8?Q?Michel_D=c3=a4nzer?= <michel at daenzer.net>
>> On 16.11.2015 22:43, Mark Kettenis wrote:
>>>
>>> There is one issue though.  The colors are wrong!  As far as I can
>>> tell red and blue are reversed in the output for anything that uses 3D
>>> acceleration (everything produced by the "2D" codepaths seems to be
>>> fine).  I've been hunting this down yesterday, but so far not been
>>> able to track this down.  Happens with both xserver 17.4 and 18.99.x,
>>> and with both Mesa 10.2.9 and 11.0.3.  The galmor-enabled
>>> xf86-video-ati driver on the AMD hardware doesn't have this issue.
>>> Feels a bit like an endianness issue, but this is all on bog-standard
>>> little-endian x86 hardware.
>>>
>>> Any clues in tracking this down would be appreciated.
>>
>> Please provide the log files and the output of glxinfo for the bad case
>> with modesetting and for the good case with radeon (preferably both on
>> the same hardware).
> 
> Xorg.0.log.radeon and glxinfo.radeon are the "good case"; glxgears
> -info says it is using "VisualID 772, 0x304".
> 
> Xorg.0.log.modesetting and glxinfo.modesetting are the "bad case";
> here glxgears -info says it is using "VisualID 222, 0xde".

[  1243.496] (II) modeset(0): [DRI2] Setup complete
[  1243.496] (II) modeset(0): [DRI2]   DRI driver: radeon
[  1243.496] (II) modeset(0): [DRI2]   VDPAU driver: radeon
[  1243.501] (--) RandR disabled
[  1243.702] (EE) AIGLX error: Calling driver entry point failed
[  1243.727] (EE) AIGLX: reverting to software rendering
[  1243.737] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[  1243.738] (II) AIGLX: Loaded and initialized swrast
[  1243.738] (II) GLX: Initialized DRISWRAST GL provider for screen 0

The problem seems to be that the DRI2 client driver name is incorrectly
determined as radeon instead of r600, so AIGLX fails to load the DRI
hardware driver and falls back to swrast_dri.so. I think you should
trace what goes wrong in
xserver/hw/xfree86/dri2/dri2.c:dri2_probe_driver_name().


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer


More information about the xorg-devel mailing list