Bug 282677 - Compositing not possible on each screen with multi head
Summary: Compositing not possible on each screen with multi head
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: multi-screen (show other bugs)
Version: 4.7.0
Platform: Ubuntu Linux
: NOR normal
Target Milestone: 4.11
Assignee: KWin default assignee
URL: https://git.reviewboard.kde.org/r/107...
Keywords: reproducible
Depends on:
Blocks:
 
Reported: 2011-09-24 12:28 UTC by Maxime Chassagneux
Modified: 2013-02-25 06:56 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 4.11
thomas.luebking: ReviewRequest+


Attachments
Just the begin of the xsession-error (3.17 KB, text/plain)
2011-09-24 12:28 UTC, Maxime Chassagneux
Details
Just the begin of the xsession-error when all is OK (second start) (3.87 KB, text/plain)
2011-09-24 12:31 UTC, Maxime Chassagneux
Details
Xorg.conf (1.98 KB, text/plain)
2011-09-24 12:32 UTC, Maxime Chassagneux
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Maxime Chassagneux 2011-09-24 12:28:35 UTC
Created attachment 63915 [details]
Just the begin of the xsession-error

Version:           4.7.0 (using KDE 4.7.0) 
OS:                Linux

I've 2 screens activate with dual desktop configuration (no xinemera).
In the first boot, each time, the compositing is not activate in one desktop (randomly).
If I deconnect my session, and reconnect the compositing start this time correctly

Reproducible: Always

Steps to Reproduce:
start a kwin compositing session on a dual desktop configuration

Actual Results:  
No compositing start on each screen, only on one screen.

Expected Results:  
Compositing start on each screen.

After a reconnection, the behaviour is OK, each screen start compositing.
Comment 1 Maxime Chassagneux 2011-09-24 12:31:55 UTC
Created attachment 63916 [details]
Just the begin of the xsession-error when all is OK (second start)
Comment 2 Maxime Chassagneux 2011-09-24 12:32:55 UTC
Created attachment 63917 [details]
Xorg.conf
Comment 3 Thomas Lübking 2011-09-24 14:35:42 UTC
Notice: this is a multihead setup (2 GPUs, screens and X11 servers and kwin instances)

The problem is most likely the OpenGLIsUnsafe check.

kwin_1 starts up, checks the setting, sets the safety variable, starts the gl init, ...
kwin_2 starts up, checks the setting, ... figures it's set to true and aborts compositing ...
kwin_1 unsets the variable

We'd need that variable per and by device/screen.
Comment 4 Martin Flöser 2011-09-25 08:18:35 UTC
probably the best idea is to make the complete Compositing group screen dependent
Comment 5 Soos Gergely 2012-01-13 13:07:17 UTC
I have this problem too in KDE 4.7.3 (kubuntu 11.10 with the fglrx restricted driver) however in my case compositioning does not start only on the second screen (on the first screen it is always active). And the issue appears randomly (at least I can't see a pattern). Compositioning usually activates after the first login, but not always, and also sometimes after a logout/login it is not activated.
Comment 6 Thomas Lübking 2012-01-13 15:30:20 UTC
A quick and dirty workaround would be to add a significant (like one second ;-) delay between the two kwin starts (in startkde i assume? try "sleep 1")

<mantra class="hint">
Most people do actually NOT want to use two independent screens with two independent window manager instances, but want to use xinerama or preferably an xrandr multiscreen setup.
</mantra>
Comment 7 Soos Gergely 2012-01-13 16:23:30 UTC
Unfortunately I can't try your workaround, because kwin is not started directly by startkde. As far as I can see it is started by ksmserver which is a binary file.

I guessed that most people use xinerama nowadays, because every piece of software is full with bugs when running on a dual screen setup. Good old KDE3 and GNOME 2 used to handle well dual screen setups. Back in those days Xinerama was a pain in the ass but nowadays dual screen is. I don't know, maybe it's time for me too to look into this "xrandr multiscreen setup".
Comment 8 Martin Flöser 2012-01-13 16:29:17 UTC
> Unfortunately I can't try your workaround, because kwin is not started
> directly by startkde. As far as I can see it is started by ksmserver which
> is a binary file.
AFAIK the additional instances are started by KWin itself by forking in 
main.cpp
> 
> I guessed that most people use xinerama nowadays, because every piece of
> software is full with bugs when running on a dual screen setup.
also consider the limitations and disadvantages like you cannot move windows 
to the other screen, you need to change Xorg.conf, etc. etc.
> Good old
> KDE3 and GNOME 2 used to handle well dual screen setups.
No, that is not true. Even in KDE 3 there have been lots of issues. Most of 
our really old bug reports are about Multi-Head and have been opened for KDE 3 
and have comments back from then that Multi-Head is unsupported.

Not to mention that there has not been OpenGL based compositing in KDE 3 ;-)
Comment 9 Soos Gergely 2012-01-13 16:52:02 UTC
For a long time I used KDE3 with compiz on dual screen and I was happy with it, no serious bugs appeared for me.

I started using linux when editing config files by hand was not such a big deal. Of course fewer people used linux back then. And for me not being able to move windows between monitors is not a big problem, actually one of my big problems with Xinerama was that windows kept opening on wrong monitors (I mean not the ones I wanted them to open on) so two independent monitors made more sense to me.
Comment 10 Soos Gergely 2012-01-13 17:38:09 UTC
Speaking of not editing config files directly, I thought I try the single X screen right now. So I moved away my xorg.conf and created a new user (not to interfere with my current settings). Then I opened System Settings/Size & Orientation. No matter what I do I cannot set up anything else but the cloned output. If I set the external monitor's Position to: Right of LVDS and press Apply then no error message or anything it just resets to the cloned mode. No error message on the console either. I hate GUI configuration tools.
Also, the "Multiple Monitors" tab shows me the text "This module is only for configuring systems with a single desktop spread across multiple monitors. You do not appear to have this configuration." in every case (with or without my dual X screen xorg.conf).
Comment 11 Thomas Lübking 2012-01-13 19:32:36 UTC
The issue here is likely fglrx.

Eg. the nvidia blob has even its own "mode" (TwinView) aside to xrandr (which won't work at all)
Have a look around the catalyst configuration tool or use the radeon driver (xf86-video-ati) if possible.
Comment 12 Soos Gergely 2012-01-17 12:03:15 UTC
You are right, the Systemsettings problem is probably an fglrx issue. But what I hate about GUIs that they have very bad error reporting. Systemsettings should tell me what it's problem is at least in it's stdout...
Anyway, I've set up in amdcccle what it calls "Multi-display desktop with display(s) 2" which looks to me like Xinerama and acts like it. Windows keep opening in the wrong monitor and another issue is the desktop cube which looks really-really bad (two half cuboids on each monitor) but the even bigger problem for me is that rotating the cube rotates away windows on both monitors which is not acceptable for me. So I'm sticking with the dual X screen.
Comment 13 Thomas Lübking 2012-01-17 16:23:31 UTC
(In reply to comment #12)
> You are right, the Systemsettings problem is probably an fglrx issue. But what
> I hate about GUIs that they have very bad error reporting. Systemsettings
> should tell me what it's problem is at least in it's stdout...
It probably even doesn't know. The fglrx driver might invalidly react on the xrandr calls. An this doesn't belong into this bug :)

> display(s) 2" which looks to me like Xinerama and acts like it. Windows keep
> opening in the wrong monitor 
can you please look at "kcmshell4 xinerama" and elaborate on this statement? Ie. what is the "wrong" monitor and why and whether all applications are affected and how you launch them (yes, that actually can matter)

> and another issue is the desktop cube which looks
> really-really bad (two half cuboids on each monitor)
I think it was supposed to only appear on one screen (like present windows) - Martin?

> but the even bigger problem for me is that rotating the cube rotates away windows on 
> both monitors which is not acceptable for me. So I'm sticking with the dual X screen.
There's only one root window in this setup and the NETWM spec doesn't specify screen dependent proeprties for the current virtual desktop. That said, the spec might be slightly dated in this regard.
Comment 14 Martin Flöser 2012-01-17 16:40:09 UTC
> > and another issue is the desktop cube which looks
> > really-really bad (two half cuboids on each monitor)
> 
> I think it was supposed to only appear on one screen (like present windows)
> - Martin?
It used to have multiple modes including scale on one screen. Well I removed 
it in I think 4.2 because it just does not make much sense and made the code 
rather complex (changing of projection matrix just for that etc. etc.). Cube 
is a pure visual effect which just does not make much sense on multi screen 
setups.
Comment 15 Soos Gergely 2012-01-18 12:34:01 UTC
Response to Thomas:
I've already saw the configuration dialog "kcmshell4 xinerama" starts. My apologies for not being clear enough. What I mean by the "wrong monitor" is not the monitor the cursor is currently on.
The option "Enable multiple monitor window placement support" makes things a little better because at least a window appears entirely on one monitor (not half part on one monitor half on the other).
"Show unmanaged windows on" is set to "Display containing pointer" - this one doesn't work (or maybe I don't understand what an unmanaged window is).
Let's say you have a panel on both monitors containing an application launcher. Then I would expect that if I click on an app in the application launcher then the app should start on the same monitor then the launcher is on. Instead it seems to open on the monitor that contains the window which currently has the focus.
Another weird sideeffect of this is say you have only one window opened on the second monitor. Then you go to the first monitor's panel right-click and open some properties, say "Application Launcher Settings" then the window opens on the second monitor which is very confusing.

But still my biggest problem is with the virtual desktops, because the two monitors are attached. Maybe I could learn to live with the problems described above but it is very impractical to me that changing a virtual desktop on one monitor changes the other monitor too.


Responding to Martin:
My opinion is that a compositioning manager as a whole is a pure visual effect (maybe with the exception of some accessibility features like zooming) so if it doesn't look good it has no purpose. The only reason I have a pretty good video card is to run a nice compositor because I want to make my desktop to look like the state of the art desktop. Before KDE4 the only good option was compiz.
I don't want to offend you but if you say you don't implement something because it doesn't make sense then KDE will become as limited as Gnome2 was (I haven't tried Gnome3 so I can't talk about that). It makes sense to me, that's why there are options - less of them in Gnome2.
My opinion is that a compositor should look as good as it can. Even if it uses more resources - people with worse video cards can disable plugins.
Comment 16 Thomas Lübking 2012-01-18 18:21:27 UTC
(In reply to comment #15)
> Response to Thomas:
> I've already saw the configuration dialog "kcmshell4 xinerama" starts. My
> apologies for not being clear enough. What I mean by the "wrong monitor" is not
> the monitor the cursor is currently on.

==> "kcmshell4 kwinoptions", focus tab (it's the first one), check "active screen follows mouse". You likely want "separate screen focus" as well.

> The option "Enable multiple monitor window placement support" makes things a
> little better because at least a window appears entirely on one monitor
The closest setup to "two screens" is gained by checking all available options, yes.

> "Show unmanaged windows on" is set to "Display containing pointer" - this one
> doesn't work (or maybe I don't understand what an unmanaged window is).
This affects only very few windows. Esp. such w/o a titlebar (and even many of those would not be covered)
The interesting checkbox is that in kwinoptions.

> Let's say you have a panel on both monitors containing an application launcher.
> Then I would expect that if I click on an app in the application launcher then
> the app should start on the same monitor then the launcher is on.
Yesno. This becomes tricky depending on how the panel/launcher works (i don't use such so i'm currently not aware of the plasma-panel behavior)
In general the new application *could* inherit the screen of the dock containing the panel (what's likely the screen containing most of the panel - in doubt the bigger one) but this....

> Instead it seems to open on the monitor that contains the window which currently has 
> the focus.
... sounds more like a job for the kwinoptions checkbox ;-)

> But still my biggest problem is with the virtual desktop
I grant that this is a defect of the current netwm spec (which was written when there was no randr and xinerama would usually not work anyway - ie. "it's rather old")
For a limited amount of cases this might be covered by sticking the applications "on the other monitor"


> Responding to Martin:
> It makes sense to me, that's why there are options - less of them in Gnome2.
I'll just hook in here.
a) playing that "you become like gnome" card stopped working long time ago, you may try but you're wasting your time.

b) Martin wasn't talking about resources (actually invoking only one monitor would require less) but code complexity (affecting maintainability)

c) tried compiz: aside that apparently ctrl+alt+lmb does no longer work (?! - compiz somehow degenerated a lot since it's under ****** control) it behaves exactly the same and spans one cube across both screens. Whether two bound cubes would be any better i don't know, but i know that the (kwin) desktop grid (aka "spaces" ;-) is far more usable to me esp. on a multiscreen setup (since it allows me to move windows across VD and screens at the same time)
Comment 17 Soos Gergely 2012-01-18 19:18:06 UTC
> ==> "kcmshell4 kwinoptions", focus tab (it's the first one), check "active
> screen follows mouse". You likely want "separate screen focus" as well.
> 
> The closest setup to "two screens" is gained by checking all available options,
> yes.
> 
All right, that's more like it! I don't know how I missed these options. Thanks.

> I grant that this is a defect of the current netwm spec (which was written when
> there was no randr and xinerama would usually not work anyway - ie. "it's
> rather old")
So what can be done?
> For a limited amount of cases this might be covered by sticking the
> applications "on the other monitor"
What do you mean by that? Do you mean the sticky attribute (aka "To Desktop > All Desktops")?

> > Responding to Martin:
> > It makes sense to me, that's why there are options - less of them in Gnome2.
> I'll just hook in here.
> a) playing that "you become like gnome" card stopped working long time ago, you
> may try but you're wasting your time.
Yes, well I always loved KDE because you could configure it the way you liked it.
It would be great if it would stay that way...

> c) tried compiz: aside that apparently ctrl+alt+lmb does no longer work (?! -
> compiz somehow degenerated a lot since it's under ****** control) it behaves
> exactly the same and spans one cube across both screens. Whether two bound
> cubes would be any better i don't know, but i know that the (kwin) desktop grid
> (aka "spaces" ;-) is far more usable to me esp. on a multiscreen setup (since
> it allows me to move windows across VD and screens at the same time)
I know, compiz has the same issues, I used it with dual X screens too. It supports dual screens better then kwin.
But the reason I mentioned compiz is that I think KDE is beginning to be as good as compiz, in some cases even better (my favorite advantage: suspends compositioning for fullscreen windows). It would be good if kwin would also have a good support for dual X screens...

Anyway, the original error still stands, and I just noticed a new thing today.
I have the keyboard shortcut <Super>+Enter to quickly enable/disable compositioning.
If you press it enough times one of the two monitors will not have compositioning with the same error and a kwin --replace does not help only if you log out and restart the X server.
Comment 18 Soos Gergely 2012-01-23 18:46:31 UTC
By the way, does anyone know or is it even possible to start effects from the command line for example using qdbus? Being able to execute something like:
qdbus org.kde.kwin-screen-1 /KWin org.kde.KWin.startEffect kwin4_effect_flipswitch
would make my life much easier. (The startEffect function does not exist; I made it up.)
Then I would be able to do different things with xbindkeys.
Comment 19 Thomas Lübking 2012-01-23 18:53:08 UTC
qdbus org.kde.kwin /KWin toggleCompositing
Comment 20 Soos Gergely 2012-01-23 21:47:39 UTC
Sorry, that's not what I meant.
qdbus org.kde.kwin /KWin org.kde.KWin.listOfEffects
The command above lists all the available effects. I would like to start (or initiate or I don't know what's the correct term) some of them like kwin4_effect_flipswitch, kwin4_effect_desktopgrid etc.
When I'm using xbindkeys the environment contains the DISPLAY (":0.0" or ":0.1") so I do know which kwin instance to call (org.kde.kwin or org.kde.kwin-screen-1).
Comment 21 Thomas Lübking 2012-01-24 00:17:06 UTC
How's that related to this bugreport?
Anyway: 
qdbus org.kde.kglobalaccel /component/kwin shortcutNames
qdbus org.kde.kglobalaccel /component/kwin invkokeShortCut <shortcut name>

Central issue regarding multihead is that kglobalaccel doesn't sufficiently support it - so this will likely not get what you want.
Comment 22 Soos Gergely 2012-01-24 12:26:44 UTC
(In reply to comment #21)
Thomas you are right in both issues, this does the same thing as pressing the shortcut, which works incorrectly, and it is not much related to this bugreport, but thanks for the tip anyway, it may come handy one day.
Comment 23 Maxime Chassagneux 2013-02-13 08:35:48 UTC
This bug is still present with KDE 4.10 version.
Comment 24 Thomas Lübking 2013-02-13 09:24:28 UTC
https://git.reviewboard.kde.org/r/107853/
Comment 25 Maxime Chassagneux 2013-02-13 16:43:05 UTC
I'm sorry but I've just made a test and the alt+tab switcher doesn't work with multi head config. I'm obliged to kill the second session of kwin (on my TV screen) to work correctly on my LCD.
Comment 26 Thomas Lübking 2013-02-13 17:06:14 UTC
This bug is about compositing, not the tabbox.
Please don't start to blur that - hook onto the mega "multihead issues" bug for that.

To shortcut this: in case you tested the patch, it's supposed to keep the focus on one screen alongside tabbox invocation. It will not allow you to use the tabbox on either screen. That's an issue in kglobalacceld.

If you think you perceived no cahnge compared to the unpatched variant please comment on the patch and precisely describe what you observe on tabbox invocation.
Comment 27 Maxime Chassagneux 2013-02-13 17:33:53 UTC
I know this bug is about compositing but you had linked an url about tabbox so I've made a comment about this too. 

Sorry for the misunderstood
Comment 28 Thomas Lübking 2013-02-13 21:52:37 UTC
(In reply to comment #27)
> I know this bug is about compositing but you had linked an url about tabbox
> so I've made a comment about this too. 

The linked patch addresses both issues, otherwise i would not have linked it here.

OT:
Alt+Tab is supposed to work on one (the main) screen.
The patch attempts to fix the loss of the input focus with alt + tab (so that subsequent alt+tab invocations would fail and cause "regular" input of some UTF char on any other screen.)

If *this* (and only this, i didn't test anything else in that regard) is not fixed for you, you should bump on bug #256242 *now*
If you have further issues with alt+tab that are *not* "only works on one screen", you should record them on that bug (or open a new one)
Comment 29 Thomas Lübking 2013-02-18 21:48:19 UTC
Git commit 53294ef164c3af5a08f20ff1f0de1de9bff5e5bd by Thomas Lübking.
Committed on 13/02/2013 at 00:40.
Pushed by luebking into branch 'master'.

improve multihead situation

prevents the focus being passed to the other head
manages OpenGLIsUnsafe setting per head
Related: bug 256242
REVIEW: 107853
FIXED-IN: 4.11

M  +7    -4    kwin/composite.cpp
M  +6    -37   kwin/tabbox/tabbox.cpp
M  +28   -0    kwin/workspace.cpp
M  +1    -0    kwin/workspace.h
M  +15   -0    kwin/xcbutils.h

http://commits.kde.org/kde-workspace/53294ef164c3af5a08f20ff1f0de1de9bff5e5bd