How multiple displays should work?

Development OS
1

I am considering to implement multiple display support in app_server, but I am not sure how it should work:

  1. How workspaces should work for multiple displays? Is single workspace correspond to single display or it contains all displays?
  2. Consider single window that is partially crossing display borders. Should it be displayed only on single screen or it parts should be displayed on both screens? Is it useful to display window parts on multiple screens?

Maybe it will be good to create poll, but I don’t know how to do it or I don’t have enough permissions for it.

15 Likes
2
  1. For reference, macOS uses separate “Spaces” for separate displays. It is possible to move a space from one display to another. If the display is plugged out (from a laptop in this case), all spaces are moved to the built-in display, and restored upon re-plug. I find it adequate, and intuitive.
  2. There should be some sort of display placement setup I guess. If two displays are set next to each other in preferences, they should share the window contents.
4 Likes
3

If the second monitor (external monitor on the laptop) is not reconnected under Windows, windows / displays outside of the range will NO longer be displayed!
You have to manually bring it back into the visible area (e.g. laptop display)! This is big crap and not mature or thought through to the end!
Otherwise under Windows: Have a look at DisplayFusion (https://www.displayfusion.com/) …

1 Like
4

Thanks X512, that would be awesome !

  1. I prefer my workspace to contain both displays, it seems easier to reposition windows from one screen to another this way. And when I switch to a new workspace, I have two empty screens in front of me to compose a new work area with new tasks. I have tried Gnome activities on Linux which behave differently, with a fixed workspace on the left monitor and activities/workspace switching on the right, but didn’t like it.

  2. I find it more aesthetically pleasing to have windows crossing display borders, because both my monitors are on the same workspace. Otherwise, it would be weird, when you drag and drop a window from one monitor to the other, to have it disappear progressively from the first monitor and then reappear instantly on the second monitor when your mouse pointer crosses the threshold between the two displays. But if it proves too difficult to code this behavior, I can live without it.

1 Like
5

X512, it would be awesome! I have 4 displays that just wait for multidisplay support to be implemented. Having 4 displays with only one of them connected really bothers me.

A workspace is by definition everything visible at the same time. Therefore workspace contains both displays.

Yes, if a window is crossing the display border, the second part of it appears on the second screen. This is very helpful with file/folder compare program: you stretch the window so that the left part of list of files to be compared is on the left display, the right (with another list of files) on another display, and you are not limited to the display width. For example, in Krusader you stretch the window to both displays, and the local filesystem is on the left display, while the remote filesystem is on the right. Drawing the window on both displays is a requirement for these usecases.

6

I think it really depends of what you’re doing.
There are people who want a cloned workspace. i.e to run a demo for a customer on a booth. You can also imagine using a projector as second display at a conference.

In some case you may want to work on a display and see results in another.
I.e you’re editing a video or making a 3D object on a workspace and have preview or rendering on another. Generally, people in this case have two different kind of monitors one usually bigger.

In another case, you’re looking for immersion in what you’re doing. Ie. You play with a car racing simulator. You want it shown on your two or even three monitors. Those people have usually two times same or very similar monitors.

7

Can we have “both”? Most of the time, it would be useful to have a workspace cover all displays, but it could also be useful to have separate workspaces for separate displays, and then “mix and match.” Now I kind of wish some other OSes had that feature…

It is definitely useful in some applications to span screens, so this should be generally supported I think, yes. But maybe for a “first cut” it is not necessary.

2 Likes
8

This would be very neat to see @X512! In terms of thinking in relation to the current API, in addition to making sure BeOS R5 compatibility is preserved (through APIs such as BScreen and BWindow), I would place one workspace on each display. After all, workspaces are already aware of separate colorspaces and screen resolutions, BWindow at least has a “ScreenChanged()” method, and BScreen has a naive idea of separate screen ids and has the “SetToNext()” function. (You can take my opinion with a grain of salt. After all, I’m just another person on the internet. :wink:)

9

Another personal/professional kind of use. It suits me best to have only one workspace at laptop screen where I have always shown apps/windows (like collaboration software) and 2-3 workspaces on the external (big) monitor. Working well on Gnome based distributions.

10

The general agreement in the devteam last time this was discussed (a long time ago) was that a workspace includes everything that’s visible on all displays. I don’t think it was a very strong agreement however. This is also what we had with the hacked multi-display support in the old Radeon and Matrox drivers.

There are many things to take into account, I think:

  • Keeping things simple: while having separate workspaces for each display is powerful, it can also become confusing if the user interface isn’t well designed.
  • Handling setups with different monitor resolutions, sizes, and dpi. While the solution implemented in Linux and Windows both sort of work, they don’t look that great. Windows will be drawn according to the font size of the display they are “mainly” in, and scaled (I guess by compositing tricks) for the parts that are on other displays. Then as you move the window more and more to another display, suddently it is redrawn natively at the new size.
  • Having different screenmodes and colorspaces: how will the Screen preferences look when handling a combination of displays and workspaces?
  • In Haiku-native programs (usually several separate windows) it’s fine to not allow a window to be in multiple displays. But maybe not so much in some ported apps or in general apps designed to be one huge window with lots of things in it, where you may just want a really large window (think things like Blender, SynC Modular, …)
  • What will be the behavior when trying to drag a window from one screen to another if we don’t allow the window to be visible on both sides? Show only an outline until the window is actually moved? Have it switch instantly to the other screen when the cursor crosses the boundary?

Besides MacOS, Windows and Linux, I think it’s not a bad idea to look at how it’s done on Amiga (and MorphOS as they have multiple displays support now). I think they are the one going strongly in the “different set of worspaces per display” so we can see how it goes for them.

I’m not sure if a poll is the right thing at this point, I think it’s more interesting to discuss the various options a bit more to be sure we understand their forces and weaknesses. Maybe even go as far as writing some code to experiment with both, but that could be too much work.

1 Like
11

app_server itself already supports multiple displays; I’ve described this in my blog when I implemented it: https://www.haiku-os.org/blog/axeld/2005-11-03_workspaces/ (it was really 15 years ago!)

It’s certainly possible to change how that works, but it’s not where you should start to work on.

What is still missing, though, is support for this in the accelerants, including their current API. If you look into the mailing lists, you will find several suggestions on how to change that. One would be to instantiate the accelerant for each attached display (that would require only minimal API changes, ie. the app_server would need to specify the display to use when instantiating the accelerant. The nicer solution would probably be to create a new accelerant API.

As you might have noticed, the app_server test environment already supports multiple displays.

12

Another idea on where to start would be to use (read: implement support for this) the remote HWInterface as a second screen.

13

Another idea on the accelerants side is to add a “display id” to the accelerant hooks, there is a proof of concept for this (very incomplete): https://review.haiku-os.org/c/haiku/+/329
This allows having a single accelerant managing multiple displays.

Possibly we need both: multiple displays on the same video card managed by the same accelerant, and multiple accelerants to manage multiple video cards.

14

In Windows 10, window is displayed on both screens but if screen DPI is different, window will have DPI of current screen. When moving window to screen with another DPI, it will suddenly change size. At least this applies to applications with DPI support.

It supports multiple windows.

I think that it is a best option. Moving windows in Workspaces works in similar way.

I never used Amiga (except in emulator for games) and I don’t know what is happening there.

1 Like
15

It is currently is not possible to move window to another screen. DrawingEngine (and related HWInterface) is set in Window constructor and there are currently no way to change it for existing Window object. Another problem is that Desktop object currently manage both user sessions and window drawing on screen (region calculation etc.). If common framebuffer for all screens approach will be not used, each screen should have separate window list and drawing management. So Desktop object can be separated to Desktop (handle user session and running applications) and DesktopScreen (handle window drawing on specific screen).

1 Like
16

My current plan of work:

  1. Implement and test multiple screen support in test_app_server. Each screen is represented as a window of host app_server. It should be possible move windows between screens, screen connecting/disconnecting should work (disconnecting is currently not implemented), BScreen and related API should work, Tracker and Deskbar should create/destroy windows on each screen.
  2. Create accelerant2 API with screen ID and hot-plug notification support. Add accelerant2 API support in app_server while keeping old API. Adjust Intel GPU driver to accelerant2 API. Keep other drivers on old API because I don’t have hardware to test.

Of course multiple video drivers should work simultaneously. It should not cause problems (at least before hardware 3D acceleration support), just create separate HWInterface for each screen.

1 Like
17

I don’t see any issues with Desktop, could you explain what you mean exactly (I’m not too close to the details anymore).
IIRC the plan was to create a multiplexing HWInterface/DrawingEngine, that would allow to move the issue to a deeper level. It should also be possible to scale windows differently on different screens, but I didn’t really think about that when I implemented the rest.

18

Desktop object is doing 2 things:

  1. Manage user session. It store user ID and list of applications running in this session.
  2. Manage window drawing on specific screen. It has background region, it calculate visible regions of windows, manage repainting. One way to implement multiple screen support is to move this logic at per-screen level.

What does it mean? Create one HWInterface for all screens that will provide one common framebuffer for drawing? It will not allow this feature:

19

A multiplexing HWInterface would be one that just forwards the drawing calls to other interfaces. It would check the window position and send the commands to the HWInterface for the corresponding screen. It would not have a framebuffer on its own in this setup.

If we want window to be able to render in two screens (because they are moved in between them for example) it would need to send the drawing commands to both screens, I guess.

Then you can do some fun things like multiplexing to a mix of local and remotedesktop displays to infinitely expand your display.

1 Like
20

Good day,

Regarding this, and thinking back that I changed from 2 display setup to 1 UW due to lack of Haiku support for multiple displays on my HW, I can think of two ways to approach this (without knowing so much yet how things work on Haiku):

1- Display root:
---- Virtual display (workspaces)
-------- physical display 1
-------- physical display N
In this situation there is only one virtual display that holds all physical devices as a whole single desktop, extending from the Master to the attached ones according to user setup
In this situation, a workspace matches the virtual display, and each workspace shows a new desktop set. Changing from one workspace to another changes the whole set

2- Display root:
---- Physical display 1 (workspaces1)
---- Physical display N (workspacesN)
In this situation each display is independent of the rest and they act as such.
In this situation, a workspace matches the physical display in which it’s set, so changing from one workspace to another only changes the physical display in which user selects a different workspace keeping other physical displays unchanged.

Now, moving windows in the situation 1 is easy, as workspace switcher would show all workspaces that match the virtual display (whole desktop), so it would work as only one display attached, as it works now with single display.
Situation 2 would make things a bit more complex, as dragging windows between workspaces inside one display would be as it is now, but in order to move it to another display need to think on how to send the window to the other display (right click on window tab -> send to display N workspace M?).

Of course could be possible arrange a mix of both, but I presume that would be complex to implement and it would make sense in cases where user has more than 2 physical displays.

While I would like to have plenty, I mean 4 physical displays, I have no physical space (and coin) to set a 4 display system unless all are 17 inch, 24 at most, and having everything way too tight on the table.

Both approaches have their pros and cons. I can think of keeping one screen always with some stuff running and another screen to do other things and workspace switching on the later only, in my case, only with the laptop now, as desktop is single display setup.

Then again, if Haiku implements something like “show all workspaces”, for single virtual display (situation 1), I think it could be like a “gallery” of all workspaces/desktops. For several physical displays, it “should” show available displays with their workspaces, be it in a gallery like, scrolling, whatever… Where each “display” entry shows its whole workspace children? Problem here, where should show this? In the first display?, the Nth? all together?

Just thinking aloud.
Regards,
RR