Bug#987382: mesa: missing complete upstream fix for more non-coherent RB and GL2 combinations

[Alex Crowe]

Source: mesa
Version: 21.0.3-1
Severity: normal
Tags: patch

This patch fixes an incomplete application of an upstream fix for newer Navi22
card such as the 6700 XT resolving screen corruption issues

Upstream commit
https://gitlab.freedesktop.org/mesa/mesa/-/commit/ccc4abdbf4b889fd1467b237c7cc2d0d20770d02



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing'), (1, 'experimental'),
(1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.12.0-rc8-custom (SMP w/16 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
--- a/src/amd/common/ac_gpu_info.c
+++ b/src/amd/common/ac_gpu_info.c
@@ -710,6 +710,7 @@ bool ac_query_gpu_info(int fd, void *dev_p, struct 
radeon_info *info,
   info->num_tcc_blocks = info->max_tcc_blocks;
}
 
+   info->tcc_rb_non_coherent = 
!util_is_power_of_two_or_zero(info->num_tcc_blocks);
info->mc_arb_ramcfg = amdinfo->mc_arb_ramcfg;
info->gb_addr_config = amdinfo->gb_addr_cfg;
if (info->chip_class >= GFX9) {

Re: Upload Mesa 19 to buster-backports?

[Alex ARNAUD]

Le 12/03/2020 à 18:36, Alex ARNAUD a écrit :
To compile Mesa 19 it involves the following dependencies that need to 
be backported:


  * meson


Meson 0.52 is now into buster-backports.


  * libclc

I've contacted the OpenCL team to backport their software to 
buster-backports.


I've also contacted the LLVM team to backport their software to backports.

Best regards.

Re: Upload Mesa 19 to buster-backports?

[Alex ARNAUD]

Hello all,

I confirm that installing Mesa 19 on Debian 10 fixes my graphical poor 
performances.


To compile Mesa 19 it involves the following dependencies that need to 
be backported:


 * meson
 * libdrm
 * libclc
 * libglvnd


There is few changes to made:
- Rebase llvm-9 to llvm-8 in related packages
- Same for clang

Then it's mostly a matter of having rights and time to do it.

How can I help to make it progress?

Best regards,
Alex.

Le 11/03/2020 à 15:32, Alex ARNAUD a écrit :

Hello the Debian X Strike Force team,

I'd like to thank you for the work you made. I'm a visual-impaired guy 
that help others being able to use Debian (especially elderly, 
visual-impaired and blind people).


I'm trying to install Debian 10 to a computer with a Intel i3-10110U 
processor and on Debian 10 there is a poor graphical performance with 
both the Intel and Modsetting driver whereas it works with Debian Testing.


After a bunch of testing I'm pretty sure the culprit is Mesa but it 
isn't available on Buster backports yet.


Could you please provide it for those having the same issue like me?

Thanks in advance,
Alex.

Upload Mesa 19 to buster-backports?

[Alex ARNAUD]

Hello the Debian X Strike Force team,

I'd like to thank you for the work you made. I'm a visual-impaired guy 
that help others being able to use Debian (especially elderly, 
visual-impaired and blind people).


I'm trying to install Debian 10 to a computer with a Intel i3-10110U 
processor and on Debian 10 there is a poor graphical performance with 
both the Intel and Modsetting driver whereas it works with Debian Testing.


After a bunch of testing I'm pretty sure the culprit is Mesa but it 
isn't available on Buster backports yet.


Could you please provide it for those having the same issue like me?

Thanks in advance,
Alex.

Upload Mesa 19 to buster-backports?

[Alex ARNAUD]

Hello the Debian X Strike Force team,

I'd like to thank you for the work you made. I'm a visual-impaired guy 
that help others being able to use Debian (especially elderly, 
visual-impaired and blind people).


I'm trying to install Debian 10 to a computer with a Intel i3-10110U 
processor and on Debian 10 there is a poor graphical performance with 
both the Intel and Modsetting driver whereas it works with Debian Testing.


After a bunch of testing I'm pretty sure the culprit is Mesa but it 
isn't available on Buster backports yet.


Could you please provide it for those having the same issue like me?

Thanks in advance,
Alex.

Backports of graphic stack of Bullseye to Buster ?

[Alex ARNAUD]

Hello all,

I'm testing a new computer with Intel UHD Graphics 620 as chipset with 
the Intel driver provided by the package "xserver-xorg-video-intel" with 
really poor performance as describe here: 
https://gitlab.freedesktop.org/xorg/xserver/issues/29


Could it be possible to backport to Buster the graphic stack of Bullseye 
like it was with Stretch or Jessie ?


(I don't know if upgrading the stack will solve my issue but I don't see 
UHD 620 supported on the "Xorg.0.log" after line "Driver for Intel(R) 
Integrated Graphics Chipsets:")


Thanks for the work you made to make Debian.

Best regards,
Alex.

Bug#837451: xserver-xorg-core: visual flashes followed by hard crash upon keyboard interaction with thinkpad x201

[Alex ARNAUD]

Le 26/04/2018 à 16:56, Uwe Kleine-König a écrit :

The freedesktop guys are responsible for the kernel, too. So it was
addressed to the right people.


Right, but what's on Debian? Does the package xorg is relevant?

Best regards,
Alex.

Bug#837451: xserver-xorg-core: visual flashes followed by hard crash upon keyboard interaction with thinkpad x201

[Alex ARNAUD]

Control: tags -1 + stretch

On Wed, 7 Dec 2016 09:56:26 +0100 Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= 
 wrote:

I already reported the issue to the upstream bug tracker and mark the
bug as forwarded accordingly.


I've read the upstream thread, as I can understand, it's related to the 
kernel, isn't it? Why not forwarding the issue on the Kernel?


I've migrated from Jessie to Stretch yesterday and I found this issue 
really annoying, IMO the severity of this bug should be raised. We have 
to backport the fix on the stable branch. I cannot use a computer that 
has visual flashes regularly. I've spent one hour to figure out the 
issue and to find this bug.


I've apply the work around to save my life but a regular user couldn't 
do that.


Best regards,
Alex.

Bug#876501: Xdmx segfault on start

[Alex]

Package: Xdmx
Version: 1.19.3-2
Severity: important

Dear Maintainer,
Xdmx segfaults when starting it with Xdmx -display 192.168.102.57:0
-norender :1
I am not sure if the parameters are correct as I was setting it up, but
it should not segfault anyway.

The trace is:

(II) dmx[o0/192.168.102.57:0]: 0x259 DirectColor 24b 8b/rgb 256 0xff
0xff00 0x00ff
(II) dmx[o0/192.168.102.57:0]: 0x25a DirectColor 24b 8b/rgb 256 0xff
0xff00 0x00ff
(II) dmx[o0/192.168.102.57:0]: 0x25b DirectColor 24b 8b/rgb 256 0xff
0xff00 0x00ff
(II) dmx[o0/192.168.102.57:0]: 0x41 TrueColor   32b 8b/rgb 256 0xff
0xff00 0x00ff
(II) dmx[o0/192.168.102.57:0]: DPMS 1.1 (on, enabled, 0 0 0)
(EE) 
(EE) Backtrace:
(EE) 0: Xdmx (xorg_backtrace+0x4a) [0x55892085c8ba]
(EE) 1: Xdmx (0x5589206f+0x170669) [0x558920860669]
(EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f95824e2000+0x110c0)
[0x7f95824f30c0]
(EE) 3: Xdmx (TimerForce+0x10) [0x55892085a360]
(EE) 4: Xdmx (0x5589206f+0x41bf1) [0x558920731bf1]
(EE) 5: Xdmx (0x5589206f+0x337b5) [0x5589207237b5]
(EE) 6: Xdmx (0x5589206f+0x40b17) [0x558920730b17]
(EE) 7: Xdmx (0x5589206f+0x40f85) [0x558920730f85]
(EE) 8: Xdmx (AddScreen+0xd7) [0x558920825fc7]
(EE) 9: Xdmx (InitOutput+0x40f) [0x55892072b4ef]
(EE) 10: Xdmx (0x5589206f+0x139b26) [0x558920829b26]
(EE) 11: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf1)
[0x7f95821652e1]
(EE) 12: Xdmx (_start+0x2a) [0x55892071f1ba]
(EE) 
(EE) Segmentation fault at address 0x0
(EE) 
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE)

with a lot of the DirectColor and TrueColor messages before.


-- System Information:
Debian Release: 9.1
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)

Init: sysvinit (via /sbin/init)

Bug#835932: xserver-xorg-video-intel: Multi-screen : only one monitor detected at startup

[Alex ARNAUD]

9,7C,7D,7E,7F,80,83,85,87,89,8C,8E,8F,9B,9C,9D,9E,9F,A3,A4,A5,A6,AC,AD,B6,B7,B8,B9,BA,BB,BC,BD,BE,BF,C0,C1,C2,D9,E2,ramlsfw

E: NAME="BRLTTY 5.2dev Linux Screen Driver Keyboard"
E: PHYS="pid-204/brltty/14"
E: PRODUCT=0/0/0/0
E: PROP=0
E: SUBSYSTEM=input
E: TAGS=:seat:
E: USEC_INITIALIZED=14037

P: /devices/virtual/input/input11/event2
N: input/event2
E: BACKSPACE=guess
E: DEVNAME=/dev/input/event2
E: DEVPATH=/devices/virtual/input/input11/event2
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_INPUT_KEYBOARD=1
E: ID_SERIAL=noserial
E: MAJOR=13
E: MINOR=66
E: SUBSYSTEM=input
E: USEC_INITIALIZED=46571
E: XKBLAYOUT=fr
E: XKBMODEL=pc105
E: XKBVARIANT=latin9


DRM Information from dmesg:
---
[1.418702] Linux agpgart interface v0.103
[8.832872] [drm] Initialized drm 1.1.0 20060810
[8.989607] [drm] Memory usable by graphics device = 1024M
[8.989614] [drm] Replacing VGA console driver
[8.991740] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[8.991743] [drm] Driver supports precise vblank timestamp query.
[9.153818] [drm] Initialized i915 1.6.0 20160229 for :00:02.0 on 
minor 0

[9.380699] fbcon: inteldrmfb (fb0) is primary device
[   11.252903] i915 :00:02.0: fb0: inteldrmfb frame buffer device


-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xserver-xorg-video-intel depends on:
ii  libc6  2.19-18+deb8u4
ii  libdrm-intel1  2.4.70-1~bpo8+1
ii  libdrm22.4.70-1~bpo8+1
ii  libpciaccess0  0.13.2-3+b1
ii  libpixman-1-0  0.32.6-3
ii  libudev1   215-17+deb8u4
ii  libx11-6   2:1.6.2-3
ii  libx11-xcb12:1.6.2-3
ii  libxcb-dri2-0  1.10-3+b1
ii  libxcb-dri3-0  1.10-3+b1
ii  libxcb-sync1   1.10-3+b1
ii  libxcb-util0   0.3.8-3
ii  libxcb11.10-3+b1
ii  libxcursor11:1.1.14-1+b1
ii  libxdamage11:1.1.4-2+b1
ii  libxext6   2:1.3.3-1
ii  libxfixes3 1:5.0.1-2+b2
ii  libxinerama1   2:1.1.3-1+b1
ii  libxrandr2 2:1.4.2-1+b1
ii  libxrender11:0.9.8-1+b1
ii  libxshmfence1  1.1-4
ii  libxss11:1.2.2-1
ii  libxtst6   2:1.2.2-1+b1
ii  libxv1 2:1.0.10-1+b1
ii  libxvmc1   2:1.0.8-2+b1
ii  xserver-xorg-core [xorg-video-abi-18]  2:1.16.4-1

xserver-xorg-video-intel recommends no packages.

xserver-xorg-video-intel suggests no packages.

-- no debconf information

--
Alex ARNAUD
Visual-Impairment Project Manager
Hypra - "Humanizing technology"

Bug#786816: xserver-xorg-video-radeon: Leaving X (suspend, switch to VT) scrambles the desktop colours

[Alex Deucher]

On Wed, May 20, 2015 at 4:53 PM, rw  wrote:
> Package: xserver-xorg-video-radeon
> Version: 1:7.5.0-1
> Severity: normal
>
> Dear Maintainer,
>
> Using X on a Thinkpad T60, just upgraded to Debian 8. Previous versions 
> worked fine for
> suspend/resume/switch to VT and back
>
> Now switching out of the desktop does something I can only describe as 
> "change RGB for GBR or
> similar". Black/white remains perfectly legible, but colours are shifted into 
> a different colour in
> such a way that the screen is mostly not legible
>

You appear to have disabled kms somehow and you are getting the vesa
driver rather than the native radeon driver.

Alex


> [18.639] (II) [KMS] drm report modesetting isn't supported.
> [18.639] (II) [KMS] drm report modesetting isn't supported.
> [18.639] (II) [KMS] drm report modesetting isn't supported.
> [18.645] (WW) Falling back to old probe method for modesetting

> [18.657] (II) VESA(0): Primary V_BIOS segment is: 0xc000
> [18.658] (II) VESA(0): VESA BIOS detected
> [18.658] (II) VESA(0): VESA VBE Version 3.0
> [18.658] (II) VESA(0): VESA VBE Total Mem: 16384 kB
> [18.658] (II) VESA(0): VESA VBE OEM: ATI ATOMBIOS
> [18.658] (II) VESA(0): VESA VBE OEM Software Rev: 9.12
> [18.658] (II) VESA(0): VESA VBE OEM Vendor: (C) 1988-2005, ATI 
> Technologies Inc.
> [18.658] (II) VESA(0): VESA VBE OEM Product: M56GL
> [18.658] (II) VESA(0): VESA VBE OEM Product Rev: 01.00
> [18.715] (II) VESA(0): Creating default Display subsection in Screen 
> section
> "Default Screen" for depth/fbbpp 24/32
> [18.715] (==) VESA(0): Depth 24, (--) framebuffer bpp 32
> [18.715] (==) VESA(0): RGB weight 888
> [18.715] (==) VESA(0): Default visual is TrueColor
> [18.715] (==) VESA(0): Using gamma correction (1.0, 1.0, 1.0)
> [18.715] (II) Loading sub module "ddc"
> [18.716] (II) LoadModule: "ddc"
> [18.716] (II) Module "ddc" already built-in
> [19.122] (II) VESA(0): VESA VBE DDC supported
> [19.122] (II) VESA(0): VESA VBE DDC Level 2
> [19.122] (II) VESA(0): VESA VBE DDC transfer in appr. 1 sec.
> [19.371] (II) VESA(0): VESA VBE DDC read successfully
> [19.372] (II) VESA(0): Manufacturer: LEN  Model: 4022  Serial#: 0
> [19.372] (II) VESA(0): Year: 2006  Week: 36
> [19.372] (II) VESA(0): EDID Version: 1.3
> [19.372] (II) VESA(0): Digital Display Input
> [19.372] (II) VESA(0): Max Image Size [cm]: horiz.: 29  vert.: 21
> [19.372] (II) VESA(0): Gamma: 2.20
> [19.372] (II) VESA(0): DPMS capabilities: StandBy Suspend Off
> [19.372] (II) VESA(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4
> [19.372] (II) VESA(0): First detailed timing is preferred mode
> [19.372] (II) VESA(0): redX: 0.610 redY: 0.330   greenX: 0.300 greenY: 
> 0.530
> [19.372] (II) VESA(0): blueX: 0.150 blueY: 0.130   whiteX: 0.313 whiteY: 
> 0.329
> [19.372] (II) VESA(0): Supported established timings:
> [19.372] (II) VESA(0): 640x480@60Hz
> [19.372] (II) VESA(0): 800x600@60Hz
> [19.372] (II) VESA(0): 1024x768@60Hz
> [19.372] (II) VESA(0): Manufacturer's mask: 0
> [19.372] (II) VESA(0): Supported standard timings:
> [19.372] (II) VESA(0): #0: hsize: 1280  vsize 1024  refresh: 60  vid: 
> 32897
> [19.372] (II) VESA(0): Supported detailed timing:
> [19.372] (II) VESA(0): clock: 108.0 MHz   Image Size:  287 x 215 mm
> [19.372] (II) VESA(0): h_active: 1400  h_sync: 1448  h_sync_end 1560 
> h_blank_end 1688 h_border: 0
> [19.372] (II) VESA(0): v_active: 1050  v_sync: 1051  v_sync_end 1054 
> v_blanking: 1066 v_border: 0
> [19.372] (II) VESA(0): Supported detailed timing:
> [19.372] (II) VESA(0): clock: 90.0 MHz   Image Size:  287 x 215 mm
> [19.372] (II) VESA(0): h_active: 1400  h_sync: 1448  h_sync_end 1560 
> h_blank_end 1688 h_border: 0
> [19.372] (II) VESA(0): v_active: 1050  v_sync: 1051  v_sync_end 1054 
> v_blanking: 1066 v_border: 0
> [19.372] (II) VESA(0): Unknown vendor-specific block f
> [19.372] (II) VESA(0):  LTD141EN9B
> [19.372] (II) VESA(0): EDID (in hex):
> [19.372] (II) VESA(0):  000030ae2240
> [19.372] (II) VESA(0):  24100103801d1578ea6f959c544c8726
> [19.372] (II) VESA(0):  21505421080081800101010101010101
> [19.372] (II) VESA(0):  010101010101302a7820511a10403070
> [19.372] (II) VESA(0):  13001fd7101825237820511a1040
> [19.372] (II) VESA(0):  307013001fd71018000f0090
> [19.372] (II) VESA(0):  43329043280f01003064905500fe
> [19.372] (II) VESA(0):  004c5444313431454e39420a2

Bug#785448: xserver-xorg-video-ati: Screen is badly tinged with green when using the open source driver

[Alex Deucher]

On Mon, May 18, 2015 at 4:32 AM, Owen Riddy  wrote:
> No worries.
>
> It turns out that the problem was the "Color Format" of my screen. Dunno
> what that is, but it was configuring poorly and the open source driver seems
> happier when it is set to RGB rather than YCbCr. Maybe Catalyst is a bit
> more forgiving or maybe there is some configuration issue here I don't
> understand.
>
> My problem is solved; there may still be a minor bug here in how the
> auto-configuration of the driver works.

The open source driver does not support YCbCr at the moment.

Alex

>
> Owen Riddy
> Email: owen.ri...@gmail.com
> Mobile: 040 163 2663
>
> --
>
> On 18 May 2015 at 17:41, Michel Dänzer  wrote:
>>
>> On 18.05.2015 16:28, Owen Riddy wrote:
>> > I have not, but if I reboot the computer to an install of Jessie using
>> > fglrx the tinge is not present; and it appeared shortly after updating
>> > to Jessie + unstable. I'll try a few things with the cable & report back
>> > if any of them have an impact, but the fglrx test suggests this problem
>> > is 100% fixable in software.
>>
>> I guess I misunderstood the comments about fglrx in your original
>> report. I agree it's probably a software bug then, though it's more
>> likely in the kernel driver than in the Xorg driver.
>>
>>
>> --
>> Earthling Michel Dänzer   |   http://www.amd.com
>> Libre software enthusiast | Mesa and X developer
>
>
>
> ___
> xorg-driver-ati mailing list
> xorg-driver-...@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-driver-ati
>


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cadnq5_n0rseyedmzzd+pmu7lxxcqgzt2chog80_4ldcgkev...@mail.gmail.com

Bug#785448: xserver-xorg-video-ati: Screen is badly tinged with green when using the open source driver

[Alex Deucher]

On Mon, May 18, 2015 at 3:28 AM, Owen Riddy  wrote:
> I have not, but if I reboot the computer to an install of Jessie using fglrx
> the tinge is not present; and it appeared shortly after updating to Jessie +
> unstable. I'll try a few things with the cable & report back if any of them
> have an impact, but the fglrx test suggests this problem is 100% fixable in
> software.

Is it only the HDMI display that is problematic?  It might be HDMI
packet related.  Does your display support audio?  You can disable
HDMI packets by setting radeon.audio=0 on the kernel command line in
grub or at runtime using xrandr (e.g., xrandr --output HDMI-0 --set
audio off).  If that helps, can you try kernel 4.1?

Alex

>
> Owen Riddy
> Email: owen.ri...@gmail.com
> Mobile: 040 163 2663
>
> --
>
> On 18 May 2015 at 12:56, Michel Dänzer  wrote:
>>
>> On 16.05.2015 21:21, Owen Riddy wrote:
>> > Package: xserver-xorg-video-ati
>> > Version: 1:7.5.0-1+b1
>> > Severity: important
>> >
>> > Dear Maintainer,
>> >
>> > I'm using the open source ati graphics with a 3-screen setup. After
>> > upgrading to unstable after the release of Jessie everything ran without
>> > issue.
>> >
>> > I booted into a seperate install of Jessie on the same computer that had
>> > flgrx installed, and after rebooting into unstable one of the screens
>> > (connected by a HDMI cable) has acquired a distinct green tinge that
>> > obscures whatever the screen is trying to show. It is a sort of neon green.
>> >
>> > This image is a graphical corruption bug - I took a screenshot using
>> > ksnapshot and on my other two screens the image dispaled withouth the green
>> > tinge.
>> >
>> > The tinge is not present:
>> >   * In the BIOS
>> >   * When GRUB is active
>> >   * Early in the boot process when the kernel is still printing text
>> >   * On a separate Debian install on the same hardware, using fglrx
>> >
>> > I tried changing the gamma settings of the screen and poking at the
>> > backlight settings but this did not help. Changing the gamma made a very
>> > slight difference but the tinge does nto seem to be caused by a rogue gamma
>> > setting.
>> >
>> > At some points during, eg, shutdown my screens go blank - usually this
>> > is black but at present the green tinged screen goes straight green.
>>
>> It sounds like there might be a problem with the physical display
>> connection. Have you checked the connector seating at both ends, maybe
>> unplugging and re-plugging them, or even using a different cable?
>>
>>
>> --
>> Earthling Michel Dänzer   |   http://www.amd.com
>> Libre software enthusiast | Mesa and X developer
>
>
>
> ___
> xorg-driver-ati mailing list
> xorg-driver-...@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-driver-ati
>


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CADnq5_P6+4Qa3sx=utwzkvfefzq1vut2sgxmp+0jmpnbasa...@mail.gmail.com

Bug#783705: xserver-xorg-video-radeon: Weird X wakeup problem since Jessie upgrade

[Alex Deucher]

On Wed, Apr 29, 2015 at 7:45 AM, Steve McIntyre  wrote:
> Package: xserver-xorg-video-radeon
> Version: 1:7.5.0-1
> Severity: normal
>
> Hi folks,
>
> I upgrade my main office desktop to Jessie on Monday, and just about
> evrrything worked really well - just half a dozen oro so config files
> needed merging with new upstream etc. Painless!
>
> However, I'm now seeing a really odd problem with X on my
> machine. I've got an AMD graphics card, which Xorg.0.log tells me is a
>
>  RADEON(0): Chipset: "PITCAIRN" (ChipID = 0x6810)
>
> and a DP+ connection to a lovely 27" NEC monitor. It works just fine
> when I'm using it, *but* when I leave it overnight and come in the
> next morning it doesn't want to wake up properly. I'm locking the
> screen with Xscreensaver and then turning off the monitor as I leave.
>
> In the morning, I turn on the screen and I don't get a display at
> all. I've wiggled the mouse, hit numlock on the keybard (the numlock
> led illuminates fine), etc., but no display. I've seen this kind of
> thing happen in the past on some machines, so I switch to VT1 and back
> to see if that helps. Still no display at all, either on console or
> under X. I log in remotely and I can see that the Xorg.0.log file has
> been updated with mode lines for the monitor, suggesting things have
> just woken up fine. But still no display.
>
> Here's the really weird thing: at this point, the monitor has
> basically locked up. It won't respond to the power/input/menu butttons
> at all, and is still showing the blue LED that says "I have signal"
> rather than switching to the amber "no signal" warning. Therefore, I
> can only assume there's a problem here with some weird invalid DP
> signal being produced.
>
> Yesterday, I gave up and rebooted after a few minutes - I had work to
> do. Today, I started searching for any other reports like this using
> my laptop. About ten minutes later while I was doing this
> (approximately, wasn't paying massive attention at this point), my
> desktop screen suddenly came to life and now it's working OK.
>
> I have no idea of where to even start debugging this. Help!
>


If this is a regression, what previous version was working correctly?
Does the problem only happen when you physically power off the
monitor?  Does it come back ok when you let dpms kick in?  How about
when you physically disconnect the monitor from the computer?  Also,
what screensavers are you using?  There may be a problematic GL
screensaver that's causing a GPU lockup.  Can you try forcing a single
known stable screensaver?

Alex


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cadnq5_oqrha6u84gd8vcmelsunfupxc-1zsu8_fufcseegd...@mail.gmail.com

Bug#782610: linux-image-3.16.0-4-amd64, xserver-xorg-video-radeon: Acer Aspire One 725: black screen in X after resume

[Alex Deucher]

On Tue, Apr 14, 2015 at 2:58 PM, Simon Richter  wrote:
> Package: linux-image-3.16.0-4-amd64,xserver-xorg-video-radeon
> Severity: normal
>
> Hi,
>
> I've recently installed an Acer Aspire One 725 with Debian jessie, and
> found that after resuming from sleep, the display remains black (but
> backlight is on) with X. Text mode consoles work fine with and without
> console-setup.
>
> This system uses an AMD CPU with integrated graphics:
>
> model name: AMD C-70 APU with Radeon(tm) HD Graphics
>
> 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee
> ATI Device [1002:980a]
>
> As I've already passed that machine back to the owner (with sleep mode
> disabled in systemd config), it is difficult for me to do further testing.

When you say sleep, do you mean suspend/resume or dpms?  Depending on
the hw involved, this patch might help:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=66c2b84ba6256bc5399eed45582af9ebb3ba2c15

Alex

>
>Simon
>
> -- System Information:
> Debian Release: 8.0
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> ___
> xorg-driver-ati mailing list
> xorg-driver-...@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-driver-ati


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cadnq5_p36tyc8wc00w63uc8cwxq7vtq0jqjoplwtfreyzxq...@mail.gmail.com

Bug#741695: xserver-xorg-video-intel: xv completely broken on HD 4400

[Alex Mestiashvili]

Cool, it works with the version from experimental -
2:2.99.911+git20140607-1~exp1 !
Also it seems that the source package has missing buid-deps, I had to
install these 3 package in order to build it on jessy:
libxcb-randr0-dev
libxcb-shape0-dev
libxcb-xfixes0-dev

Thanks,
Alex


On Tue, Jun 10, 2014 at 10:45 PM, maximilian attems  wrote:

> On Tue, Jun 10, 2014 at 10:38:24PM +0200, Alex Mestiashvili wrote:
> > I am experiencing the same trouble with my i3-4130T CPU and Intel HD
> 4400.
> > It works fine with 3.13, but doesn't work on 3.14 and 3.15-rc8 kernels.
> >
> > The symptoms are the same, I see only a picture or short line of a
> "video"
> > while the rest is static.
> > adding Option "AccelMethod" "sna" didn't help me.
> > Also works fine via OpenGL.
>
> did you try latest experimental xserver-xorg-video-intel with >= 3.14
> linux?
>
>
> best,
>
> --
> maks
>

Bug#741695: xserver-xorg-video-intel: xv completely broken on HD 4400

[Alex Mestiashvili]

I am experiencing the same trouble with my i3-4130T CPU and Intel HD 4400.
It works fine with 3.13, but doesn't work on 3.14 and 3.15-rc8 kernels.

The symptoms are the same, I see only a picture or short line of a "video"
while the rest is static.
adding Option "AccelMethod" "sna" didn't help me.
Also works fine via OpenGL.

Regards,
Alex

Bug#746409: xserver-xorg-video-radeon: No 3D acceleration with radeon driver.

[Alex Deucher]

On Tue, Apr 29, 2014 at 2:58 PM, Владимир Титов  wrote:
> Package: xserver-xorg-video-radeon
> Version: 1:6.14.4-8
> Severity: normal
>
> Greetings everyone.I installed Debian Wheezy 7.5 on HDD. OS boot and GNOME 3
> loading in fallback mode with error. I installed firmware-linux-nonfree 
> package
> and reboot. GNOME loading in fallback mode again.
> ..xsession-errors says:
> openConnection: connect: Нет такого файла или каталога
> cannot connect to brltty at :0
> gnome-session-is-accelerated: No hardware 3D support.
> gnome-session-check-accelerated: Helper exited with code 256
> gnome-session[3321]: WARNING: Session 'gnome' runnable check failed:
> Завершено с кодом 1
> dmesg|grep radeon command says:
> [5.404816] [drm] radeon kernel modesetting enabled.
> [5.406813] radeon :01:00.0: setting latency timer to 64
> [5.411254] radeon :01:00.0: VRAM: 512M 0x -
> 0x1FFF (512M used)
> [5.411263] radeon :01:00.0: GTT: 512M 0x2000 -
> 0x3FFF
> [5.412519] [drm] radeon: 512M of VRAM memory ready
> [5.412524] [drm] radeon: 512M of GTT memory ready.
> [5.415360] [drm] radeon: ib pool ready.
> [5.474763] platform radeon_cp.0: firmware: agent loaded
> radeon/RV730_pfp.bin into memory
> [5.614678] platform radeon_cp.0: firmware: agent loaded 
> radeon/RV730_me.bin
> into memory
> [5.678174] platform radeon_cp.0: firmware: agent loaded 
> radeon/R700_rlc.bin
> into memory
> [5.682544] radeon :01:00.0: WB enabled
> [5.682639] radeon :01:00.0: irq 43 for MSI/MSI-X
> [5.682650] radeon :01:00.0: radeon: using MSI.
> [5.682703] [drm] radeon: irq initialized.
> [5.906783] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed
> (scratch(0x8500)=0xCAFEDEAD)
> [5.906846] radeon :01:00.0: disabling GPU acceleration
> [5.923350] radeon :01:00.0: f712dc00 unpin not necessary
> [5.924982] radeon :01:00.0: f712d800 unpin not necessary
> [5.925979] [drm] radeon: power management initialized
> [5.992586] fbcon: radeondrmfb (fb0) is primary device
> [6.069809] fb0: radeondrmfb frame buffer device
> [6.073226] [drm] Initialized radeon 2.16.0 20080528 for :01:00.0 on
> minor 0
> So there is no 3D acceleration even with firmware loaded.I tried to install 
> ATI
> proprietary driver(fglrx-legacy-driver), it work only if I create file
> /etc/modprobe.d/fglrx-kms.conf and write "options fglrx modeset=1". Otherwise 
> X
> Server isn't loading - only black screen. With working fglrx GNOME also 
> loading
> in fallback mode. In Windows graphic card work correct.
>

Can you try a newer kernel?  3.2.0 is pretty old.

Alex


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CADnq5_O0vRSrid4gB=�=cWfcD5JpD=w58vpf9pa0xdqjw...@mail.gmail.com

Bug#742307: xserver-xorg-video-radeon: Radeon HD 6570 ("Turks") - severe display corruption esp. after boot

[Alex Deucher]

On Sat, Mar 22, 2014 at 1:05 AM, Benjamin Moody  wrote:
> Package: xserver-xorg-video-radeon
> Version: 1:6.14.4-8
> Severity: important
>
> Dear Maintainer,
>
> I have a Radeon HD 6570 card manufactured by XFX.  I'm having multiple
> problems with this card, some of which are probably kernel-related
> rather than X-related.
>
> I'm using the stable kernel and Xorg, as you can see below, but I've
> also tried the X server and drivers from testing (xserver-xorg-core
> 1.15.0-2, xserver-xorg-video-radeon 7.3.0-1+b1), with the same
> results.
>
>  - Disabling KMS (radeon.modeset=0) and using the "vesa" Xorg driver
>seems to work perfectly.  (Obviously no hardware acceleration.)
>
>  - If I enable KMS but don't start X, the screen is corrupted (a
>pattern of wrongly colored pixels in each 64-pixel-wide column.)
>The corruption is annoying, but consistent (it even looks the same
>from one boot to the next, although I haven't examined it closely.)
>
>See http://i.imgur.com/NxwoaUP.jpg for an example - sorry about the
>poor quality, and it's uglier than the picture makes it look.
>
>  - The same effect occurs if I use X with the "fbdev" driver.  In this
>case I can take a screenshot, and the corruption is not visible in
>the image file; from this I gather that X's internal memory is
>perfectly fine and the corruption is entirely on the display side.
>
>  - If I use KMS and the "radeon" driver:
>
> - When I start X for the first time after booting, the screen is
>   complete garbage.  It is filled with either (apparently) white
>   noise, or a scrambled version of whatever was on the screen
>   before I rebooted.
>
>   Usually, the mouse cursor is displayed; I can move the cursor
>   around, and I can use Ctrl-Alt-Backspace to kill the server.
>   However, I can't tell if the server is responding to any input
>   beyond that.  Every few seconds, the screen briefly turns black
>   then reappears.
>
>   The server log shows a number of error messages along the lines
>   of "EQ overflowing" (see the second copy of Xorg.0.log below.)
>
> - After killing the X server, the console appears fine (the
>   previous corruption has disappeared.)
>
> - When I start X for the second time, occasionally it works
>   correctly.  More often, I see similar results to the above, and
>   have to kill the server again.
>
> - When I start X for the *third* time, everything seems to work
>   correctly (including accelerated GL and Xv, although I haven't
>   tested them thoroughly.)
>
> So it appears that there is some sort of initialization that ought to
> be done by the kernel, but is not being done until the X driver is
> started.
>
> Furthermore, there's some additional initialization needed for the X
> driver itself to work, which for some reason only happens after
> starting & stopping X repeatedly.
>


>
> Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)

Is this still an issue with a newer kernel?  IIRC, this issue was
fixed a while ago.

Alex


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CADnq5_M+76_+ancG5qvFm+Usj3LLzWrN=+tvbfbt2vcuu5w...@mail.gmail.com

Bug#732514: [PATCH] fixes for Radeon KMS on kFreeBSD

[Alex Deucher]

On Wed, Dec 18, 2013 at 4:18 PM, Robert Millan  wrote:
> On 18/12/2013 22:09, Julien Cristau wrote:
>> On Wed, Dec 18, 2013 at 22:05:27 +0100, Robert Millan wrote:
>>
>>> Besides, when it comes to KMS drivers, is there a point in auto-loading them
>>> just because the hardware is present? AFAICS it makes a lot more sense to 
>>> load
>>> them only when X is started and we know we will need them.
>>>
>> Yes.  At least on linux it also gives you the fb console.
>
> Oh. Well we don't enable that yet (but now that you mention it, maybe we
> should...).
>
>> And there's
>> been a number of bug reports where X failed to start because the radeon
>> kernel driver was loaded too late.
>
> Where's this race condition? Is it related to the Linux plumbing, or something
> that could affect us too?

It could affect you too.  With UMS, the ddx would load the kernel
driver, but the kernel driver didn't actually do anything until the
ddx explicitly asked it to something.  With UMS, the ddx still took
care of hw init, the kernel driver basically just managed dma
addresses.  With KMS, the kernel driver inits and manages the hw so it
takes relatively longer to load and the ddx may try and access the
kernel driver before it's finished loading leading to fail.

Alex

>
> --
> Robert Millan
>
> ___
> xorg-driver-ati mailing list
> xorg-driver-...@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-driver-ati


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cadnq5_mbheazvam68k5up2gj70_zgfv5rxa9znd63r6+xmb...@mail.gmail.com

Bug#732514: [PATCH] fixes for Radeon KMS on kFreeBSD

[Alex Deucher]

On Wed, Dec 18, 2013 at 4:09 PM, Julien Cristau  wrote:
> On Wed, Dec 18, 2013 at 22:05:27 +0100, Robert Millan wrote:
>
>> Besides, when it comes to KMS drivers, is there a point in auto-loading them
>> just because the hardware is present? AFAICS it makes a lot more sense to 
>> load
>> them only when X is started and we know we will need them.
>>
> Yes.  At least on linux it also gives you the fb console.  And there's
> been a number of bug reports where X failed to start because the radeon
> kernel driver was loaded too late.

You also may want to use the driver without X, e.g., wayland, or
headless compute.  Additionally, if you have the driver loaded you can
use advanced power management features and dpms which are not
available with vesa or vga mode.

Alex

>
> Cheers,
> Julien
>
> ___
> xorg-driver-ati mailing list
> xorg-driver-...@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-driver-ati
>


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CADnq5_MBA5rn7NN94nQMmVMdb4iS0PnPS=-35una2u-fpdv...@mail.gmail.com

Bug#714510: xserver-xorg-video-radeon: Display corrupted after resume on ATI Radeon HD 2400 XT

[Alex Deucher]

On Sun, Jun 30, 2013 at 3:59 AM, Tobias Gerdin  wrote:
> Package: xserver-xorg-video-radeon
> Version: 1:6.14.4-8
> Severity: important
> Tags: upstream
>
> Dear Maintainer,
>
> After resuming system after a suspend (to RAM) the display is corrupted. It 
> is still
> possible to see what's going on but everything turns into a highly 
> unhealthy-looking
> (for the display) green-orange flickering mess.
>
> The system is this Apple iMac, see:
> http://www.everymac.com/systems/apple/imac/specs/imac-core-2-duo-2.0-20-inch-aluminum-specs.html
>
> I have never gotten this to work in Linux I think, and it's the only issue 
> that keeps me
> from switching to Linux from OS X (sounds works now as of the Wheezy release).
>
> I observe the same issue on Ubuntu (tried 12.04LTS and 13.04).
>

You might try a newer kernel or if you are using EFI to boot, try
using the legacy bios option.  Unfortunately, macs do just about
everything differently you may need some sort of mac specific quirk to
make it work properly, especially with EFI boot.

Alex


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cadnq5_nhzojq0mvxfxxxlctaoqswzaxfffbwalnf76ugo2g...@mail.gmail.com

Bug#529178: xserver-xorg-video-ati: Suffering from this bug + Possible mitigation

[Alex Deucher]

On Wed, Apr 3, 2013 at 2:22 PM, Pablo Oliveira  wrote:
> On Wed, Apr 3, 2013 at 3:34 PM, Alex Deucher  wrote:
>>
>> On Tue, Apr 2, 2013 at 10:04 AM, Pablo Oliveira  wrote:
>> > Package: xserver-xorg-video-ati
>> > Version: 1:6.14.4-8
>> > Followup-For: Bug #529178
>> > [...]
>> >
>> > * If I run "xset dpms force off" the problems disappears completely.
>>
>> To clarify, do you mean that after a dpms cycle both monitors work
>> correctly?
>
>
> Yes, after turning off DPMS, both monitors work correctly.
> I have been using the system all day without any flickering problems.
>
>>
>> Does a newer kernel help?  3.2 is pretty old.  There were
>> a number of display related fixes that went into 3.7 for example.
>
>
> I will try with a new kernel and report back.
>
> Also, I would add that, like the other people affected by this bug,
> the problem triggers often when scrolling a window.

Is this the same issue?  I.e., does the blinking come back after a
dpms cycle if you scroll?  If so, it sounds like it may be a bandwidth
issue.  You might try booting with radeon.disp_priority=2 on the
kernel command line in grub.

Alex


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cadnq5_o_kq4gryopyjww0p_gsy18j102aq9pxk568lnmhwe...@mail.gmail.com

Bug#529178: xserver-xorg-video-ati: Suffering from this bug + Possible mitigation

[Alex Deucher]

On Tue, Apr 2, 2013 at 10:04 AM, Pablo Oliveira  wrote:
> Package: xserver-xorg-video-ati
> Version: 1:6.14.4-8
> Followup-For: Bug #529178
>
> Dear Maintainer,
>
> After updating my system to wheezy, and in particular the
> xserver-xorg-video-ati package to version 1:6.14.4-8, I
> now suffer from a similar issue.
>
> I have two monitors. The right one, and only the right one, randomly
> turns off and on.
>
> * I use the default Xorg configuration and setup dual monitors
>   using xrandr --output DVI-0 --left-of DVI-1 --auto.
>
> * The two monitors are identical models: SAMSUNG SyncMasterB1940.
>   The problem does not seem to be in the monitors: when I swap the two DVI
>   connectors, the left one starts to flicker on and off and the right
>   one works flawlessly.
>
> * If I run "xset dpms force off" the problems disappears completely.

To clarify, do you mean that after a dpms cycle both monitors work
correctly?  Does a newer kernel help?  3.2 is pretty old.  There were
a number of display related fixes that went into 3.7 for example.

Alex


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cadnq5_opmwpwktt8vivzf9yj09zjadabmisby6zx2b1+cf3...@mail.gmail.com

Bug#702739: xserver-xorg-input-evdev: Lenovo USB Scrollpoint mouse is unusable

[Alex Corcoles]

/0
E: PROP=8
E: SUBSYSTEM=input
E: UDEV_LOG=3
E: USEC_INITIALIZED=12690213

P: /devices/platform/i8042/serio1/input/input11/event11
N: input/event11
S: input/by-path/platform-i8042-serio-1-event-mouse
E: DEVLINKS=/dev/input/by-path/platform-i8042-serio-1-event-mouse
E: DEVNAME=/dev/input/event11
E: DEVPATH=/devices/platform/i8042/serio1/input/input11/event11
E: ID_INPUT=1
E: ID_INPUT_TOUCHPAD=1
E: ID_PATH=platform-i8042-serio-1
E: ID_PATH_TAG=platform-i8042-serio-1
E: ID_SERIAL=noserial
E: MAJOR=13
E: MINOR=75
E: SUBSYSTEM=input
E: UDEV_LOG=3
E: USEC_INITIALIZED=12908789

P: /devices/platform/i8042/serio1/input/input11/mouse1
N: input/mouse1
S: input/by-path/platform-i8042-serio-1-mouse
E: DEVLINKS=/dev/input/by-path/platform-i8042-serio-1-mouse
E: DEVNAME=/dev/input/mouse1
E: DEVPATH=/devices/platform/i8042/serio1/input/input11/mouse1
E: ID_INPUT=1
E: ID_INPUT_TOUCHPAD=1
E: ID_PATH=platform-i8042-serio-1
E: ID_PATH_TAG=platform-i8042-serio-1
E: ID_SERIAL=noserial
E: MAJOR=13
E: MINOR=33
E: SUBSYSTEM=input
E: UDEV_LOG=3
E: USEC_INITIALIZED=12907300

P: /devices/platform/pcspkr/input/input7
E: DEVPATH=/devices/platform/pcspkr/input/input7
E: EV=40001
E: ID_INPUT=1
E: ID_PATH=platform-pcspkr
E: ID_PATH_TAG=platform-pcspkr
E: ID_SERIAL=noserial
E: MODALIAS=input:b0010v001Fp0001e0100-e0,12,kramls1,2,fw
E: NAME="PC Speaker"
E: PHYS="isa0061/input0"
E: PRODUCT=10/1f/1/100
E: PROP=0
E: SND=6
E: SUBSYSTEM=input
E: UDEV_LOG=3
E: USEC_INITIALIZED=12504610

P: /devices/platform/pcspkr/input/input7/event7
N: input/event7
S: input/by-path/platform-pcspkr-event-spkr
E: DEVLINKS=/dev/input/by-path/platform-pcspkr-event-spkr
E: DEVNAME=/dev/input/event7
E: DEVPATH=/devices/platform/pcspkr/input/input7/event7
E: ID_INPUT=1
E: ID_PATH=platform-pcspkr
E: ID_PATH_TAG=platform-pcspkr
E: ID_SERIAL=noserial
E: MAJOR=13
E: MINOR=71
E: SUBSYSTEM=input
E: UDEV_LOG=3
E: USEC_INITIALIZED=12625766

P: /devices/virtual/input/input13
E: DEVPATH=/devices/virtual/input/input13
E: EV=3
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_INPUT_KEYBOARD=1
E: ID_SERIAL=noserial
E: KEY=       
fffe
E: 
MODALIAS=input:b0003vpe0004-e0,1,k71,72,73,74,75,76,77,78,79,7A,7B,7C,7D,7E,7F,80,81,82,83,84,85,86,87,88,89,8A,8B,8C,8D,8E,8F,90,91,92,93,94,95,96,97,98,99,9A,9B,9C,9D,9E,9F,A0,A1,A2,A3,A4,A5,A6,A7,A8,A9,AA,AB,AC,AD,AE,AF,B0,B1,B2,B3,B4,B5,B6,B7,B8,B9,BA,BB,BC,BD,BE,BF,C0,C1,C2,C3,C4,C5,C6,C7,C8,C9,CA,CB,CC,CD,CE,CF,D0,D1,D2,D3,D4,D5,D6,D7,D8,D9,DA,DB,DC,DD,DE,DF,E0,E1,E2,E3,E4,E5,E6,E7,E8,E9,EA,EB,EC,ED,EE,EF,F0,F1,F2,F3,F4,F5,F6,F7,F8,F9,FA,FB,FC,FD,FE,FF,ramlsfw

E: NAME="ACPI Virtual Keyboard Device"
E: PRODUCT=3/0/0/4
E: PROP=0
E: SUBSYSTEM=input
E: UDEV_LOG=3
E: USEC_INITIALIZED=22040968

P: /devices/virtual/input/input13/event13
N: input/event13
E: BACKSPACE=guess
E: DEVNAME=/dev/input/event13
E: DEVPATH=/devices/virtual/input/input13/event13
E: DMI_VENDOR=ASUSTeK Computer INC.
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_INPUT_KEYBOARD=1
E: ID_SERIAL=noserial
E: MAJOR=13
E: MINOR=77
E: SUBSYSTEM=input
E: UDEV_LOG=3
E: USEC_INITIALIZED=22052888
E: XKBLAYOUT=es
E: XKBMODEL=pc105


DRM Information from dmesg:
---
[1.272963] Linux agpgart interface v0.103
[1.273214] agpgart-intel :00:00.0: Intel 945GME Chipset
[1.273380] agpgart-intel :00:00.0: detected gtt size: 262144K 
total, 262144K mappable

[1.273548] agpgart-intel :00:00.0: detected 8192K stolen memory
[1.273826] agpgart-intel :00:00.0: AGP aperture is 256M @ 0xd000
[   10.706624] [drm] Initialized drm 1.1.0 20060810
[   10.873254] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[   10.873263] [drm] Driver supports precise vblank timestamp query.
[   11.200208] [drm] initialized overlay support
[   11.224181] fbcon: inteldrmfb (fb0) is primary device
[   11.672617] fb0: inteldrmfb frame buffer device
[   11.672623] drm: registered panic notifier
[   11.673018] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on 
minor 0



-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (500, 'testing'), (300, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xserver-xorg-input-evdev depends on:
ii  libc6  2.13-38
ii  libmtdev1  1.1.2-1
ii  xserver-xorg-core [xorg-input-abi-16]  2:1.12.4-5

xserver-xorg-input-evdev recommends no packages.

xserver-xorg-input-evdev suggests no packages.

-- no debconf information

--
   ___mail: alex at corcoles dot net
 {~._.~}   ICQ: 66791436
  ( Y )MSN: koalillo at fastmail dot fm
 ()~*~()Y!: koalillo
 (_)-(_)  http://alex.corcoles.net/


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/513cfdd4.30...@corcoles.net

Bug#698503: tearing with Radeon HD 6970

[Alex Deucher]

On Sat, Jan 19, 2013 at 8:59 AM, Marc Dequènes  wrote:
> Package: xserver-xorg-video-radeon
> Version: 1:6.14.4-6
> Severity: normal
>
>
> Coin,
>
> At the end of the 2012 year, i upgraded my desktop machine, switching from
> Radeon HD 4890 to Radeon HD 6970. Since then i experience tearing, easily
> visible when watching videos for example. I was using Unagi at the time, so
> i stopped using it which only reduced the effect.
>
> It is not easy to show the resulting effect so i tried some camera shots
> (see attached) using the following video :
>   http://www.youtube.com/watch?v=ceX18O9pvLs
> Unfortunately, it does not seem to show anything proving I'm not drunk. The
> other machine i can test on has got a Mobility Radeon X300 and besides some
> slowness display it properly ; shots on this machine also show "brightness
> blocks", even if less blocks and with a perfect separation line.
>
> Tell me if i can test anything else.

What are you using to render the videos (Xv, GL)?  Did you also change
your desktop environment?  Note that if you are using a compositing
manager (compiz, gnome shell, kwm, etc.), the compositing manager is
responsible for preventing tearing by syncing screen updates to vsync.
 If you are using Xv, the driver's anti-tearing Xv features only work
when rendering directly to the display buffer.  If you are using a
composting manager, the driver renders to an offscreen buffer and the
compositor is responsible for updating the display buffer with the new
Xv data.

Alex


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cadnq5_ovcej17kinr5uwwdedkv3rf-5mklxcmkoikso0_bl...@mail.gmail.com

Bug#682099: xserver-xorg-video-ati: EXAPixmaps=On screen tearing at high resolution under certain configurations

[Alex Deucher]

On Wed, Oct 24, 2012 at 5:41 AM, James Robertson  wrote:
>> The only other option I was going to try was using a Display port to
>> DVI adapter from the side of my laptop to replace the VGA from the
>> docking station.  If I purchase one to  try that I'll let you know.
>
> I bought a an Active display port adapter for my laptop.  That won't
> even work with resolutions above 1280x1024 under Debian (works fine up
> to native 1980x1080 res on Windows 7).
>
> I wanted to use one of my monitors in portrait mode but the the
> rotation would not work if I had Option "NoAccel" "true".  Of course
> disabling it meant I get the hideous screen corruption.
>
> All of this works fine on Windows 7 with DVI/VGA or Display Port so at
> least I can confirm it's not a hardware limitation.
>
> I am quite bummed to have this problem.  Can anyone suggest ways in
> which I can troubleshoot/resolve it?

Can you try a newer kernel?  3.6 or 3.7?  That may help with the
modesettings.  As for the acceleration, corruption, you might try a
newer version of mesa.

Alex


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CADnq5_OiUdx-80yc7w7fX5dsi-QT=fv9At=Dws=kn6J-HD=n...@mail.gmail.com

Bug#688828: xserver-xorg-video-radeon: brightness controls don't work

[Alex Deucher]

On Tue, Sep 25, 2012 at 8:57 PM, Geoff Crompton
 wrote:
> Package: xserver-xorg-video-radeon
> Version: 1:6.14.4-5
> Severity: normal
>
> Dear Maintainer,
>
> The brightness controls on my iMac aren't effective at changing the brightness
> of either of my displays. They do popup the gnome brightness indicator, and
> alter the values of /sys/class/backlight/acpi_video0/brightness.
>
> But they don't effect the brightness of either the primary display, or the
> secondary display I've got attached (via a thunderbolt to DVI connector).
> Likewise the gnome system settings brightness controls slide around, and do
> alter  /sys/class/backlight/acpi_video0/brightness, but don't change the
> brightness.
>
> Rebooting into Mac and setting the brightness there seems to maintain that
> brightness setting when I reboot back into Linux. I'm booting with grub-efi.

If apple uses the built in GPU backlight controller, it may work with
the new backlight control patches in my drm-3.7 branch:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.7-wip

Alex


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cadnq5_p+-3n8qrr4fmrncaoqbzwamu2e+pb0wdbvvuum7ba...@mail.gmail.com

Bug#687461: xserver-xorg-video-radeon: HD 6310 video gives only colored snow/black screen

[Alex Deucher]

On Wed, Sep 12, 2012 at 5:50 PM, Michael Evans  wrote:
> Package: xserver-xorg-video-radeon
> Version: 1:6.14.4-5
> Severity: normal
>
> Dear Maintainer,
>
> I get no video, only colored snow.  Boot seems OK up until X is started.
> The system is then unusable.  (I am writing from a different wheezy
> install).

Make sure you install the firmware package and that the firmware is
available in the initrd if you are using one.

Alex


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CADnq5_OC3ZZRggE=sepo_08veebk+dctwyw9qzyjapvmzez...@mail.gmail.com

Bug#686971: [radeon] display unwantingly dimmed, dimming state leaking across VT switch

[Alex Deucher]

On Fri, Sep 7, 2012 at 3:45 PM, Yann Dirson  wrote:
> Package: xserver-xorg-video-radeon
> Version: 1:6.14.4-5
> Severity: normal
>
> What I can easily reproduce:
>
> Running "xscreensaver-command -activate", and hitting Ctrl-Alt-F1
> while it is fading away leaves me on a dimmed tty1.  Switching to
> other text consoles does not change the dimming.  Switching back to my
> X session shows correct luminosity, and it I then go back to text
> consoles they are OK as well.  Not so important if it were not for the
> original problem, which is not so easy to reproduce:
>
> (I was told) there was a Ctrl-alt-Fn console switch while xscreensaver
> was fading out my X display.  When I went back and switched back to my
> own session, my display was dimmed, while other X displays were not
> when I switched to them.  When I switched to a text console, it was
> dimmed when I switched from my dimmed X, and was not dimmed when I
> switched from the other, non-dimmed, ones.
>
> A quick look at utils/fade.c in the xscrensaver source shows it is
> possibly using xf86vidmode for the fading operation, so I went looking
> for a tool to query the xf86vm settings, but found none.  The closest
> I found was xcalib, but I could not have anything queried with it
> either.  Eventually I guessed right with "xcalib -a -c" and everything
> was back in good shape, but less stubborn ones would have rebooted
> their machines like a windows box long before...
>
> The "leaking dim state" makes me guess the problem would be more in
> the radeon side of things, rather than at the xf86vm level, but that's
> a wild guess only...
>

The fade effect is done by adjusting the gamma.  When you switch VTs,
just the display base address is changed.  The gamma is not changed.
I suspect this may affect other drivers as well so probably needs to
be fixed in common code.

Alex


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CADnq5_ONiHfTh=uHmL9Rn=8kdk1p3pjsykv+5-2mmxqqn2g...@mail.gmail.com

Bug#682099: xserver-xorg-video-ati: EXAPixmaps=On screen tearing at high resolution under certain configurations

[Alex Deucher]

On Fri, Jul 20, 2012 at 1:45 PM, Michel Dänzer  wrote:
> On Don, 2012-07-19 at 23:43 +1000, James Robertson wrote:
>> Package: xserver-xorg-video-ati
>> Version: 1:6.14.4-5
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> I have a Lenovo R500 laptop with an "[AMD] nee ATI RV620 [Mobility Radeon HD 
>> 3400
>> Series]" graphics chip
>>
>> I recently obtained 2x AOC monitors with a 1920x1080 resolution and have
>> these connected via DVI and VGA to a laptop docking station.
>>
>> The laptop only supports a maximum of 2 displays at once.
>>
>> With the laptop display disabled I get screen tearing and corruption when
>> using 1 or both of the external monitors with 1920x1080 resolution.
>> But strangely if I set one of them to a lower resolution such as 1680x1050
>> (the other still at 1920x1080) the screen tearing issue dissapears.  Odd 
>> given
>> a single display gets the tearing...
>>
>> If using the laptop's display in conjunction with either DVI or VGA
>> connected monitor at 1920x1080 I experience no tearing.
>>

Also note that rendering can only be synchronized to one head at a
time to avoid tearing.  If you have windows that span multiple heads,
you may get tearing on the non-synced heads.

Alex


--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CADnq5_PQq+-_nu+JyBMwAGsnpwL028pub1ZJE8ûHtyP•v...@mail.gmail.com

Bug#677864: srsly?

[Alex Goebel]

Are we really sure it's a service to debian users or debian as a 
distribution to simply remove compiz from wheezy based on a number of 
minor(?) issues that are so obscure that they needed a fake RC bug?




--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fe6c1a8.5030...@gmail.com

Bug#661943: xserver-xorg-video-radeon: Unable to set native resolution with KMS enabled

[Alex Deucher]

On Mon, Mar 5, 2012 at 12:42 PM, Christopher Dow
 wrote:
> Unfortunately, my problem is that I can't change the display modes to the 
> native resolution.  Even with one display disabled, I still can't set the 
> native resolution.  I get the same "input timing not supported" message every 
> time I have tried.
>
> It wouldn't be a problem if the default was not what I wanted but I could 
> change to the correct resolution.
>
> Most of my attempts to change the resolution have been been using the KDE 
> display tool (which, as I understand, uses xrandr underneath).  However, I've 
> also attempted to use xrandr directly.
>

What mode gets picked when you start up with a single display
attached?  Can you attach your xorg log with a single display?  Does
the console pick the correct mode before X starts?



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cadnq5_na4zosck-sxvn79sgynk6lah3mlxgek61ygbwdxuy...@mail.gmail.com

Bug#661943: xserver-xorg-video-radeon: Unable to set native resolution with KMS enabled

[Alex Deucher]

On Fri, Mar 2, 2012 at 3:30 PM, Christopher Dow
 wrote:
> Package: xserver-xorg-video-radeon
> Version: 1:6.14.3-2
> Severity: important
>
> I am unable to set the the native resolution of my monitors with KMS enabled. 
>  Whenever I try to set the native resolution, the monitor displays the 
> following message message (with  replaced with the apropriate 
> native resolution:
>
> "The current input timing is not supported by the monitor display. Please 
> change your input timing to  or any other monitor listed timing 
> as per the monitor specifications."
>
> I have two monitors ('Dell P2210' and a 'Dell P2010H').  I am not able to the 
> native resolution for either of these monitors.  You can find the 
> specifications for these monitors here:
>
> http://support.dell.com/support/edocs/monitors/P2210/en/ug/about.htm#Specifications
> http://support.dell.com/support/edocs/monitors/P2010H/en/ug/about.htm#Specifications
>
> Whenever boot into Debian, I get this same message for a few seconds and then 
> the display goes to a lower resolution.  I also get the same message if I try 
> to switch to any of the virtual terminals.
>
> If I disable KMS, I am able to set the native resolution for both of these 
> monitors (however, then I can't set my desktop to span 2 monitors but that is 
> probably a different issue).
>

[13.127] (II) RADEON(0): Output DisplayPort-0 connected
[13.127] (II) RADEON(0): Output DisplayPort-1 connected
[13.127] (II) RADEON(0): Using fuzzy aspect match for initial modes
[13.127] (II) RADEON(0): Output DisplayPort-0 using initial mode 1152x864
[13.127] (II) RADEON(0): Output DisplayPort-1 using initial mode 1152x864

The xserver (not the driver) is picking 1152x864 since it's the
largest common mode supported by both monitors.  You'll have to use
xrandr to choose a different mode (or specify different default modes
in your xorg.conf).  Alternatively, you can start up X with one
monitor attached and then enable the second one manually with xrandr.

Alex



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CADnq5_PTiDg2+ZP0BvRfHey6sEQyut1KyWq0forgffrSXu==l...@mail.gmail.com

Bug#658636: Acknowledgement (xserver-xorg-video-radeon: Multiple DRI regressions)

[Alex Deucher]

On Tue, Feb 7, 2012 at 7:32 PM, Witold Baryluk  wrote:
>
> So why there are two incompatible drivers, especially when radeon looks
> to be providing framebuffer anyway? Is radeonfb module supporting even
> some older hardware so it is keeped in kernel?

radeon covers all hw radeonfb covers and more.  The reason radeonfb is
still around is that it covers a few corner cases (suspend and resume
on ppc mac cards) which hasn't been ported over to radeon yet.  On
x86, there is no reason to use radeonfb.

Alex



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cadnq5_o9uxr6oqssfcd13ua0vlcfcsh2gtteqnvpkswpyn6...@mail.gmail.com

Bug#630345: gdb trace and logs with experimental drivers

[Alex Deucher]

On Sun, Jan 8, 2012 at 2:15 AM, Craig Small  wrote:
> On Wed, Jan 04, 2012 at 09:48:50AM -0500, Alex Deucher wrote:
>> Is there any chance you are using a hybrid laptop with both Intel and
>> AMD GPUs in it?  Based on your log this looks like it a MUX-less one
> It is definitely a hybrid laptop with Intel and AMD GPUs.  I'm not sure
> if it is muxless or not.  This has worked with the closed-source fglrx
> drivers.

They support this setup.

>
>> MUX-less systems aren't supported yet as we need a fair amount of drm
>> and X infrastructure to handle buffer sharing between GPUs and
>> decoupled display and rendering.
> When you mean "we" you're talking about xorg and the people supporting
> it?  I completely understand this is really a problem of ATI's doing.
>

It's a problem of a lack of manpower in the open source stack.  It's a
huge amount of non-driver work to support this.

Alex

>  - Craig
>
> --
> Craig Small VK2XLZ   http://enc.com.au/          csmall at : enc.com.au
> Debian GNU/Linux     http://www.debian.org/      csmall at : debian.org
> GPG fingerprint:     5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cadnq5_pg-ae16vq+ft3k-29+bjqrszn95e2doyfvtk-wenv...@mail.gmail.com

Bug#630345: gdb trace and logs with experimental drivers

[Alex Deucher]

On Wed, Jan 4, 2012 at 4:54 AM, Craig Small  wrote:
> I tried the radeon and intel drivers. The intel bit works ok but when i
> make a minimal xorg.conf to use the radeon chip the X server crashes.
>
> Attached is the gdb logs and Xorg.0.log files.  I hope these help make
> sense of what is going wrong.
>

Is there any chance you are using a hybrid laptop with both Intel and
AMD GPUs in it?  Based on your log this looks like it a MUX-less one
in which case the discrete AMD card is not actually connected to any
displays (or if it is, it might only be connected to an external
monitor port).  We can double check by posting your dmesg output.
MUX-less systems aren't supported yet as we need a fair amount of drm
and X infrastructure to handle buffer sharing between GPUs and
decoupled display and rendering.

Alex

>  - Craig
> --
> Craig Small VK2XLZ   http://enc.com.au/          csmall at : enc.com.au
> Debian GNU/Linux     http://www.debian.org/      csmall at : debian.org
> GPG fingerprint:     5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5
>
> ___
> xorg-driver-ati mailing list
> xorg-driver-...@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-driver-ati
>



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cadnq5_mndjlwgye3ju0ey6oj-tktogffoyrhkr4fiyfjutq...@mail.gmail.com

Bug#648598: Gnome3: complete system freeze, fallback OK

[Alex Deucher]

On Mon, Nov 14, 2011 at 9:34 AM, Joost Kraaijeveld
 wrote:
> On Mon, 2011-11-14 at 09:15 -0500, Alex Deucher wrote:
>> I would suggest using KMS rather than UMS.  When you switch to KMS,
>> I'd also suggest using the r600 gallium 3D driver and removing the
>> Virtual line from your xorg.conf.
> Ah, there is an error in the KMS radeon-kms.conf file: when it crashed
> the (now commented out) "options radeon modeset=1" was active. I had to
> disable that to be able to use the machine and file the bug. Sorry about
> the confusion.
>
> Further, is there a difference between the xserver-xorg-video-radion
> driver and the "r600 gallium driver" and if so, what is the Debian
> package for that? I did notice that glxinfo did say it was using gallium
> 0.4. Would that mean that I was using the right driver?

I'm not familiar with the debian packages.  The r600 gallium driver is
the 3D OpenGL driver. xorg-video-radeon is the Xorg ddx(2D, Xv,
xrandr, etc.).  If glxinfo says gallium 0.4 on RV670 that is correct.

Alex

>
> --
> Groeten,
>
> Joost Kraaijeveld
> Askesis B.V.
> Molukkenstraat 14
> 6524NB Nijmegen
> tel: 024-3888063 / 06-51855277
> fax: 024-3608416
> web: www.askesis.nl
>
>



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cadnq5_nyhrypjc7skf3no-gookxcbjy-6cbm0enqa2en92b...@mail.gmail.com

Bug#648598: Gnome3: complete system freeze, fallback OK

[Alex Deucher]

On Sun, Nov 13, 2011 at 5:26 AM, Joost Kraaijeveld
 wrote:
> Package: xserver-xorg-video-radeon
> Version: 1:6.14.3-1
> Severity: critical
> Justification: breaks the whole system
>
> Dear Maintainer,
>
> After some time running Gnome3 with the new shell my system lock up. It 
> completely freezes, nothing works: no alt+F1 ,
> ctrl+alt+del, alt-backspace, no remote login via ssh possible and the machine 
> does not respons to pings. The only way to reboot
> is using the power button (off and than on). Just using the reset button 
> results in not finding the boot disk anymore. I can't find
> anything in any of the log files (messages, kernel, debug, daemon). The 
> freeze *almost* always happens during drag and drop operations or when using 
> the mouse to click on icons (menu, evolution expanding threads etc). 
> Sometimes it happens when doing nothing with the system but when audio is 
> playing. Running Gnome3 in the fallback mode works OK and no freeze happens.
>

I would suggest using KMS rather than UMS.  When you switch to KMS,
I'd also suggest using the r600 gallium 3D driver and removing the
Virtual line from your xorg.conf.

Alex



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cadnq5_m8zim_rvl2nxfkdueagvedbkdxomqocbdmtyzsvkk...@mail.gmail.com

Bug#648222: Significant 2D performance regression with ColorTiling

[Alex Deucher]

On Sun, Nov 13, 2011 at 1:34 PM, Iustin Pop  wrote:
> On Thu, Nov 10, 2011 at 06:15:43PM +0100, Michel Dänzer wrote:
>> On Don, 2011-11-10 at 18:01 +0100, Michal Suchanek wrote:
>> > On 10 November 2011 17:46, Alex Deucher  wrote:
>> > > On Wed, Nov 9, 2011 at 12:36 PM, Iustin Pop  wrote:
>> > >>
>> > >> The recent upgrade of xserver-xorg-video-radeon from 1:6.14.2-2 to
>> > >> 1:6.14.3-1 enabled ColorTiling for my card, which in turn caused a
>> > >> significant performance degradation in 2D (yes, I understand it should
>> > >> make 3D faster, but I didn't know it should slow down 2D applications).
>> > >>
>> > >> I'm using plain 2D environment (openbox, no compositing, anything) and
>> > >> plain xterm (bitmap fonts, no AA, etc.). The speed of display text has
>> > >> changed significantly enough that I can "see" my mutt refreshing the
>> > >> inbox and drawing the lines.
>> > >
>> > > Tiling will speed up all rendering (2D and 3D).  However, it sounds
>> > > like you are using an environment that is mostly software rendering.
>> > > As such in order for the CPU to access tiled buffers, the GPU has to
>> > > copy them to a linear buffer before CPU can access it properly.
>> >
>> > FWIW I have color tiling enabled and have no speed issues in urxvt -
>> > TrueType fonts, AA enabled, etc.
>> >
>> > Unlike xterm urxvt (rxvt-unicode) uses some special font-rendering
>> > libraries, however.
>> >
>> > If I understand it correctly xterm would use the in-server bitmap font
>> > rendering which the X server can accelerate as much as it wants.
>>
>> Core bitmap fonts are completely unaccelerated so far with EXA. xterm
>> can also use Xft for font rendering via the -fa option though, which is
>> well accelerated.
>
> Hi all, thanks for the replies.
>
> I've tested further and this seems to be a problem specific to xterm
> (and possibly other software? not sure how to test e.g. firefox's UI
> speed):
>
> Test file: ~20K lines. I've chosen the font sizes so as to have the same
> number of lines in full-screen. The timing is simply "time cat file".
>
> ColorTiling disabled:
>
> xterm -fn fixed:      ~3.3s
> xterm -fa Mono -fs 8: ~8.6s
> rxvt-unicode -fn fixed: ~0.07s
> rxvt-unicode -fn xft:Mono:pixelsize=11: ~0.05s
>
> ColorTiling enabled:
>
> xterm -fn fixed:      ~21s
> xterm -fa Mono -fs 8: ~7.8s
> rxvt-unicode -fn fixed: ~0.6s usually, sometimes ~0.1s??
> rxvt-unicode -fn xft:Mono:pixelsize=11: ~0.05s
>
> So it seems to me that:
>
> a) whatever xterm does, it is very sub-optimal
> b) while xterm's -fa mode is indeed sped up by ColorTiling, it's still
>   many times slower than with ColorTiling disabled and using core
>   fonts
> c) also rxvt-unicode with core fonts is slowed down by color tiling,
>   sometimes very much so (10x)
>
> Based on this I think this is mostly an xterm bug (-fa should/could be
> much faster), but I wonder if it also applies to other purely software
> 2D rendering.

It likely does.  We optimize the accelerated paths rather than the slow paths.

Alex



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cadnq5_nrxqyyw63re830m1nxojv63p8t5vdmj1biruxuwsu...@mail.gmail.com

Bug#648222: Significant 2D performance regression with ColorTiling

[Alex Deucher]

On Wed, Nov 9, 2011 at 12:36 PM, Iustin Pop  wrote:
> Package: xserver-xorg-video-radeon
>
> Version: 1:6.14.3-1
> Severity: minor
>
> Hi,
>
> The recent upgrade of xserver-xorg-video-radeon from 1:6.14.2-2 to
> 1:6.14.3-1 enabled ColorTiling for my card, which in turn caused a
> significant performance degradation in 2D (yes, I understand it should
> make 3D faster, but I didn't know it should slow down 2D applications).
>
> I'm using plain 2D environment (openbox, no compositing, anything) and
> plain xterm (bitmap fonts, no AA, etc.). The speed of display text has
> changed significantly enough that I can "see" my mutt refreshing the
> inbox and drawing the lines.
>
> Cat-ing a big (~4K lines of text) file on a full-screen xterm is:
>
> - 6.14.2-2 (low power profile): ~0.8s
> - 6.14.3   (high power)       : ~3.1s
> - 6.14.3   (low power)        : ~5.0s
>
> So it's more than 5x time slower, which makes it "unpleasant".
>
> Simply disabling ColorTiling makes the problem go away, and 6.14.3 is as
> fast as 6.14.2.
>

Tiling will speed up all rendering (2D and 3D).  However, it sounds
like you are using an environment that is mostly software rendering.
As such in order for the CPU to access tiled buffers, the GPU has to
copy them to a linear buffer before CPU can access it properly.

Alex



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CADnq5_MZWwp_s5MhB1PQCLk1GzQ1dRDwCK0KvX=ltsez_yu...@mail.gmail.com

Bug#605051: (no subject)

[Alex Brotman]

I can confirm the same activity as David.  No longer segfaults.

The driver itself still seems regressed.  It did work in Lenny, I cannot get a 
usable screen through auto-detection with Squeeze or Wheezy.




--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1320420399.7527.yahoomail...@web39705.mail.mud.yahoo.com

Bug#605051: #605051 not reproducible with xserver-xorg-core 2:1.11.1.902-1

[Alex Brotman]

I was planning to update this machine to Wheezy, I can retest this.  I still 
owe the BTS another bug about the driver regression anyway, so I could 
hopefully test that also.



- Original Message -
From: Daniel Kahn Gillmor 
To: 605...@bugs.debian.org; 605051-submit...@bugs.debian.org
Cc: 
Sent: Thursday, November 3, 2011 3:55 PM
Subject: Bug#605051: #605051 not reproducible with xserver-xorg-core 
2:1.11.1.902-1

I'm running sid on a powerpc mac mini with similar arrangement to the
one submitted as #605051.

Xorg -configure does not Segfault or Bus Error (though it does return an
non-zero return code):

> 0 root@bigpuff:~# lspci
> :00:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 AGP
> :00:10.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 
> 9200] (rev 01)
> 0001:10:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 PCI
> 0001:10:17.0 Unassigned class [ff00]: Apple Computer Inc. KeyLargo/Intrepid 
> Mac I/O
> 0001:10:18.0 USB Controller: Apple Computer Inc. KeyLargo/Intrepid USB
> 0001:10:19.0 USB Controller: Apple Computer Inc. KeyLargo/Intrepid USB
> 0001:10:1a.0 USB Controller: Apple Computer Inc. KeyLargo/Intrepid USB
> 0001:10:1b.0 USB Controller: NEC Corporation USB (rev 43)
> 0001:10:1b.1 USB Controller: NEC Corporation USB (rev 43)
> 0001:10:1b.2 USB Controller: NEC Corporation USB 2.0 (rev 04)
> 0002:20:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 Internal PCI
> 0002:20:0d.0 Unassigned class [ff00]: Apple Computer Inc. UniNorth/Intrepid 
> ATA/100
> 0002:20:0e.0 FireWire (IEEE 1394): Apple Computer Inc. UniNorth 2 FireWire 
> (rev 81)
> 0002:20:0f.0 Ethernet controller: Apple Computer Inc. UniNorth 2 GMAC (Sun 
> GEM) (rev 80)
> 0 root@bigpuff:~# Xorg -configure
> 
> X.Org X Server 1.11.1.902 (1.11.2 RC 2)
> Release Date: 2011-10-28
> X Protocol Version 11, Revision 0
> Build Operating System: Linux 2.6.32-5-powerpc64 ppc Debian
> Current Operating System: Linux bigpuff 3.0.0-2-powerpc-smp #1 SMP Fri Oct 7 
> 23:29:23 UTC 2011 ppc
> Kernel command line: BOOT_IMAGE=/vmlinux-3.0.0-2-powerpc-smp 
> root=/dev/mapper/bigpuff-root ro quiet
> Build Date: 02 November 2011  12:09:24PM
> xorg-server 2:1.11.1.902-1 (Cyril Brulebois ) 
> Current version of pixman: 0.22.2
>     Before reporting problems, check http://wiki.x.org
>     to make sure that you have the latest version.
> Markers: (--) probed, (**) from config file, (==) default setting,
>     (++) from command line, (!!) notice, (II) informational,
>     (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> (==) Log file: "/var/log/Xorg.0.log", Time: Thu Nov  3 15:49:01 2011
> List of video drivers:
>     s3virge
>     r128
>     nouveau
>     sis
>     s3
>     mach64
>     trident
>     radeon
>     mga
>     ati
>     sisusb
>     savage
>     tdfx
>     chips
>     fbdev
> (++) Using config file: "/root/xorg.conf.new"
> (==) Using system config directory "/usr/share/X11/xorg.conf.d"
> (II) [KMS] No DRICreatePCIBusID symbol, no kernel modesetting.
> Number of created screens does not match number of detected devices.
>   Configuration failed.
> Server terminated with error (2). Closing log file.
> 0 root@bigpuff:~# 

Note: this is the same machine that has the difficulties reported in
#646025.

i'm happy to provide more detailed reporting from this system if that
would be useful.  please let me know what you'd like to see.

hth,

    --dkg



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1320354207.4535.yahoomail...@web39708.mail.mud.yahoo.com

Bug#630345: xserver-xorg-video-radeon: Xserver crashes with HD6700M card

[Alex Deucher]

On Mon, Aug 22, 2011 at 1:38 PM, Willian Gustavo Veiga
 wrote:
> Of course I can Alex. It's attached.
> Thank you very much.

The radeon has no connectors specified in the vbios so it's muxless.
Not much we can do with it until X gets re-architected to decouple
display and rendering.

Alex



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CADnq5_POt4LNh2Rjzn5k3ToCEHY-9iA2hgRBM6_=legzdjf...@mail.gmail.com

Bug#630345: xserver-xorg-video-radeon: Xserver crashes with HD6700M card

[Alex Deucher]

On Sun, Aug 21, 2011 at 1:13 PM, Willian Veiga  wrote:
> Alex Deucher, I have an AMD Radeon HD 6470M but I can't select which
> card I want to use in  the BIOS setup.
>
> How do I know if my GPU display is MUXes or MUX-less? I've tried to
> select the discrete card using vgaswitcheroo but i get a black screen
> and the computer crashes.
>

Most new systems are muxless, so it's probably muxless.  Can you post
the dmesg from your system?

Alex

> # lspci -v
> 01:00.0 VGA compatible controller: ATI Technologies Inc NI
> Seymour00:02.0 VGA compatible controller: Intel Corporation 2nd
> Generation Core Processor Family Integrated Graphics Controller (rev
> 09) (prog-if 00 [VGA controller])
>        Subsystem: Dell Device 04ca
>        Flags: bus master, fast devsel, latency 0, IRQ 54
>        Memory at f640 (64-bit, non-prefetchable) [size=4M]
>        Memory at d000 (64-bit, prefetchable) [size=256M]
>        I/O ports at f000 [size=64]
>        Expansion ROM at  [disabled]
>        Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
>        Capabilities: [d0] Power Management version 2
>        Capabilities: [a4] PCI Advanced Features
>        Kernel driver in use: i915
>
>  [AMD Radeon HD 6470M] (prog-if 00 [VGA controller])
>        Subsystem: Dell Device 04ca
>        Flags: bus master, fast devsel, latency 0, IRQ 56
>        Memory at e000 (64-bit, prefetchable) [size=256M]
>        Memory at f7b2 (64-bit, non-prefetchable) [size=128K]
>        I/O ports at e000 [size=256]
>        Expansion ROM at f7b0 [disabled] [size=128K]
>        Capabilities: [50] Power Management version 3
>        Capabilities: [58] Express Legacy Endpoint, MSI 00
>        Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
>        Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 
> 
>        Capabilities: [150] Advanced Error Reporting
>        Kernel driver in use: radeon
>
> # uname -a
> Linux willian 3.0.0-1-amd64 #1 SMP Wed Aug 17 04:08:52 UTC 2011 x86_64 
> GNU/Linux
>
> Thank you very much.
>
>
>
> ___
> xorg-driver-ati mailing list
> xorg-driver-...@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-driver-ati
>



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cadnq5_nd7e-hdcd7spl+tsm6ru_nfm4jx9ms9eqbd6w_6a-...@mail.gmail.com

Bug#630345: xserver-xorg-video-radeon: Xserver crashes with HD6700M card

[Alex Deucher]

On Mon, Jun 13, 2011 at 2:50 AM, Craig Small  wrote:
> Package: xserver-xorg-video-radeon
> Version: 1:6.14.2-1
> Severity: important
>
> I have one of these dual card laptops. It works fine with the simple Intel
> driver.
> I made a small xorg.conf file and rebooted. This file only specified the 
> radeon
> driver and the BusID.
> When I did that the server crashed every time.

Is there an option in your bios setup to select the discrete graphics?
Try selecting that. vgaswitcheroo only supports hybrid GPUs with
display MUXes. Some new laptops are MUX-less whihc means the display
hardware is only attached to one of the GPUs and the other one is
strictly used for rendering. Unfortunately, the X server needs a lot
of work to support that scenario so it will not be supported any time
soon in the open source drivers.

Alex



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/BANLkTimBEaWYSfz6OP=eiwalmg8sew-...@mail.gmail.com

Bug#621854: fixed in upstream xorg 1.9rc5/1.8.99.905

[Alex]

scratch that; still broken on 1.10.1 in testing for laptop, just took
a while to trigger.  following up in upstream bug
https://bugs.freedesktop.org/show_bug.cgi?id=26213



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/BANLkTik+=bGb7u_GVT=lxyhth6akgbp...@mail.gmail.com

Bug#621854: fixed in upstream xorg 1.9rc5/1.8.99.905

[Alex]

via patch Revert "dix: use the event mask of the grab for TryClientEvents."

http://cgit.freedesktop.org/xorg/xserver/patch/?id=1884db430a5680e37e94726dff46686e2218d525
http://lists.freedesktop.org/archives/xorg-announce/2010-July/001354.html

grabbutton would cause the input mask to be incorrectly applied.  this
is no longer an issue on my testing instance (xorg 1.10), but has now
cropped up on an old-stable -> stable upgrade (xorg 1.*mumble* -> 1.7)



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktimkwfqqjwfdju0rndfj2dnhhry...@mail.gmail.com

Bug#627554: xserver-xorg-video-radeon: HD 5750 3rd screen displays interesting psychedelic colour swirl pattern covering whole screen

[Alex Deucher]

On Tue, May 24, 2011 at 4:00 PM, Tim Wootton  wrote:
> On 22/05/11 21:49, Tim Wootton wrote:
>>
>> On 22/05/11 21:16, Alex Deucher wrote:
>>
>>>
>>> Are you using native DP or a DP to HDMI converter? If you are using a
>>> converter, is it an active or passive converter? If it's passive,
>>> you'll have the same limitation as before.
>>
>> It's a passive, got an active on order now, so I will see if that does
>> the trick. Thanks for the advice.
>
>
> Ok,so now using an active converter (Sapphire with Eyefinity logo), but
> still the same problem, perhaps it could be a bug after all.

Please attach your xorg log and dmesg output.  You might also want to
try the recent DP patches I posted for 2.6.40.  They are available in
the radeon-drm-testing branch of Dave's tree:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=refs/heads/drm-radeon-testing

Alex



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktimjjtotbv_hwtlxa-5dqpejbrm...@mail.gmail.com

Bug#627554: xserver-xorg-video-radeon: HD 5750 3rd screen displays interesting psychedelic colour swirl pattern covering whole screen

[Alex Deucher]

On Sun, May 22, 2011 at 3:37 PM, Tim Wootton  wrote:
> On 22/05/11 00:06, Alex Deucher wrote:
>
>> Not a bug.  Only 2 non-DP monitors are supported since there are only
>> two plls.  If you want 3 or more monitors the rest have to be DP.  The
>> fact that you can make it work with some fiddling is pure luck and is
>> completely unsupported.  You end up with one of the plls driving two
>> monitors which only works if both monitors have the same clock and you
>> get the ordering right.
>
> Switched HDMI for DP, so now running 2 x DVI and 1 x DP, I get exactly the
> same symptoms.

Are you using native DP or a DP to HDMI converter?  If you are using a
converter, is it an active or passive converter?  If it's passive,
you'll have the same limitation as before.

Alex

>
>>
>> Alex
>>
>
>



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktimj7qf7dh_vw9l8ec49nx7ri6p...@mail.gmail.com

Bug#627554: xserver-xorg-video-radeon: HD 5750 3rd screen displays interesting psychedelic colour swirl pattern covering whole screen

[Alex Deucher]

On Sat, May 21, 2011 at 6:11 PM, Tim Wootton  wrote:
> Package: xserver-xorg-video-radeon
> Version: 1:6.14.1-1+b1
> Severity: normal
> Tags: upstream
>
> When trying to get 3 screens working off an HD 5750, one of the screens is 
> coming up with cyan-ish background part way through boot, and when x launches 
> I get an interesting psychedelic colour swirl across that whole screen. It's 
> just possible to make out shapes of icons, windows etc. that should be 
> displayed on the screen.
>
> In troubleshooting I have discovered that if I install the closed source 
> driver & reboot, and then uninstall it and reboot again back into the open 
> driver then the 3 monitor setup works fine with the open driver. I think the 
> closed driver must be setting somthing up during boot that allows the open 
> driver to work with the 3rd screen so long as I havn't removed power 
> completely & only booted with a reset.
>
> I can tell early in the boot which screen is going to have the problem by the 
> cyan background.
>
> I have the monitors connected to the 2xDVI and 1xHDMI, the DP is unused.

Not a bug.  Only 2 non-DP monitors are supported since there are only
two plls.  If you want 3 or more monitors the rest have to be DP.  The
fact that you can make it work with some fiddling is pure luck and is
completely unsupported.  You end up with one of the plls driving two
monitors which only works if both monitors have the same clock and you
get the ordering right.

Alex



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/BANLkTinRieYKxnXdTiG3AKeOW7SBc7=a...@mail.gmail.com

Bug#626115: xserver-xorg-video-radeon: kernel crash after period of user inactivity

[Alex Deucher]

On Sun, May 8, 2011 at 7:13 PM, jamie  wrote:
> Package: xserver-xorg-video-radeon
> Version: 1:6.14.1-1
> Severity: normal
>
>
> While actively working on my laptop, I experience no problems. However,
> when I am away from the machine for more than about 5 or 10 minutes, the
> screen either goes blank (still backlit, but unresponsive to keyboard
> presses) or I get a kernel dump.
>
> Below is a hand-typed representation of what I hope is the relevent
> information from the last kernel dump (subject to typos).
>
> Note - I tried and failed to manually trigger the problem by triggering
> my xscreensaver and by executing: set dpms standby|suspend|off|on etc.
>
> This problem began after upgrading to xserver-xorg-video-radeon 1:6.14.1-1
>
> Thanks for all your work!
> jamie
>
>
> invalid opcode: 
>
> Pid: 5107, comm: kworker/0:0 Tainted: G      C 2.6.38-2-amd64 #1 TOSHIBA 
> Satellite T115D/Satellite T115D
>
> Call Trace:
>  kref_sub
>  ttm_bo_reserve [ttm]
>  radeon_unpin_work_func [radeon]
>  T.765 [radeon]
>  radeon_unpin_work_func [radeon]
>  process_one_work
>  worker_thread
>  worker_thread
>  worker_thread
>  kthread
>  kernel_thread_helper
>  kthread
>  kernel_thread_helper
>
> Code: ..
> RIP ttm_bo_ref_bug [ttm]
>  RSP
>

Looks like:
https://bugzilla.kernel.org/show_bug.cgi?id=32402

You can disable pageflipping as a workaround.
Option "EnablePageFlip" "False"



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktimksrogd7echhjslmh82b1wvnp...@mail.gmail.com

Bug#585777: Radeon gamma bug, display too bright when using VGA output

[Alex Deucher]

On Tue, Apr 26, 2011 at 4:41 PM, Andrew Rule  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 26/04/11 20:39, Alex Deucher wrote:
>> On Tue, Apr 26, 2011 at 3:56 AM, Andrew Rule  wrote:
>> Hi,
>>
>> I also have this problem.  It appeared for me when I upgraded from Xorg
>> 1.7.x to Xorg 1.9.5
>>
>> I am using
>> "ATI Radeon Mobility 9200 (M9+) 5C63 (AGP)" (ChipID = 0x5c63)
>> as X reports it, and
>> Linux amos 2.6.38.3 #2 SMP PREEMPT Sat Apr 16 22:03:19 BST 2011 i686
>> GNU/Linux
>> from kernel.org
>>
>> I tried setting Gamma in /etc/X11/xorg.conf, but it didn't pick it up.
>> If I run xgamma after logging in to X, it *does* change the gamma - but
>> still not enough.  So I can set Gamma to 0.3 in the file, but if I set
>> it using xgamma, it actually darkens the screen somewhat - but it is
>> still not right.  Output from xgamma:
>> -> Red  0.300, Green  0.300, Blue  0.300
>> <- Red  0.300, Green  0.300, Blue  0.300
>>
>>
>>> It's not the gamma, but the dac adj values.
>>
>>
>> I tried
>> radeontool regset DAC_MACRO_CNTL 0x0808
>> but it didn't work for me.  (Perhaps that is not a surprise, I am using
>> a tower PC, not a laptop.)
>>
>>> You are probably using the secondary dac.  The dac adjust values for
>>> the TV dac are in
>>> TV_DAC_CNTL.
>>
>>
>> Perhaps I should not mention this here, but X is also unstable for me
>> under KDE now, so I'm using sawfish for the time being.  Specifically,
>> it crashes when notifications popup in KDE.
>>
>> Another problem I have noticed is that when scrolling a window under
>> another window, the contents of the lower window smudges.  O, and popup
>> hints from firefox come up in the wrong place for the search box.
>>
>> And, as you can see from the attached files, I am not using KMS -
>> because I found that unstable since upgrading the kernel from 2.6.36.1
>> to 2.6.38.x (although previously the virtual terminals had not worked at
>> all, and now they do occasionally; but it was stable under X, now it is
>> not.)
>>
>>> What is unstable with KMS?  KMS is more likely to be fixed that UMS at
>>> this point.  If you want to fix UMS, you'll probably have to bisect
>>> xf86-video-ati to find out what change caused the breakage.  Your time
>>> would be better off spend bisecting to see what caused the instability
>>> with KMS.
>>
>>> Alex
>
> So your saying that this problem with the dac adj values is totally
> dependant on whether I'm using KMS or UMS?  And I should research
> further and report it as another bug?  Or try Xorg 1.9.5 using KMS and
> report any bugs that happen with them?

No.  I'm saying UMS is slowly being deprecated, so if you are seeing a
problem, KMS is more likely to get fixed.  It should work fine with
either KMS or UMS, but it has apparently regressed on your card at
least with UMS.

Alex

>
>>
>>
>> Please ask further questions if you need.  I'm gonna try downgradeing X,
>> cos I'd like to have a screen I can look at pictures on :-)
>>
>> Sincerely,
>>
>> Andrew Rule
>>
>> PS please tell me if I should open a new bug for some of this, I wasn't
>> sure.  But the gamma stuff seemed so similar I thought it might be the
>> same bug.
>>
>> PPS: package versions:
>> firmware-linux/testing uptodate 0.29
>> libc6/testing uptodate 2.11.2-11
>> libdrm-radeon1/testing upgradeable from 2.4.23-3 to 2.4.24-2
>> libdrm2/testing upgradeable from 2.4.23-3 to 2.4.24-2
>> libpciaccess0/testing uptodate 0.12.1-1
>> libpixman-1-0/testing uptodate 0.21.4-2
>> libudev0/testing upgradeable from 166-1 to 167-3
>> xserver-xorg-core/testing uptodate 2:1.9.5-1
>> xserver-xorg-video-radeon/testing uptodate 1:6.14.1-1
>>
>> I upgraded to:
>> firmware-linux/testing uptodate 0.29
>> libc6/testing uptodate 2.11.2-11
>> libdrm-radeon1/testing uptodate 2.4.24-2
>> libdrm2/testing uptodate 2.4.24-2
>> libpciaccess0/testing uptodate 0.12.1-1
>> libpixman-1-0/testing uptodate 0.21.4-2
>> libudev0/testing upgradeable from 166-1 to 167-3
>> xserver-xorg-core/testing uptodate 2:1.9.5-1
>> xserver-xorg-video-radeon/testing uptodate 1:6.14.1-1
>>
>> with no obvious change, certainly not to the gamma issue.
>>>
> ___
> xorg-driver-ati mailing list
> xorg-driver-...@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-driver-ati
>>>
>>>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk23LgwACgkQAXpg5UuOD0XQuwCg0mkLClLtR+UT9972+2853He9
> WysAn3t87LNY02xCgB+rc26gggccn0jy
> =1R4y
> -END PGP SIGNATURE-
>



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktin3pemvwxosj7ugkhxgwqr096b...@mail.gmail.com

Bug#585777: Radeon gamma bug, display too bright when using VGA output

[Alex Deucher]

On Tue, Apr 26, 2011 at 3:56 AM, Andrew Rule  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> I also have this problem.  It appeared for me when I upgraded from Xorg
> 1.7.x to Xorg 1.9.5
>
> I am using
> "ATI Radeon Mobility 9200 (M9+) 5C63 (AGP)" (ChipID = 0x5c63)
> as X reports it, and
> Linux amos 2.6.38.3 #2 SMP PREEMPT Sat Apr 16 22:03:19 BST 2011 i686
> GNU/Linux
> from kernel.org
>
> I tried setting Gamma in /etc/X11/xorg.conf, but it didn't pick it up.
> If I run xgamma after logging in to X, it *does* change the gamma - but
> still not enough.  So I can set Gamma to 0.3 in the file, but if I set
> it using xgamma, it actually darkens the screen somewhat - but it is
> still not right.  Output from xgamma:
> - -> Red  0.300, Green  0.300, Blue  0.300
> <- Red  0.300, Green  0.300, Blue  0.300
>

It's not the gamma, but the dac adj values.

>
> I tried
> radeontool regset DAC_MACRO_CNTL 0x0808
> but it didn't work for me.  (Perhaps that is not a surprise, I am using
> a tower PC, not a laptop.)

You are probably using the secondary dac.  The dac adjust values for
the TV dac are in
TV_DAC_CNTL.

>
> Perhaps I should not mention this here, but X is also unstable for me
> under KDE now, so I'm using sawfish for the time being.  Specifically,
> it crashes when notifications popup in KDE.
>
> Another problem I have noticed is that when scrolling a window under
> another window, the contents of the lower window smudges.  O, and popup
> hints from firefox come up in the wrong place for the search box.
>
> And, as you can see from the attached files, I am not using KMS -
> because I found that unstable since upgrading the kernel from 2.6.36.1
> to 2.6.38.x (although previously the virtual terminals had not worked at
> all, and now they do occasionally; but it was stable under X, now it is
> not.)

What is unstable with KMS?  KMS is more likely to be fixed that UMS at
this point.  If you want to fix UMS, you'll probably have to bisect
xf86-video-ati to find out what change caused the breakage.  Your time
would be better off spend bisecting to see what caused the instability
with KMS.

Alex

>
> Please ask further questions if you need.  I'm gonna try downgradeing X,
> cos I'd like to have a screen I can look at pictures on :-)
>
> Sincerely,
>
> Andrew Rule
>
> PS please tell me if I should open a new bug for some of this, I wasn't
> sure.  But the gamma stuff seemed so similar I thought it might be the
> same bug.
>
> PPS: package versions:
> firmware-linux/testing uptodate 0.29
> libc6/testing uptodate 2.11.2-11
> libdrm-radeon1/testing upgradeable from 2.4.23-3 to 2.4.24-2
> libdrm2/testing upgradeable from 2.4.23-3 to 2.4.24-2
> libpciaccess0/testing uptodate 0.12.1-1
> libpixman-1-0/testing uptodate 0.21.4-2
> libudev0/testing upgradeable from 166-1 to 167-3
> xserver-xorg-core/testing uptodate 2:1.9.5-1
> xserver-xorg-video-radeon/testing uptodate 1:6.14.1-1
>
> I upgraded to:
> firmware-linux/testing uptodate 0.29
> libc6/testing uptodate 2.11.2-11
> libdrm-radeon1/testing uptodate 2.4.24-2
> libdrm2/testing uptodate 2.4.24-2
> libpciaccess0/testing uptodate 0.12.1-1
> libpixman-1-0/testing uptodate 0.21.4-2
> libudev0/testing upgradeable from 166-1 to 167-3
> xserver-xorg-core/testing uptodate 2:1.9.5-1
> xserver-xorg-video-radeon/testing uptodate 1:6.14.1-1
>
> with no obvious change, certainly not to the gamma issue.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk22epYACgkQAXpg5UuOD0UtzwCgmLNnarwPog1J+v6TmvAwOA3Q
> PC8AnjW6/ejWvwW7ewVIIMq7MZWs+J72
> =NH8l
> -END PGP SIGNATURE-
>
> ___
> xorg-driver-ati mailing list
> xorg-driver-...@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-driver-ati
>
>



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/BANLkTi=h+1etp-fb3rd-ptozzzr1lj3...@mail.gmail.com

Bug#622346:

[Alex Deucher]

On Tue, Apr 19, 2011 at 6:22 AM, Boris Hollas  wrote:
> Package: xserver-xorg-video-radeon
> Version: 1:6.13.1-2+squeeze1
> Severity: normal
>
> The problem is also present if the laptop lid is closed. If this is the
> intended behavior, I propose a change request: If the laptop lid is closed and
> an external monitor is connected, the external monitor shall be run at its
> native resolution.
>
> If this issue is not specific to the radeon driver, it should be filed for
> xorg.

This is not specific to the radeon driver.  It's up to the desktop
environment (gnome/kde/etc.) to decide what to do when the lid is
closed.

Alex



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktin7bryszr++gqlwtyw0uar6p6m...@mail.gmail.com

Bug#621854: xserver-xorg-input-evdev: mouse unplug/plug and xinput --set* causes X events to not route properly to client windows

[Alex]

Package: xserver-xorg-input-evdev
Version: 1:2.3.2-6
Severity: important
Tags: upstream


after a mouse is unplugged/replugged, X no longer sends any events except to 
the current window; including the WM.   xev running in background does not 
receive motionNotify.  affects both keyboard and mouse. 

this can also be triggered by repeated invocations of mouse.sh;  also occurs on 
first login to a cold boot gdm instance.  after restarting gdm, mouse/keyboard 
operate properly after login.. usually.   no errors are noted in logs when this 
issue occurs.

..xsession:
-
#!/bin/sh
LANGUAGE=en_US.UTF-8
export LANGUAGE
xrdb ~/.Xdefaults
xset mouse 22/10 0 
~/mouse.sh
xcalib -screen 0 downloads/dell_3007wfp-hc.icc 
xcalib -screen 1 downloads/dell_2407wfp.icm

exec startxfce4

mouse.sh:
#!/bin/sh
DEV="Saitek Cyborg R.A.T.7 Mouse" 

# setup proper button handling / ignore
xinput --set-button-map "$DEV" 1 2 3 4 5 0 0 8 9 7 6 10 0 0 0 0 0 0 0 0 0

xinput --set-ptr-feedback "$DEV"  0 18 10 
xinput --set-prop "$DEV" "Device Accel Profile" 5 
xinput --set-prop "$DEV" "Device Accel Constant Deceleration" 5 
xinput --set-prop "$DEV" "Device Accel Adaptive Deceleration" 3 
xinput --set-prop "$DEV" "Device Accel Velocity Scaling" 1

#xinput list-props "$DEV"
#xinput get-feedbacks "$DEV"

-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Dec 24 15:49 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 1889472 Feb 18 15:42 /usr/bin/Xorg

Diversions concerning libGL are in place

diversion of /usr/lib/libGL.so to /usr/lib/nvidia/diversions/libGL.so by 
libgl1-nvidia-alternatives
diversion of /usr/lib/libGL.so.1 to /usr/lib/nvidia/diversions/libGL.so.1 by 
libgl1-nvidia-alternatives
diversion of /usr/lib32/libGL.so to /usr/lib32/nvidia/diversions/libGL.so by 
libgl1-nvidia-alternatives-ia32
diversion of /usr/lib32/libGL.so.1 to /usr/lib32/nvidia/diversions/libGL.so.1 
by libgl1-nvidia-alternatives-ia32
diversion of /usr/lib/xorg/modules/extensions/libglx.so to 
/usr/lib/nvidia/diversions/libglx.so by libglx-nvidia-alternatives
diversion of /usr/lib/libGL.so.1.2 to /usr/lib/nvidia/diversions/libGL.so.1.2 
by libgl1-nvidia-alternatives
diversion of /usr/lib/debug/usr/lib/xorg/modules/extensions/libglx.so to 
/usr/lib/nvidia/diversions/libglx.so.dbg by libglx-nvidia-alternatives
diversion of /usr/lib32/libGL.so.1.2 to 
/usr/lib32/nvidia/diversions/libGL.so.1.2 by libgl1-nvidia-alternatives-ia32

VGA-compatible devices on PCI bus:
--
01:00.0 VGA compatible controller [0300]: nVidia Corporation G84 [GeForce 8600 
GT] [10de:0402] (rev a1)
02:00.0 VGA compatible controller [0300]: nVidia Corporation G84 [GeForce 8600 
GT] [10de:0402] (rev a1)

Xorg X server configuration file status:

-rw-r--r-- 1 root root 1652 Jan 28 19:00 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---
Section "ServerFlags"
Option  "Xinerama" "1"
Option  "AllowEmptyInput" "True"
EndSection

# match on product to not init other mice
Section "InputClass"
Identifier "rat"
MatchProduct "Saitek Cyborg R.A.T.7 Mouse"
MatchIsPointer "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
EndSection

Section "ServerLayout"
Identifier "X.org Configured"
Screen  0  "Screen0" 0 250 
Screen  1  "Screen1" 2560 0
EndSection

Section "Files"
ModulePath   "/usr/lib/xorg/modules"
EndSection

Section "Monitor"
Identifier   "Monitor0"
VendorName   "Monitor Vendor"
ModelName"Monitor Model"
EndSection

Section "Monitor"
Identifier   "Monitor1"
VendorName   "Monitor Vendor"
ModelName"Monitor Model"
EndSection

Section "Device"
Identifier  "Card0"
Driver  "nvidia"
BusID   "PCI:1:0:0"
EndSection

Section "Device"
Identifier  "Card1"
Driver  "nvidia"
BusID   "PCI:2:0:0"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor"Monitor0"
DefaultDepth 24
Option "AddARGBGLXVisuals" "True"
Option "TwinView" "0"
SubSection "Display"
Depth 24
EndSubSection
EndSection

Section "Screen"
Identifier "Screen1"
Device "Card1"
Monitor"Monitor1"
DefaultDepth 24
Option "AddARGBGLXVisuals" "True"
Option "Rotate" "left"
Option "TwinView" "0"
SubSection "Display"
Viewport   0 0
Depth 24
EndSubSection
EndSection


/etc/X11/xorg.conf.d does not exist.

KMS configuration files:

/etc/modprobe.d/i915-kms.conf:
  options i915 modeset=1
/etc/modprobe.d/radeon-kms.conf:
  options radeon modeset=1

Kernel version (/proc/version):
-

Bug#620858: slow performance continues

[Alex Deucher]

On Mon, Apr 4, 2011 at 8:01 PM, Andres Cimmarusti  wrote:
> Package: xserver-xorg-video-radeon
> Version: 1:6.14.0-1
> Followup-For: Bug #620858
>
> I set vblank_mode=0 using a .drirc file in my home directory. This
> caused the overall slow down I was only experiencing after resuming from
> suspend to manifest itself all the time. Framerate in glxgears was no
> longer in sync with refresh rate, but it was quite poor (<200 fps). In
> the past I've gotten more like 800 fps (radeon) and 1200 (catalyst on
> lenny). Also, only by moving the cursor with the touchpad, causes the
> framerate in glxgears to drop further.

gears is not a benchmark.  It's highly CPU dependant.

>
> Desktop experience is quite slow. I pulled mesa 7.10.1 from experimental
> to see if this would help, but it didn't. The good news is that, after
> waking from suspend graphics performance is the same.
>
> Also I would like to correct a statement I made on my first email.
> Restarting X does not fix the problem (when vblank_mode is NOT set to
> zero).
>
> $ glxinfo | grep renderer
> OpenGL renderer string: Gallium 0.4 on ATI RS480
>

Since you are using gallium make sure it is built with llvm support as
that is very important for asics without vertex hardware.  You can
also disable tear-free buffer swaps by adding:
Option "SwapbuffersWait" "FALSE"
to the device section of your xorg.conf.  That coupled with
vblank_mode=0 should give you maximum framerates at the expense of
tearing.

Alex



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktimvq9f3+n+cosn2woqhzzlocnb...@mail.gmail.com

Bug#616301: xserver-xorg-video-radeon:screen goes black, system hangs after 2sec:[youtube(FF/Opera)-reset req.]

[Alex Deucher]

On Sun, Mar 6, 2011 at 1:36 PM, Ben Hutchings  wrote:
> On Sun, 2011-03-06 at 13:08 -0500, Alex Deucher wrote:
>> On Fri, Mar 4, 2011 at 8:50 PM, Ben Hutchings  wrote:
>> > On Fri, 2011-03-04 at 21:01 +0200, Faidon Liambotis wrote:
>> >> severity 616301 critical
>> >> thanks
>> >
>> > No, not unless it will affect a large proportion of users.
>> >
>> >> My system locks up whenever I click on a YouTube video link since
>> >> yesterday. I can probably live without YouTube :), but in any case this
>> >> shouldn't happen.
>> >>
>> >> This isn't a singled out case nor in exotic, possibly faulty, hardware.
>> >> It's on a standard 1½-year old Dell OptiPlex 780 desktop with a Radeon
>> >> HD card (one of the standard configurations) and this is on a stock
>> >> squeeze system.
>> >>
>> >> The findings so far seem to suggest this is a Mesa issue; I'd probably
>> >> file it under "Linux kernel bugs" (or even DoS bugs) but I'm not sure
>> >> where to properly file such bugs in the post-KMS stack world.
>> >
>> > If there is a kernel driver involved then it should be assigned to the
>> > kernel.  Even without KMS, a Mesa driver should be considered untrusted
>> > and should not be able to trigger a crash or hang.  With KMS, this
>> > applies to the X driver too.
>> >
>>
>> With or without KMS, the userspace acceleration drivers can certainly
>> cause GPU hangs if the 3D engine is programmed with some combination
>> of commands it doesn't like.
>
> You can't solve the halting problem but you can implement a watchdog,
> can't you?

We have lockup detection and asic reset support, but depending on the
lockup it may or may not be able to successfully reset the asic.
Also, as for the command buffer checking, we try to protect against
basic stupidity, but the chips are just too complex to check for every
possible scenario that might cause a hang.

Alex

>
> Ben.
>
> --
> Ben Hutchings
> Once a job is fouled up, anything done to improve it makes it worse.
>



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktinn3qd_vj+g6c75-ch6yyxv_b-s9bu-gtpdc...@mail.gmail.com

Bug#616301: xserver-xorg-video-radeon:screen goes black, system hangs after 2sec:[youtube(FF/Opera)-reset req.]

[Alex Deucher]

On Fri, Mar 4, 2011 at 8:50 PM, Ben Hutchings  wrote:
> On Fri, 2011-03-04 at 21:01 +0200, Faidon Liambotis wrote:
>> severity 616301 critical
>> thanks
>
> No, not unless it will affect a large proportion of users.
>
>> My system locks up whenever I click on a YouTube video link since
>> yesterday. I can probably live without YouTube :), but in any case this
>> shouldn't happen.
>>
>> This isn't a singled out case nor in exotic, possibly faulty, hardware.
>> It's on a standard 1½-year old Dell OptiPlex 780 desktop with a Radeon
>> HD card (one of the standard configurations) and this is on a stock
>> squeeze system.
>>
>> The findings so far seem to suggest this is a Mesa issue; I'd probably
>> file it under "Linux kernel bugs" (or even DoS bugs) but I'm not sure
>> where to properly file such bugs in the post-KMS stack world.
>
> If there is a kernel driver involved then it should be assigned to the
> kernel.  Even without KMS, a Mesa driver should be considered untrusted
> and should not be able to trigger a crash or hang.  With KMS, this
> applies to the X driver too.
>

With or without KMS, the userspace acceleration drivers can certainly
cause GPU hangs if the 3D engine is programmed with some combination
of commands it doesn't like.

Alex

> Ben.
>
> --
> Ben Hutchings
> Once a job is fouled up, anything done to improve it makes it worse.
>
> ___
> xorg-driver-ati mailing list
> xorg-driver-...@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-driver-ati
>
>



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/AANLkTi=wfwtq5sxo26xosg8ctoeok_ymw28n2hofd...@mail.gmail.com

Bug#615657: xserver-xorg-video-ati: xrandr --rotate kills X

[Alex Deucher]

On Sun, Feb 27, 2011 at 6:31 PM, Arian Sanusi  wrote:
> Package: xserver-xorg-video-ati
> Version: 1:6.14.0-1
> Severity: normal
>
>
> running:
>
> xrandr --output DVI-0 --rotate
>
> makes the X-Server die imediately, nothing written to log, no output when
> started from a VT. Graphics Processor is a Radeon HD3000 (AMD 760G).
> Monitors go to Stand because of no Input, the keyboard is unusable until
> sysrq-unraw, switching to a vt afterwards does not recover modesetting,
> still no Output. Starting X p.e. by starting a display manager over ssh
> recovers modesetting.
>
> This happens all combinations of Xorg 1.7.7 from testing, 1.9.4 from
> unstable, Kernel 2.6.32 from testing and 2.6.37 from unstable. However, this
> does not happen with Ubuntu Maverick (1.9.0 + 2.6.35) nor with gentoo (1.9.4
> + 2.6.36)
>

> [   21.248538] [drm] Loading RS780 Microcode
> [   21.274940] [drm:r600_startup] *ERROR* Failed to load firmware!

Install the linux firmware package.  rotation requires acceleration
and acceleration is not available without the firmware.

Alex



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/AANLkTikb-FqZ_ZwDcJzCArq_E5oNc+Bw=MACAwq=r...@mail.gmail.com

Bug#570466: it's been a month, is this still a problem?

[Alex Deucher]

On Tue, Feb 22, 2011 at 4:50 PM, Rémi Letot  wrote:
> Le 21/02/11 19:01, Cyril Brulebois a écrit :
>>
>> Hi Rémi,
>>
>> Rémi Letot  (26/10/2010):
>>>
>>> I have tried that option on 2.6.36 and 2.6.32 from sid, and I
>>> haven't had a single blackout for more than one week. It could still
>>> be a coincidence since the problem is completely random, but that
>>> would be a huge one...
>>> […]
>>> I'll try to build that and use it at my next reboot.
>>
>> what's the status with 2.6.37-1-$arch available in sid (possibly with
>> an up-to-date X stack in sid)?
>
> Hi,
>
> I'm tracking sid for most of the system, and experimental when available for
> the X stack.
>
> Since I reported the bug, the only combination that was potentially free
> from blackouts was with kernel 2.6.37-rc7. I say potentially because I'm not
> 100% sure, but I can't remember having had a blackout with that kernel. But
> I don't have that package anymore, so I can't verify that.
>
> I rebooted this morning to 2.6.37-1 and got several blackouts since then.
> The blackouts tend to disappear when uptime rises, so I don't reboot often
> :-)
>
> By the way, the radeon.new_pll=0 trick has not been possible with 2.6.37. As
> passing that option while booting used to solve the problem (or more
> probably hide it), has that option been renamed or is it gone ?

It was removed in 2.6.37 as it always uses the old pll algo.  However,
there were a lot of pll fixes in 2.6.38 that should show up in the
stable stream as well.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a6f9761743bf35b052180f4a8bdae4d2cc0465f6
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=51d4bf840a27fe02c883ddc6d9708af056773769
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f523f74eac1897b13c05c88ce6e5de0a7c34578b
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=619efb105924d8cafa0c1dd9389e9ab506f5425d
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a4b40d5d97f5c9ad0b7f4bf2818291ca184bb433
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=5b40ddf888398ce4cccbf3b9d0a18d90149ed7ff
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9f4283f49f0a96a64c5a45fe56f0f8c942885eef

Alex

>
> Thanks,
> --
> Rémi
>



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/AANLkTik5tA0tpHo67ZsCDuJy1uo31=oae5kfk71jy...@mail.gmail.com

Bug#536098: xserver-xorg-video-radeon: deterministic X lockup with dri

[Alex Deucher]

On Mon, Feb 21, 2011 at 12:46 PM, Cyril Brulebois  wrote:
> Hi!
>
> Alex Deucher  (08/07/2009):
>> On Wed, Jul 8, 2009 at 8:22 AM, Jonathan Rafael
>> Ghiglia wrote:
>> > I can't mess up with this computer right now. I tried the packages
>> > from unstable (7.4*) with no luck (same bug).  Again, changing AGP
>> > mode has no effect, while turning on PCI mode (apparently) solves
>> > the problem, but reduces performances.
>>
>> In that case it could be a flakey AGP bridge on your computer.  Most
>> AGP chipsets were in one way or another.
>
> I'm not sure where to go from here. Call it a hardware bug and close
> this report? Jonathan, what do you think?
>

I would suggest trying a kms enabled kernel.  If you have problems try
booting with radeon.agpmode=x where x = -1 or 1 or 2 or 4 or 8 on the
kernel command line in grub.  -1 disables agp and uses the internal
gart mechanism, which should work but with reduced performance.  1-8
will change the agp mode accordingly.

Alex

> KiBi.
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk1ipPYACgkQeGfVPHR5Nd3X7wCgqc8oktEk+4OJNiNZ70ye4ew8
> TTMAni3CVQ8XviuEf2sifnd9ab19s9Hx
> =cAP6
> -END PGP SIGNATURE-
>
>



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/AANLkTimq5xHGD406x-zz-S=kfa_pnajhhmxiciptp...@mail.gmail.com

Bug#437332: xserver-xorg-video-ati: Failed to detect secondary monitor, MergedFB/Clone mode disabled

[Alex Deucher]

On Mon, Feb 21, 2011 at 12:28 PM, Cyril Brulebois  wrote:
> Hi Alberto/Alex,
>
> Alex Deucher  (13/08/2007):
>> Hmmm... I didn't realize you were using an XPRESS chip.  multi-head
>> is handling is not really working properly at the moment due to a
>> lack of documentation on the XPRESS chips.
>
> could you please tell us what the status is with squeeze's or sid's X
> stack?

I'm not sure about debian specifically, but rs4xx chips are working
fine on upstream kernels and have been for a while (since kms was
introduced at least).

Alex

>
> KiBi.
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk1ioKUACgkQeGfVPHR5Nd13ogCfXirRc4jDgzrPMtAbl+mSjUl7
> 3jAAoJ5wOV6+MW7rDpUN0PG9zGOFcjPS
> =hQgc
> -END PGP SIGNATURE-
>
>



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/AANLkTinLO˜D9hscndk_45+cRLdiy+N1F0AcGOKkp=d...@mail.gmail.com

Bug#610818: Fixed, at least partly

[Alex Dănilă]

Hi Cyril,

7.10-3 is the first version of Mesa which didn't freeze the machine 
running Braid, and 7.10-2 did crash. I see 7.10-4 is available but I 
didn't try it yet.


Alex

On 02/19/2011 12:05 PM, Cyril Brulebois wrote:

Alex Dănilă  (19/02/2011):
   

After installing the newest Mesa, with Gallium3D enabled, I can play
Braid without crashes.
 

Hi Alex,

what was the status with 7.10-2? Was it crashy then? Since r600
gallium is failing on a number of cards, we're planning to get back to
r600 classic in the next upload.

KiBi.
   





--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d5f9e16.1020...@gmail.com

Bug#610818: Fixed, at least partly

[Alex Dănilă]

Hi,
After installing the newest Mesa, with Gallium3D enabled, I can play 
Braid without crashes.


At least for me, this is fixed.
Thank you,
Alex



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d5f0a78@gmail.com

Bug#613137: xserver-xorg-video-radeon: no video signal or kbd after manually launching X

[Alex Deucher]

On Mon, Feb 14, 2011 at 4:09 PM, GSR  wrote:
> Hi,
> jcris...@debian.org (2011-02-13 at 1104.39 +0100):
>> > back, the screen shows the bg (or maybe it was left from previous run)
>> > and then monitor goes into sleep immediately, ignoring kbd as original
>> > report.
>> You should probably trim your xorg.conf down to just monitor sections to
>> stop other stuff interfering...
>
> Spliting it into files inside xorg.conf.d/ and playing renaming game
> (easier to move "foo.conf" to "foo.conf-" to see what part is wrong) I
> found the problem of the black screen, but also issues with how things
> are done with outputs and config. Maybe worth new bugs?
>
> The problem line was 'FontPath "unix/:7100"' XFS is running, but seems
> that having that line in the conf makes it go nuts in unrelated ways.
>
> The left issues are:
>
> System sees an inexistant monitor on VGA connector. The cable is
> there, but the monitor is off and not responding (otherwise it would
> had seen valid vendor name, etc via DDC, right?). Even so, the system
> insists in giving it some random settings and keep the output fully
> enabled.

If the driver can't detect the monitor using ddc, it uses load
detection for analog monitors in case the monitor does not support
ddc.  In your case the connected monitor is creating a load on the
connector.  Also, note that monitors are supposed to keep ddc working
even when the monitor is powered off, so just turning a monitor off
will not general prevent the driver from seeing it.

>
> Once that monitor is configured via .conf file(s) with better
> Modelines than DDC ever provided, it keeps the output enabled even
> when the config has 'Option "Enable" "false"'. At least xrandr keeps
> the modelines right.

IIRC, you need:
Option "Disable" "True"

>
> Set DVI-0 to be primary wihth 'Option "Primary" "true"', but that one
> is ignored and VGA is still enabled. It is trully obsessed with having
> that output even if not needed and told to forget about it for now. ;]
> Workaround is to issue "xrandr --output VGA-0 --off" in ~/.xsession,
> so apps do not get confused with false overlapping monitors (maximize,
> etc).
>
> I guess this bug can be closed. Thanks for the help.
>
> GSR
>
>
>
>
> ___
> xorg-driver-ati mailing list
> xorg-driver-...@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-driver-ati
>



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/AANLkTi=v2idjy8w_skb+xmzrvj0w5fp8u1wm-tqrv...@mail.gmail.com

Bug#607510: Suggestion about slow radeon, debian bug 607510

[Alex Deucher]

On Fri, Feb 11, 2011 at 5:06 PM, Gábor Melis  wrote:
> GSR  writes:
>
>> Hi,
>> daen...@debian.org (2011-02-11 at 1035.03 +0100):
>>> On Fre, 2011-02-11 at 05:54 +0100, GSR wrote:
>>> > Could you check MigrationHeuristic setting? And try with "greedy"?
>>> This option doesn't have any effect with current upstream xserver and
>>> KMS, and even with older xservers where it accidentally had an effect,
>>> it's probably better to use the radeon driver option "EXAPixmaps" "off"
>>> if you want to prevent acceleration on all pixmaps other than the
>>> visible screen.
>>>
>>> Might be worth trying the current X server and driver in sid first
>>> though to see if they're doing better.
>>
>> With KMS & 6.13.1-2+squeeze1 (Sid has 6.13.2-2, update scheduled in
>> some days) removing MigrationHeuristic from xorg.conf gives acceptable
>> speed, same than with it. So at some point in the past, the issue that
>> required greedy was solved. The obvious test was >5 sec canvas
>> refreshes in GIMP when repositioning the content. Thanks for the tip.
>>
>> GSR
>>
>
> I have tested smart, greedy, exapixmaps on/off with EXA and 'options
> radeon modeset=0'. They don't seem to have any noticable effect with the
> exception of smart that made xorg segfault. Apart from that, the old
> konsole font still makes konsole crawl and there are noise-like
> artifacts on the icons in the taskbar and on window borders.
>
> Another data point is what my other, almost identical t60, does. With
> kms it starts to flicker randomly as if vert sync were off. Sometimes it
> rights itself for no apparent reason. It's unusable. Without kms there
> is no flicker after a day of testing. The konsole font issue is still
> there though.
>
> Note that the two machines have almost identical hardware: the first has
> a slightly faster cpu and 3945ABG wireless, the second has a slower cpu
> and AR5212 wireless. Furthermore, both have the same packages installed
> (by now they both run squeeze) and the same xorg.conf. The module list
> has very few differences and those are due to the different wireless
> cards. BIOS settings are identical, too. BIOS versions are not quite the
> same (2.20 and 2.26), but both are pretty recent (the second behaved the
> same with 2.17 that's older than 2.20). Xorg logs are pretty much the
> same.
>
> For the flickering, Option "DisplayPriority" "HIGH" didn't help either.

There were some pll regressions in 2.6.37.  Try 2.6.38-rc4 or newer.
For reference:
https://bugzilla.kernel.org/show_bug.cgi?id=26552

>
> Gabor
>
>
>
> ___
> xorg-driver-ati mailing list
> xorg-driver-...@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-driver-ati
>



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktikw_vlqby30kz6st3nd+d+xq_dzdfuofrv+z...@mail.gmail.com

Bug#607227: xserver-xorg-video-radeon: with kms, screen flickers, without kms xorg eats 100% CPU

[Alex Deucher]

On Fri, Dec 17, 2010 at 5:21 PM, Marcos Marado
 wrote:
> Hello again,
>
> 2010/12/17 Alex Deucher :
>> 2010/12/16 Marcos Marado :
>>> 2010/12/16 Michel Dänzer :
>>>> On Mit, 2010-12-15 at 21:29 +, Marcos Marado wrote:
>>>>> After installing on this machine squeeze from the debian-installer
>>>>> beta 2, I noticed that the
>>>>> screen sometimes flickers (opening a konsole an maximizing it will
>>>>> result in a more frequent flickering).
>>>>>
>>>>> Searching about it, I was led to believe that this could be a kms
>>>>> problem, so I deactivated it.
>>>>> Now the flicker is gone, but the computer is awefully slow, and a top
>>>>> shows Xorg eating 100% CPU.
>>>>
>>>> [...]
>>>>
>>>>> [   17.750916] [drm:radeon_do_init_cp] *ERROR* Failed to load firmware!
>>>>
>>>> [...]
>>>>
>>>>> Versions of packages xserver-xorg-video-radeon suggests:
>>>>> pn  firmware-linux                     (no description available)
>>>>
>>>> Does installing this package and rebooting help for any of your
>>>> problems?
>>>
>>> Thank you very much for your quick reply. I should have looked into the 
>>> logs...
>>> Installed firmware-linux, and now the 100% CPU issue is gone.
>>> Unfortunately, the flickering issue (more often on black screens) is still
>>> present with kms, so for now I'm sticking with having it disabled.
>>
>> Try booting with radeon.new_pll=0 and/or radeon.disp_priority=2 on the
>> kernel command line in grub.
>
> Yup, just did one test: turned modeset on and booted with
> radeon.new_pll=0 and the flickering is gone.
>

OK, this should be fixed in 2.6.37 then.

Alex

> Feel free to ask me anything else you think it might be useful.
>
> Best regards,
> --
> Marcos Marado
>



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktim6cb160wvspvqean6vy9fuaxxpysvpd_e5w...@mail.gmail.com

Bug#607227: xserver-xorg-video-radeon: with kms, screen flickers, without kms xorg eats 100% CPU

[Alex Deucher]

2010/12/16 Marcos Marado :
> Hi there,
>
> 2010/12/16 Michel Dänzer :
>> On Mit, 2010-12-15 at 21:29 +, Marcos Marado wrote:
>>> After installing on this machine squeeze from the debian-installer
>>> beta 2, I noticed that the
>>> screen sometimes flickers (opening a konsole an maximizing it will
>>> result in a more frequent flickering).
>>>
>>> Searching about it, I was led to believe that this could be a kms
>>> problem, so I deactivated it.
>>> Now the flicker is gone, but the computer is awefully slow, and a top
>>> shows Xorg eating 100% CPU.
>>
>> [...]
>>
>>> [   17.750916] [drm:radeon_do_init_cp] *ERROR* Failed to load firmware!
>>
>> [...]
>>
>>> Versions of packages xserver-xorg-video-radeon suggests:
>>> pn  firmware-linux                     (no description available)
>>
>> Does installing this package and rebooting help for any of your
>> problems?
>
> Thank you very much for your quick reply. I should have looked into the 
> logs...
> Installed firmware-linux, and now the 100% CPU issue is gone.
> Unfortunately, the flickering issue (more often on black screens) is still
> present with kms, so for now I'm sticking with having it disabled.
>
> If you want to have doing some debugging/testing/whatever, feel free to ask...
>

Try booting with radeon.new_pll=0 and/or radeon.disp_priority=2 on the
kernel command line in grub.

Alex


> Best regards,
> --
> Marcos Marado
>
>
>
> ___
> xorg-driver-ati mailing list
> xorg-driver-...@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-driver-ati
>



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktinf4fdgag3xoppp7kfoixksntwyejtnz4vox...@mail.gmail.com

Bug#585777: xserver-xorg-video-radeon: Radeon gamma bug still there

[Alex Deucher]

On Mon, Nov 22, 2010 at 9:14 PM, V. Gaibler  wrote:
> Package: xserver-xorg-video-radeon
> Version: 1:6.13.1-2+squeeze1
> Severity: normal
>
> The problem is still there in squeeze for graphics card Radeon Mobility X600
> (lspci shows "VGA compatible controller: ATI Technologies Inc M24 1P [Radeon
> Mobility X600]"). Only kernel 2.6.32-5 is available (linux-image-2.6.32-5-686)
> and is the default chosen kernel. This might be an ugly bug in sqeeze...
> The fix described above, however, still works.
>

The upstream drm fix is:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3a89b4a9ca7ce11e3b7d5119aea917b9fc29a302

Alex



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktikb22jt19-1ylzbdlf__xm+1jfwqotmrzgud...@mail.gmail.com

Bug#602620: fails to install

[Alex Goebel]

Package: libxaw7-dev
Version: 2:1.0.8-1

Apparently the dev package contains the library itself.

Unpacking libxaw7-dev (from .../libxaw7-dev_2%3a1.0.8-1_amd64.deb) ...
dpkg: error processing 
/var/cache/apt/archives/libxaw7-dev_2%3a1.0.8-1_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/libXaw.so', which is also in package 
libxaw7 2:1.0.8-1




--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4cd57cb5.8060...@gmail.com

Bug#570466: it's been a month, is this still a problem?

[Alex Deucher]

On Wed, Oct 13, 2010 at 3:28 PM, Rémi Letot  wrote:
> Le 13/10/10 20:14, Andres Cimmarusti a écrit :
>>
>> Have you tried kernel 2.6.35 in experimental?
>
> yes, and now I'm on 2.6.36rc6 from experimental. The blackouts tend to be
> less frequent, but still there.
>
>> Also, try dri2 packages were recently upgraded in squeeze. However,
>> you may also try the ones in experimental.
>
> I'm using all from sid or experimental:
>
> - mesa 7.8.2-2
> - radeon 1:6.13.1-2
> - drm 2.4.22-1
>
>> Hope the issue is solved
>
> I have tried every new possibly involved package when they are published in
> sid or experimental. But the issue is not solved.
>

Does booting with radeon.new_pll=0 help?  Alternatively, you can try
Dave's drm-radeon-testing tree as it has some pll patches:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=refs/heads/drm-radeon-testing

Alex

> HTH,
> --
> Rémi
>
>
>
> ___
> xorg-driver-ati mailing list
> xorg-driver-...@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-driver-ati
>



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktik3pjtk4xpdbzvdfbnb8ln2flrn+ewsd=mee...@mail.gmail.com

Bug#595767: Won't load hardware acceleration after system start

[Alex Deucher]

On Wed, Oct 6, 2010 at 6:17 AM, Ivan Vilata i Balaguer  wrote:
> Cyril Brulebois (2010-10-05 19:12:12 +0200) wrote:
>
>> Please install 2.6.32 kernel from sid, boot it with KMS enabled, and
>> send both kernel & X logs so that we can determine why DRI doesn't
>> work out of the box in that case.
>
> Done.  Here you have both log files.

You have radeonfb loaded which is claiming the device preventing the
kms drm from loading.

Alex

>
> --
> Ivan Vilata i Balaguer -- http://ivan.lovesgazpacho.net/
>
> ___
> xorg-driver-ati mailing list
> xorg-driver-...@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-driver-ati
>
>



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlkti=-mntbn0w4evsdqn4j1ak+sp2pzav4rbrrp...@mail.gmail.com

Bug#597358: xserver-xorg-video-radeon: Screen brightness flickers when KMS is enabled

[Alex Deucher]

On Mon, Sep 27, 2010 at 11:19 AM, Cyril Brulebois  wrote:
> Aaron Small  (26/09/2010):
>> I'm having trouble applying these patches - the first two were able to
>> apply, but the third patch seems to be applied to source quite
>> different than what I have. I can't figure out how to apply it even
>> manually. I'm using the debian linux-source-2.6.32 package, version
>> 2.6.32-23. Is there a better kernel source I could try to apply to?
>
> Probably linux-2.6's master?

Yes.

Alex

>
> Mraw,
> KiBi.
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAkygthgACgkQeGfVPHR5Nd0hegCeLowKgIyzRX2ilkbEf997DKIA
> VWQAn3yr0MxPh3pBrsdNJQgyVP5ldaPh
> =mH2w
> -END PGP SIGNATURE-
>
>



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlkti=vipu2qrxr5b3qphpzkp181nxopzcg3y-2p...@mail.gmail.com

Bug#595767: xserver-xorg-video-radeon: Won't load hardware acceleration after system start

[Alex Deucher]

On Tue, Sep 7, 2010 at 6:48 AM,   wrote:
> Hi,
>
>> Make sure the radeon drm is loaded before you start X.
>>
>> Alex
>>
>
> Radeon drm is loaded by xorg.conf which is loaded by X, isn't it? How can I 
> get that to load before X starts?
>

For KMS, the drm needs to be loaded before X starts since it fully
controls the hw with KMS rather then being partially shared with the
userspace driver.  You need to adjust your udev or modprobe or initrd
settings to make sure the module is loaded before X starts.

The problem is, when the ddx attempts to load the drm, it often does
not finish initializing the hardware before X starts so the ddx
assumes KMS is not enabled and then both the ddx and the drm attempt
to control the hardware.

Alex

> Cheers
>
> Frank
> --
> GMX DSL SOMMER-SPECIAL: Surf & Phone Flat 16.000 für nur 19,99 Euro/mtl.!*
> http://portal.gmx.net/de/go/dsl
>



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlkti=m-qg0_5pm3-d6sqcsmkfecwyymuzbnyg7k...@mail.gmail.com

Bug#595767: xserver-xorg-video-radeon: Won't load hardware acceleration after system start

[Alex Deucher]

On Mon, Sep 6, 2010 at 10:42 AM, Julien Cristau  wrote:
> On Mon, Sep  6, 2010 at 16:15:44 +0200, Frank Kottler wrote:
>
>> after boot, the started GUI has no enabled hardware acceleration:
>>
>> ~$ glxinfo | grep -i render
>> direct rendering: Yes
>> OpenGL renderer string: Software Rasterizer
>>
>> Which means, e.g., i can't start compiz.
>>
>> But after killing and restarting X, everything works fine:
>>
>> ~$ glxinfo | grep -i render
>> direct rendering: Yes
>> OpenGL renderer string: Mesa DRI R200 (RV250 4C66) 20090101 x86/MMX/SSE2 TCL
>> DRI2
>>
>> IMHO, that means some part of the graphical driver is loaded too late for the
>> system to detect hardware acceleration actually IS available.
>>
>> Any solutuions?


Make sure the radeon drm is loaded before you start X.

Alex

>>
> Send dmesg and X log from when that happens.
>
> Cheers,
> Julien
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAEBCAAGBQJMhP3pAAoJEDEBgAUJBeQMGPUP/Rkgo+FTa8iTReWbUOSL1AKl
> lJK4P78KrjX8ff9+vtx4exff7skP5DiLjsOOFJefgb1Py1GYxbMix17G2G8VUla6
> 0CujQNsTv+m/hKRI9/409km8lI8dgWQIn/jV9gilnt5AY+xkU6z05hP1DOHlbUfi
> 3CSfaATYoD7vqW0P2Oa0inBtPQnfFrxwPT4sPZaC1ex4IfLcwoCU1p1Bk+UPw7FY
> 29dxzVvdg4k9IFsiRVSJS3mRIlAyMk4pOvVKHHBi/cjMeSdTWcpw2+6ke8teIsWt
> VSzV6NwzqQSW71JaQ8SypqQ4B7eKuoSdankpCKL5nRYZPT61gPTI5LzKC6WZA2V7
> eHVbVj+yRhDRmU6zosdZtpeFZc1N8DVu5Ik8vSdvkncaF7rTubrvjTiZfQDxnuTt
> rVm34E3fFtCIthMhCB+ZZwBjTQ+deXY9mldO/No6XholETdunG2hAC9v3qf/RK01
> Wrgue4UEv/xrZxXTnrGa+p0gtr6q8YgC8Hsej7Hlzi+auZNZ1dtuhrfg/IDe/JZw
> U+6ipdVDFtwx9l3DWaaK6JkwKqvjMVU2+gZ24dIcADbvFzWx271HeZfvM4rjt5NU
> noLu+uO4Na7QmQHW0wQtYRSWbkh96I/5E51OVZwjpxcBD56EiGFVy+LYP1+ebQIQ
> dt3mjIgzqSl/uvs70Lsb
> =jkQu
> -END PGP SIGNATURE-
>
> ___
> xorg-driver-ati mailing list
> xorg-driver-...@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-driver-ati
>
>



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktimyag5co9mz6pgn1xgi_f6yxmxkldzydnbny...@mail.gmail.com

Bug#595033: xserver-xorg-video-ati: Only one display works at a time with RV620 [FirePro 2260] with two DisplayPort output

[Alex Deucher]

On Tue, Aug 31, 2010 at 10:59 AM, Thomas PIERSON  wrote:
> Package: xserver-xorg-video-ati
> Version: 1:6.13.1-2
> Severity: normal
>
> Hi,
>
> I have an issue with 2 monitors connected on two DislpayPort output. The card
> is an ATI "FirePro 2260". And only one display can works at a time.
> $ lspci | grep VGA
> 02:00.0 VGA compatible controller: ATI Technologies Inc RV620 [FirePro 2260]
>
> My issue looks like this archived bug : http://bugs.debian.org/cgi-
> bin/bugreport.cgi?bug=569970
>> The symptoms are that only one display can be driven at a time.
> It also talk about two DisplayPort connections.
>
> So, the 2 monitor are connected and activated in clone mode :
>
> $ xrandr
> Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 8192 x 8192
> DisplayPort-0 connected 1280x1024+0+0 (normal left inverted right x axis y
> axis) 408mm x 255mm
>   1680x1050      60.0 +
>   1600x1200      60.0
>   1400x1050      60.0
>   1280x1024      75.0     60.0*
>   1440x900       59.9
>   1280x960       60.0
>   1152x864       75.0
>   1024x768       75.1     70.1     60.0
>   832x624        74.6
>   800x600        72.2     75.0     60.3     56.2
>   640x480        72.8     75.0     66.7     60.0
>   720x400        70.1
>   640x400        70.0
> DisplayPort-1 connected 1280x1024+0+0 (normal left inverted right x axis y
> axis) 380mm x 305mm
>   1280x1024      60.0*+   75.0
>   1152x864       75.0
>   1024x768       75.1     60.0
>   800x600        75.0     60.3
>   640x480        75.0     60.0
>   720x400        70.1
>
> But only one display works.
> After that if I run for example :
> xrandr --output DisplayPort-0 --left-of DisplayPort-1
> I have a black screen on the 2 monitors and I can't access to a terminal.
>
> I noticed something else : When I turn off and on again the second monitor
> (manually) an kernel error occurred :
> [18515.140220] [drm:radeon_process_aux_ch] *ERROR* Buffer to small for return
> answer 1 6
> During some seconds, the main monitor get stranges color and lights intensity!
>
> It seem to be the same problem that the bug #569970 but I am not sure.
> Someone have an idea to solve this?
> Tell me if you need other logs or informations.

You need this patch most likely:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=5137ee940c3e593ae5578a7a12a604eb8f239ac0
which means 2.6.36rc3 or newer.

Alex

>
> Regards,
> Thomas PIERSON
>
>
> ___
> xorg-driver-ati mailing list
> xorg-driver-...@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-driver-ati
>
>



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktimxxyczq9g7ddcmgqk7wcfmd9b0avvq7x3nk...@mail.gmail.com

Bug#594569: xserver-xorg-video-radeon: Unable to wake up from suspend/hiberate with RC410 [Radeon Xpress 200M]

[Alex Deucher]

On Fri, Aug 27, 2010 at 5:48 AM, Julien Cristau  wrote:
> On Fri, Aug 27, 2010 at 11:14:15 +0200, janca wrote:
>
>> Kernel version (/proc/version):
>> Linux version 2.6.32-5-686 (Debian 2.6.32-20) (b...@decadent.org.uk) (gcc 
>> version 4.3.5 (Debian 4.3.5-2) ) #1 SMP Thu Aug 12 13:38:27 UTC 2010
>>
> Does 2.6.35 work better?

if that doesn't work, try this patch.  Also, please attach the output
of lspci -vnn so I can get the subsystem pci ids.

index bd74e42..0ea943a 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -3041,6 +3041,12 @@ void radeon_combios_asic_init(struct drm_device *dev)
rdev->pdev->subsystem_device == 0x30a4)
return;

+   /* quirk for rs4xx laptop to make it resume
+* - it hangs on resume inside the dynclk 1 table.
+*/
+   if (rdev->family == CHIP_RS400)
+   return;
+
/* DYN CLK 1 */
table = combios_get_table_offset(dev, COMBIOS_DYN_CLK_1_TABLE);
if (table)



>
> Cheers,
> Julien
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAEBCAAGBQJMd4oCAAoJEDEBgAUJBeQMN4gP/A1yoHtIWamOiSMvH48CFARW
> oWfYKkz1Fpxy8AsEDVJS+NhTMaqxdS1pwYVTUfkNq1MB29fyiS8dTE95e0B2arUg
> 2Nr/i+RrOeZsbMWlzu3/j5XsXnAuEki68+OractIlivwND32NXMaryzAoMuWvJVB
> 0aZfmdjgMsHWXngP7/fvqPxgpOdxLp3YFe9NwrEGR9Fwtqt+hO6rTsg4pBLOwGy7
> 476ef2UAV8zx8E0GHWiKs54q84XdbvbRaY/a9xRcbV11/5bMP/WEnpygYiDqYPNy
> kcsPzwEn5dhmLF+DPHTYyYYBsSaBlPvHfTcEm+zzh1t3GFWOzVdILo2rkSaGzmt4
> /OxtoGMgskLKylLQVHxozOOuLRO3F6NnjSxs2qRkH3lnQgvpB/HQqTC3aRphhAU9
> eqOvKaoq7q78K1naSCZkVYWUJ+YHv/AORYpe/ilIwrLYCeJKfAr3hmrMqgNotNvH
> xup9S02qeznERQ5Bc3DwJpXG0IgSNrDjvIkjXZ84/ogNYRkTi4PQTbdQsjQ9pzuc
> C8eWaFVCAMBKe8I+Iil2HlEKr5hI2yPS0C+fzYu8ymBaUSuPisfKCR1wRRbF1+JM
> 2KcGzwALj30yWV/K0YBx7zdcMBLmiCAr3cIHN05ay8UeKIH1BFarvEYkwJEEiJU4
> l7cA+FbkoQopsbI2PsrL
> =LnKm
> -END PGP SIGNATURE-
>
> ___
> xorg-driver-ati mailing list
> xorg-driver-...@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-driver-ati
>
>



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktinsua_frsa8g9jir1dhuq=0dyoyoz0yty6xc...@mail.gmail.com

Bug#589346: xorg: Graphical acceleration only available to one X user

[Alex Dănilă]

Enabling KMS solved this. Please close.

Thank you for the solution,
Alex
On 08/01/2010 01:57 AM, Alex Dănilă wrote:

Hi,

thanks, I understand.
KMS is disabled on my computer because it breaks any rendering (Xorg 
and virtual terminal). I guess I should first solve that...


By Javascript I meant fancy animations on the web, I can tell you, 
that does work terribly without acceleration.


Alex

On 07/17/2010 01:42 AM, Brice Goglin wrote:

Le 16/07/2010 22:19, Alex Dănilă a écrit :

Package: xorg
Version: 1:7.5+6
Severity: normal

Some types of acceleration are not availabe to the second simultaneous
log-in on the machine. I only say some types,
because some things work fast, others slow:
Fast:
-window resizing (both kwin and metacity)
-Opera animations, drawing, javascript
-KDE Plasma animations
-video seems to work decently.

Slow:
-window moving (both kwin and metacity)
-scrolling (Dolphin, Opera)
-3d is much slower (TORCS: 5-15 fps on the first login, 0-1 fps on the
second)

Additionaly, Kwin compositing cannot be enabled on the second login,
only on the first. Please ask for any
information I failed to provide.

Reproduce:
-login to an desktop session
-start a new desktop session without closing the first one, and notice
the problems with this session.

Video driver:
xserver-xorg-video-radeon 1:6.13.1-1

This situation has been the same for a long time in Debian Unstable
(more than a year), regardless of drm, mesa, kde version, xorg version.

In the past, DRI was only available to a single session. But with KMS
and modern stuff, it should work fine. Make sure you run KMS (which
means kernel at 2.6.32-5 from testing) and (if it doesn't) please send
your X log.

Brice

PS: javascript certainly has nothing to do with X :)








--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c59b6d0.7010...@gmail.com

Bug#589348: xorg: Jerky cursor and keyboard lagging, slow rendering speed for 5-15 seconds after changing screen

[Alex Dănilă]

Enabling kernel modesetting solved this problem. As before, I didn't 
manage to profile and see what's happening.


From my POV this bug can be closed. However, if you give me 
instructions on how to profile, I'm willing to take some time and 
provide the results.


Thanks,
Alex

On 08/01/2010 02:39 AM, Alex Dănilă wrote:

Hi,

The bug was reproducible for me on my previous computer, a desktop.

Anyway, the processor it used entirely by Xorg, and on a sysprof I can 
see it is spending time with kernel functions. The syslog doesn't say 
anything else to me, but I attached it. Is that useful, or I should 
somehow find out exactly what functions Xorg is calling.


Thank you,
Alex

On 07/17/2010 02:27 AM, Julien Cristau wrote:

This bug report as it stands is useless, because it obviously isn't
reproducible for anyone else...

Try to figure out where the hang is happening.

Cheers,
Julien







--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c59b688.1070...@gmail.com

Bug#590493: xorg-radeon: server does not start, no video output, when no screen connected

[Alex Deucher]

On Mon, Aug 2, 2010 at 2:07 AM, Yann Dirson  wrote:
> On Sun, Aug 01, 2010 at 10:12:27PM -0400, Alex Deucher wrote:
>> On Mon, Jul 26, 2010 at 3:21 PM, Yann Dirson  wrote:
>> > Package: xserver-xorg-video-radeon
>> > Version: 1:6.13.1-2
>> > Severity: normal
>> >
>> > Turning on my box, I see the monitor claiming no video output.
>> > Checking video cable, I see it was not fully plugged and fixed that,
>> > but got no change.  Logging remotely I see (log below) that the server
>> > indeed failed to start because of this.  Restarting gdm fixed the
>> > problem.
>> >
>> > It is a very unfriendly behaviour indeed.  Google shows people with
>> > other video chips got a similar issue, so indeed the problem may not
>> > be specific to the radeon driver, please reassign as see fit.
>> >
>>
>> Unfortunately, if there is no monitor plugged in, the driver has no
>> way of know what's connected, so it has no idea what connectors to
>> light up.  That said, in xserver 1.9, the xserver will start with a
>> default 1024x768 framebuffer and no connected outputs, and if you are
>> using kms and a hotplug enabled driver, you will get an event when a
>> monitor finally gets plugged in.
>
> That's more like what I'd have expected.  Can be considered fixed-upstream ?
>

I suppose so, although only kms drivers will work properly in that scenario.

Alex



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktim1tjylctg=4lhlorhwab+eksvk48o8htz7x...@mail.gmail.com

Bug#590493: xorg-radeon: server does not start, no video output, when no screen connected

[Alex Deucher]

On Mon, Jul 26, 2010 at 3:21 PM, Yann Dirson  wrote:
> Package: xserver-xorg-video-radeon
> Version: 1:6.13.1-2
> Severity: normal
>
> Turning on my box, I see the monitor claiming no video output.
> Checking video cable, I see it was not fully plugged and fixed that,
> but got no change.  Logging remotely I see (log below) that the server
> indeed failed to start because of this.  Restarting gdm fixed the
> problem.
>
> It is a very unfriendly behaviour indeed.  Google shows people with
> other video chips got a similar issue, so indeed the problem may not
> be specific to the radeon driver, please reassign as see fit.
>

Unfortunately, if there is no monitor plugged in, the driver has no
way of know what's connected, so it has no idea what connectors to
light up.  That said, in xserver 1.9, the xserver will start with a
default 1024x768 framebuffer and no connected outputs, and if you are
using kms and a hotplug enabled driver, you will get an event when a
monitor finally gets plugged in.

Alex


> -- Package-specific info:
> /var/lib/x11/X.roster does not exist.
>
> /var/lib/x11/X.md5sum does not exist.
>
> X server symlink status:
> lrwxrwxrwx 1 root root 13 May 23 19:22 /etc/X11/X -> /usr/bin/Xorg
> -rwxr-xr-x 1 root root 1878240 Jun  3 17:09 /usr/bin/Xorg
>
> /var/lib/x11/xorg.conf.roster does not exist.
>
> VGA-compatible devices on PCI bus:
> 01:05.0 VGA compatible controller: ATI Technologies Inc RS880 [Radeon HD 4250]
>
> /etc/X11/xorg.conf does not exist.
>
> Kernel version (/proc/version):
> Linux version 2.6.34.1-3-ge5b0813-dirty (r...@home) (gcc version 4.4.4 
> (Debian 4.4.4-6) ) #2 SMP Tue Jul 20 00:06:04 CEST 2010
>
> Xorg X server log files on system:
> -rw-r--r-- 1 root root 30669 Jul 22 23:41 /var/log/Xorg.20.log
> -rw-r--r-- 1 root root 31448 Jul 26 20:53 /var/log/Xorg.0.log
>
> /var/log/Xorg.0.log.old:
>
> X.Org X Server 1.7.7
> Release Date: 2010-05-04
> X Protocol Version 11, Revision 0
> Build Operating System: Linux 2.6.32-5-amd64 x86_64 Debian
> Current Operating System: Linux home 2.6.34.1-3-ge5b0813-dirty #2 SMP Tue 
> Jul 20 00:06:04 CEST 2010 x86_64
> Kernel command line: BOOT_IMAGE=/vmlinuz-2.6.34.1-3-ge5b0813-dirty 
> root=/dev/mapper/home-root ro quiet
> Build Date: 03 June 2010  03:01:44PM
> xorg-server 2:1.7.7-2 (Julien Cristau )
> Current version of pixman: 0.16.4
>        Before reporting problems, check http://wiki.x.org
>        to make sure that you have the latest version.
> Markers: (--) probed, (**) from config file, (==) default setting,
>        (++) from command line, (!!) notice, (II) informational,
>        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> (==) Log file: "/var/log/Xorg.0.log", Time: Mon Jul 26 20:47:35 2010
> (==) Using system config directory "/usr/share/X11/xorg.conf.d"
> (==) No Layout section.  Using the first Screen section.
> (==) No screen section available. Using defaults.
> (**) |-->Screen "Default Screen Section" (0)
> (**) |   |-->Monitor ""
> (==) No monitor specified for screen "Default Screen Section".
>        Using a default monitor configuration.
> (==) Automatically adding devices
> (==) Automatically enabling devices
> (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
>        Entry deleted from font path.
> (==) FontPath set to:
>        /usr/share/fonts/X11/misc,
>        /usr/share/fonts/X11/100dpi/:unscaled,
>        /usr/share/fonts/X11/75dpi/:unscaled,
>        /usr/share/fonts/X11/Type1,
>        /usr/share/fonts/X11/100dpi,
>        /usr/share/fonts/X11/75dpi,
>        /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType,
>        built-ins
> (==) ModulePath set to "/usr/lib/xorg/modules"
> (II) The server relies on udev to provide the list of input devices.
>        If no devices become available, reconfigure udev or disable 
> AutoAddDevices.
> (II) Loader magic: 0x7c5e80
> (II) Module ABI versions:
>        X.Org ANSI C Emulation: 0.4
>        X.Org Video Driver: 6.0
>        X.Org XInput driver : 7.0
>        X.Org Server Extension : 2.0
> (++) using VT number 7
>
> (--) PCI:*(0:1:5:0) 1002:9715:1043:843e ATI Technologies Inc RS880 [Radeon HD 
> 4250] rev 0, Mem @ 0xd000/268435456, 0xfe8f/65536, 
> 0xfe70/1048576, I/O @ 0xb000/256
> (II) Open ACPI successful (/var/run/acpid.socket)
> (II) LoadModule: "extmod"
> (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so
> (II) Module extmod: vendor="X.Org Foundation"
>        compiled for 1.7.7, module version = 1.0.0
>        Module class: X.Org Server Extension
>        ABI class: X.Org Server Extension, vers

Bug#589346: xorg: Graphical acceleration only available to one X user

[Alex Dănilă]

Hi,

thanks, I understand.
KMS is disabled on my computer because it breaks any rendering (Xorg and 
virtual terminal). I guess I should first solve that...


By Javascript I meant fancy animations on the web, I can tell you, that 
does work terribly without acceleration.


Alex

On 07/17/2010 01:42 AM, Brice Goglin wrote:

Le 16/07/2010 22:19, Alex Dănilă a écrit :
   

Package: xorg
Version: 1:7.5+6
Severity: normal

Some types of acceleration are not availabe to the second simultaneous
log-in on the machine. I only say some types,
because some things work fast, others slow:
Fast:
-window resizing (both kwin and metacity)
-Opera animations, drawing, javascript
-KDE Plasma animations
-video seems to work decently.

Slow:
-window moving (both kwin and metacity)
-scrolling (Dolphin, Opera)
-3d is much slower (TORCS: 5-15 fps on the first login, 0-1 fps on the
second)

Additionaly, Kwin compositing cannot be enabled on the second login,
only on the first. Please ask for any
information I failed to provide.

Reproduce:
-login to an desktop session
-start a new desktop session without closing the first one, and notice
the problems with this session.

Video driver:
xserver-xorg-video-radeon 1:6.13.1-1

This situation has been the same for a long time in Debian Unstable
(more than a year), regardless of drm, mesa, kde version, xorg version.
 

In the past, DRI was only available to a single session. But with KMS
and modern stuff, it should work fine. Make sure you run KMS (which
means kernel at 2.6.32-5 from testing) and (if it doesn't) please send
your X log.

Brice

PS: javascript certainly has nothing to do with X :)

   





--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c54aa40.8040...@gmail.com

Bug#589348: xorg: Jerky cursor and keyboard lagging, slow rendering speed for 5-15 seconds after changing screen

[Alex Dănilă]

Package: xorg
Version: 1:7.5+6
Severity: normal

After activating a screen the following symptoms happen (usually) less 
than 10 seconds:

-the cursor is jerky
-moving a window or clicking does not seems to happen immediately
-shortcuts (ex. Alt+Tab) do not work, and typing is lagging.

This is not caused by intense disk activity, which usually freezes Xorg. 
It happens even though

there's absolutely no disk activity.

Reproduce:
-login to desktop session
-Ctrl+Alt+F1 to change to a terminal (or suspend to RAM, swith to 
another X session etc.)

-go back to the desktop session (Ctrl+Alt+F7, resume from suspend, etc)
-notice the lag described.

This happened in Unstable for a long time, I believe regardless of 
driver version and other Xorg components.


Please ask for any other needed information.



-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.34-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xorg depends on:
ii2.30.2-1   The GNOME terminal emulator 
applic

ii4:4.4.4-1  X terminal emulator for KDE 4
ii7.9.0+git20100608.bcf63dbb-0ub A free implementation of 
the OpenG
ii7.9.0+git20100610.63834285-0ub A free implementation of 
the OpenG
ii7.9.0+git20100610.63834285-0ub The OpenGL utility library 
(GLU)

ii7.5+5  X applications
ii7.5+1  X session utilities
ii7.5+4  X11 utilities
ii7.4+1  X font server utilities
ii7.5+5  X11 XKB utilities
ii7.5+1  X server utilities
ii1:1.0.4-1  X authentication utility
ii1:1.0.1100 dpi fonts for X
ii1:1.0.175 dpi fonts for X
ii1:1.0.1standard fonts for X
ii1:1.0.1-1  scalable fonts for X
ii1:7.5+2X Window System font 
utility progr

ii1.2.0-2X server initialisation tool
ii1.8-1  X Keyboard Extension (XKB) 
configu
ii1:1.5-1Core documentation for the 
X.org X

ii1:7.5+6the X.Org X server
ii261-1  X terminal emulator

xorg recommends no packages.

Versions of packages xorg suggests:
pn  xorg-docs  (no description available)

-- no debconf information




--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c40c279.2020...@gmail.com

Bug#589346: xorg: Graphical acceleration only available to one X user

[Alex Dănilă]

Package: xorg
Version: 1:7.5+6
Severity: normal

Some types of acceleration are not availabe to the second simultaneous 
log-in on the machine. I only say some types,

because some things work fast, others slow:
Fast:
-window resizing (both kwin and metacity)
-Opera animations, drawing, javascript
-KDE Plasma animations
-video seems to work decently.

Slow:
-window moving (both kwin and metacity)
-scrolling (Dolphin, Opera)
-3d is much slower (TORCS: 5-15 fps on the first login, 0-1 fps on the 
second)


Additionaly, Kwin compositing cannot be enabled on the second login, 
only on the first. Please ask for any

information I failed to provide.

Reproduce:
-login to an desktop session
-start a new desktop session without closing the first one, and notice 
the problems with this session.


Video driver:
xserver-xorg-video-radeon 1:6.13.1-1

This situation has been the same for a long time in Debian Unstable 
(more than a year), regardless of drm, mesa, kde version, xorg version.


-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.34-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xorg depends on:
ii2.30.2-1   The GNOME terminal emulator 
applic

ii4:4.4.4-1  X terminal emulator for KDE 4
ii7.9.0+git20100608.bcf63dbb-0ub A free implementation of 
the OpenG
ii7.9.0+git20100610.63834285-0ub A free implementation of 
the OpenG
ii7.9.0+git20100610.63834285-0ub The OpenGL utility library 
(GLU)

ii7.5+5  X applications
ii7.5+1  X session utilities
ii7.5+4  X11 utilities
ii7.4+1  X font server utilities
ii7.5+5  X11 XKB utilities
ii7.5+1  X server utilities
ii1:1.0.4-1  X authentication utility
ii1:1.0.1100 dpi fonts for X
ii1:1.0.175 dpi fonts for X
ii1:1.0.1standard fonts for X
ii1:1.0.1-1  scalable fonts for X
ii1:7.5+2X Window System font 
utility progr

ii1.2.0-2X server initialisation tool
ii1.8-1  X Keyboard Extension (XKB) 
configu
ii1:1.5-1Core documentation for the 
X.org X

ii1:7.5+6the X.Org X server
ii261-1  X terminal emulator

xorg recommends no packages.

Versions of packages xorg suggests:
pn  xorg-docs  (no description available)

-- no debconf information




--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c40bee6.5040...@gmail.com

Bug#587999: further info

[Alex Deucher]

2010/7/6 Michel Dänzer :
> On Mon, 2010-07-05 at 23:14 +0200, Ulrich Eckhardt wrote:
>> On Monday 05 July 2010 09:03:53 you wrote:
>> > On Sam, 2010-07-03 at 23:58 +0200, Ulrich Eckhardt wrote:
>> > > (EE) RADEON(0): [dri] RADEONDRIGetVersion failed to open the DRM
>> > > [dri] Disabling DRI.
>> >
>> > It should work better with the DRI enabled.
>>
>> Good catch, but shouldn't it work even without DRI?
>
> It should, if someone were to fix the problem(s) with the non-DRI big
> endian XVideo code paths. DRI is generally desirable anyway though as it
> provides significantly better performance across the board.
>
>
>> > If so, please post the output of running
>> >
>> > sudo modprobe radeon
>> >
>> > as well as the messages appearing in the dmesg output after it.
>>
>> The module is already loaded. I can unload it though, even with a running X11
>> session, "lsmod" shows that its refcount is zero. When loading it, it outputs
>> "[drm] radeon kernel modesetting enabled." in dmesg. However, when starting
>> the X server, it outputs "radeonfb :00:10.0: Invalid ROM contents" there.
>
> Looks like radeonfb is preventing the radeon kernel module from working
> with kernel modesetting (KMS). Disable radeonfb or load radeon with
> modeset=0.
>
>
> P.S. To fellow upstream radeon developers: In this case it would
> probably be more useful to initialize the DRM without KMS?
>

Makes sense as that was the original behavior.

Alex



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktim88bjzycb68ovnjaimyeaqexecmtqkjafp0...@mail.gmail.com

Bug#583120: xserver-xorg-video-radeon: Hibernate broken when KMS enabled on Radeon Mobility M6 LY

[Alex Deucher]

On Tue, May 25, 2010 at 10:51 AM, Kjö Hansi Glaz  
wrote:
> Package: xserver-xorg-video-radeon
> Version: 1:6.13.0-2
> Severity: important
>
>
> I tested radeon KMS on a squeeze system, with xserver-xorg-video-radeon
> and some related packages as well as kernel 2.6.32-5 from unstable on an
> IBM thinkpad X32.
>
> It works quite well but it breaks suspend/hibernate. The system hangs
> during the suspend process, after that pm-utils write "performing
> hibernate" in its logs (all hooks succeded).
>
> I tested with and without the uswsusp package installed, which didn't
> changed anything.
>
> I tried to add-remove some hooks, but this was also unsuccessful. I
> tested the following combinaisons:
>
> --quirk-test --quirk-radeon-off --quirk-s3-bios --quirk-s3-mode
>  --quirk-dpms-suspend
> --quirk-test --quirk-s3-bios --quirk-s3-mode --quirk-dpms-suspend
> --quirk-test --quirk-radeon-off --quirk-s3-bios --quirk-s3-mode

Please try without any quirks.  KMS shouldn't need them and they will
likely break things.

Alex



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktil4wb94xfnk_nmwu2gwfz5wlkg4eo4dzzbuq...@mail.gmail.com

Bug#570988: xserver-xorg-video-intel: X dies intermittantly with "Failed to submit batchbuffer: Input/Output error"

[Alex King]

Package: xserver-xorg-video-intel
Version: 2:2.9.1-3
Severity: normal

I typically work for several hours, then X dies (screen goes black,) and after
a minute a GDM error comes up "Failed to start the X server".   When I look at
the details, I see the "Failed to start submit batchbuffer: Input/Output
error," and also ... i830 batchbuffer.h intel_batch_emit_dword Assertion
pI830->patch_ptr != ((void)0)



-- Package-specific info:
/var/lib/x11/X.roster does not exist.

/var/lib/x11/X.md5sum does not exist.

X server symlink status:
lrwxrwxrwx 1 root root 13 Aug 25  2007 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 1725368 Apr 20 06:17 /usr/bin/Xorg

/var/lib/x11/xorg.conf.roster does not exist.

VGA-compatible devices on PCI bus:
00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE 
Chipset Integrated Graphics Device (rev 01)

/var/lib/x11/xorg.conf.md5sum does not exist.

Xorg X server configuration file status:
-rw-r--r-- 1 root root 3055 Apr 19 13:31 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
# /etc/X11/xorg.conf (xorg X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the /etc/X11/xorg.conf manual page.
# (Type "man /etc/X11/xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
#   sudo dpkg-reconfigure -phigh xserver-xorg

Section "Files"
FontPath"/usr/share/fonts/X11/misc"
FontPath"/usr/X11R6/lib/X11/fonts/misc"
FontPath"/usr/share/fonts/X11/cyrillic"
FontPath"/usr/X11R6/lib/X11/fonts/cyrillic"
FontPath"/usr/share/fonts/X11/100dpi/:unscaled"
FontPath"/usr/X11R6/lib/X11/fonts/100dpi/:unscaled"
FontPath"/usr/share/fonts/X11/75dpi/:unscaled"
FontPath"/usr/X11R6/lib/X11/fonts/75dpi/:unscaled"
FontPath"/usr/share/fonts/X11/Type1"
FontPath"/usr/X11R6/lib/X11/fonts/Type1"
FontPath"/usr/share/fonts/X11/100dpi"
FontPath"/usr/X11R6/lib/X11/fonts/100dpi"
FontPath"/usr/share/fonts/X11/75dpi"
FontPath"/usr/X11R6/lib/X11/fonts/75dpi"
# path to defoma fonts
FontPath"/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType"
EndSection

Section "Module"
Load"i2c"
Load"bitmap"
Load"ddc"
Load"dri"
Load"extmod"
Load"freetype"
Load"glx"
Load"int10"
Load"vbe"
EndSection

Section "InputDevice"
Identifier  "Generic Keyboard"
Driver  "kbd"
Option  "CoreKeyboard"
Option  "XkbRules"  "xorg"
Option  "XkbModel"  "pc104"
Option  "XkbLayout" "us"
EndSection

Section "InputDevice"
Identifier  "Configured Mouse"
Driver  "mouse"
Option  "CorePointer"
Option  "Device""/dev/input/mice"
Option  "Protocol"  "ImPS/2"
Option  "Emulate3Buttons"   "true"
EndSection

Section "Device"
Identifier  "Generic Video Card"
#Driver "ati"
#BusID  "PCI:1:0:0"
EndSection

Section "Monitor"
Identifier  "Generic Monitor"
Option  "DPMS"
HorizSync   28-64
VertRefresh 43-60
EndSection

Section "Screen"
Identifier  "Default Screen"
Device  "Generic Video Card"
Monitor "Generic Monitor"
DefaultDepth16
SubSection "Display"
Depth   1
Modes   "1280x1024" "1024x768" "800x600" "640x480"
EndSubSection
SubSection "Display"
Depth   4
Modes   "1280x1024" "1024x768" "800x600" "640x480"
EndSubSection
SubSection "Display"
Depth   8
Modes   "1280x1024" "1024x768" "800x600" "640x480"
EndSubSection
SubSection "Display"
Depth   15
Modes   "1280x1024" "1024x768" "800x600" "640x480"
EndSubSection
SubSection "Display"
Depth   16
Modes   "1280x1024" "1024x768" "800x600" "640x480"
EndSubSection
SubSection "Display"
Depth   24
Modes   "1280x1024" "1024x768" "800x600" "640x480"
EndSubSection
EndSection

Section "ServerLayout"
Identifier  "Defau

Bug#577996: xorg: Screen occasionaly fails to unblank after resuming from suspend

[Alex]

On Sun, Apr 18, 2010 at 05:17:10PM +0200, Julien Cristau wrote:
> Please run
> /usr/share/bug/xserver-xorg/script 3>/tmp/xorg-bug-577996.txt
> and send the resulting file to this bug.
> 
> Cheers,
> Julien

Attached.

-- 
Alex, homepage: http://www.bennee.com/~alex/
It's not whether you win or lose, it's how you place the blame.
/var/lib/x11/X.roster does not exist.

/var/lib/x11/X.md5sum does not exist.

X server symlink status:
lrwxrwxrwx 1 root root 13 Nov 29 00:52 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 1725368 Apr 17 19:39 /usr/bin/Xorg

/var/lib/x11/xorg.conf.roster does not exist.

VGA-compatible devices on PCI bus:
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express 
Integrated Graphics Controller (rev 03)

/var/lib/x11/xorg.conf.md5sum does not exist.

Xorg X server configuration file status:
-rw-r--r-- 1 root root 1077 Nov 29 00:52 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
# xorg.conf (X.Org X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the xorg.conf manual page.
# (Type "man xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
#   sudo dpkg-reconfigure -phigh xserver-xorg

Section "InputDevice"
Identifier  "Generic Keyboard"
Driver  "kbd"
Option  "XkbRules"  "xorg"
Option  "XkbModel"  "pc105"
Option  "XkbLayout" "gb"
EndSection

Section "InputDevice"
Identifier  "Configured Mouse"
Driver  "mouse"
EndSection

Section "Device"
Identifier  "Configured Video Device"
EndSection

Section "Monitor"
Identifier  "Configured Monitor"
EndSection

Section "Screen"
Identifier  "Default Screen"
Monitor "Configured Monitor"
EndSection


Kernel version (/proc/version):
Linux version 2.6.32-4-686 (Debian 2.6.32-11) (m...@debian.org) (gcc version 
4.3.4 (Debian 4.3.4-8) ) #1 SMP Tue Apr 6 07:02:27 UTC 2010

Xorg X server log files on system:
-rw-r--r-- 1 root root 30778 Apr 19 07:14 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file
/var/log/Xorg.0.log:

This is a pre-release version of the X server from The X.Org Foundation.
It is not supported in any way.
Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
Select the "xorg" product for bugs you find in this release.
Before reporting bugs in pre-release versions please check the
latest version in the X.Org Foundation git repository.
See http://wiki.x.org/wiki/GitPage for git access instructions.

X.Org X Server 1.7.6.901 (1.7.7 RC 1)
Release Date: 2010-04-12
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.26-2-amd64 i686 Debian
Current Operating System: Linux trent 2.6.32-4-686 #1 SMP Tue Apr 6 07:02:27 
UTC 2010 i686
Kernel command line: BOOT_IMAGE=/vmlinuz-2.6.32-4-686 
root=UUID=5ea0587f-bec8-47ba-a953-acf91c37656b ro 
root=UUID=5ea0587f-bec8-47ba-a953-acf91c37656b ro
Build Date: 17 April 2010  06:34:55PM
xorg-server 2:1.7.6.901-2 (Cyril Brulebois ) 
Current version of pixman: 0.16.4
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Sun Apr 18 10:09:58 2010
(==) Using config file: "/etc/X11/xorg.conf"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(==) No Layout section.  Using the first Screen section.
(**) |-->Screen "Default Screen" (0)
(**) |   |-->Monitor "Configured Monitor"
(==) No device specified for screen "Default Screen".
Using the first device section listed.
(**) |   |-->Device "Configured Video Device"
(==) Automatically adding devices
(==) Automatically enabling devices
(WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
Entry deleted from font path.
(==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dp

Bug#577996: xorg: Screen occasionaly fails to unblank after resuming from suspend

[Alex]

On Sun, Apr 18, 2010 at 01:48:40PM +0200, Julien Cristau wrote:
> On Sun, Apr 18, 2010 at 10:55:16 +0200, Alex wrote:
> > On Fri, Apr 16, 2010 at 01:11:33AM +0200, Cyril Brulebois wrote:
> > > Alex Bennee  (15/04/2010):
> > 
> > Seems more stable but have had it blank up on me at least once with -4
> > kernel. Do you know what commit/patch was meant to have fixed it?
> > 
> -4 has a backport of the whole drm subsystem from 2.6.33, so that's
> pretty massive.
> 
> FWIW I also have occasional trouble with the screen staying black after
> resume, but vt switch to the console and back to X fixes it.  Do you
> still have issues on vt switch?

I don't seem to be able to VT switch in this mode or if I am the
screen isn't changing.

-- 
Alex, homepage: http://www.bennee.com/~alex/
There has been an alarming increase in the number of things you know
nothing about.


signature.asc
Description: Digital signature

Bug#577996: xorg: Screen occasionaly fails to unblank after resuming from suspend

[Alex]

On Fri, Apr 16, 2010 at 01:11:33AM +0200, Cyril Brulebois wrote:
> Hi,
> 
> Alex Bennee  (15/04/2010):
> > Since a recent update to sid (in the last 2 weeks) resume from
> > suspend has become unreliable.
> 
> 
> please upgrade your kernel from your current 2.6.32-3-$arch to current
> 2.6.32-4-$arch. Many fixes in there, which should make you happy.

Seems more stable but have had it blank up on me at least once with -4
kernel. Do you know what commit/patch was meant to have fixed it?

-- 
Alex, homepage: http://www.bennee.com/~alex/
What we anticipate seldom occurs; what we least expect generally happens.
-- Bengamin Disraeli


signature.asc
Description: Digital signature

Bug#577996: xorg: Screen occasionaly fails to unblank after resuming from suspend

[Alex Bennee]

Package: xorg
Version: 1:7.5+5
Severity: important
Tags: sid

Since a recent update to sid (in the last 2 weeks) resume from suspend has
become unreliable. Although the machine appears to resume OK I'm unable to
unlock X as the screen is blank. I've been unable to switch to console mode
(possibly due to X screensaver having locked out).



-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-3-686 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xorg depends on:
ii  libgl1-mesa-dri   7.7.1-1A free implementation of the OpenG
ii  libgl1-mesa-glx [libgl1]  7.7.1-1A free implementation of the OpenG
ii  libglu1-mesa  7.7.1-1The OpenGL utility library (GLU)
ii  lxterminal [x-terminal-emulat 0.1.7-1desktop independent vte-based term
ii  rxvt-unicode-ml [x-terminal-e 9.07-1 multi-lingual terminal emulator wi
ii  x11-apps  7.5+5  X applications
ii  x11-session-utils 7.5+1  X session utilities
ii  x11-utils 7.5+3  X11 utilities
ii  x11-xfs-utils 7.4+1  X font server utilities
ii  x11-xkb-utils 7.5+2  X11 XKB utilities
ii  x11-xserver-utils 7.5+1+b1   X server utilities
ii  xauth 1:1.0.4-1  X authentication utility
ii  xfce4-terminal [x-terminal-em 0.4.3-1Xfce terminal emulator
ii  xfonts-100dpi 1:1.0.1100 dpi fonts for X
ii  xfonts-75dpi  1:1.0.175 dpi fonts for X
ii  xfonts-base   1:1.0.1standard fonts for X
ii  xfonts-scalable   1:1.0.1-1  scalable fonts for X
ii  xfonts-utils  1:7.5+2X Window System font utility progr
ii  xinit 1.2.0-1X server initialisation tool
ii  xkb-data  1.8-1  X Keyboard Extension (XKB) configu
ii  xorg-docs-core1:1.5-1Core documentation for the X.org X
ii  xserver-xorg  1:7.5+5the X.Org X server
ii  xterm [x-terminal-emulator]   256-1  X terminal emulator

xorg recommends no packages.

Versions of packages xorg suggests:
pn  xorg-docs  (no description available)

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100415222632.8688.29172.report...@localhost.localdomain

Bug#540101: classification?

[Alex Deucher]

On Fri, Apr 2, 2010 at 10:40 AM, Andres Cimmarusti
 wrote:
>>The overlay doesn't currently support rotation.
>
> In that case, shouldn't this bug report be classified as wishlist?
>
> Is this still true with the newer radeon drivers + kernels?

For rotation you need to use the textured video adapter.

Alex



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/q2ua728f9f91004020757weda29e2t7944316194255...@mail.gmail.com

Bug#575945: exa not working with 2.6.33

[Alex Deucher]

On Tue, Mar 30, 2010 at 12:31 PM, Eduard Bloch  wrote:
> Package: xserver-xorg-video-radeon
> Version: 1:6.12.192-2
> Severity: important
>
> Hello,
>
> about a month ago, I was using radeon driver with my onboard IGP (HD4200
> from 785G chipset), and kernel 2.6.32.x.
> The only thing I needed to set explicitely were the
>    Option "AccelMethod" "exa"
>    Option  "DRI" "on"
> options and then everything (except 3D) was fine.
>
> Now I tried to use it again with 2.6.33. Result: works in 2D (less or
> more) but XVideo does not work at all.
>
> When KMS is enabled in the kernel module then I cannot see any reason
> for its breakage (log file attached).
>
> With KMS disabled, the 2D performace is a lot worse (slow repainting
> when moving/maximizing/switching windows) and I see a message in
> Xorg.0.conf telling:
>
> (WW) RADEON(0): Direct rendering is not supported when VGA arb is necessary 
> for the device
> (EE) RADEON(0): [dri] DRIScreenInit failed.  Disabling DRI.

I suspect you are missing the ucode needed by the chip.  Make sure you
have the linux-firmware package installed.

Alex



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/a728f9f91003301349t35c1c62fya3742bd0aa32a...@mail.gmail.com

Bug#575681: xserver-xorg-video-radeon: shows severe artifacts since switching to KMS

[Alex Deucher]

On Sun, Mar 28, 2010 at 5:55 AM, Fabian Greffrath
 wrote:
> Package: xserver-xorg-video-radeon
> Version: 1:6.12.192-2
> Severity: normal
>
> Hi,
>
> since KMS has been activated in version 1:6.12.192-2, my display shows severe 
> artifacts. Occasionally the fonts become unreadable and some areas of the 
> screen show a checkerboard pattern, c.f. the attached screen shot. My 
> graphics adapter is a "ATI Technologies Inc R300 AD [Radeon 9500 Pro]".
>

Does changing the agpmode or disabling AGP help?  Add:
radeon.agpmode=X
where X = -1, 1, 2, or 4 to the kernel command line.  -1 will use pci
gart rather than agp.

Alex


>  - Fabian
>
>
>
> -- Package-specific info:
> /var/lib/x11/X.roster does not exist.
>
> /var/lib/x11/X.md5sum does not exist.
>
> X server symlink status:
> lrwxrwxrwx 1 root root 13 Apr  9  2007 /etc/X11/X -> /usr/bin/Xorg
> -rwxr-xr-x 1 root root 1712808 Feb 16 09:39 /usr/bin/Xorg
>
> /var/lib/x11/xorg.conf.roster does not exist.
>
> VGA-compatible devices on PCI bus:
> 02:00.0 VGA compatible controller: ATI Technologies Inc R300 AD [Radeon 9500 
> Pro]
>
> /var/lib/x11/xorg.conf.md5sum does not exist.
>
> Xorg X server configuration file status:
> -rw-r--r-- 1 root root 932 Mar 23 20:17 /etc/X11/xorg.conf
>
> Contents of /etc/X11/xorg.conf:
> Section "InputDevice"
>        Identifier      "Generic Keyboard"
>        Driver          "kbd"
>        Option          "CoreKeyboard"
>        Option          "XkbRules"      "xorg"
>        Option          "XkbModel"      "cymotionlinux"
>        Option          "XkbLayout"     "de"
>        Option          "XkbVariant"    "nodeadkeys"
> EndSection
>
> Section "Device"
>        Identifier      "Default Screen"
>        Driver          "radeon"
> #       Option          "NoDDC"                 "true"
> #       Option          "DDCMode"               "off"
> #       Option          "DDC"                   "off"
> EndSection
>
> Section "Monitor"
>        Identifier      "Configured Monitor"
>        HorizSync       60-92
>        VertRefresh     50-160
> #       Option          "NoDDC"                 "true"
> #       Option          "DDCMode"               "off"
> #       Option          "DDC"                   "off"
>  # 1152x864 @ 100.00 Hz (GTF) hsync: 91.50 kHz; pclk: 143.47 MHz
>  Modeline "1152x864_100.00"  143.47  1152 1232 1360 1568  864 865 868 915  
> -HSync +Vsync
> EndSection
>
> Section "Screen"
>        Identifier      "Default Screen"
>        Monitor         "Configured Monitor"
> #       DefaultDepth    24
> #       SubSection "Display"
> #               Modes           "1152x864_100.00" "1280x1024" "1024x768" 
> "800x600" "640x480"
> #       EndSubSection
> EndSection
>
>
> Xorg X server log files on system:
> -rw-r--r-- 1 root root 49356 Sep 14  2008 /var/log/Xorg.20.log
> -rw-r--r-- 1 root root 37583 Mar 28 11:39 /var/log/Xorg.0.log
>
> Contents of most recent Xorg X server log file
> /var/log/Xorg.0.log:
>
> X.Org X Server 1.7.5
> Release Date: 2010-02-16
> X Protocol Version 11, Revision 0
> Build Operating System: Linux 2.6.32-trunk-686 i686 Debian
> Current Operating System: Linux beppo 2.6.32-4-686 #1 SMP Wed Mar 17 17:16:41 
> UTC 2010 i686
> Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-4-686 
> root=UUID=ff43013e-d698-4d97-a4f3-aad02610d17e ro quiet
> Build Date: 16 February 2010  08:37:23AM
> xorg-server 2:1.7.5-1 (bgog...@debian.org)
> Current version of pixman: 0.16.4
>        Before reporting problems, check http://wiki.x.org
>        to make sure that you have the latest version.
> Markers: (--) probed, (**) from config file, (==) default setting,
>        (++) from command line, (!!) notice, (II) informational,
>        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> (==) Log file: "/var/log/Xorg.0.log", Time: Sun Mar 28 11:38:57 2010
> (==) Using config file: "/etc/X11/xorg.conf"
> (==) No Layout section.  Using the first Screen section.
> (**) |-->Screen "Default Screen" (0)
> (**) |   |-->Monitor "Configured Monitor"
> (==) No device specified for screen "Default Screen".
>        Using the first device section listed.
> (**) |   |-->Device "Default Screen"
> (==) Automatically adding devices
&g

Bug#574169: xserver-xorg-video-radeon: dims display after some days of uptime

[Alex Deucher]

On Wed, Mar 24, 2010 at 8:36 AM, Piotr Engelking  wrote:
> I can reproduce this bug with xserver-xorg-video-radeon 1:6.12.192-1,
> KMS-enabled upstream stable kernel 2.6.33.1, and xscreensaver 5.10-7
> by running 'xscreensaver-command -lock' in X and switching to another
> console before the screen finishes fading. (This requires the
> xscreensaver 'fade' option to be enabled, which is on by default.)
> After unlocking X, the screen is considerably dimmer. Running xgamma
> results in the following output:
>
> $ xgamma
> -> Red  1.000, Green  1.000, Blue  1.000
> $
>
> Running 'xgamma -gamma 1' _does_ however result the screen to normal 
> brightness.
>
> This bug may very well not be radeon-related, but I am not able to
> test it on another hardware at the moment - please do. (Cc-ing
> xscreensaver maintainers.)

The fade effect done by adjusting the gamma (driver independent).  The
gamma isn't changed when you switch VTs.

Alex



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/a728f9f91003240820x20588751y5493e69b4aa6c...@mail.gmail.com

Bug#572911:

[Alex Hvostov]

On Fri, 2010-03-19 at 17:11 +0100, Brice Goglin wrote:
> The whole point is that glxgears reports something that is meaningless
> and we're trying to fight about it by hiding as much as possible all
> reports that show glxgears in big. Some distributions even hide the
> glxgears fps output by default because of this meaningless output.

glxgears is showing the same problem (very poor performance) as every
other application I've tested. How is that meaningless?

> The reason is: KMS sometimes synchronizes the commands it sends to the
> GPU with the vertical refresh rate. In this case, it just becomes
> impossible to see more fps than the refresh rate (ie 60fps for
> instance). Getting 8000fps from glxgears may just be impossible in the
> future. Measuring real FPS is a matter of using an application that uses
> the GPU so much that it will be slower than the refresh rate. So people
> use Quake or other complex 3D games to benchmark these.

AisleRiot gets ~15-30 FPS, which is terrible considering it's just a
solitaire game. armagetronad locks up the entire X display for seconds
at a time, leaving only a split second between lock-ups where the mouse
cursor can be moved.

> AisleRiot is probably a matter of 2D acceleration, which is another
> problem (likely related to DRM and EXA, but not related to OpenGL).
> x11perf might measure this properly, not sure how. I am not sure about
> ZSNES.

AisleRiot uses libclutter (and, therefore, OpenGL) for drawing. ZSNES
uses OpenGL as well. Both show very poor performance.


signature.asc
Description: This is a digitally signed message part

Bug#572911:

[Alex Hvostov]

On Fri, 2010-03-19 at 16:34 +0100, Brice Goglin wrote:
> Alex Hvostov wrote:
> > This issue happens to me, too. It is most definitely not solved.
> >   
> 
> There is nothing to solve in this report, glxgears is not a benchmark,
> so having a "slow glxgears" means nothing. Moreover, you're not even
> using KMS/DRI2, so your "problem" has nothing to do here.
> 
> cheers,
> Brice

Please reread my message. I am experiencing poor performance in
AisleRiot and ZSNES as well. This is when KMS is *on*; I experience no
such performance issue when KMS is off.

Honestly. This is insulting.



signature.asc
Description: This is a digitally signed message part

Bug#574037: [xserver-xorg-video-radeon] OpenGL 3d games crash after a while on RV350 AP [Radeon 9600]

[Alex Deucher]

On Mon, Mar 15, 2010 at 5:43 PM, Matej Zary  wrote:
> Package: xserver-xorg-video-radeon
> Version: 1:6.12.5-1
> Severity: normal
>
> --- Please enter the report below this line. ---
>
>
> OpenGL 3D games like UrbanTerror or Unreal Tournament crash after while with
> these lines:
>
> drmRadeonCmdBuffer: -12. Kernel failed to parse or rejected command stream.
> See dmesg for more info.
> Signal: SIGSEGV [segmentation fault]
> Aborting.
> Segmentation fault

These should be fixed in these upstream commits:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=7a9f0dd9c49425e2b0e39ada4757bc7a38c84873
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=b4fe945405e477cded91772b4fec854705443dd5

Alex


>
>
> $dmesg
>
> [  322.305400] [drm] Num pipes: 1
> [  372.981310] ut-bin: page allocation failure. order:4, mode:0x40d0
> [  372.981320] Pid: 2120, comm: ut-bin Not tainted 2.6.32-3-686 #1
> [  372.981325] Call Trace:
> [  372.981346]  [] ? __alloc_pages_nodemask+0x476/0x4e0
> [  372.981355]  [] ? __get_free_pages+0xc/0x17
> [  372.981363]  [] ? __kmalloc+0x30/0x128
> [  372.981404]  [] ? radeon_cp_cmdbuf+0x111/0x121e [radeon]
> [  372.981416]  [] ? do_page_fault+0x271/0x287
> [  372.981423]  [] ? do_page_fault+0x0/0x287
> [  372.981435]  [] ? error_code+0x73/0x78
> [  372.981465]  [] ? atom_rv515_force_tv_scaler+0xdb9/0x2ad2
> [radeon]
> [  372.981479]  [] ? copy_from_user+0x104/0x10e
> [  372.981498]  [] ? radeon_commit_ring+0x47/0x91 [radeon]
> [  372.981518]  [] ? radeon_cp_texture+0x859/0x87f [radeon]
> [  372.981540]  [] ? drm_ioctl+0x89/0x268 [drm]
> [  372.981554]  [] ? drm_ioctl+0x1d2/0x268 [drm]
> [  372.981574]  [] ? radeon_cp_cmdbuf+0x0/0x121e [radeon]
> [  372.981582]  [] ? sched_clock+0x5/0x7
> [  372.981592]  [] ? sched_clock_local+0x15/0x11b
> [  372.981606]  [] ? update_curr+0x106/0x1b3
> [  372.981616]  [] ? sched_slice+0x67/0x7f
> [  372.981623]  [] ? hrtimer_forward+0x10c/0x124
> [  372.981634]  [] ? scheduler_tick+0xd3/0x1ec
> [  372.981644]  [] ? vfs_ioctl+0x49/0x5f
> [  372.981651]  [] ? do_vfs_ioctl+0x4aa/0x4e5
> [  372.981661]  [] ? __rcu_process_callbacks+0x6c/0x227
> [  372.981669]  [] ? rcu_process_callbacks+0x33/0x39
> [  372.981678]  [] ? __do_softirq+0x115/0x151
> [  372.981685]  [] ? sys_ioctl+0x41/0x58
> [  372.981694]  [] ? syscall_call+0x7/0xb
> [  372.981699] Mem-Info:
> [  372.981703] DMA per-cpu:
> [  372.981707] CPU    0: hi:    0, btch:   1 usd:   0
> [  372.981711] Normal per-cpu:
> [  372.981715] CPU    0: hi:  186, btch:  31 usd:   0
> [  372.981725] active_anon:29573 inactive_anon:37882 isolated_anon:6
> [  372.981728]  active_file:22348 inactive_file:23447 isolated_file:0
> [  372.981731]  unevictable:2 dirty:31 writeback:80 unstable:0
> [  372.981733]  free:1849 slab_reclaimable:2142 slab_unreclaimable:1220
> [  372.981736]  mapped:13266 shmem:89 pagetables:711 bounce:0
> [  372.981751] DMA free:2072kB min:84kB low:104kB high:124kB
> active_anon:2852kB inactive_anon:3800kB active_file:1444kB
> inactive_file:5712kB unevictable:0kB isolated(anon):0kB isolated(file):0kB
> present:15868kB mlocked:0kB dirty:0kB writeback:0kB mapped:48kB shmem:0kB
> slab_reclaimable:36kB slab_unreclaimable:4kB kernel_stack:0kB pagetables:8kB
> unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable?
> no
> [  372.981764] lowmem_reserve[]: 0 492 492 492
> [  372.981780] Normal free:5324kB min:2792kB low:3488kB high:4188kB
> active_anon:115440kB inactive_anon:147728kB active_file:87948kB
> inactive_file:88076kB unevictable:8kB isolated(anon):24kB isolated(file):0kB
> present:503872kB mlocked:8kB dirty:124kB writeback:320kB mapped:53016kB
> shmem:356kB slab_reclaimable:8532kB slab_unreclaimable:4876kB
> kernel_stack:1464kB pagetables:2836kB unstable:0kB bounce:0kB
> writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
> [  372.981794] lowmem_reserve[]: 0 0 0 0
> [  372.981801] DMA: 2*4kB 2*8kB 2*16kB 1*32kB 1*64kB 1*128kB 1*256kB 1*512kB
> 1*1024kB 0*2048kB 0*4096kB = 2072kB
> [  372.981820] Normal: 1017*4kB 61*8kB 10*16kB 1*32kB 7*64kB 1*128kB 0*256kB
> 0*512kB 0*1024kB 0*2048kB 0*4096kB = 5324kB
> [  372.981838] 46406 total pagecache pages
> [  372.981842] 516 pages in swap cache
> [  372.981846] Swap cache stats: add 3470, delete 2954, find 303/393
> [  372.981851] Free swap  = 519900kB
> [  372.981854] Total swap = 530136kB
> [  372.988490] 131056 pages RAM
> [  372.988497] 0 pages HighMem
> [  372.988500] 2369 pages reserved
> [  372.988503] 79440 pages shared
> [  372.988506] 101416 pages non-shared
> [  374.229712] [drm] Num pipes: 1
> [  374.326107] ut-bin[2120]: segfault at bec ip b736e9e7 sp bffbce70 error 4
> in Core.so[b72f7000+

Bug#572311: No display output from Radeon RV610 on Alpha

[Alex Deucher]

On Sat, Mar 13, 2010 at 3:57 AM, Michael Cree  wrote:
> On 13/03/10 06:57, Alex Deucher wrote:
>>
>> On Fri, Mar 12, 2010 at 4:57 AM, Michael Cree  wrote:
>>>
>>> On 10/03/10 08:44, Alex Deucher wrote:
>>>>>>>>
>>>>>>>> On Sun, Mar 7, 2010 at 3:47 AM, Michael Cree
>>>>>>>>  wrote:
>>>>>>>>>
>>>>>>>>> Thanks, that hint was helpful.  I have drummed up a patch
>>>>>>>>> (attached)
>>>>>>>>> that
>>>>>>>>> replaces some use of the UINT16LE_TO_CPU(), etc., macros with
>>>>>>>>> generic
>>>>>>>>> interfaces from the Xserver's compiler.h header file.  Now works
>>>>>>>>> correctly
>>>>>>>>> on RV610 video card on an Alpha XP1000.  Have also verified that
>>>>>>>>> the
>>>>>>>>> driver
>>>>>>>>> still works on an RV710 card on AMD64 architecture.
>>>>
>>>> Can you add the alignment stuff to the ATOM_BSWAP16/32 functions in
>>>> radeon_atombios.c?
>>>> e.g.,
>>>> return ldw_u(bswap_16(x));
>>>
>>> That's a good idea, however I think the ldw_u() must be inside the byte
>>> swap
>>> as the (mis)alignment issues must be dealt with at the point of loading
>>> the
>>> datum, whereas endianess can be fixed later.
>>>
>>> Attached is a new patch that uses the ldw_u() macros and also leaves the
>>> UINT16LE_TO_CPU, etc., macros in place.  Verified working on Alpha and
>>> AMD64
>>> architectures, but I don't have a suitable big-endian machine to test
>>> this.
>>
>> Wouldn't it be cleaner to just put the ldw_u() in ATOM_BSWAP16()?
>>
>> --- a/src/radeon_atombios.c
>> +++ b/src/radeon_atombios.c
>> @@ -28,6 +28,7 @@
>>  #endif
>>  #include "xf86.h"
>>  #include "xf86_OSproc.h"
>> +#include "compiler.h"
>>
>>  #include "radeon.h"
>>  #include "radeon_reg.h"
>> @@ -2981,7 +2982,7 @@
>> atombios_get_command_table_version(atomBiosHandlePtr atomBIOS, int
>> index, int *m
>>
>>  UINT16 ATOM_BSWAP16(UINT16 x)
>>  {
>> -    return bswap_16(x);
>> +    return bswap_16(ldw_u(x));
>>  }
>
> No, that won't work for two reasons:
>
> 1) It's only in the big endian code path.  There are little endian
> architectures that need the ldw_u().
>
> 2) ldw_u()'s argument is a pointer (i.e. the address from which the word is
> to be loaded) not a value.  This is also the reason that I didn't include
> the ldw_u()s in the UINT16LE_TO_CPU, etc., macro definitions in Decoder.h.
>  Those macros sometimes wrap an access via a pointer and at other times they
> wrap an actual value.  Use of ldw_u() is only appropriate at the actual
> access of a datum from the AtomBios, i.e., those cases that perform an
> access through a pointer.

Thanks,  I've gone ahead and pushed it to master and 6.12-branch.

Alex



--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/a728f9f91003151031h690a2d9fk265661f73e5f...@mail.gmail.com