Bug 239873 - Dual head setting ignored on login
Summary: Dual head setting ignored on login
Status: RESOLVED DUPLICATE of bug 183143
Alias: None
Product: kde
Classification: I don't know
Component: dualhead (show other bugs)
Version: unspecified
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-28 16:48 UTC by thoth
Modified: 2010-05-29 05:42 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description thoth 2010-05-28 16:48:55 UTC
Version:           unspecified (using KDE 4.4.3) 
OS:                Linux

When an external monitor is connected to a Thinkpad T60 and the user uses System Settings -> Display to disable either internal or external monitor, the setting is not saved across logout/relogin.

Reproducible: Always

Steps to Reproduce:
1. Connect external monitor and boot laptop.
2. Log into KDE.
3. Open System Settings -> Display (both displays detected and active).
4. Disable either display; save changes.
5. Log out and log back in.

Actual Results:  
Sometimes: both displays on again after login, despite changes.
Other times: one display "off", but mouse still movable to "dark" display and listed desktop width the size of both displays, not single display.

Expected Results:  
Disabled display remains dark; mouse not able to move "onto" that display; desktop width the size of single remaining display.

Current workaround: start KDE from $HOME/.xsession, which contains calls to xrandr. For example:

xrandr --output VGA --off
startkde

When this is done, KDE correctly ignores the disable display and does not include the display in desktop width.

ADDITIONAL BUG: When this workaround is used, starting System Settings -> Display in the KDE session will cause ALL SCREENS to go permanently dark until Xorg is manually killed/restarted from a virtual console.
Comment 1 Christoph Feck 2010-05-29 05:42:23 UTC

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