Fix for multiple screens but non virtual desktop

[Paul Andreassen <paul@…>]

The problem is the wrong screen is used to obtain size details on multi-screen systems without a virtual desktop.

First brought to my attention on the user mail list. ​Messages on User Mail List.

Seems two or three people encountered this problem without a decent workaround.

I've fixed and tested this for 18.1. Attached is a patch to fix the problem for the svn tree. I didn't compile it but it is so simple there shouldn't be a problem.

18.1 testing output

Virtual Desktop Xinerama Screen 0
Total desktop width=2880, height=1200, numscreens=2, isVirtualDesktop=1, primaryScreen=0
Using screen 0, 1600x1200 at 0,0

Virtual Desktop Xinerama Screen 1
Total desktop width=2880, height=1200, numscreens=2, isVirtualDesktop=1, primaryScreen=0
Using screen 1, 1280x960 at 1600,0

Virtual Desktop Xinerama Screen all
Total desktop width=2880, height=1200, numscreens=2, isVirtualDesktop=1, primaryScreen=0
Using all screens (currently 2)
Total width = 2880, height = 1200

Non-Virtual Desktop Screen 0:0
Total desktop width=1600, height=1200, numscreens=2, isVirtualDesktop=0, primaryScreen=0
Using screen 0, 1600x1200 at 0,0

Non-Virtual Desktop Screen 0:1
Total desktop width=1280, height=960, numscreens=2, isVirtualDesktop=0, primaryScreen=1
Using screen 1, 1280x960 at 0,0

[paul@…]

svn patch

[danielk]

Wouldn't it be possible to specify the screen you want the bounds calculated for as the "Xinerama screen"?

Doesn't this limit you to putting the video on the same monitor as the menus?

I know I'm currently displaying video on a different monitor than the menus...

[paul@…]

You've missed the point of the patch. This patch doesn't change Xinerama at all. Xinerama is when you are combining multiple monitors to provide one desktop and windows can move between monitors. This patch only fix a bug for non Xinerama multiple monitors which have separate desktops and windows can't move between monitors.

Wouldn't it be possible to specify the screen you want the bounds calculated for as the "Xinerama screen"?

Mythtv's Xinerama support already does this. For people with disable Xinerama there is only the current display (primaryScreen).

Doesn't this limit you to putting the video on the same monitor as the menus?

This is all Mythtv supports, in my understanding.

I know I'm currently displaying video on a different monitor than the menus...

You have been using a bug/feature and can continue using it.

[danielk]

I understood why you were doing this, but your fix doesn't get rid of the Xinerama setup in appearance so you can still set this, but it doesn't work with your patch applied.

It looks like GetNumberOfXineramaScreens?(void) was changed at some point to return the number of screens even when Xinerama is not supported; which sort of defeats the purpose of this function. This is why the Xinerama config option is still available when you don't have xinerama. But as you point out, you can only but the video on a separate screen if you have Xinerama, so needing to configure this for only adds confusion.

I was hoping you would be able to tell me these things to save me the time of looking into it.

[danielk]

(In [7271]) Fixes #347.

The Xinerama config was exposed for single-server multi-screen non-Xinerama setups due to a change in GetNumberOfXineramaScreens?() and was being used in these non-Xinerama setups. This fixes GetNumberOfXineramaScreens?() and documents it so that it's function isn't confused with QDesktop::numScreens(). It also uses Paul Andreassen's desktop->primaryScreen() fix so that single-server multi-screen non-Xinerama setups work correctly.

Bigel, this may break MacOS X multi-screen setups, my understanding is that these work somewhat like Xinerama, perhaps we can enable a "screen" setting on OS X? But first I need to know, does a MacOS X multi-screen setup ever not support Xinerama functionality?

[paul@…]

Sorry but for me there was no Xinerama setup in appearance when Xinerama disabled.

I'm running Debian stable with Xfree86 4.3.0.dfsg.1-14 so a little behind the times.