Version: (using KDE 4.4.3) OS: Linux Installed from: Archlinux Packages Since updating to 4.4.3 yesterday, if I close my laptop lid, the screen turns off; but when I open the lid again, the screen refuses to turn back on, regardless of moving my mouse around or hitting keyboard keys. I have to quit to a console shell (the screen comes back on then, although goes black again if I then go back into X) and restart KDM.
- do you still see a pointer? - in case you're using desktop effects (compositing), does pressing alt+shift+f12 help? -> does it help to suspend compositing this way _before_ closing the lid?
(In reply to comment #1) > - do you still see a pointer? Nope. The screen is shut off, i.e. via dpms. > - in case you're using desktop effects (compositing), does pressing > alt+shift+f12 help? Haven't tried, because... > -> does it help to suspend compositing this way _before_ closing the lid? Nope. Tried disabling desktop effects entirely (via systemsettings) before closing the lid...no dice. (In fact, right now I'm running with them totally off and still hitting this.)
Just found out some additional info... If I go to a console and then back it *does* actually work -- I thought it didn't because I was expecting it to be on term 7 and it's on term 8 (not sure why). However, when I come back I have two prompts from KDE Daemon saying that the monitor configuration has changed -- the first one saying that a monitor has been disconnected, and the second one saying that a monitor has been reconnected.
... great, means i can delete my loooong list of mid-air questions ;-) The X11 Device/Monitor gets lost during the suspension and is not sucessfully readded on wakeup w/o a VT change, should be an Xorg or driver issue (maybe kephal, but unlikely kwin) -> reassigning to kephal, as there's probably more experience/insight You could try to deactivate the randr kded module (kcmshell4 kcmkded, "Detecting RANDR...") or statically configure the device in /etc/X11/xorg.conf (if there isn't one so far) logout, go to VT1, "telinit 3", "sudo X -configure", move the output to /etc/X11/xorg.conf, "telinit 5" please post your HW info (gpu/driver, maybe notebook model)
What kind of packages do you use KDEmod? Or extra? which architecture? i686 or x86_64?
I didn't say suspension. I said closing the laptop lid. There is no suspend going on. Using kdemod packages on x86_64. FWIW, now plasma-dekstop also crashes when this happens.
Well I would like to add to this tracker with my information. I am experiencing the same thing with kdemod in Arch Linux x86_64. Plasma workspace crashes when the lid is closed. I normally have suspend to RAM enabled when lid is closed, but I disabled for testing. It also crashes when on AC (so no suspend occurs normally in this case) When I reopen the lid I see the display settings screen with all of the outputs greyed out. I tried clicking 'detect displays' and nothing happens. I've tried switching to tty1 (ctrl+alt+f1) and back, restarting compositing, disabling compositing in system settings. This doesn't happen in fluxbox, and I have a script that launches fluxbox on a second X server for gaming: xinit /usr/bin/startfluxbox -- :1 If I have this second X server running and close the lid, plasma crashes but X doesn't. As far as packages installed, here is the pastebin of: sudo pacman -Q http://pastebin.com/VpPVw5DA Here is lspci: http://pastebin.com/CWcHZxDk I'm running all of the latest packages and kernel, with no testing repositories. For kdemod I'm running kdemod-extragear and kdemod-core for repos. Here is a screenshot of what I see when I get back from a closed lid: [URL=http://img94.imageshack.us/i/displayhr.jpg/][IMG]http://img94.imageshack.us/img94/2656/displayhr.jpg[/IMG][/URL]
I also failed to mention that I don't use kdm, I boot to CLI and startx.
There is a thread about this in the chakra forum: http://www.chakra-project.org/bbs/viewtopic.php?pid=17758 I'm having a similar problem. KDEmod, too. x86_64, too. My KDE session including Xorg vanishes as I close the lid. I set power devil to lock the screen in that case. Usually it ends up with a text screen with blinking cursor in the upper left corner. Locking screen via menu works fine. Problems arise just when I close the lid. Seems like it could be related to the Intel 4500MHD chipset.
Yes I started a thread there as well, and my chipset is also a 4500MHD.
I don't have power devil set to manage power (kept doing wonky things with dimming my display). My chipset is Intel, X3100 (i965).
The same happens here, Archlinux vanilla KDE packages, also 4500MHD chipset.
so "close the lid" is just like "xset dpms force off" for everyone and this causes either: a) unability to reset dpms to "on" by pointer movement or kbd input b) plasma-desktop crashes (but kwin keeps running, shots from Lee) c) apparently Xorg crashes (Franks notion about the blinking cursor) It also only happens on the lid close, not by using the screenlocker menuentry, nor by eg calling "xset dpms force off"
...send too fast... Could it be some HAL event? Does anybody encountering this issue have a configured /etc/X11/xorg.conf? What if you prevent the powerdevil intervention? (don't attempt to dpms/lock screen at all)
So, I tried something: 1. "xset dpms force off" is working ok 2. set power devil to "do nothing" and closed my lid. As I open it again I have a screen without backlight. Doesn't matter how much I move my trackpoint or which key I press. I can switch to tty1 and back to tty8, tough and get a login prompt on tty1 and a slightly scrambled sceen on tty8. In the middle of tty8 there is a screen unplugged window - as far as I can read it. Font is scrambled, window just one button without anything on it. I closed it with the x. Plasma desktop has graphic issues in taskbar and on parts of the widgets on the screen. There are a couple of thing I have seen always with this: in /var/log/Xorg.0.log I have messages a lot of these: (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Input/output error once this: (WW) intel(0): i830_uxa_pixmap_swap_bo_with_image: bo map failed Seems like they occur on VT switch. In ~/.xsession-errors I have messages, that kglobalaccel unregisters all hotkeys and reregisters again. This a couple (> 10) of times. I do have an /etc/X11/xorg.conf, but its just those lines: Section "Device" Identifier "Card0" Driver "intel" Option "XvMC" "true" EndSection So it seems like it is not Power Devils fault - when Power Devil really does nothing....
Another note: Looked in /var/log/everything.log and saw this: May 10 17:39:47 stars kernel: [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung May 10 17:39:47 stars kernel: render error detected, EIR: 0x00000000 May 10 17:39:47 stars kernel: [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 1452218 at 1452217)
Created attachment 43441 [details] .xsession-errors just login and close the lid After some investigation I removed laptop-mode-tools, as they were triggered in /etc/acpi/events/*lid*, and now everytime I close my lid and open it again, I have a nice kdm login screen after pressing a button. Tried with powerdevil set to "lock screen" and "do nothing". Whished I could try another kernel, but kernel26-lts won't let me mount my encrypted LVM2 partition for some reason.
"xset dpms force off" works fine for me -- moving the mouse brings the display back. I also have PowerDevil display handling disabled, as it liked to dim my screen to lowest setting at arbitrary and annoying times. So it isn't (shouldn't be) PowerDevil's fault.
(In reply to comment #17) > Created an attachment (id=43441) [details] > .xsession-errors just login and close the lid > > After some investigation I removed laptop-mode-tools, as they were triggered in > /etc/acpi/events/*lid*, and now everytime I close my lid and open it again, I > have a nice kdm login screen after pressing a button. > > Tried with powerdevil set to "lock screen" and "do nothing". Whished I could > try another kernel, but kernel26-lts won't let me mount my encrypted LVM2 > partition for some reason. I also have laptop-mode-tools installed......however I don't want to remove the package entirely. I'm going to see about disabling that action and see what happens.
(In reply to comment #19) > I also have laptop-mode-tools installed......however I don't want to remove the > package entirely. I'm going to see about disabling that action and see what > happens. Just to be clear about this: laptop-mode-tools just trigger something, but its not their fault. And as I said, I have a login screen after open the lid, so my KDE session just vanishes...
(In reply to comment #20) > not their fault. And as I said, I have a login screen after open the lid, so my > KDE session just vanishes... That means "X crashed" (kdm catches the process death and restarts its GUI - and a new XServer in doubt) -> compare the X PIDs nex time you encounter this (meaning to store the original X PID everytime ;-) @Frank (and anybody else) Please try to deactivate the RandR kded module ("kcmshell4 kcmkded") as the attached .xsession-errors note: a randr event -> rebuildscreens -> a lot of trouble (look out for "kdeinit4: exit", sighups, fatals)
(In reply to comment #20) > (In reply to comment #19) > > I also have laptop-mode-tools installed......however I don't want to remove the > > package entirely. I'm going to see about disabling that action and see what > > happens. > > Just to be clear about this: laptop-mode-tools just trigger something, but its > not their fault. And as I said, I have a login screen after open the lid, so my > KDE session just vanishes... I see what you mean. I removed laptop-mode-tools to test and I get the same results, most likely because I don't use KDM. I use startx.
(In reply to comment #21) > Please try to deactivate the RandR kded module ("kcmshell4 kcmkded") as the That seems to help. No problem, even with "lock screen on close", yet.
(In reply to comment #23) > (In reply to comment #21) > > Please try to deactivate the RandR kded module ("kcmshell4 kcmkded") as the > > That seems to help. No problem, even with "lock screen on close", yet. (In reply to comment #23) > (In reply to comment #21) > > Please try to deactivate the RandR kded module ("kcmshell4 kcmkded") as the > > That seems to help. No problem, even with "lock screen on close", yet. Same here, I somehow missed that and it is working now, suspend and all. Would this affect anything if I don't use multiple monitors?
Disabling the kded randr part fixed my issue, in the sense that now when I open my lid again the display works. It's certainly only a workaround though and not ideal -- when I close my lid now the screen does not turn off, and when I open my lid the screen turns off, then back on.
(In reply to comment #25) > Disabling the kded randr part fixed my issue, in the sense that now when I open > my lid again the display works. It's certainly only a workaround though and not > ideal -- when I close my lid now the screen does not turn off, and when I open > my lid the screen turns off, then back on. Really? The screen doesn't turn off...........I'll have to test mine with AC on. That's definitely not optimal. Maybe a laptopmode action script would fix that.
Looks like the screen turned off eventually (I don't have PowerDevil turned on so it wouldn't be using PD stuff to detect laptop lid closed). With the kded randr part in use, the screen turned off immediately but then had all the problems described above... Seems like everyone on this bug is running Arch packages? Are people running kdemod or regular?
(In reply to comment #27) > Looks like the screen turned off eventually (I don't have PowerDevil turned on > so it wouldn't be using PD stuff to detect laptop lid closed). With the kded > randr part in use, the screen turned off immediately but then had all the > problems described above... > > Seems like everyone on this bug is running Arch packages? Are people running > kdemod or regular? I'm running kdemod on Arch x86_64. Additionally my screen turns off immediately when I close the lid. I have powerdevil enabled in system settings/power management for system and screen.
(In reply to comment #27) > Seems like everyone on this bug is running Arch packages? Are people running > kdemod or regular? KDEmod x86_64, for me, too. #12 seems to run extra.
Yes, I'm running extra packages
My encouragement to get this fixed. Please vote for this bug! It deserves to be a higher priority/severity, there are many Intel graphic chipsets out there... It's a showstopper for me as I'm using multiple monitors. Remaining on 4.4.2. Thanks.
(In reply to comment #25) > Disabling the kded randr part fixed my issue, in the sense that now when I open > my lid again the display works. It's certainly only a workaround though and not > ideal -- when I close my lid now the screen does not turn off, and when I open > my lid the screen turns off, then back on. <Disclaimer>I've no idea how this is supposed to work</Disclamer>, but i'd say if you don't want to change screens by closing the lid, PowerDevil is the tool of your choice (to trigger dpms off when the lid is closed). If you use multiple monitors dynamically there should be some configuration on what to do on lid events (dpms or some randr event. likely not both) @Francois Does the problem occur with a second monitor attached as well and what happens as result? (i.e. eg. "X crashes - on both monitors of course") And what would be the supposed behaviour (internal display off, monitor on?)
Can anyone tell us what happens with an external monitor when this bug happens? @Thomas: sorry but when I saw other arch linuxers having pb with 4.4.3 and seeing this bug, I just did not upgrade yet, still on 4.4.2. My words were for encouragement and getting people to vote for this bug (was the first one to vote on it).
(In reply to comment #32) > <Disclaimer>I've no idea how this is supposed to work</Disclamer>, but i'd say > if you don't want to change screens by closing the lid, PowerDevil is the tool > of your choice (to trigger dpms off when the lid is closed). Maybe, if PowerDevil didn't have a habit of randomly dimming my screen to min brightness and not ramping it back up, and not actually effectively switching back to performance profiles when e.g. I plug in a power cord. IOW, if it worked. It's super flexible, but reliable it ain't.
(In reply to comment #33) > Can anyone tell us what happens with an external monitor when this bug happens? > > @Thomas: sorry but when I saw other arch linuxers having pb with 4.4.3 and > seeing this bug, I just did not upgrade yet, still on 4.4.2. My words were for > encouragement and getting people to vote for this bug (was the first one to > vote on it). I hooked my laptop up to my westinghouse monitor via HDMI and the results were different almost every time. I had it set to clone the laptop's screen with each screen's native resolution (1920x1080 external, 1366x768 laptop). However since it's set to clone it looks like the laptop screen just cuts off it's res from the larger one, so the task bar and kicker aren't showing at the bottom. I re-enabled randr monitoring as well. Here are some of the results: Close the lid: the external remains normal and the laptop goes black. the hdmi goes black and the laptop retains the cropped screen. hdmi goes black and the laptop returns to native res both screens go black and I have to kill KDE and X by pressing ctrl+alt+F1 and ctrl+c. Each time I closed the lid all of the options went grey but the HDMI. Really strange and random. I tried to develop a pattern by closing the lid repeatedly, but it never stuck to a certain result.
I went ahead and upgraded to 4.4.3 hoping to get lucky (compared to the number of 4500MHD out there, not so many people complain here). I did get lucky: no black screen when returning from suspend. However I get a couple popups telling me a monitor change has been detected, and all windows were reduced to a tiny size, as if my screen was minuscule. This happened consistently when running disconnected from the main and any external monitor (otherwise closing my lid just locks the screen). Once I got a black screen but the mouse was visible and moving, so I managed to restart X with cli. I have now disabled kde monitor change detection (krandr service), waiting for a fix...
(In reply to comment #36) > However I get a couple popups telling me a monitor change has been detected, > and all windows were reduced to a tiny size, as if my screen was minuscule. > This happened consistently when running disconnected from the main and any > external monitor (otherwise closing my lid just locks the screen). I have almost the same issue on 4.4.4 - firefox window is tiny (others seem ok), plasma-desktop is missing after opening lid, kwin sometimes crash. And BOTH locking screen on close and "Detecting RANDR" are OFF. When locking is enabled there is just black screen and I always need to re-run kwin with --replace option in tty. It is Intel GM965/GL960.
Now I also get the black screen returning from standby, and monitor change krandr service was disabled. Intel 4500MHD, Arch linux 64, KDE 4.4.4
I just updated to 4.4.4-1 yesterday on Arch. I'll go ahead and enable the RANDR option and see what happens. Arch x86_64 with kdemod here, no testing repos. Just to reiterate the lid close action works fine now when aforementioned RANDR option is disabled.
Actually this bug is not related to suspend/resume in my case. While my laptop was connected to the main I closed the lid and reopened it a few hours later. Black screen, but can still go to virtual console. The computer did not go into standy or hibernate. I killed x server anyway. This is very frustrating. This happened when not connected to an external monitor, and I seems to not happen when connected to external monitor in my case (have to validate this with further test). In any case I attach my xorg.log if anyone is interested.
Hmm, sorry I can't attach my log file: Software error: CGI parsing error: 400 Bad request (malformed multipart POST) at Bugzilla/CGI.pm line 108. For help, please send mail to the webmaster (sysadmin@kde.org), giving this error message and the time and date of the error.
Created attachment 48087 [details] xorg.log until I killed x because of black screen
On my machine I now confirm this bug is not happening when connected to an external monitor. I can reproduce it by closing and then opening the laptop lid. It does not matter if the system is configured to suspend when closing the lid (it's not in my case). So probably this bug has more to do with returning from power saving (when the screen turns back on). I'm open to suggestions on how to further diagnose this issue...
(In reply to comment #43) > On my machine I now confirm this bug is not happening when connected to an > external monitor. I can reproduce it by closing and then opening the laptop > lid. It does not matter if the system is configured to suspend when closing the > lid (it's not in my case). So probably this bug has more to do with returning > from power saving (when the screen turns back on). I'm open to suggestions on > how to further diagnose this issue... By power saving I assume you mean DPMS. For me at least, there is no suspend or hibernate going on.
> (In reply to comment #44) > By power saving I assume you mean DPMS. For me at least, there is no suspend or > hibernate going on. Probably yes: http://en.wikipedia.org/wiki/VESA_Display_Power_Management_Signaling
What does "probably yes" mean? Don't you know what you meant when you said "returning from power saving"?
I certainly know what I mean when I say "power saving". Whether it matches your understanding, I don't know. If you translate it as DPMS, you're probably right. It's not about suspending or hibernating, so DPMS sounds right.
Hi, I had the same problem, but it seems to have gone away in 4.4.5. Was it fixed? Or am I just lucky?
I'm also good with the latest update, no more black screen. It's not kde 4.4.5, I noticed it got better since the last xorg + intel driver update about 3 weeks ago or so.
Confirmed, it works for me, too.
due to last three comments setting this bug to fixed. If it is still an issue for someone in 4.5 please reopen.