Multiple displays support

[pulkomandy]

A generic ticket to track the current status of multiple displays support as a whole.

History

Some of our old drivers do support multiple monitors. The matrox, neomagic, nvidia (legacy) and via drivers support the DUALHEAD_CAPABLE protocol. The radeon (legacy) driver also supports multiple monitors but does not appear to set the flag, I assume it uses a different protocol?

These were developped with BeOS compatibility in mind which put a requirement of not modifying app_server. They were distributed with a replacement screen preferences (based on the Haiku one?) that allows configuring the separate video modes for each display.

The lack of changes in app_server means the OS as a whole doesn't know there are multiple displays, it just sees a very large framebuffer. This has some downsides, for example, CenterOnScreen will put things in between the two displays, there is no way to put DeskBar at the center edge, etc.

Modern drivers

Both the Intel and Radeon HD drivers have some attempt at initializing multiple displays. Both are incomplete and nonworking. A first goal here would be to set up two displays in clone mode reliably. See for example #12970

The EFI framebuffer driver does not yet support multiple displays, but in theory it is possible if the hardware/firmware allows it. See #18440

There is also a work in progress "ACPI display" driver, in theory that would provide us with a unified and standard way to access and control the displays (letting ACPI bytecode do the hard work for setting brightness, etc), but it is yet unclear how this will integrate with the existing drivers.

Testing

We are in a kind of deadlock situation: no one works seriously on multiple displays support in the drivers because app_server doesn't really know to use it, and no one works on app_server multiple monitor support because there are no drivers to test it with.

To get out of this, we have some options:

• Can QEMU emulate one of the cards where we have multihead support already working?
• Can we add a driver for one of QEMU videocards where multiple displays are possible? Is there something to be done with virtio_display for example?
• Can we support multiple displays with multiple videocards? That is a bit different to set up since app_server would need several accelerants and the framebuffer will be really split in two parts handled by different hardware. Is that useful in the modern age?
• Another option is to have test_app_server simulate multiple displays by having multiple windows opened

What needs to be done in app_server and non-driver parts

• BScreen needs to handle the fact that there are multiple screens
• app_server must keep track of which window is on which screen
• screen with different bpp are a problem, especially for things like BColorControl which is completely different on 8bpp screens. How do we switch between the two modes? How does it work if a window is in-between two screens? Do we bother supporting 8bpp at all?
• There are also problems with uneven DPI between displays, how to scale the GUI appropriately?

Surely, some of this can wait until we have the displays actually showing something

Other things to consider

We need some way to properly expose each display to userspace. The API for this can be in BScreen, but it needs to be routed from there to the driver. The current way is to go through app_server and the accelerant. Should we consider exposing each display (in addition to each videocard) as a separate device in /dev? What other API could we use?

This would be useful for example to implement screen brightness using DDC/CI, and also for getting EDID. Currently this is all handled in graphics drivers directly, with a lot of shared code. It would be nice if the EDID parsing was moved to userspace (to common code in app_server maybe?) and drivers could just provide an interface to read the raw EDID data

[waddlesplash]

IIRC it is possible to start a VM in QEMU with two video cards attached; one of which is supported by the built in VESA BIOS and the other one which isn't (perhaps ATI Rage128? can't remember.) Then the VESA driver will work for the primary screen, and a different accelerant can be used for the secondary screen. No modifications to drivers are needed to get this setup to function already, but of course app_server doesn't handle it. So that seems to be a way to start working on app_server already.

[X512]

It is also should be possible to attach multiple ATI video cards in QEMU.

[X512]

Replying to pulkomandy:

• screen with different bpp are a problem, especially for things like BColorControl which is completely different on 8bpp screens. How do we switch between the two modes? How does it work if a window is in-between two screens? Do we bother supporting 8bpp at all?
• There are also problems with uneven DPI between displays, how to scale the GUI appropriately?

app_server can send a message to BWindow and BView's it contains when most window part is moved on another screen. Clients can adjust GUI scaling, BColorControl palette settings or other per-screen properties.

[pulkomandy]

IIRC it is possible to start a VM in QEMU with two video cards attached

Yes, that's an option, but at the moment I am more interested in multiple displays handled by the same videocard, I think this is a more common setup nowadays (I mean, since the early 2000s or so)?

app_server can send a message to BWindow and BView's it contains when most window part is moved on another screen. Clients can adjust GUI scaling, BColorControl palette settings or other per-screen properties.

Yes, I think that's a good way to handle it. It means app_server has to track which screen a window is "mostly" in. There could be some difficulties if parts of the framebuffer have different bpp, but do we really want to bother with that? Can we assume people will use 32bpp everywhere?

[X512]

Replying to pulkomandy:

Can we assume people will use 32bpp everywhere?

Some modern displays supports 48bpp or more, so we can't. Window still can use bpp of screen that it mostly in and perform color conversion for parts overflowing to another screens.