The fact that the data stream that is needed to drive it is split into two streams/cables/connections (and only in one – although the “native” one – mode out of many supported) simply provides zero justification to present it to X/RANDR as “two outputs”, it serves no purpose and only causes problems.
Amd firepro w4100 3 monitors error driver#
The only proper solution is to “join” back the tiles into one physical output at the driver level and expose that to X/RANDR (and to KMS for that matter) and never expose separate tiles to X/RANDR. Why on earth is RANDR machinery even needed for this? The functionality of joining back ONE physical device separated at the data transport level into two does not belong in RANDR.
![amd firepro w4100 3 monitors error amd firepro w4100 3 monitors error](https://i5.walmartimages.com/asr/c0a1977b-8b05-46e8-842c-fc04a714cb29_1.7e66fc8d4c22c136b6b94a639fbde540.jpeg)
(but what if some application has a different idea of "monitors" than the WM? What then? Games and other full-screen apps want to change resolution of "outputs"/CRTCs, but "monitors" do not have a concept of resolution change, how are they supposed to deal with "monitors?" They have to deal with underlying outputs/CRTCs/tiles directly to do it.
![amd firepro w4100 3 monitors error amd firepro w4100 3 monitors error](https://shop.immel.de/images/product_images/original_images/38041998.jpg)
![amd firepro w4100 3 monitors error amd firepro w4100 3 monitors error](https://c1.neweggimages.com/ProductImageCompressAll1280/14-195-115_R08.jpg)
This problem is solved in Xorg just above the driver abstraction level.