The last upload solved this problem with xserver-xorg-video-radeon
version 1:6.12.2-2.
I think this bug can be closed now.
Thanks for your help,
didit.
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
2009/4/16 Alex Deucher :
> Does reverting the commit (f8c7d6a6162196a743f6885ecaf63ba50de1722a)
> mentioned in the bug above fix the issue?
Yes it does. Congratulations, you've found the culprit!
(Sorry, I didn't notice earlier that you already suspected this commit.)
--
To UNSUBSCRIBE, email
2009/4/15 Alex Deucher :
> Sounds like:
> https://bugs.freedesktop.org/show_bug.cgi?id=21199
Indeed.
> Does:
> xset dpms force off
> followed by moving the mouse cause both screens to come on?
Yes it does. Thanks for the workaround!
I'm ready to test patches to solve this issue if needed.
Thank
2009/4/14 Alex Deucher :
> Both heads are probably using the same crtc, but xrandr isn't smart
> enough to assign a different one. You can see what crtc is in use by
> running xrandr --verbose. You can assign a different crtc to the
> other head like so:
> xrandr --output DVI-1 --crtc 1 --mode 12
Package: xserver-xorg-video-radeon
Version: 1:6.12.2-1
Severity: normal
The dualhead setup I've been using for more than 6 months broke up with
the last upgrade. The two identical monitors work fine in clone mode but
the following command results in a black screen on DVI-1 (the monitor
goes to sta
I was pleased to see that since I upgraded to debian kernel
linux-image-2.6.17-1-em64t-p4-smp,
DRI works on my system. A big "thank you" to everybody involved in
this, including the packagers
of xorg and of the linux kernel.
The graphic board (lspci):
ATI Technologies Inc RV370 5B64 [FireGL V3100
6 matches
Mail list logo
