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
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://galle
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 sessi
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 stay
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 coincide
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
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
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
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
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 one
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
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.
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
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 seve
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 s
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
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).
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
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
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/R60
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 h
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]
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: sque
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, t
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 gnom
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?
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
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,
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
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-ttcidf
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-ttcidf
31 matches
Mail list logo
