Bug 346499

Summary:	kscreen does not restore configuration on startup
Product:	[Plasma] KScreen	Reporter:	Rafael Jesús Alcántara Pérez <rafaelalcantaraperez>
Component:	common	Assignee:	Daniel Vrátil <dvratil>
Status:	RESOLVED DUPLICATE
Severity:	major	CC:	jpalaciosdev
Priority:	NOR
Version:	5.2.95
Target Milestone:	---
Platform:	Kubuntu
OS:	Linux
Latest Commit:		Version Fixed In:

Description Rafael Jesús Alcántara Pérez 2015-04-23 07:38:30 UTC

On startup, the saved configuration is not loaded.
I have two monitors, a Dell and an Acer with different resolutions. Until the sddm login, the two monitors are cloned. But when I start my KDE session (I'm using now Kubuntu Vivid Vervet, but It behaves the same from the beginning of using kscreen), the Dell monitor takes its full resolution (as configured in kscreen) and the Acer gets blank (no signal). Every time I have to enter in the kscreen and enable the Acer monitor and configure it properly.

Reproducible: Always

Steps to Reproduce:
1. Starts the session.


Actual Results:  
The Acer monitor is disconnected (no signal)

Expected Results:  
The Acer monitor should change its resolution to the values set in the last time kscreen was configured.

Comment 1 Juan Palacios 2015-05-25 11:42:37 UTC

I have the same problem. I use two monitors: an older LG (VGA) and a new Benq (HDMI), both connected to the onboard cargs (intel HD4000).
I have it working right now, but not using kscreen at all and configuring the two monitors in xorg:
My /etc/X11/xorg.conf.d/20-monitors.conf:
Section "Monitor"
		Identifier  "HDMI1"
		Option      "Primary" "true"
EndSection

Section "Monitor"
		Identifier  "VGA1"
		Option      "RightOf" "HDMI1"
EndSection

Then i had to disable KScreen 2 service in System Settings- > Startup and Shutdown -> Service Manager.

Comment 2 Rafael Jesús Alcántara Pérez 2015-06-06 08:07:01 UTC

Finally, I'm using xrandr to do the job (arandr can create scripts that use xrandr to change the screen setup).

Comment 3 Rafael Jesús Alcántara Pérez 2015-06-07 11:05:58 UTC


*** This bug has been marked as a duplicate of bug 346961 ***