Bug#587999: further info

[Michel Dänzer]

On Don, 2010-07-08 at 21:35 +0200, Ulrich Eckhardt wrote: 
> On Tuesday 06 July 2010 09:34:41 you wrote:
> > On Mon, 2010-07-05 at 23:14 +0200, Ulrich Eckhardt wrote:
> > > Good catch, but shouldn't it [Xvideo] work even without DRI?
> > 
> > It should, if someone were to fix the problem(s) with the non-DRI big
> > endian XVideo code paths.
> 
> Is there a bug report for this already? I couldn't locate anything with "big 
> endian" in the topic...

I faintly remember this being reported before, but I can't find another
bug report right now. Maybe it was just on the upstream mailing list.


> > Looks like radeonfb is preventing the radeon kernel module from working
> > with kernel modesetting (KMS). Disable radeonfb or load radeon with
> > modeset=0.
> 
> I tried "rmmod radeon" followed by "modprobe radeon modeset=0". I then logged 
> out of X, restarted the X server (from KDM) and logged back in. No changes, 
> still no DRI. However, when I removed the radeon module again, I suddenly had 
> a messed-up screen. Painting operations were going anywhere, as if driver code 
> and the graphics adapter had different ideas of how the graphics memory is 
> organized. What shocked me here was that I was able to remove the radeon 
> module. I'd understand it if it wasn't used, but apparently it was!?

It probably wasn't so much 'in use' as it touched the hardware on unload
in ways which confused the X driver and/or radeonfb. That kind of thing
is hard to prevent with several drivers fighting for hardware access,
which is something addressed by KMS.

> Anyway, tried the same again after logging out and back in again. However, 
> this time I removed radeon, drm_kms_helper, ttm and drm. I then loaded drm 
> with "modprobe drm debug=1" and then loaded radeon with "modprobe radeon 
> modeset=0". Still, no DRI. The results of both kern.log and Xorg.log are 
> attached.

This is the reason for the DRI being disabled now:

> (II) RADEON(0): Memory manager initialized to (0,0) (1728,4854)
> (II) RADEON(0): Reserved area from (0,1680) to (1728,1682)
> (II) RADEON(0): Largest offscreen area available: 1728 x 3172
> (II) RADEON(0): Will use front buffer at offset 0x0
> (II) RADEON(0): Will use back buffer at offset 0x9cf000
> (II) RADEON(0): Will use depth buffer at offset 0x14e2000
> (II) RADEON(0): Will use 0 kb for textures at offset 0x1ff5000
> (EE) RADEON(0): Static buffer allocation failed.  Disabling DRI.
> (EE) RADEON(0): At least 34020 kB of video memory needed at this resolution and depth.

Maybe it'll work without Option "AccelMethod" "XAA" (or with explicit
"EXA" instead), otherwise you'll need to reduce the maximum desktop size
via the Virtual directive or run in depth 16. 


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer