Enable multi monitor span *CHANGES REQUESTED* #30641

New Issue

Wander Lairson Costa · 2012-03-22T22:40:31+01:00

2012-03-22 22:40:31 +01:00

%%%This patch adds a new option to cmake build: WITH_MULTI_MONITOR_SPAN, which when activated, provides multi monitor spanning on full screen mode.

It is currently implemented only for SDL2.

Thanks,
Wander Lairson Costa%%%

%%%This patch adds a new option to cmake build: WITH_MULTI_MONITOR_SPAN, which when activated, provides multi monitor spanning on full screen mode. It is currently implemented only for SDL2. Thanks, Wander Lairson Costa%%%

Wander Lairson Costa commented

2012-03-22 22:40:31 +01:00

Changed status to: 'Open'

Campbell Barton commented

2012-03-23 03:03:37 +01:00

%%%I'm not so keen on this being a build option - seems very specific - would prefer this be an environment variable, and perhaps later on it can be added as a proper ghost option.%%%

Dalai Felinto commented

2012-03-23 04:54:25 +01:00

%%%I agree with Campbell here.
Either we (1) expose this as a feature (accessible through command-line) (2) we set it as the only way (3) we leave as it is.

The first would be ideal, but do you think it's possible to have the same behaviour for nonSDL? if so that could even be an option in the ui.
Also is it possible to choice which displays to take over? Or the only options are to use one or to use all?%%%

%%%I agree with Campbell here. Either we (1) expose this as a feature (accessible through command-line) (2) we set it as the only way (3) we leave as it is. The first would be ideal, but do you think it's possible to have the same behaviour for nonSDL? if so that could even be an option in the ui. Also is it possible to choice which displays to take over? Or the only options are to use one or to use all?%%%

Wander Lairson Costa commented

2012-03-23 11:30:42 +01:00

%%%> I agree with Campbell here.
Sounds reasonable for me too...

Either we (1) expose this as a feature (accessible through command-line) (2) we set it as the only way (3) we leave as it is.

I am not sure which is better (1) Expose it as a command line option (2) Expose it through a environment variable, as Campbell suggested.

The first would be ideal, but do you think it's possible to have the same behaviour for nonSDL?

I think so, I know it is possible at least for X11 backend, as it is the backend that SDL was using during my tests.

if so that could even be an option in the ui.

You mean, when I run the player inside the dev env?

Also is it possible to choice which displays to take over? Or the only options are to use one or to use all?

I am not sure, but I think this is a kind of "all or nothing" option.%%%

%%%> I agree with Campbell here. Sounds reasonable for me too... > Either we (1) expose this as a feature (accessible through command-line) (2) we set it as the only way (3) we leave as it is. I am not sure which is better (1) Expose it as a command line option (2) Expose it through a environment variable, as Campbell suggested. > The first would be ideal, but do you think it's possible to have the same behaviour for nonSDL? I think so, I know it is possible at least for X11 backend, as it is the backend that SDL was using during my tests. > if so that could even be an option in the ui. You mean, when I run the player inside the dev env? > Also is it possible to choice which displays to take over? Or the only options are to use one or to use all? I am not sure, but I think this is a kind of "all or nothing" option.%%%

Wander Lairson Costa commented

2012-03-23 15:59:25 +01:00

%%%I updated the patch to, instead of monitor spanning be a build option, be a command line option. When you run blenderplayer with "-f -o" options, monitor spanning should be enabled if supported. I chose '-o' as the option because my two other candidates (-m and -s) are already being used.

Implementation details:
I created another attribute for GPG_Application called m_multiMonitorSpan and the respective getter and setter.
I added a new parameter to beginFullScreen inside GHOST_ISystem and propagated it to GHOST_System.
Inside GHOST_System, besides changing beginFullScreen I also changed createFullScreenWindow to receive the same parameter.
Finally, createFullScreenWindow calls createWindow with either GHOST_kWindowStateFullScreen or the new GHOST_kWindowStateMultiMonitorSpan value.
I also reviewed the other graphics backend to check if my changes don't break compilation and changed Carbon implementation to build successfully (but I couldn't test it, as I don't have a Mac available).

The new patch file is SDL2-enable-multi-monitor-span-cmdline.patch.
%%%

%%%I updated the patch to, instead of monitor spanning be a build option, be a command line option. When you run blenderplayer with "-f -o" options, monitor spanning should be enabled if supported. I chose '-o' as the option because my two other candidates (-m and -s) are already being used. Implementation details: I created another attribute for GPG_Application called m_multiMonitorSpan and the respective getter and setter. I added a new parameter to beginFullScreen inside GHOST_ISystem and propagated it to GHOST_System. Inside GHOST_System, besides changing beginFullScreen I also changed createFullScreenWindow to receive the same parameter. Finally, createFullScreenWindow calls createWindow with either GHOST_kWindowStateFullScreen or the new GHOST_kWindowStateMultiMonitorSpan value. I also reviewed the other graphics backend to check if my changes don't break compilation and changed Carbon implementation to build successfully (but I couldn't test it, as I don't have a Mac available). The new patch file is SDL2-enable-multi-monitor-span-cmdline.patch. %%%

Dalai Felinto commented

2012-03-23 16:03:30 +01:00

%%%Do you also get lots of "Expose events pushed" and then an eventual "no windows available, cant fullscreen" ?
I got it to work once, but then quitted and re-launched and got the error above.

Either we (1) expose this as a feature (accessible through command-line) (2) we set it as the only way (3) we leave as it is.

I am not sure which is better (1) Expose it as a command line option (2) Expose it through a environment variable, as Campbell suggested.

May be worth checking how other softwares do. I know osgviewer allows for desktop spanning for example but I think it's automatic%%%

%%%Do you also get lots of "Expose events pushed" and then an eventual "no windows available, cant fullscreen" ? I got it to work once, but then quitted and re-launched and got the error above. >> Either we (1) expose this as a feature (accessible through command-line) (2) we set it as the only way (3) we leave as it is. >I am not sure which is better (1) Expose it as a command line option (2) Expose it through a environment variable, as Campbell suggested. May be worth checking how other softwares do. I know osgviewer allows for desktop spanning for example but I think it's automatic%%%

Wander Lairson Costa commented

2012-03-23 16:12:11 +01:00

%%%> Do you also get lots of "Expose events pushed" and then an eventual "no windows available, cant fullscreen" ?

I got it to work once, but then quitted and re-launched and got the error above.

The "no windows available, cant fullscreen" is because I didn't remove it from GHOST_DisplayManager.cpp:56. The change is from my previous patch #30636. I decided to leave it there in case SDL2 provides support for a less intrusive solution.

I didn't check the reason for the "Expose events pushed" messages, but I am getting them too.

Either we (1) expose this as a feature (accessible through command-line) (2) we set it as the only way (3) we leave as it is.

I am not sure which is better (1) Expose it as a command line option (2) Expose it through a environment variable, as Campbell suggested.

May be worth checking how other softwares do. I know osgviewer allows for desktop spanning for example but I think it's automatic

I will check it. Anyway I provided another patch that does it through a command line option.%%%

%%%> Do you also get lots of "Expose events pushed" and then an eventual "no windows available, cant fullscreen" ? > I got it to work once, but then quitted and re-launched and got the error above. The "no windows available, cant fullscreen" is because I didn't remove it from GHOST_DisplayManager.cpp:56. The change is from my previous patch #30636. I decided to leave it there in case SDL2 provides support for a less intrusive solution. I didn't check the reason for the "Expose events pushed" messages, but I am getting them too. >>> Either we (1) expose this as a feature (accessible through command-line) (2) we set it as the only way (3) we leave as it is. >> I am not sure which is better (1) Expose it as a command line option (2) Expose it through a environment variable, as Campbell suggested. > May be worth checking how other softwares do. I know osgviewer allows for desktop spanning for example but I think it's automatic I will check it. Anyway I provided another patch that does it through a command line option.%%%

Dalai Felinto commented

2012-03-28 20:55:05 +02:00

%%%small note: you documented as if -m was to toggle the option, but in the code you are checking it against -o%%%

Wander Lairson Costa commented

2012-03-28 21:42:15 +02:00

%%%My bad. Already updated, thanks.%%%

Campbell Barton commented

2015-04-16 13:59:48 +02:00

This patch only works on SDL, and seems SDL specific.

For now I'd rather just have an env var... since it means adding an arg which isnt supported to all other ghost subclasses (and isnt likely to be supported).
If support is added for other systems, is added - we can make a command line argument.

This patch only works on SDL, and seems SDL specific. For now I'd rather just have an env var... since it means adding an arg which isnt supported to all other ghost subclasses (and isnt likely to be supported). If support is added for other systems, is added - we can make a command line argument.

Sergey Sharybin commented

2015-04-16 14:04:54 +02:00

Added subscriber: @Sergey

Bastien Montagne commented

2015-05-22 12:03:31 +02:00

Added subscriber: @mont29

Bastien Montagne commented

2015-05-22 12:03:31 +02:00

Changed status from 'Open' to: 'Archived'

Bastien Montagne closed this issue

2015-05-22 12:03:31 +02:00

Bastien Montagne self-assigned this 2015-05-22 12:03:31 +02:00

Bastien Montagne commented

2015-05-22 12:03:31 +02:00

No news here since month… archiving for now, we can always reopen should the raised points be addressed.

Wander Lairson Costa commented

2015-05-24 16:06:55 +02:00

Hi,

Sorry for the delay in answering, things were kind of messy. I was updating the patch, but this - [x] caught my eyes. I wonder why the createFullScreenWindow method is calling createWindow with the GHOST_kWindowStateNormal state and later this become a full screen window.

http://bit.ly/1JN3yND

Hi, Sorry for the delay in answering, things were kind of messy. I was updating the patch, but this - [x] caught my eyes. I wonder why the createFullScreenWindow method is calling createWindow with the GHOST_kWindowStateNormal state and later this become a full screen window. - [x] http://bit.ly/1JN3yND

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Enable multi monitor span *CHANGES REQUESTED* #30641

Enable multi monitor span CHANGES REQUESTED #30641