app_server needs to be multi-head aware

[kallisti5]

Multiple monitors beyond the hacked together radeon driver will not function due to hooks missing important information such as "which display does this effect"

Each monitor is considered a crt controller (crtc)

The following hooks need a multi-monitor parameter (ex: uint8 display):

• B_ACCELERANT_MODE_COUNT
• B_GET_EDID_INFO
• B_GET_MODE_LIST
• B_GET_PREFERRED_DISPLAY_MODE
• B_GET_DISPLAY_MODE
• B_SET_DISPLAY_MODE (not *required* as we could just set the recommended mode stored in the accelerant on all displays)
• is_mode_supported callback in "create_display_modes"

New hooks may be needed to specify:

• Get number of displays... B_GET_DISPLAY_COUNT?

Other hooks may include:

• Monitor hotplug events (reversed from accelerant -> app_server)

radeon_hd stores multiple monitors internally and shows that making the app_server as unaware of multiple heads is almost possible except for the cases above where we need guidance.

This is definitely a post-R1 enhancement as it would break binary compatibility with existing Be drivers and would be a big task introducing potential bugs.

[X512]

Replying to kallisti5:

The following hooks need a multi-monitor parameter (ex: uint8 display):

Why not just introduce hook like B_SET_ACTIVE_DYSPLAY and apply all display commands to active dysplay? Default active display is primary display for compatability.

This is definitely a post-R1 enhancement as it would break binary compatibility with existing Be drivers and would be a big task introducing potential bugs.

It is possible to have two kinds of drivers, isn't it?

[axeld]

Another option would be to clone the accelerant for each head; this would allow to implement it with minimum changes to the interface.

Also, there is no need to actually break compatibility: just create a new API together with a new HWInterface implementation, and let the app_server support both.

The accelerant interface needs a redesign anyway, if you want to prepare it for drivers capable of supporting compositing. Ie. the app_server needs to maintain the memory for the graphics card in order to allocate blocks for textures as needed. The remaining acceleration functions need to be able to work on blocks of memory rather than one screen, etc. Even support for 32 bit hardware mouse cursors would be nice to have for a start :-)

There is little reason to try to squeeze it all into the existing accelerant API which isn't really adequate anymore.

[kallisti5]

Replying to axeld:

Another option would be to clone the accelerant for each head; this would allow to implement it with minimum changes to the interface.

I'm not 100% sold on this idea... probing displays is difficult (especially on newer cards where we have to walk down DisplayPort paths) Hot plugging monitors sounds like *big* pain here.

Also, there is no need to actually break compatibility: just create a new API together with a new HWInterface implementation, and let the app_server support both.

This is a really good idea... i'd rather not *completely* trash the old BeOS accelerant layout as it is working. (even though we aren't abi compatible with BeOS drivers)

The accelerant interface needs a redesign anyway, if you want to prepare it for drivers capable of supporting compositing. Ie. the app_server needs to maintain the memory for the graphics card in order to allocate blocks for textures as needed. The remaining acceleration functions need to be able to work on blocks of memory rather than one screen, etc. Even support for 32 bit hardware mouse cursors would be nice to have for a start :-)

There is little reason to try to squeeze it all into the existing accelerant API which isn't really adequate anymore.

All really good points. I forgot about compositing... it should be rolled into this as multi-head changes would be a great time to lay the basework for compositing.

[axeld]

Replying to kallisti5:

Replying to axeld:

Another option would be to clone the accelerant for each head; this would allow to implement it with minimum changes to the interface.

I'm not 100% sold on this idea... probing displays is difficult (especially on newer cards where we have to walk down DisplayPort paths) Hot plugging monitors sounds like *big* pain here.

I don't really see where the pain is coming from, although I agree that this path is not that appealing. But it would be a valid option if we'd care about compatibility here.

This is a really good idea... i'd rather not *completely* trash the old BeOS accelerant layout as it is working. (even though we aren't abi compatible with BeOS drivers)

We are not? My memory might fail me here, but I don't remember any issues. Where do we break it?

it should be rolled into this as multi-head changes would be a great time to lay the basework for compositing.

Definitely. Looking at other current graphics driver APIs would certainly be a good idea.

[kallisti5]

Replying to axeld:

Replying to kallisti5:

Replying to axeld: This is a really good idea... i'd rather not *completely* trash the old BeOS accelerant layout as it is working. (even though we aren't abi compatible with BeOS drivers)

We are not? My memory might fail me here, but I don't remember any issues. Where do we break it?

Ah.. I was under the wrong assumptions. As mmu_man said in irc: "it has been extended but should still be compatible"

[kallisti5]

(In #8626) adding blocked by #8612.

It's unlikely that the VESA edid matches the DisplayPort endpoint edid.

As the accelerant mode_set hook doesn't pass the crtc id, the hook functions are blissfully unaware of the needed information to properly train each display port device.

[kallisti5]

Replying to axeld:

Another option would be to clone the accelerant for each head; this would allow to implement it with minimum changes to the interface.

The accelerant would still need to know which head it's operating on.

Also, the drivers would need to be redesigned to support spawning an accelerant for each "monitor". The Radeon HD driver (several others as well I think) isn't aware of the number of monitors attached to each display.

[kallisti5]

(In #9932) adding blocked by #8612 We don't even support multiple monitors yet :-)

[kallisti5]

(In #11907) Likely due to lack of multi-monitor support. You plugged the external monitor in and got a mode-line not matching your laptops. Once you unplugged it Haiku continued to use the external mode-line on the LCD.

Blocked by #8612.

To solve:

• Bring up boot menu (press space a bunch just before the splash)
• Set video safe mode.
• Erase this file: /boot/home/config/settings/Screen_data
• Reboot.