UDL device cannot get its own screen
zboszor at pr.hu
Wed Nov 13 16:58:50 UTC 2019
2019. 11. 12. 17:41 keltezéssel, Ilia Mirkin írta:
> On Tue, Nov 12, 2019 at 9:23 AM Böszörményi Zoltán <zboszor at pr.hu> wrote:
>> But no, all GPU devices (now only one, the UDL device) have screen 0
>> (a.k.a. DISPLAY=:0.0) set when AutoBindGPU is true:
>> [ 2444.576] xf86AutoConfigOutputDevices: xf86NumScreens 2 xf86NumGPUScreens 1
>> [ 2444.576] xf86AutoConfigOutputDevices: GPU #0 driver 'modesetting' 'modeset' scrnIndex
>> 256 origIndex 257 pScreen->myNum 256 confScreen->screennum 0
>> confScreen->device->identifier 'Intel0'
>> confScreen->device->screen 0 confScreen->device->myScreenSection->screennum 0
>> confScreen->device->myScreenSection->device->screen 0
>> Somehow, Option "Device" should ensure that the UDL device is actually
>> treated as a framebuffer that can be rendered into (i.e. to be modeset(2)
>> instead of modeset(Gn)) and it should be woken up automatically.
>> This is what AutoBindGPU is supposed to do, isn't it?
>> But instead of assigning to screen 0, it should be assigned to whatever
>> screen number it is configured as.
>> I know it's not a common use case nowadays, but I really want separate
>> fullscreen apps on their independent screens, including a standalone UDL
>> device, instead of having the latters as a Xinerama extension to some
>> other device.
> If you see a "G", that means it's being treated as a GPU device, which
> is *not* what you want if you want separate screens. You need to try
> to convince things to *not* set the devices up as GPU devices, but
> instead put each device (and each one of its heads, via ZaphodHeads)
> no a separate device, which in turn will have a separate screen.
I created a merge request that finally made it possible what I wanted.
Now, no matter if I use the intel or modesetting drivers for the
Device sections using the Intel heads, or AutoBindGPU set to true or
false, the UDL device is correctly matched with its Option "kmsdev"
setting to the plaform device's device path.
This patch seems to be a slight layering violation, but since the
modesetting driver is built into the Xorg server sources, the patch
may get away with it.
More information about the xorg