Bug 314423

Summary:	no-screens auto configuration
Product:	[Plasma] KScreen	Reporter:	Aaron J. Seigo <aseigo>
Component:	common	Assignee:	Alex Fiestas <afiestas>
Status:	RESOLVED WAITINGFORINFO
Severity:	major	CC:	dvratil
Priority:	VHI
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	On-disk config matching the external monitor on the desk Another config (though not for the screens triggering the problem) Another config (though not for the screens triggering the problem)

Description Aaron J. Seigo 2013-02-04 14:01:20 UTC

It is apparently possible to put KScreen into a configuration where no screens are activated. Due to its learn-and-save-to-restore-later approach (which is generally good) this can quite easily leave on in a situation where screens simply can not be accessed.

(.. without going to a console)

This scenario occurred on my laptop when I disconnected the monitor on my desk from my laptop; after waiting a few seconds the internal screen did not come on. (I suspected the infamous Intel+xrandr events bug here ...) So I plugged the external monitor in and apparently KScreen had saved a new configuration in which neither monitor was on; although looking at the configuration file (attached) it appears that the external monitor should have been turned on. Upon moving the configuration files out of the way and trying again, KScreen once again turned on the external screen as expected and I was able to get back to a working internal screen.

Aside from why KScreen interpreted the settings the way it did, it should never be possible to put KScreen into a "no screens activated" configuration.

This was with kscreen at commit e6460db855d610f5e3a98c3a8408e775c8c2d24c and libkscreen at 0bbbd93ec9d25bd238768029ae2218f46869e2b7

Reproducible: Always

Comment 1 Aaron J. Seigo 2013-02-04 14:11:54 UTC

Created attachment 76904 [details]
On-disk config matching the external monitor on the desk

Comment 2 Aaron J. Seigo 2013-02-04 14:12:20 UTC

Created attachment 76905 [details]
Another config (though not for the screens triggering the problem)

Comment 3 Aaron J. Seigo 2013-02-04 14:12:33 UTC

Created attachment 76906 [details]
Another config (though not for the screens triggering the problem)

Comment 4 Alex Fiestas 2013-02-09 14:43:08 UTC

I can reproduce this bug, though it does not seem to be related with configurations.

Set priority at VHI, we can't screw people screens.

Comment 5 Alex Fiestas 2013-02-09 15:01:03 UTC

Git commit 09b7e1ccc1156aa671bf33d2db460a9c770811b4 by Àlex Fiestas.
Committed on 09/02/2013 at 15:57.
Pushed by afiestas into branch 'master'.

Check if the EDID is valid before using it

In the XRandR backend we are always returning an EDID object but it can
be invalid.

M  +2    -2    kded/serializer.cpp

http://commits.kde.org/kscreen/09b7e1ccc1156aa671bf33d2db460a9c770811b4

Comment 6 Alex Fiestas 2013-02-09 15:05:24 UTC

I'm quite confident that commit fixes it, but let's make sure of it.

Can you attach "kscreen-console output" and "xrandr --verbose" with your laptop connected to the laptop in your desk?

I want to check if your monitor has an EDID, if it does not then the commit should fix it, if it does then your bug is something else :p

Comment 7 Alex Fiestas 2013-02-24 13:50:46 UTC

Can you reproduce the bug with recent libkscreen/kscreen code?

Comment 8 Alex Fiestas 2013-03-28 17:21:08 UTC

Can you reproduce the bug with KScreen RC1/0.0.81 ?

Thanks !

Comment 9 Christoph Feck 2013-04-24 11:53:47 UTC

To further investigate this issue, KDE developers need the information requested in comment #6. If you can provide it, or need help with finding that information, please add a comment.

Comment 10 Alex Fiestas 2013-05-10 17:12:22 UTC

Setting it as resolved since I think we got this fixed and the bug has been quiet for quite few time.

If you can still reproduce you know the drill, reopen the bug :p

thanks !