add to accelerant api to support managing multiple montors

[kallisti5]

We could add to the accelerant API to enable the app_server to detect the number of displays on a card, and tell the accelerant instance which display to focus on.

That would mean that the app_server would spawn one accelerant for every attached monitor. (we would need to throughly go over locking in each video card driver however)

This ticket is to track the progression of this idea. As these changes may bump the API, *NO* diffs attached should be pushed upstream until a final decision is reached.

We also need to decide if such a change is a pre-or post R1 change. We could start laying the groundwork pre-R1 so the changes post-R1 would be minimal. (however, that needs some discussion). Without a change to the accelerant api, Haiku will not support multiple displays at R1.

[kallisti5]

revision 1 of the proposed changes, likely needs expanding.

[kallisti5]

in the 1st revision patch, connector_type and encoder_type are populated by the macros in ​http://cgit.haiku-os.org/haiku/tree/headers/private/graphics/common/video_configuration.h

[kallisti5]

revision 2 of the proposed changes, added hook to set display to focus on.

[axeld]

Close as duplicate of #8612?

[kallisti5]

well.. #8612 is the app_manager side of it. we could call this the accelerant side of the issue as the app_server would just be the consumer of these changes. (thus #10486 blocking 8612)

[kallisti5]

hm.. is there any reason I have to bump the accelerant api? I don't see very many use cases for people running accelerants from other (older / newer) haiku versions pre-R1.

[axeld]

I'm not sure if it ever has been bumped, but if it has, there is indeed no need to do that again.

[kallisti5]

evision 3 of the proposed changes. Rename hooks and expand monitor info

[axeld]

How about renaming B_GET_ATTACHED_DISPLAY_COUNT to B_ACCELERANT_DISPLAY_COUNT to make it better fit the rest? (and also your other suggested addition) Same for the typedef then, of course. And if you're already about to add FBC protection to the monitor_info struct, you can as well add a bit more than just a single uint32. Alternatively, we can also provide the size of the structure, so it can always be extended.

[kallisti5]

How about renaming B_GET_ATTACHED_DISPLAY_COUNT to B_ACCELERANT_DISPLAY_COUNT to make it better fit the rest? (and also your other suggested addition) Same for the typedef then, of course.

Originally I went with the differing name as the display count isn't central to the instance of the accelerant, but is central to the card. (aka, displaycount represents to total attached displays on a card, it isn't accelerant specific as the accelerant will generally only handle a single display)

And if you're already about to add FBC protection to the monitor_info struct, you can as well add a bit more than just a single uint32. Alternatively, we can also provide the size of the structure, so it can always be extended.

Size of the struct isn't a bad idea, we may want to add more to these structs at a later date as it is hard to see everything they may need. Should we drop the version field in favour of a size? (version in monitor isn't used for much at the moment)

[kallisti5]

Revision 4 of the proposed changes. Rename hooks to more basic name

[kallisti5]

PulkoMandy mentioned in irc that tracking multiple instances of multiple accelerants across multiple cards and displays would be a nightmare in app_server. (not even thinking about clones for 3D rendering)

Looking at some of my previous notes, here is an alternate option. This is what I was originally thinking before getting side tracked with the "one-accelerant-per-monitor" path.

Thoughts? I'm nicknaming this one medusa as that will be the branch name I'm working out of on github :-)

Pretty much one accelerant per card, but we put the x + y offset of the framebuffer in frame_buffer_config and add the crtc to each function that would need to know which monitor the call is for.

I'm questioning the need for virtual_width / virtual_height and friends in display_mode.. don't think a virtual screen size in addition to the set display mode is useful on modern hardware.

[kallisti5]

medusa. Throw the baby out with the bath water. revision 1

[axeld]

I can't follow PulkoMandy's argument at all, though. Why would that be a nightmare? It really makes no difference at all.

Anyway, the API is not really sufficient either way, as some things (like cloning) should be done in the driver, not the app_server. Furthermore, there are screen configurations, where the app_server would benefit (albeit slightly) from a contiguous framebuffer when it actually spans this way over the monitors (I'm not sure this is worth taking into account, though -- it might make a difference with 3D acceleration, though).

[pulkomandy]

I don't remember saying that, either...

I was only wondering which way we want to go with this. The current hack in Radeon driver is to have a big frame buffer, and each display shows only part of it. If both display show the same part, you have clone mode. If they show different parts, you have poor man's dualscreen mode, with some problems because apps don't know about it, and for example CenterOnScreen will put window in the middle, split between the two displays.

In X11, they use the same solution with a single framebuffer, but they allow apps (or, actually, window managers) to query about the displays positions and put things at the right place.

Another solution is to allocate a separate framebuffer for each display. This can work, but we have to take care of some things, for example a window that has parts visible on each screen (if we make this possible) will have to draw on both framebuffers. I think this requires calling the Draw() method twice, because splitting the drawing primitives between two framebuffers inside app_server sounds complicated to me (this is where the "nightmare" comes from). On the other hand, this makes it possible to do a dual-head setup with two video cards easy, as there is no need to share a framebuffer.

I'm also still unsure how this would map to workspaces. From the user standpoint, workspaces are already layed out in space, in a grid. Mapping this to the available displays may be non-trivial. We may make the workspace cover both displays, allow each display to show any workspace independent from the others, or force the workspace > display mapping to be spacially correct. If your workspaces are setup this way:

0 1
2 3 
4 5

The left monitor can only show even workspaces. The right monitor shows the workspace at n+1 (so you can see (0,1), (2,3), or (4,5).

Then there is the problem of dinamically adding/removing displays, where we want windows to come back to the visible area, but we don't want their positions to be lost if you re-plug the same monitor again.

I'm not sure it's a good idea to rush into writing code, when, as far as I know, none of this has been discussed yet and we don't even know how the multi-display thing is supposed to work, from the user point of view.

[axeld]

Replying to pulkomandy:

I'm also still unsure how this would map to workspaces.

That's actually pretty clear, following the existing API, see: ​http://www.haiku-os.org/blog/axeld/2005-11-03_workspaces.

What we need to make the app_server properly multi head capable is a HWInterface that acts as a proxy. There is no need to call Draw() twice on the application side for this.

[pulkomandy]

Both patches migrated to Gerrit: ​https://review.haiku-os.org/328 and ​https://review.haiku-os.org/329