Mapping physical screens to KDE containments
1i5t5.duncan at cox.net
Mon Apr 11 11:01:36 BST 2016
Felix Miata posted on Sun, 10 Apr 2016 23:06:01 -0400 as excerpted:
> Nick Coghlan composed on 2016-04-11 12:42 (UTC+1000):
>> Using a multi-monitor setup under Plasma 5 (Fedora 23), I have a
>> problem where the configured panel applet will disappear and not come
>> back if an external monitor is reconfigured to clone the laptop
>> monitor, and then switched back to being an independent screen.
> Looks like you must have found the explanation why I have a whole bunch
> of F23 and F24 installations in which I never see a panel any more. I'm
> never using a laptop, but I do have several multi-output gfxcards to
> which I only sometimes connect more than one display. When I do, it's
> always in an extended desktop mode configured manually either using
> xrandr or xorg.conf*
> via /etc/X11*.
A similar problem here, tho on a triple-monitor setup with a permanent
layout configured in xorg that plasma would ideally simply leave alone...
only it doesn't.
In my case I strongly suspect that the hardware side of the problem is
the fact that apparently one of my three monitors, actually a 48" TV
connected via HDMI, actually fully turns off from the point of view of
the graphics card and X when I'm idle long enough to screen-blank, so
that it actually appears disconnected, and when it powers back on it
appears to be a hardware plug event causing plasma to detect it as a
newly plugged monitor, instead of part of the same triple-monitor setup
that's always configured. In doing so I guess it violates some standard
(my 42" TV/monitor never behaves that way, nor does the 21" actual
computer monitor, the other two of the three). Regardless, it would seem
as if plasma should detect that it's the same hardware I had before and
configure it the same way via kscreen, only it doesn't, resulting in a
problem very similar to what you've described with the panel, *PLUS*
another one with the ordering of the actual plasma desktop configurations
for each monitor -- one (the 21" actual computer monitor) always stays
the same, the other two often come back switched.
Oh, and krunner often refuses to popup after I come back from screen-
blanking as well.
FWIW, from what I've read, these are the remaining issues of what were
once far more severe plasma5 multi-monitor bugs. Apparently (I only
switched to plasma5 from kde4 relatively recently as it had blocker-level
bugs, generally kwin segfaults and constant respawning, on my setup until
recently, which for all I know were part of the previously way more
severe multi-monitor bugs) they've mostly been fixed, but what we're
seeing is what remains.
I've developed some workarounds that tend to reset back to a working
config, for me, however. In general, this involves force-terminating and
restarting the affected plasma component, sometimes along with a kwin
window rule to help windows get positioned correctly after the restart.
* For krunner, the problem seems to be that after the screen blanking,
it's confused about what the coordinates of the focused (xinerama/randr)
screen are and hitting the krunner hotkey will apparently "display and
focus" the krunner window as whatever was focused loses focus, except
that whatever coordinates krunner actually pops up at aren't actually on-
monitor anywhere that I can see, so who knows /where/ it's popping up,
obviously not on the focused monitor (aka xinerama screen).
+ My workaround involves two things:
+a) setting up a kwin window rule for krunner.
On the matching tab, window class, exact match, krunner krunner, with
match whole window class checked, window role unimportant, window type
normal window, window title exact match, krunner. (Description aka rule
name is your choice, I simply called my rule krunner, here.)
On the size and position tab, initial placement, force, under mouse.
(That's not quite the normal behavior but at least I can always find it
then.) Ignore requested geometry, force, yes.
+b) When krunner won't appear, I simply force-quit and restart it, with a
script that runs these commands:
(The sleep, backgrounding with &, and disown, may or may not be actually
necessary, but I'm actually using a generic script with the name filled
in as a variable, so anything I restart that way gets the same
treatment. If it's necessary, failure to do it will cause the just
restarted app to terminate again when the script ends, a problem the
I actually have a custom hotkey/menu sequence configured (in a non-kde
custom-scripted hotkey solution, as kde tends to break working and long
committed to "muscle memory" hotkey sequences at least every major
version upgrade, forcing me to relearn some new hotkey combination as I
can no longer configure the old one to work) that pops up a "reset" menu,
with krunner one of the options.
* For plasma panel, a rather limited workaround uses much the same two-
part technique. The limit is that because plasma5 doesn't set unique
window class, window role and window title for each of its panels (as
plasma4 did), the rule will apply to all panels and possibly to other
popups like the add plasmoid dialog (aka add widgets, aka plasma/widget
explorer). If you have just one panel that's fine, but more panels
becomes problematic, and now that the plasmoid explorer is affected by
the same rule, I have to temporarily disable the rule any time I want to
add new plasmoids/widgets.
+ Two part workaround with additional limits:
+a) window rule for plasma panel
Matching tab: (I call it simply plasma panel.) Window class, exact
match, plasmashell plasmashell, match whole window class checked. Window
role unimportant (this is where plasma4 distinguished them, with roles
such as panel#1, panel#2, etc, so the rule could apply to a specific
panel; unfortunately the window role is blank for panels in plasma5, so
that doesn't work any more). Window type, Dock(panel). Window title,
exact match, Plasma. (Setting dock type is absolutely vital!! Otherwise
you'll get matches on things like the activities/desktops, etc, **NOT**
what you want!!)
Size and position tab: Screen, force, <appropriate screen number,
experiment if needed>. Optional: position, apply initially, <as
Forcing the screen aka monitor number should make sure it appears on the
same monitor consistently. If you only set this, you should be able to
get away with multiple panels at different positions, but they'll all be
forced to the same screen/monitor.
Setting the position can be used to keep a panel appearing at the same
place on the monitor. For non-auto-hide, you can likely force position,
but that will break auto-hide, while apply initially can be used to start
it out in the correct location without breaking autohide.
+b) Restarting plasmashell and/or kwin may be needed. With the window
rule in place I find it isn't always.
plasmashell (same as krunner but with plasmashell instead:
kwin (note that it's kwin_x11 here, differentiating from kwin_wayland,
and that I use killall instead of kquitapp5, killall could be a problem
if you're running a second kde session with its own kwin, but in general
shouldn't be, because that would normally be another user and unless
you're running as root, killall can normally only kill apps running as
the same user):
Another alternative for kwin that will work in most cases:
But while that's simpler, from my experience it's not always as reliable.
Unfortunately, this workaround has rather more limits and down sides than
I'd like, but it does at least seem to get things back where they belong,
if you're willing to live with those limits. As mentioned above, it
means you can only put panels on one screen, which of course means that
said screen must always exist. In the only sometimes attached external
monitor case with both it and the builtin monitor on, that will limit you
to either putting the panels on the builtin, or using clone mode. You
won't be able to put the panels on the external monitor (other than in
clone mode) as that would mean they're not available when only the
builtin monitor is running.
Attempting to use multiple panels with the positioning set will almost
certainly end up piling them on top of each other and thus not working,
so only doing the force screen thing may work better there. The problem
is that sometimes the panels disappear entirely if position, apply
initially, isn't active and set somewhere they can actually be seen,
because apparently much like krunner, they get confused about where the
screen actually is and popup somewhere offscreen.
For the missing panels problem, set position to force and the coordinates
to somewhere that's actually displayed. Then turn off force so you can
move the panel, and you should be able to use normal panel settings to
drag it to an edge and position it as desired. I've had to do that a few
times here, because while I only have the one panel, I sometimes turn off
the positioning thing either to work around the next limit/down-side, or
simply because I'm hoping it's fixed now, only to find out that the
problem's still there after the next idle-screen-blanking, and my panels,
while they are apparently still considered to be on the same screen/
monitor, are nowhere to be seen (or to be unhidden, with autohide on).
Also, at least with current plasma-live (I think with earlier plasma5 it
didn't accidentally match, but can't be sure as I didn't use it long
enough to remember for sure), the plasmoid explorer aka add-widgets
dialog will match the rule as well, which will cause problems trying to
use it with the optional positioning. Fortunately, once I have my
plasmoids setup I don't tend to change them much, so I just manually
disable the rule (I simply append an x to the window title, making it
Plasmax, so it doesn't match, for a temporary disable) if I want to add
plasmoids, so the add-plasmoid dialog behaves normally.
* For the activities switching monitors, I find that the problem usually
fixes itself with a simple plasmashell restart, using the script above.
In general, I really wish they'd either fix the remaining bits of this
bug, or at least assign properly distinctive window roles or titles to
the various windows, so window rules could be limited to matching just
one panel, not all of them and not other windows such as the plasmoid
Oh well... On the bright side, it'll probably be fixed in a few years...
just in time for them to dump it and start on the all new and buggy kde/
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.
More info: http://www.kde.org/faq.html.
More information about the kde