Mapping physical screens to KDE containments

[Duncan]

Felix Miata posted on Fri, 15 Apr 2016 00:49:22 -0400 as excerpted:

> Never having configured either a triple display setup, or multi with
> LVDS, I can only speculate that blocking kscreen control of display
> configuration could work as well as it does here with only two and no
> hotplugging. Put the following in ~/.config/kded5rc:
> 
> 	[Module-kscreen]
> 	autoload=false
> 
> Configuration entirely via xorg.conf, or alternatively, via xrandr in a
> startup script, is prerequisite to this working as desired.

I haven't tried it yet, but thanks for pointing me in this direction as 
it appears promising! =:^)

Just a couple points filling in additional detail, for those who may be 
interested.  Nothing critical.

1) The file in question should actually be by freedesktop.org directories 
spec $XDG_CONFIG_HOME/kded5rc, with the default location for the dir if 
that var isn't set being ~/.config, thus the default path you mentioned.

I have a dislike for hidden files I acquired way back last century on the 
MS side of things, after deleting an "empty" directory that wasn't so 
empty after all.  Of course there default visibility is controlled by the 
hidden attribute, while on Unix/Linux it's a leading dot in the name, so 
~/.config is normally hidden, and as I said, I really do NOT like such 
hidden files and directories, particularly when they contain such vital 
configuration information as the $XDG_CONFIG_HOME dir does.

So that's one variable among several that I set, unsurprisingly, to the 
unhidden version of the same location, ~/config (no leading dot so not 
hidden by default).

Which means it's ~/config/kded5rc , here.

Tho I do have a symlink ~/.config -> config just in case something ends 
up hard-coding the default, as some things invariably do, so the files 
end up in the right place anyway.  As such either path ends up in the 
same place here, so without either actually file-tracing the appropriate 
apps or looking at the code, I can't be sure kde/plasma5 is actually 
honoring the correct $XDG_CONFIG_HOME var instead of hard-coding the 
default location, but given that the move from the old kde4 $KDEHOME 
location (defaulting to ~/.kde) was in ordered to be more compliant with 
the freedesktop.org specs, it would highly surprise me if the var wasn't 
honored, and I and I suppose most kde/plasma devs would consider 
hardcoding the location (as opposed to hard-coding the var-unset default 
location) a bug.


Of course most users who have actually set that var themselves will know 
all this and won't need told, but various distros may set it, or change 
the var-unset default location via patch, and that could be confusing to 
users who don't find the default location works for them.  This 
additional information could point them in the right direction to check 
and see if that var is set (and to what if so) and/or to check their 
distro to see if it patches the var-unset default location.

2) Perhaps more interesting for most users, the GUI to change the 
settings in this file appears to be kde systemsettings, startup and 
shutdown, background services.

The specific setting in question there is in the lower-half startup 
services list, kscreen 2.  There's a checkbox there that's likely to be 
checked by default.  Unchecking it and hitting apply should toggle both 
the setting in the file (between autoload=true and autoload=false) and 
the service state (between running and not running).  It does here.


So I've located both the file and the GUI setting in question, and have 
the kscreen service configured off, now.  I'll see how that goes, and 
will I expect follow up with my results in a few days.

Thanks again for the pointer.  It does appear at least related and thus 
promising, tho I had looked at it before and decided it must be a more 
general setting.  But now I'm actually checking, and if it works, I'll 
owe it to you for prompting me to go back and actually try it. =:^)

I intend to leave this reply marked unread when I get it back on the 
list, so as to remember to followup in a few days.  Hopefully I do indeed 
get back to do so. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.