OS2World OLD-STATIC-BACKUP Forum

OS/2 - Technical => Hardware => Topic started by: demetrioussharpe on 2011.05.22, 19:48:19

Title: Multi-monitor Systems
Post by: demetrioussharpe on 2011.05.22, 19:48:19
Hello all,

Is you may/may not know, I'm writing a graphic's driver framework for OS/2-eCS. One area that I do not want to leave out is support for multi-headed/multi-monitor systems. Since I've never had a need for running such systems, I do not have enough experience to know what's good/bad in such an implementation & which features would be most needed. To that end, what I'd like from you all is a basic list of features that you would like to be available in such an implementation. Keep in mind, I must create an API which allows multiple monitors to work, regardless of if the system has multiple video cards, a video card with multiple display ports, or a combination of the two. With that being said, which features would you like?

P.S.  Please also give an example of usage for each feature!
Title: Re: Multi-monitor Systems
Post by: miturbide on 2011.05.22, 20:34:35
Hi demetrius

My experience with multi-monitors is very basic. I had the need only for two monitors that can be an external one or a project.

I can only tell you my feature list based only on user interaction or users features, not a technical features.

Taking the experience of Windows 7 the request will be:
Windows 7 does this on the Multiple Screen list (check screenshot 2)

When extending the desktop:

The basic features:

I'm not sure if you are asking for this kind of features.
Title: Re: Multi-monitor Systems
Post by: demetrioussharpe on 2011.05.22, 21:08:37
Quote from: miturbide on 2011.05.22, 20:34:35
Hi demetrius

My experience with multi-monitors is very basic. I had the need only for two monitors that can be an external one or a project.

I can only tell you my feature list based only on user interaction or users features, not a technical features.

Taking the experience of Windows 7 the request will be:

  • Being able to extend desktop
  • Being able to show the same on several screens
Windows 7 does this on the Multiple Screen list (check screenshot 2)

When extending the desktop:

  • Being able to adjust the screen postition (left, right, up down) when you extend your desktop (Screenshot 3)
  • An easy way to select the resolution for each screen.

The basic features:

  • Easy way to identify screens
  • Change resolution without reboot
  • Monitor orientation - landscape, portrait and the inverse ones

I'm not sure if you are asking for this kind of features.

This is exactly the kind of feedback that I'm looking for & the pics drove your points home even better! I understood everything that you asked for, except when you mentioned inverse monitor orientation. What exactly does this mean? Please, go into as much (or less) detail as you need to.
Title: Re: Multi-monitor Systems
Post by: RobertM on 2011.05.22, 22:07:21
One core feature missing in the current OS/2 support is the ability to set full screen modes (whether a PM window or a VIO graphics window) to the monitor that contains the majority of the object being full-screened.

The current driver setup probably does have some portion this capability, but it is unused except via xWP's multiple desktop feature, where "invalidated" desktop areas are not used or considered when making an object full screen.
Title: Re: Multi-monitor Systems
Post by: demetrioussharpe on 2011.05.22, 22:22:01
Has anyone had experience with using OS/2 with multiple video cards? Is that currently possible?
Title: Re: Multi-monitor Systems
Post by: miturbide on 2011.05.22, 22:23:08
"Monitor orientation - landscape, portrait and the inverse ones"

I meant to have the 4 orientation modes posible. Landscape and Landscape upsidedow. Portrait and portrait upside down. Just like rotating the monitor 90º in the 4 positions that you can..... sorry Im not good explainin it in english.

Other feature to add:
Title: Re: Multi-monitor Systems
Post by: demetrioussharpe on 2011.05.22, 22:24:23
Quote from: RobertM on 2011.05.22, 22:07:21
One core feature missing in the current OS/2 support is the ability to set full screen modes (whether a PM window or a VIO graphics window) to the monitor that contains the majority of the object being full-screened.

The current driver setup probably does have some portion this capability, but it is unused except via xWP's multiple desktop feature, where "invalidated" desktop areas are not used or considered when making an object full screen.

What do you mean? Please explain farther. Are you referring to being able to have a window moved to another monitor where it only shows that window in fullscreen mode? Is the window even shown, or is it just the client area where the data shows up at?
Title: Re: Multi-monitor Systems
Post by: demetrioussharpe on 2011.05.22, 22:29:52
Quote from: miturbide on 2011.05.22, 22:23:08
"Monitor orientation - landscape, portrait and the inverse ones"

I meant to have the 4 orientation modes posible. Landscape and Landscape upsidedow. Portrait and portrait upside down. Just like rotating the monitor 90º in the 4 positions that you can..... sorry Im not good explainin it in english.

Oh, ok, I understand now. It wasn't a problem with your english, I just don't know this topic that well.


QuoteOther feature to add:

  • Autodetect quantity of monitors

On the backend, I'm trying to expose this by exporting a structure that contains a count of how many framebuffers there are & an array of pointers to each of them. I hope that this is sufficient, from the driver API perspective. With this driver interface not being used yet, there's plenty of time to try to get this right.
Title: Re: Multi-monitor Systems
Post by: RobertM on 2011.05.22, 23:36:46
Quote from: demetrioussharpe on 2011.05.22, 22:24:23
Quote from: RobertM on 2011.05.22, 22:07:21
One core feature missing in the current OS/2 support is the ability to set full screen modes (whether a PM window or a VIO graphics window) to the monitor that contains the majority of the object being full-screened.

The current driver setup probably does have some portion this capability, but it is unused except via xWP's multiple desktop feature, where "invalidated" desktop areas are not used or considered when making an object full screen.

What do you mean? Please explain farther. Are you referring to being able to have a window moved to another monitor where it only shows that window in fullscreen mode? Is the window even shown, or is it just the client area where the data shows up at?

Hi,

If you are currently running a multi-monitor setup under OS/2 (as I do), let's say you have a PM window open (any... a folder, an app, whatever), and the window is constrained to one monitor. When you full screen it, the window is full screened across both monitors, as opposed to being full screened to only the monitor it is on.

The same applies (unless something has changed recently) to using various video player apps in full screen mode (such as mPlayer). Or when switching such an app from windowed to full screen. In the case of mPlayer, that means the video is centered across both viewports on both monitors, with half the video on one, and the other half on the other monitor.

Each of those issues is of course separate, with the first probably being easier to address. And of course, the desired results would be something akin to what happens in Windows. For instance, when I am watching Netflix on my laptop, the external port is usually plugged into my TV. I have a browser window open on the LCD, and one open on the secondary viewport (ie: the TV). If I full screen the Netflix player (or YouTube video, or whatever), it only full-screens to the viewport that corresponds with the original windowed object. That allows me to watch videos on the secondary viewport, while having another browser window/folders/whatever, still viewable on the primary viewport. OS/2 currently will full screen across both and center the image - and of course, also reports the combined resolution size as one single viewport (in my case, on my OS/2 setup, that's 2560x1024, instead of (2) x 1280x1024).

Best,
Rob
Title: Re: Multi-monitor Systems
Post by: RobertM on 2011.05.22, 23:41:59
See attached...
Title: Re: Multi-monitor Systems
Post by: demetrioussharpe on 2011.05.23, 00:42:10
Quote from: RobertM on 2011.05.22, 23:36:46
Quote from: demetrioussharpe on 2011.05.22, 22:24:23
Quote from: RobertM on 2011.05.22, 22:07:21
One core feature missing in the current OS/2 support is the ability to set full screen modes (whether a PM window or a VIO graphics window) to the monitor that contains the majority of the object being full-screened.

The current driver setup probably does have some portion this capability, but it is unused except via xWP's multiple desktop feature, where "invalidated" desktop areas are not used or considered when making an object full screen.

What do you mean? Please explain farther. Are you referring to being able to have a window moved to another monitor where it only shows that window in fullscreen mode? Is the window even shown, or is it just the client area where the data shows up at?

Hi,

If you are currently running a multi-monitor setup under OS/2 (as I do), let's say you have a PM window open (any... a folder, an app, whatever), and the window is constrained to one monitor. When you full screen it, the window is full screened across both monitors, as opposed to being full screened to only the monitor it is on.

The same applies (unless something has changed recently) to using various video player apps in full screen mode (such as mPlayer). Or when switching such an app from windowed to full screen. In the case of mPlayer, that means the video is centered across both viewports on both monitors, with half the video on one, and the other half on the other monitor.

Each of those issues is of course separate, with the first probably being easier to address. And of course, the desired results would be something akin to what happens in Windows. For instance, when I am watching Netflix on my laptop, the external port is usually plugged into my TV. I have a browser window open on the LCD, and one open on the secondary viewport (ie: the TV). If I full screen the Netflix player (or YouTube video, or whatever), it only full-screens to the viewport that corresponds with the original windowed object. That allows me to watch videos on the secondary viewport, while having another browser window/folders/whatever, still viewable on the primary viewport. OS/2 currently will full screen across both and center the image - and of course, also reports the combined resolution size as one single viewport (in my case, on my OS/2 setup, that's 2560x1024, instead of (2) x 1280x1024).

Best,
Rob

So from what I'm understanding (& based on the pics), you want to be able to choose between these two types of viewing, but you'd like for both of them to be possible, correct?
Title: Re: Multi-monitor Systems
Post by: warpcafe on 2011.05.23, 12:51:00
Hi Dee,

not sure if that is a feature that would be on your side of the fence, but... at work, on Windows, the driver we use (Intel IIRC) provides us with an additional window button (close to the upper right edge of window title bar) which, when clicked, moves the current window to the next screen. (That kinda saves you from dragging windows around your extended desktop).

Example:
- I have a 22" wide screen TFT attached to my laptop
- Both act as an extended desktop, with each having its own different resolution
- As soon as the laptop detects the external TFT being attached, it
-- a) extends the desktop
-- b) provides the additional window button (always only for the window having the focus)

Button behaviour:
- When I launch the browser, its window appears -say- on my laptop screen
- When it has the focus (obviously immediately when it's just launched) the new button appears
- Clicking on the button will move the window onto the external TFT's screen
- Clicking the button again will make the window being moved back onto my laptop's screen
(There is some logic around the screen-swapping, as the window is scaled and moved in accordance with where/how it was on the previous screen. And, oh yes, that button is only activated for non-fullscreen windows...)

But again, as I said, I am not sure if you are the correct recipient for the "button thing"... at least I guess you would need to provide an API function for it. (?)

Other than that, my experience with multiple screen on OS/2 is limited to that very special moment when I had a Matrox multihead card being returned by a customer: I thought "why not give it a try", plugged it into my desktop and made it work ...(drumroll)... only to discover that I was only able to make it clone the desktop. Not extend it. I said "what kinda crap is that?!". And that's it. :-P

Cheers,
Thomas
Title: Re: Multi-monitor Systems
Post by: demetrioussharpe on 2011.05.23, 20:07:26
Quote from: warpcafe on 2011.05.23, 12:51:00
Hi Dee,

Hello!


Quotenot sure if that is a feature that would be on your side of the fence, but... at work, on Windows, the driver we use (Intel IIRC) provides us with an additional window button (close to the upper right edge of window title bar) which, when clicked, moves the current window to the next screen. (That kinda saves you from dragging windows around your extended desktop).

Example:
- I have a 22" wide screen TFT attached to my laptop
- Both act as an extended desktop, with each having its own different resolution
- As soon as the laptop detects the external TFT being attached, it
-- a) extends the desktop
-- b) provides the additional window button (always only for the window having the focus)

Button behaviour:
- When I launch the browser, its window appears -say- on my laptop screen
- When it has the focus (obviously immediately when it's just launched) the new button appears
- Clicking on the button will move the window onto the external TFT's screen
- Clicking the button again will make the window being moved back onto my laptop's screen
(There is some logic around the screen-swapping, as the window is scaled and moved in accordance with where/how it was on the previous screen. And, oh yes, that button is only activated for non-fullscreen windows...)

This is a very interesting idea & I feel that something like this could be considered to be part of the framework; I really like this idea a lot! Is this button positioned on the left side of the maximize/minimize/close button cluster? It ONLY displays on the window that  has focus? Is this button always available, or does it only work on extended desktops or something like that?


QuoteBut again, as I said, I am not sure if you are the correct recipient for the "button thing"... at least I guess you would need to provide an API function for it. (?)

I'm under the assumption that no one will use my driver work (regardless of quality) unless I build a solid, useable userspace API around it (& configuration apps to control the features & functions). You've come to the right place, I'll be sure to put this on my feature list when I start writing the userspace support portions.


QuoteOther than that, my experience with multiple screen on OS/2 is limited to that very special moment when I had a Matrox multihead card being returned by a customer: I thought "why not give it a try", plugged it into my desktop and made it work ...(drumroll)... only to discover that I was only able to make it clone the desktop. Not extend it. I said "what kinda crap is that?!". And that's it. :-P

Yeh, that would've been my response too! What good is it to have multiple screens, if the only thing that the extra screen(s) can show is the same stuff that's on your primary screen??? Hopefully, I can do better!
Title: Re: Multi-monitor Systems
Post by: RobertM on 2011.05.23, 22:32:52
Quote from: demetrioussharpe on 2011.05.23, 00:42:10
Quote from: RobertM on 2011.05.22, 23:36:46
Quote from: demetrioussharpe on 2011.05.22, 22:24:23
Quote from: RobertM on 2011.05.22, 22:07:21
One core feature missing in the current OS/2 support is the ability to set full screen modes (whether a PM window or a VIO graphics window) to the monitor that contains the majority of the object being full-screened.

The current driver setup probably does have some portion this capability, but it is unused except via xWP's multiple desktop feature, where "invalidated" desktop areas are not used or considered when making an object full screen.

What do you mean? Please explain farther. Are you referring to being able to have a window moved to another monitor where it only shows that window in fullscreen mode? Is the window even shown, or is it just the client area where the data shows up at?

Hi,

If ... still viewable on the primary viewport. OS/2 currently will full screen across both and center the image - and of course, also reports the combined resolution size as one single viewport (in my case, on my OS/2 setup, that's 2560x1024, instead of (2) x 1280x1024).

Best,
Rob

So from what I'm understanding (& based on the pics), you want to be able to choose between these two types of viewing, but you'd like for both of them to be possible, correct?

Not particularly concerned if the current method works. That I am presuming should still be easily achievable by manually resizing the window across viewport. More concerned with (which OS/2 currently doesn't do) constraining a full screen request to a single monitor.
Title: Re: Multi-monitor Systems
Post by: demetrioussharpe on 2011.05.24, 04:47:57
Quote from: RobertM on 2011.05.23, 22:32:52
Not particularly concerned if the current method works. That I am presuming should still be easily achievable by manually resizing the window across viewport. More concerned with (which OS/2 currently doesn't do) constraining a full screen request to a single monitor.

Ok, to be clear, you'd like the capability to make the app maximize, but be confined to just one screen?
Title: Re: Multi-monitor Systems
Post by: RobertM on 2011.05.24, 10:04:25
Quote from: demetrioussharpe on 2011.05.24, 04:47:57
Quote from: RobertM on 2011.05.23, 22:32:52
Not particularly concerned if the current method works. That I am presuming should still be easily achievable by manually resizing the window across viewport. More concerned with (which OS/2 currently doesn't do) constraining a full screen request to a single monitor.

Ok, to be clear, you'd like the capability to make the app maximize, but be confined to just one screen?

Correct... (wow, that's a lot less wordy than my attempt). Comes in handy for watching videos... rather annoying having a video split across two monitors.  ;)

Question, how do you plan on handling full screen CMDLINE sessions?
Title: Re: Multi-monitor Systems
Post by: demetrioussharpe on 2011.05.25, 07:22:21
Quote from: RobertM on 2011.05.24, 10:04:25
Question, how do you plan on handling full screen CMDLINE sessions?

Well, my plan is to present the compositor with a virtual framebuffer by using a virtual driver class to communicate with the actual video cards. This will provide enough seperation to allow the rendered output's destination to be changed without disrupting the actual data. By changing the configuration of the virtual framebuffer, the virtual driver can decide which data goes to which screen. Ideally, that should cover the command line sessions that're used as full screen, also. However, I'm sure that there will be quite a few edge cases that'll have to be worked out in order to mature the codebase.
Title: Re: Multi-monitor Systems
Post by: warpcafe on 2011.05.25, 11:12:43
Hi,

sounds like a plan. ;) Also this would solve a couple of possible annoyances I came across when thinking about how it would work.
I remember that when I was developing software, one of my usual lines of code went like

Quote"make window become centered horizontally and vertically" - pseudo code:

win.top = int ( ( screen.height - win.height ) / 2 )
win.left = int ( ( screen.width - win.width ) / 2)

I am sure almost every developer has some flavor of this code lying around... and I wonder what the impact will be when this is used, for instance, in a 2-monitor extended desktop setup...? Will the window appear 50% on right margin of left screen and 50% on left margin of right screen then? Will the virtualized driver/framebuffer handle this for the requesting applications automatically? Or is that already covered by the way how OS/2 works?

Feature request: (While we're at it... ;) )
One thing that really drives me nuts with an extended desktop (here: windows) is the following:
- you have 2 screens: A and B
- you launch a program and its window appears on screen A
- you drag the window onto screen B
- now you do something that causes a secondary window of the program to become opened (e.g. "open file" dialog)
-> ta-daa: This "popup" appears on screen A.

The problem is that if you look an the program window on screen B you hardly notice the secondary window at all.
I am not sure if that can be handled in an elegant way so that it becomes "transparent" to applications that they automatically stick to the screen they're currently being displayed upon... would be great though... :-P

Cheers,
Thomas
Title: Re: Multi-monitor Systems
Post by: warpcafe on 2011.05.25, 12:14:57
Hi,

Quote from: demetrioussharpe on 2011.05.23, 20:07:26
This is a very interesting idea & I feel that something like this could be considered to be part of the framework; I really like this idea a lot! Is this button positioned on the left side of the maximize/minimize/close button cluster? It ONLY displays on the window that  has focus? Is this button always available, or does it only work on extended desktops or something like that?

Exactly.
That feature becomes available only if the video driver detects that
- there is more than one output device
- the desktop is extended
And then, the button is displayed on "active" titlebars only (meaning only the focused window has it)

However... this dynamic way of showing an additional button only for the focused window isn't mandatory for me - it would be OK to have it also on the "incative" windows (or "all" windows so to say). Not sure which way is easier to imlement.

One glitch however happens with windows that use their own style: While the button displays correctly on all windows that use the default theme currently selected, it overlays the standard button cluster (min|max|resize,close) of e.g. Google Chrome. I've attached a sample screenshot. And the additional button is not really aligned correctly even with the standard window styles... looks pretty much like a window handler "hack" to me.

Note that the feature perhaps is cool, however its implementation into the user interface is a bit... sluggish.
An "elegant" way of implementing this in eCS could be to provide this function in a way that the usual "enahncers" (XWP, eWP, eStyler) can make use of it. Example: "middle-button click on titlebar" or ctrl-doubleclick... or any hotkey combination like shift+ctrl+cursor-left... ;)

Cheers,
Thomas
Title: Re: Multi-monitor Systems
Post by: Sigurd on 2011.05.25, 13:47:08
Quote from: miturbide on 2011.05.22, 22:23:08
"Monitor orientation - landscape, portrait and the inverse ones"

I meant to have the 4 orientation modes posible. Landscape and Landscape upsidedow. Portrait and portrait upside down. Just like rotating the monitor 90º in the 4 positions that you can..... sorry Im not good explainin it in english.

Other feature to add:

  • Autodetect quantity of monitors

Hi,

it would like to have these feature as well! As you may have seen in my Youtube videos I am using a X200T (Tablet) notebook quite well with OS/2.

With Windows (XP, Vista or 7) there is a function to rotate the Display, as Martin describes. Even though it can use "auto rotation" as well, so it automatically jumps to the view depending in wich way the user moves the Laptop.

There is a hardwarebutton (below the screen) for Rotation availiable as well.

For me I would be very happy to have the possibility to rotate the screen and "by hand" would be really very good.
Auto Rotation is not necessary at all - even if it is quite cool :-)
Having the hardware button working for this would be great as well, because once you switch to tablet mode by Flipping the Screen around -it does lay on the keyboard and covers the keys :-( (You can see this happening almost in the end of my vidoe "The longest death in computer history" at youtube)
With Wim Brul we have been able to use the Stylus as a mouse replacement - and that is really cool by the way - it would be good to have a possibility to change Rotation by having a Mouse command defined so that this could be used with the Stylus.

I am really looking forward to see what will happen with your project. If I can be helpfull in testing "rotation" or something like this - just ask for!

Here a picture with Warp 4 MCP2 and the X200T


Title: Re: Multi-monitor Systems
Post by: warpcafe on 2011.05.25, 14:09:52
Hi,

looking at Sigurds scenario, again the solution wouold be to provide a "hookable" function that can be used by the enhancers.
OK, a hotkey will not make sense here because the keyboard isn't accessible. But even then, if someone comes up with a "mous gesture" handler for the enhancers, the function "rotate primary screen" could be assigned a gesture.

The most relevant part here for me is that the driver must be able to handle screen rotations separately for each physical screen.
That's quite some fiddling around the actual core task to have a driver :))

I strongly recommend to think about modularization of the tasks/features:
If one provides API calls to rotate screen(s), clone|extend dekstop, swap screen for a given window these could be made available to the next layer of user applications which would then make them available as mouse gestures, hotkeys or even -heck- launchpad buttons. In any way it saves the driver developer from having to hardcode everything in the first stage with roughly about 98,5% of users complaining that they prefer a different method for ... whatever.

Just my 2ct, cheers,
Thomas
Title: Re: Multi-monitor Systems
Post by: demetrioussharpe on 2011.05.25, 15:36:01
Quote from: warpcafe on 2011.05.25, 11:12:43
Hi,

sounds like a plan. ;) Also this would solve a couple of possible annoyances I came across when thinking about how it would work.
I remember that when I was developing software, one of my usual lines of code went like

Quote"make window become centered horizontally and vertically" - pseudo code:

win.top = int ( ( screen.height - win.height ) / 2 )
win.left = int ( ( screen.width - win.width ) / 2)

I am sure almost every developer has some flavor of this code lying around... and I wonder what the impact will be when this is used, for instance, in a 2-monitor extended desktop setup...? Will the window appear 50% on right margin of left screen and 50% on left margin of right screen then? Will the virtualized driver/framebuffer handle this for the requesting applications automatically? Or is that already covered by the way how OS/2 works?

Feature request: (While we're at it... ;) )
One thing that really drives me nuts with an extended desktop (here: windows) is the following:
- you have 2 screens: A and B
- you launch a program and its window appears on screen A
- you drag the window onto screen B
- now you do something that causes a secondary window of the program to become opened (e.g. "open file" dialog)
-> ta-daa: This "popup" appears on screen A.

The problem is that if you look an the program window on screen B you hardly notice the secondary window at all.
I am not sure if that can be handled in an elegant way so that it becomes "transparent" to applications that they automatically stick to the screen they're currently being displayed upon... would be great though... :-P

Cheers,
Thomas

I don't think it depends so much on the framebuffer, as it most likely depends on how the GUI is designed. In some OSs, the GUI would default to trying to start the window at the top left corner. For some, it's the center of the screen. If these defaults are not wanted, the app designer is usually able to specify where they'd like the window to appear at initially. You may actually be dealing with a product of app designer didn't expect the desktop to ever be so big, so the window always opens in the first screen.
Title: Re: Multi-monitor Systems
Post by: demetrioussharpe on 2011.05.25, 17:21:26
Quote from: warpcafe on 2011.05.25, 12:14:57
Hi,

Quote from: demetrioussharpe on 2011.05.23, 20:07:26
This is a very interesting idea & I feel that something like this could be considered to be part of the framework; I really like this idea a lot! Is this button positioned on the left side of the maximize/minimize/close button cluster? It ONLY displays on the window that  has focus? Is this button always available, or does it only work on extended desktops or something like that?

Exactly.
That feature becomes available only if the video driver detects that
- there is more than one output device
- the desktop is extended
And then, the button is displayed on "active" titlebars only (meaning only the focused window has it)

However... this dynamic way of showing an additional button only for the focused window isn't mandatory for me - it would be OK to have it also on the "incative" windows (or "all" windows so to say). Not sure which way is easier to imlement.

One glitch however happens with windows that use their own style: While the button displays correctly on all windows that use the default theme currently selected, it overlays the standard button cluster (min|max|resize,close) of e.g. Google Chrome. I've attached a sample screenshot. And the additional button is not really aligned correctly even with the standard window styles... looks pretty much like a window handler "hack" to me.

Note that the feature perhaps is cool, however its implementation into the user interface is a bit... sluggish.
An "elegant" way of implementing this in eCS could be to provide this function in a way that the usual "enahncers" (XWP, eWP, eStyler) can make use of it. Example: "middle-button click on titlebar" or ctrl-doubleclick... or any hotkey combination like shift+ctrl+cursor-left... ;)

Cheers,
Thomas

I'm sure that something can be worked out that'll be less of a visual distraction!
Title: Re: Multi-monitor Systems
Post by: demetrioussharpe on 2011.05.25, 17:26:10
Quote from: Sigurd on 2011.05.25, 13:47:08
Quote from: miturbide on 2011.05.22, 22:23:08
"Monitor orientation - landscape, portrait and the inverse ones"

I meant to have the 4 orientation modes posible. Landscape and Landscape upsidedow. Portrait and portrait upside down. Just like rotating the monitor 90º in the 4 positions that you can..... sorry Im not good explainin it in english.

Other feature to add:

  • Autodetect quantity of monitors

Hi,

it would like to have these feature as well! As you may have seen in my Youtube videos I am using a X200T (Tablet) notebook quite well with OS/2.

With Windows (XP, Vista or 7) there is a function to rotate the Display, as Martin describes. Even though it can use "auto rotation" as well, so it automatically jumps to the view depending in wich way the user moves the Laptop.

There is a hardwarebutton (below the screen) for Rotation availiable as well.

For me I would be very happy to have the possibility to rotate the screen and "by hand" would be really very good.
Auto Rotation is not necessary at all - even if it is quite cool :-)
Having the hardware button working for this would be great as well, because once you switch to tablet mode by Flipping the Screen around -it does lay on the keyboard and covers the keys :-( (You can see this happening almost in the end of my vidoe "The longest death in computer history" at youtube)
With Wim Brul we have been able to use the Stylus as a mouse replacement - and that is really cool by the way - it would be good to have a possibility to change Rotation by having a Mouse command defined so that this could be used with the Stylus.

I am really looking forward to see what will happen with your project. If I can be helpfull in testing "rotation" or something like this - just ask for!

Here a picture with Warp 4 MCP2 and the X200T




Though, I'm not sure what effect my implementation of these features will have on your tablet, I look forward to providing them in the hopes that someone will be able to tie them to the actual hardware within your device.
Title: Re: Multi-monitor Systems
Post by: demetrioussharpe on 2011.05.25, 17:30:13
Quote from: warpcafe on 2011.05.25, 14:09:52
Hi,

looking at Sigurds scenario, again the solution wouold be to provide a "hookable" function that can be used by the enhancers.
OK, a hotkey will not make sense here because the keyboard isn't accessible. But even then, if someone comes up with a "mous gesture" handler for the enhancers, the function "rotate primary screen" could be assigned a gesture.

The most relevant part here for me is that the driver must be able to handle screen rotations separately for each physical screen.
That's quite some fiddling around the actual core task to have a driver :))

I strongly recommend to think about modularization of the tasks/features:
If one provides API calls to rotate screen(s), clone|extend dekstop, swap screen for a given window these could be made available to the next layer of user applications which would then make them available as mouse gestures, hotkeys or even -heck- launchpad buttons. In any way it saves the driver developer from having to hardcode everything in the first stage with roughly about 98,5% of users complaining that they prefer a different method for ... whatever.

Just my 2ct, cheers,
Thomas

My plan is to put this virtual device within EMIT3D.DLL. It will be the lowest layer within that dll, so it'll talk directly to the video drivers. It's presence should not change anything for the driver writers, because it will communicate to the drivers through the same interface as was already planned for the drivers.
Title: Re: Multi-monitor Systems
Post by: RobertM on 2011.05.25, 22:39:07
Quote from: demetrioussharpe on 2011.05.25, 07:22:21
Quote from: RobertM on 2011.05.24, 10:04:25
Question, how do you plan on handling full screen CMDLINE sessions?

Well, my plan is to present the compositor with a virtual framebuffer by using a virtual driver class to communicate with the actual video cards. This will provide enough seperation to allow the rendered output's destination to be changed without disrupting the actual data. By changing the configuration of the virtual framebuffer, the virtual driver can decide which data goes to which screen. Ideally, that should cover the command line sessions that're used as full screen, also. However, I'm sure that there will be quite a few edge cases that'll have to be worked out in order to mature the codebase.

Ummm... wow! If I'm following you correct, that means true full-screen to windowed (or vice versa) switching, simply by reassigning the output. Nice!
Title: Re: Multi-monitor Systems
Post by: demetrioussharpe on 2011.05.25, 23:21:25
Quote from: RobertM on 2011.05.25, 22:39:07
Quote from: demetrioussharpe on 2011.05.25, 07:22:21
Quote from: RobertM on 2011.05.24, 10:04:25
Question, how do you plan on handling full screen CMDLINE sessions?

Well, my plan is to present the compositor with a virtual framebuffer by using a virtual driver class to communicate with the actual video cards. This will provide enough seperation to allow the rendered output's destination to be changed without disrupting the actual data. By changing the configuration of the virtual framebuffer, the virtual driver can decide which data goes to which screen. Ideally, that should cover the command line sessions that're used as full screen, also. However, I'm sure that there will be quite a few edge cases that'll have to be worked out in order to mature the codebase.

Ummm... wow! If I'm following you correct, that means true full-screen to windowed (or vice versa) switching, simply by reassigning the output. Nice!

Basically, yes. But, as always, the devil is in the details.
Title: Re: Multi-monitor Systems
Post by: jep on 2011.05.28, 09:37:54
Hello,

the first two images show how pointer movement between two screens can be handled.
It's very confusing if the pointer doesn't appear on the second screen right next to the exit point from the first screen.

The rest of the images show a few 3D-CAD images that I modeled some time ago.

Missing images:
CRT Monitor
Monitor and projector
Monitor and TV
Monitor and Laptop
...?

//Jan-Erik
Title: Re: Multi-monitor Systems
Post by: demetrioussharpe on 2011.05.28, 23:01:27
Quote from: jep on 2011.05.28, 09:37:54
Hello,

the first two images show how pointer movement between two screens can be handled.
It's very confusing if the pointer doesn't appear on the second screen right next to the exit point from the first screen.

The rest of the images show a few 3D-CAD images that I modeled some time ago.

Missing images:
CRT Monitor
Monitor and projector
Monitor and TV
Monitor and Laptop
...?

//Jan-Erik

I can't promise that you'll be able use an extended desktop on multi-head setups that use displays without identical resolutions.
Title: Re: Multi-monitor Systems
Post by: jep on 2011.05.30, 09:49:00
Yes, I guess it would be a bit of a challenge to create something like that on top of everything else.

I hope you all understood the purpose of the red line(s) in the first two images!
The red line(s) show where the user can't exit one view and enter the other and where to move the mouse pointer by hand as the arrows show.
Only the overlapping length of the adjacent sides can be used for the mouse pointer to go from one monitor/view to the other.

Another interesting feature would be to set/switch which monitor should act as No 1 and the next as No 2 etc to allow e.g. laptops to use a large external monitor as the primary display
Several of our developers where I work use that feature when they're sitting in the office.

//Jan-Erik
Title: Re: Multi-monitor Systems
Post by: demetrioussharpe on 2011.05.31, 00:11:50
Quote from: jep on 2011.05.30, 09:49:00
Yes, I guess it would be a bit of a challenge to create something like that on top of everything else.

Yeh, it really would complicate things vastly. Afterall, I'm new to a lot of this.


Quote
Another interesting feature would be to set/switch which monitor should act as No 1 and the next as No 2 etc to allow e.g. laptops to use a large external monitor as the primary display
Several of our developers where I work use that feature when they're sitting in the office.

Quite honestly, that's one of my next few blocks of code to work on. Though, I had different motivations for it, I wanted to be able to change the order of framebuffer outputs. In addition to the usage case that you just touched on, it would also allow you to setup a multitude of monitors & decide the order that they are in. This would be beneficial when you take into consideration a 3x2 or 3x3 display setup. You'd want the final desktop image to be in the correct order, so you'd want to be able to configure the output regardless of the actual physical layout of the monitors.
Title: Re: Multi-monitor Systems
Post by: warpcafe on 2011.06.21, 14:26:24
Hi Rob,

Quote from: RobertM on 2011.05.22, 23:36:46
If you are currently running a multi-monitor setup under OS/2 (as I do),
... [snip]

ehhh... looking at your pics... how the heck did you manage to get this to work in eCS?
I was always able to only clone the desktops. What's the trick behind it?

You might have mentioned it somewhere in the thread, but are you running this
- with Matrox "DualHead2Go" or similar
- by using SNAP instead of Panorama or vice-versa including the "widescreen activator"
- or is this a virtualized eCS

Please let me know, cheers,
Thomas