Bug#932892: libwayland-server0: wayland crashes when I (un)plug a monitor
Package: libwayland-server0 Version: 1.17.0-1 Severity: normal Dear Maintainer, when I plug or unplug a monitor, my desktop session crashes and I'm back at the gdm login screen. If I do the same when at the gdm login screen, it disappears and doesn't come back. Then I have to restart the pc. I have errors in syslog: gnome-shell[4078]: segfault at ?? ip sp error 4 in libwayland-server.so.0.1.0[?+7000] I have several errors since I tried multiple combinations, so I replaced the non constant parts of the error with ??. There are probably things that I can do to have better error messages, but you'll have to guide me :-) I'm now using gnome on Xorg, which doesn't crash, so the problem is with wayland. Thanks a lot, -- Rémi -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libwayland-server0 depends on: ii libc62.28-10 ii libffi6 3.2.1-9 libwayland-server0 recommends no packages. libwayland-server0 suggests no packages. -- no debconf information
Bug#901604: xwayland: reliably crashes the system when opening certain pages in firefox
Package: xwayland Version: 2:1.20.0-2 Severity: normal Dear Maintainer, when I open certain pages in firefox, the Xwayland process goes to 100% CPU time, the firefox window becomes unresponsive, and trying to switch to another window hangs the complete system. example web pages: https://gallery.technet.microsoft.com/scriptcenter/Reset-Windows-Update-Agent-d824badc http://www.companyweb.be/gratisbtwopzoeken_recherchertvagratuit.asp This happens even if I open the web pages in new tabs, without displaying the tab. It could be related to the shortcut icon, since wayland hangs before the icon is displayed in the tab bar. This happens under the default gnome session, but not with gnome on xorg, so I have an easy fallback solution. Please don't hesitate to ask for more info or tests, I have no idea how to debug such a crash, but I can follow instructions :-) Thanks for your work, -- Rémi -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xwayland depends on: ii libaudit1 1:2.8.3-1 ii libbsd0 0.9.1-1 ii libc6 2.27-3 ii libdrm2 2.4.92-1 ii libegl1 1.0.0+git20180308-3 ii libepoxy0 1.4.3-1 ii libgbm1 18.1.1-1 ii libgcrypt20 1.8.3-1 ii libgl1 1.0.0+git20180308-3 ii libpixman-1-0 0.34.0-2 ii libselinux1 2.8-1 ii libsystemd0 238-5 ii libwayland-client0 1.15.0-2 ii libxau6 1:1.0.8-1+b2 ii libxdmcp6 1:1.1.2-3 ii libxfont2 1:2.0.3-1 ii libxshmfence1 1.3-1 ii xserver-common 2:1.20.0-2 xwayland recommends no packages. xwayland suggests no packages. -- no debconf information
Bug#657440: xkb-data: cannot switch between two kb layout in gnome
Hi Le 26/01/12 12:11, Cyril Brulebois a écrit : I'm not sure if Gnome interferes here. Feel free to open a bare session (http://x.debian.net/faq/general.html) and play with setxkbmap to see whether the layout is fucked up, or if the layout switcher in gnome is buggy. I launched a bare X session as requested, and there setxkbmap works perfectly. So I guess it's an interraction between xkb-data and the layout switcher in gnome, but I don't know which one is buggy. Please note as additionnal information that if I put the be layout as default in gnome and restart my session, I have no problem anymore in the layout switcher: it works fine directly after login, and the layouts are not inverted when I choose them. Anyway, feel free to report your findings on an upstream bug (https://bugs.freedesktop.org/ product xkeyboard-config) and let us know about the URL for tracking. I'm not sure xkeyboard-config is the real culprit as setxkbmap works fine. I would even say that the gnome layout switcher is now a more compelling suspect :-) What can I do to diagnose this further ? 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/4f255127.7040...@poukram.net
Bug#657440: xkb-data: cannot switch between two kb layout in gnome
Package: xkb-data Version: 2.5-1 Severity: normal Dear Maintainer, I upgraded my sid system, and xkb-data was upgraded to 2.5-1. Normaly, my X configuration is azerty Belgian at the time of gdm, and switches to French bépo (façon dvorak) once in gnome. After upgrading xkb-data, the layout stays Belgian even after login. Gnome's keyboard applet says fr, and the bépo layout it selected in the menu if I expand it, but the real used layout is Belgian. More than that, I can't select the other option in the keyboard applet. Now if I open keyboard parameters and change the order of the layouts (that is make Belgian first in the list), I can use the menu to switch layouts again. If I change the orders again, I can still switch but the layouts are inverted: selecting be gets me bépo, and fr gets me be... Reverting to xkb-data 2.3-2 from testing fixes everything. Thanks a lot, don't hesitate to ask for more info or tests. -- Rémi -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=fr_BE.utf8, LC_CTYPE=fr_BE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20120126112017.9571.2639.report...@sphax.lybrafox.lan
Bug#570466: it's been a month, is this still a problem?
Le 22/02/11 23:35, Alex Deucher a écrit : 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. I have been on 2.6.38 for 4 days without a single blackout. This could still be a coincidence (it happened before), but that would be quite a big one. So unless you need other info, I propose that this bug be closed for now, if the blackouts come back I can still reopen it. For information, right now I have kernel 2.6.38 from experimental, mesa 7.10-4 with R600g, libdrm 2.4.23-3, and xorg radeon driver 1:6.14.0-1. 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/4d6d17f0.5080...@poukram.net
Bug#570466: it's been a month, is this still a problem?
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 ? 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/4d642faa.5010...@poukram.net
Bug#569778: is this still an issue?
Le 21/02/11 18:58, Cyril Brulebois a écrit : Hi Rémi, Rémi Letot (15/04/2010): Now I must say that I haven't tested this much further since the focus seems to be on kms, which I always use nowadays. I can of course temporarily switch back to non kms mode for testing when needed, but since this is bound to impact my usage for quite some time, please ask for that only when non kms testing is relevant (which might be now, just say so) if I got it right, you're mainly using KMS, but willing to test UMS if we need that? In which case, I'd say we're done with this issue since it's no longer affecting you, and I'm tempted to close this bug report. If somebody *has* to use UMS for whatever reason, a new bug report is welcome. Does that look like a plan? KiBi. ok for me 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/4d639f10.8010...@poukram.net
Bug#570466: it's been a month, is this still a problem?
Le 18/10/10 17:30, Alex Deucher a écrit : On Wed, Oct 13, 2010 at 3:28 PM, Rémi Letot wrote: 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? 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... 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 I'll try to build that and use it at my next reboot. 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/4cc6b0e0.5060...@poukram.net
Bug#570466: it's been a month, is this still a problem?
Le 18/10/10 17:30, Alex Deucher a écrit : Does booting with radeon.new_pll=0 help? I cold rebooted with this option shortly after your mail, meaning more than 40 hours ago, and to date I have not experienced the problem at all. This is still no complete proof since I have randomly had long periods (like more than a week) in the past without the problem, but if it's a coincidence it is a strong one. I'll report back if the problem resurfaces. I'll also try the 2.6.32 kernel with this option at my next reboot. 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 argh, is there a documented process to build a debian package from this? HTH, -- 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/4cbed820.7000...@poukram.net
Bug#570466: it's been a month, is this still a problem?
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. HTH, -- 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/4cb60866.1050...@poukram.net
Bug#596012: some more info
Hello, I too have been hit by this. I use the radeon driver too, but others with intel cards have been hit (see 595973 and 595776). The trigger is compiz (or probably any compositing manager), and a switch from console to X. I can run compiz without any problem, provided that I don't switch to console. When I do, the only way to recover my display is to restart X. Even blindly switching to metacity doesn't help. When I trigger that bug, I get a black screen, or a screen covered by my background image. Windows are invisible, but reactive (my mouse pointer reacts, and I can interract with windows). One strange thing: if I start an X session with metacity, then switch to console and back to X, all works fine. Except starting compiz after that triggers the bug. So compiz does not have to be the active window manager when the "console->X" switch occurs to trigger the bug. Going back to xserver-xorg-core_1.7.7-4 fixes everything. 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/4c874898.8010...@poukram.net
Bug#595973: same as 596012
Hello, I too has been bitten by this. I think that this is the same as 596012: resuming actually first goes to console, then to X, which triggers the bug. 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/4c874506.30...@poukram.net
Bug#595776: same as 596012 and 595973
Hello, it's not obvious for a non developper like me to know that such similarly named packages are not part of the same source. Anyway your remark helped me narrow this down on my system. I think that this bug is actually the same as 596012 and 595973. See 596012 which is the most specific : resuming from suspend actually goes first to console, then to X, which stays black because it comes from console. The real trigger is the switch from console to X. I'll add more information there. 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/4c874466.5080...@poukram.net
Bug#570466: no change with kernel 2.6.34
Hello, I upgraded my kernel to 2.6.34 from experimental, which didn't change anything. However I noted something which might be of interrest : my laptop blacks out several times during the few hours after I cold boot it. Each time I get it back with a "s2ram && powerup" cycle. But after several such blackouts, the blackouts tend to be less frequent, and finally do not happen anymore. Right now my uptime is almost 10 days, and I have worked several days without a single blackout. HTH, -- 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/4c091da5.2090...@poukram.net
Bug#570466: still there with all latest
Hello, just to report that the situation has not evolved with all latest related packages from experimental : - kernel 2.6.33-1~experimental.4 - libdrm2 2.4.20-2 - radeon 1:6.13.0-1 - mesa 7.8.1-1 Still a few rare random blackouts, during which the machine stays fully functionnal, just the screen goes black. The only way to get my screen back is a reboot or (s2ram && powerup), and to my knowledge I have nothing strange in syslog or xorg.log. I'll track updates to sid or experimental and report any change as soon as it occurs. 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/4bde8ecf.4040...@poukram.net
Bug#569778: is this still an issue?
Hello, I think that this is related to 570466, the only difference is that without kms I am able to revive the screen by switching to a VT and back to X. Now I must say that I haven't tested this much further since the focus seems to be on kms, which I always use nowadays. I can of course temporarily switch back to non kms mode for testing when needed, but since this is bound to impact my usage for quite some time, please ask for that only when non kms testing is relevant (which might be now, just say so) Tanks, -- 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/4bc77d92.2040...@poukram.net
Bug#570466: it's been a month, is this still a problem?
Hello, yes this is still a problem with all latest packages. But I noticed a drastic drop in the frequency of the blackouts since I upgraded to kernel 2.6.33-1~experimental.4. To the point where I can now use my laptop in kms mode without too much problem (I have had days without a blackout). I also found out that by putting my laptop to sleep and waking it up I can revive my screen, so even the occasionnal blackout is not such a problem anymore. 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/4bc775bf@poukram.net
Bug#570466: not fixed after all
Hello, the stability of my laptop was apparently due to a missing firmware file (R600_rlc.bin), which prevented DRI2 to work. Now that I have that file back (I also upgraded to latest 2.6.33 kernel from experimental), I have problems again with KMS/DRI2. However the problem evolved, as my laptop does not completely crash anymore. Only the screen randomly turns blank and doesn't come back. For example, I can still switch to a VT. The screen somehow flickers but remains blank, but I can blindly login and issue commands or reboot. I suspect that my X session is still useable, but of course without knowing where my pointer is, it's quite complicated to prove :-) I logged in through ssh, and X is no longer using 100% CPU. I have no error in syslog or the Xorg log, so it seems that the beast is blind but didn't notice anything unusual. Tell me if I can help further. 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/4b943788.4010...@poukram.net
Bug#570466: xserver-xorg-video-radeon: randomly hangs when using kms/dri2
Michel Dänzer a écrit : > On Fri, 2010-02-26 at 11:17 +0100, Rémi Letot wrote: >> As there is never too much info, here is how I get kms (I might do >> something wrong) : I boot without X (which loads radeon without kms), >> login as root, modprobe -r radeon drm, modprobe radeon modeset=1, and >> then only start gdm. Maybe the system would react differently if radeon >> was loaded directly with kms enabled, but I don't know how to >> selectively achieve that at boot time. > > You can pass > > radeon.modeset=1 > > on the kernel command line. Almost too easy... So I tried with kms right from the boot, and it didn't change anything. Same complete crash with black screen after some random time. Don't know if it helps, but to know if the crashes also happen without X, I'll leave the laptop boot to console with kms and stay there. This will have to wait for tonight (after work) so I can leave it on console long enough. 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/4b87b9e6.9040...@poukram.net
Bug#570466: xserver-xorg-video-radeon: randomly hangs when using kms/dri2
Brice Goglin a écrit : > > Can you try with a 2.6.33-rc kernel ? Ok, sorry for the delay but this is quite high voodoo for me :-) I recompiled 2.6.33-rc8 with latest svn.debian.org patches, found and downloaded a missing firmware file here : http://people.freedesktop.org/~agd5f/radeon_ucode/R600_rlc.bin Now the symptom is different : the screen goes black, the system is unreachable on the network (even ping), and my harddrive completely stops moving. Which indicates a complete crash, not only the X part. As the system is completely crashed, I have nothing in syslog. Of course I can't be sure that the cause is the same because it is completely random and the symptom is different, but the frequency of the crashes is very similar. And it still works fine (but without dri2) without kms. By the way I have other problems with 2.6.33 and kms that are not present with 2.6.32 : my second screen never lights up (it does receive a signal, and is configurable in the gnome screen configuration panel, but it stays black), and there are artifacts in the titlebars of windows under gnome-shell (not in metacity). In the meantime I upgraded mesa to 7.7-4, but it still crashes. As there is never too much info, here is how I get kms (I might do something wrong) : I boot without X (which loads radeon without kms), login as root, modprobe -r radeon drm, modprobe radeon modeset=1, and then only start gdm. Maybe the system would react differently if radeon was loaded directly with kms enabled, but I don't know how to selectively achieve that at boot time. > By the way, your bug reports seem to have always the same wrongly > formatted From: line. Yes I just noticed this, it must come from the mail configuration on my laptop, but I already had a look and have absolutely no idea where it comes from. I'll investigate asap... 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/4b879fa0.4070...@poukram.net
Bug#570466: xserver-xorg-video-radeon: randomly hangs when using kms/dri2
Michel Dänzer a écrit : > FWIW, gnome-shell itself should work without DRI2 if started like > > LIBGL_ALWAYS_INDIRECT=1 gnome-shell > > but the output of OpenGL apps won't be properly integrated with the > compositing. > Hello, just tried it, but even with "LIBGL_ALWAYS_INDIRECT=1" I'm still hit by #564950 and #561206. 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/4b7f0d78.9040...@poukram.net
Bug#569778: probably not sleep related after all
Hello, just got it while using the laptop, so it might not be sleep related after all. It happened exactly six minutes after waking up my laptop from suspend to ram. I have the first messages in syslog at 18:03:06, and got this when it happened : Feb 14 18:09:06 sphax kernel: [37354.924381] [drm] Resetting GPU Feb 14 18:09:08 sphax acpid: client 2897[0:0] has disconnected Feb 14 18:09:09 sphax acpid: client connected from 2897[0:0] Feb 14 18:09:09 sphax acpid: 1 client rule loaded Feb 14 18:09:10 sphax kernel: [37358.362808] [drm] Resetting GPU I'll report if I can find other things. 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/4b783192.9010...@poukram.net
Bug#515734: libxi6: works by configuring hal properly
Package: libxi6 Version: 2:1.2.1-2 Severity: normal I just updated xorg on a sid box, and suffered from this problem in gdm and gnome. I created a file in /etc/hal/fdi/policy as suggested by Julien Valroff to configure X, and this solved the problem. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libxi6 depends on: ii libc6 2.9-6 GNU C Library: Shared libraries ii libx11-6 2:1.2.1-1 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar libxi6 recommends no packages. libxi6 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
Bug#394349: compiz: some windows are unaffected
Michel Dänzer a écrit : Did a killall compiz.real, which restarts it. The behaviour is the same as before : the first terminal is ok, the second one is sluggish. Note how both windows were created before the second compiz instance started, which contradicts your theory. Not really, this latest procedure just proves that the second window's bad behaviour survives a change of "managing compiz" (please forgive my "less-than-optimum" vocabulary). The first window already behaved nicely even under compiz. More important, the first window was still created out of compiz, the second one in compiz, which is the only difference that I can see between the two. I am really not an expert in development, even less in graphics development, but the only explanation that I can see is that compiz initializes or configures something differently than metacity. Or maybe it is the other way : maybe gnome-terminal initializes something differently when under compiz (although I don't know if gnome-terminal is aware of the window manager). Which program creates that difference I don't know, but it leads to a working or broken behaviour. Maybe this is linked to a poorly designed or even broken driver, maybe not. But the good behaviour of the first window, even after multiple compiz restarts proves that it *can* work right. Again, if you think that it's not worth debugging, especially because of the closed driver, just leave it closed. Or better yet, split it from the original bug report (after all I think it's clearly another issue) and tag it "won't fix", after all this is just a corner case of one specific application and a closed driver which doesn't come from debian. But that way it's clearly documented, and I can report whatever I find with future versions of the involved programs. Thanks, -- Rémi
Bug#394349: compiz: some windows are unaffected
Michel Dänzer a écrit : I thought of something that might explain the mystery: Do you happen to have transparent background enabled in gnome-terminal? Nope, the original configuration, I didn't change anything from the default config. How is the resize performance of the two kinds of gnome-terminal windows after you kill and restart compiz? Did a killall compiz.real, which restarts it. The behaviour is the same as before : the first terminal is ok, the second one is sluggish. I also tried to restart gtk-window-decorator which didn't change anything. Thanks, -- Rémi
Bug#394349: compiz: some windows are unaffected
Michel Dänzer a écrit :
All these windows cohexist in a single X session, so I don't think that
it's related to the way the Nvidia driver behaves. Compiz must do
something to the terminal windows it creates that metacity doesn't do,
the trick is to find that difference :-)
'Must do' why? I don't see anything that would follow from.
English is not my mother tongue, so maybe the tone is not right and
"must do" is too categoric, but to answer your question : because
gnome-terminal windows started before compiz are not affected, they
behave quite normally under compiz on the same display at the same time.
Procedure : I start gnome with metacity, then a gnome-terminal window,
then compiz ("compiz --replace" in that terminal for example), then
start another gnome-terminal. Both gnome-terminals are on the same
screen at the same time with compiz, but behave very differently. The
first one, launched before compiz, is free of any problem. The second
one, launched after compiz, freezes my desktop for 2 seconds everytime I
resize it.
Maybe this is related to the driver, but the problem-free behaviour of
the first terminal, even under compiz, proves that compiz can handle
them well.
Now I tested other terminals (xterm and Eterm), and none of them
displays the problematic behaviour. There is definitely something
strange at work between compiz, the nvidia proprietary driver, and
gnome-terminal. Compiz could handle it well, but wether it's worth
investigating is totally up to you, I have a replacement solution for
the moment and I won't bug you anymore :-)
I'll probably investigate the problem when any of the three contenders
is updated to see if it's solved and report here if this is the case.
Thanks for your work,
--
Rémi
Bug#394349: compiz: some windows are unaffected
Brice Goglin a écrit : Yes, that's strange. But the initial reporter did not complain about this, so it could just be nVidia related problem. We don't know at all what the nvidia-glx binary driver does for Compiz, so it's impossible to debug this here. Yep this could be completely unrelated to what the original reporter experienced. But IMHO the fact that terminal windows created before compiz is launched don't suffer from the slowdown proves that compiz *can* handle terminal windows very well on Nvidia hardware. All these windows cohexist in a single X session, so I don't think that it's related to the way the Nvidia driver behaves. Compiz must do something to the terminal windows it creates that metacity doesn't do, the trick is to find that difference :-) If you think (as I do now) that this is not related to what the original reporter experienced, don't hesitate to split the bug. Thanks, -- Rémi
Bug#394349: compiz: some windows are unaffected
Hello, thanks for your answer. I use the nvidia driver on a 7600go, so no EXA here. Everything is uptodate to sid versions. Of course it could be a driver bug. But before closing the bug, don't you find the fact that windows started before compiz are unaffected a bit disturbing ? Thanks, -- Rémi begin:vcard fn;quoted-printable:R=C3=A9mi Letot n;quoted-printable:Letot;R=C3=A9mi email;internet:[EMAIL PROTECTED] tel;work:+32 81 66 55 00 version:2.1 end:vcard
Bug#394349: compiz: some windows are unaffected
Package: compiz Version: 0.5.2-2 Followup-For: Bug #394349 Hello, I just installed sid on my laptop and was bitten by this bug. But I have more info. First of all, gnome-terminal windows are much more affected than other applications. I do notice some slight slowdown for other apps, but gnome-terminal has a clear 2 seconds delay between the moment I move the border, and the moment it starts moving. After that delay the move is quite fast but seems to happen in multiple jerky steps instead of fluidly. During the delay everything freezes on my screen. Much more interresting : windows that I started before launching compiz are unaffected. I start gnome with metacity, create some windows (terminals are good candidates because it's so easy to spot), then start compiz --replace in a terminal. All those windows react normaly to resizing. But if I start another terminal it will be a hog to resize, and freeze my display while waiting. Maximizing displays the same behaviour. Pre-compiz terminals are ok, post-compiz terminals have a clear delay before maximizing. One more symptom in this case, the maximized terminal window is blank until I click on it. Ok, enough for tonight, don't hesitate to ask for more info or tests. Thanks for your great work, -- Rémi -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-686 (SMP w/2 CPU cores) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages compiz depends on: ii compiz-core 0.5.2-2+b1 OpenGL window and compositing mana ii compiz-gnome 0.5.2-2+b1 OpenGL window and compositing mana ii compiz-gtk0.5.2-2+b1 OpenGL window and compositing mana ii compiz-plugins0.5.2-2+b1 OpenGL window and compositing mana compiz recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#171750: xlibs: XftConfig doesn't map sans/serif/mono
The paths are better handled by defoma : dir "/usr/share/fonts/truetype/freefont" dir "/usr/share/fonts/truetype" can both be replaced by dir "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" I also have the following line : dir "/var/lib/defoma/x-ttcidfont-conf.d/dirs/CID" HTH, -- Rémi Letot
Bug#171750: xlibs: XftConfig doesn't map sans/serif/mono
The paths are better handled by defoma : dir "/usr/share/fonts/truetype/freefont" dir "/usr/share/fonts/truetype" can both be replaced by dir "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" I also have the following line : dir "/var/lib/defoma/x-ttcidfont-conf.d/dirs/CID" HTH, -- Rémi Letot -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
