Bug#687203: dpi/resolution setting lost on suspend/resume
This might be related to bugs #582566 (xset -b setting lost) #541388 (xmodmap settings lost) #568868 (key repeat settings lost) Furthermore, I think the bug appeared when upgrading from squeeze to wheezy. -- Carsten Otto o...@informatik.rwth-aachen.de LuFG Informatik 2 http://verify.rwth-aachen.de/otto/ RWTH Aachenphone: +49 241 80-21211 signature.asc Description: Digital signature
Bug#680377: xorg: update FAQ: How to set correct DPI
Dear all, I found out that "xrandr --dpi " indeed works in the sense that xterm fonts get bigger. However, I still do not know how to properly configure X so that a high DPI display is properly used (e.g. in Firefox without plugins). Best regards, -- Carsten Otto o...@informatik.rwth-aachen.de LuFG Informatik 2 http://verify.rwth-aachen.de/otto/ RWTH Aachenphone: +49 241 80-21211 signature.asc Description: Digital signature
Bug#541388: xserver-xorg: Xmodmap settings lost across suspend/hibernate
Dear all, I also experience this bug. For my configuration please have a look at the (possibly related) bug #687203. Best regards, -- Carsten Otto o...@informatik.rwth-aachen.de LuFG Informatik 2 http://verify.rwth-aachen.de/otto/ RWTH Aachenphone: +49 241 80-21211 signature.asc Description: Digital signature
Bug#686611: xserver-xorg-video-nouveau: Distorted graphics with GeForce 4200Go (NV28)
On 2012-09-09 21:53 +0200, r ductor wrote: > 4) Booted with experimenta kernel > linux-image-3.5-trunk-686-pae > Version: 3.5.2-1~experimental.1 > black TTY and black X so I cannot document this. > > I've reported the bug upstream > https://bugs.freedesktop.org/show_bug.cgi?id=54700 > (but I reported the bug with the old kernel, the new one breaks the > system badly) I'm afraid upstream won't be interested in that then, since they don't support the 3.2 kernel. > As for the driver modesetting, I use > Package: xserver-xorg-video-modesetting > State: installed > Automatically installed: no > Version: 0.3.0-1 > # cat /etc/modprobe.d/blacklist-nouveau.conf > blacklist nouveau You should not blacklist nouveau, the modesetting driver actually needs that kernel module to be loaded. > # cat /etc/X11/xorg.conf.d/98-me > Section "Device" > Identifier "Device0" > Driver "modesetting" > BusID "pci::01:00.0" > EndSection > > but nouveau is still loaded. (I attach dmsg and Xorg.log if somebody > can understand why I cannot start modesetting, maybe the pci data I > used are wrong ... I'm really incompetent!) There's no need to specify the BusID, but your file is ignored entirely because its name does not end in ".conf". See xorg.conf.d(5). Cheers, Sven -- 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/87d31t65v4@turtle.gmx.de
Processed: tagging 687190
Processing commands for cont...@bugs.debian.org: > tags 687190 + moreinfo Bug #687190 [libdrm-nouveau1a] libdrm-nouveau1a: X crashes, uses 100% cpu, spams Xorg.log with "-28" Added tag(s) moreinfo. > thanks Stopping processing here. Please contact me if you need assistance. -- 687190: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687190 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.134729874218960.transcr...@bugs.debian.org
Bug#687190: libdrm-nouveau1a: X crashes, uses 100% cpu, spams Xorg.log with "-28"
On Mon, Sep 10, 2012 at 18:22:30 +0200, ryx wrote: > Package: libdrm-nouveau1a > Version: 2.4.33-3 > Severity: normal > > Dear Maintainer, > > after a recent upgrade, X is rather unstable. It sometimes uses 100% CPU > with no discernible reason or pattern, got killed by the oom-killer > twice in a week so far, and spams the Xorg.log.0 with over a million > lines like "[433173.629] -28" (of course with varying timestamps, but > the -28 is constant). > Please attach full dmesg and X log. Cheers, Julien signature.asc Description: Digital signature
Bug#687190: libdrm-nouveau1a: X crashes, uses 100% cpu, spams Xorg.log with "-28"
Package: libdrm-nouveau1a Version: 2.4.33-3 Severity: normal Dear Maintainer, after a recent upgrade, X is rather unstable. It sometimes uses 100% CPU with no discernible reason or pattern, got killed by the oom-killer twice in a week so far, and spams the Xorg.log.0 with over a million lines like "[433173.629] -28" (of course with varying timestamps, but the -28 is constant). I have no clue where to file this bug, so I tried libdrm-nouveau1a for now. My versions are: - linux-image-3.2.0-3-rt-686-pae - xserver-xorg: 1:7.7+1 - xserver-xorg-video-nouveau: 1:1.0.1-3 - libgl1-mesa-dri: 8.0.4-2 - libdrm-nouveau1a: 2.4.33-3 (of course) Video card: GeForce 8600 GT (rev a1) oom-killer-lines (dmesg) are: [257166.771142] Killed process 3877 (Xorg) total-vm:740544kB, anon-rss:524868kB, file-rss:60096kB [632730.455670] Killed process 19943 (Xorg) total-vm:619484kB, anon-rss:308864kB, file-rss:41760kB (sounds a bit strange to me, since I have 4G ram, and beforehand a few other processes (iceweasel, using more memory) got killed.) Please tell me if I can provide anything else to help. Greetings, Paul -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (700, 'testing'), (650, 'stable'), (630, 'unstable'), (610, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-3-rt-686-pae (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libdrm-nouveau1a depends on: ii libc6 2.13-35 ii libdrm22.4.33-3 ii multiarch-support 2.13-35 libdrm-nouveau1a recommends no packages. libdrm-nouveau1a suggests no packages. -- 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/20120910162230.11948.73771.reportbug@localhost.localdomain
[bts-link] source package xserver-xorg-input-synaptics
# # bts-link upstream status pull for source package xserver-xorg-input-synaptics # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user bts-link-upstr...@lists.alioth.debian.org # remote status report for #609903 (http://bugs.debian.org/609903) # Bug title: xserver-xorg-input-synaptics: enable LEDDoubleTap feature # * https://bugs.freedesktop.org/show_bug.cgi?id=39055 # * remote status changed: (?) -> NEW usertags 609903 + status-NEW # remote status report for #683762 (http://bugs.debian.org/683762) # Bug title: On/Off button & LED indicator doesn't work on HP Folio 13 - 2000 # * https://bugs.freedesktop.org/show_bug.cgi?id=39055 # * remote status changed: (?) -> NEW usertags 683762 + status-NEW thanks -- 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/20120910163518.10023.57161.btsl...@sonntag.debian.org
Bug#687058: xserver-xorg-video-radeon: Gnome 3 fonts rendering problem (also appeared at fonts in Blender Software)
reassign 687058 libgl1-mesa-dri kthxbye On Son, 2012-09-09 at 03:04 +0300, Manolis wrote: > Package: xserver-xorg-video-radeon > Version: 1:6.14.4-5 > Severity: important > > As you can see in the screenshot i've included, fonts are corrupted. > This type of font's corruption appeared in the past when using Blender > 3D software. Got solved using software DRI, but now, i cannot use > Gnome 3 without hardware DRI, but only in fallback mode. > > Fonts in programs are ok, only Gnome 3 fonts are rendered as in screenshot. Reassigning to libgl1-mesa-dri, though it might also be a kernel issue, see e.g. https://bugs.freedesktop.org/show_bug.cgi?id=35457 . -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer -- 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/1347290823.30263.390.camel@thor.local
Processed: Re: Bug#687058: xserver-xorg-video-radeon: Gnome 3 fonts rendering problem (also appeared at fonts in Blender Software)
Processing commands for cont...@bugs.debian.org: > reassign 687058 libgl1-mesa-dri Bug #687058 [xserver-xorg-video-radeon] xserver-xorg-video-radeon: Gnome 3 fonts rendering problem (also appeared at fonts in Blender Software) Bug reassigned from package 'xserver-xorg-video-radeon' to 'libgl1-mesa-dri'. No longer marked as found in versions xserver-xorg-video-ati/1:6.14.4-5. Ignoring request to alter fixed versions of bug #687058 to the same values previously set > kthxbye Stopping processing here. Please contact me if you need assistance. -- 687058: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687058 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.134729122230040.transcr...@bugs.debian.org
Bug#686971: [radeon] display unwantingly dimmed, dimming state leaking across VT switch
On Fre, 2012-09-07 at 21:45 +0200, 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... Since you're using KMS, the gamma ramp leaking from X into console is probably a kernel issue. The other problem might be a core X server issue. In general, the drivers will just set the gamma ramp when/as the kernel / X server requests, not by themselves. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer -- 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/1347289658.30263.387.camel@thor.local
Bug#675977: Andrew's patch fixes the issue but you need VMWare Workstation 9
Hi, Andrew's patch seems to fix the issue for me. Matteo, I couldn't get it to work after compiling and got it to work after doing the following: - Upgrade from VMWare Workstation 7 to workstation 9 (alternatively use Player 5) - Installed libgl1-mesa-dri-experimental (might not be needed - I did this and the above at the same time) 3D acceleration is working nicely now!
Bug#686971: [radeon] display unwantingly dimmed, dimming state leaking across VT switch
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
