UDL device cannot get its own screen

[Pekka Paalanen]

On Wed, 23 Oct 2019 14:12:03 +0200
Böszörményi Zoltán <zboszor at pr.hu> wrote:

> 2019. 10. 23. 9:42 keltezéssel, Pekka Paalanen írta:
> > On Tue, 22 Oct 2019 17:50:21 +0200
> > Böszörményi Zoltán <zboszor at pr.hu> wrote:
> >   
> >> Hi,
> >>
> >> I have the below configuration for an Intel based POS system that,
> >> while advertises 3 outputs (DP1, VGA1 and HDMI1 with xf86-video-intel),
> >> only two are usable. DP1 for the built-in touchscreen and VGA1 for
> >> the external VGA connector.
> >>
> >> I wanted to use an USB DisplayLink device as the 3rd output, with all
> >> three output using its own Screen number, i.e. :0.0 :0.1 and :0.2.  
> > 
> > ...
> >   
> >> The third observation is that while I am using this configuration below,
> >> so the UDL device should be assigned to :0.2 (and active!), it is really
> >> assigned to :0[.0] as an inactive output. See that there's no "*" indicator
> >> set for any of the supported modes on DVI-I-1-1.
> >>
> >> How can I set up 3 different Screens correctly for 3 separate fullscreen
> >> applications?
> >>
> >> I am using Xorg 1.20.4 patched with the "autobind GPUs to the screen"
> >> patch from Dave Airlie that at least wakes up the UDL device and makes
> >> it visible without extra magic with providers/sinks.  
> > 
> > Hi,
> > 
> > for your specific use case, auto-bind is exactly what you do not want.
> > So drop the patch or (since the patch is in upstream master already)
> > use the option it adds to stop auto-binding.  
> 
> With Option "AutoBindGPU" "false" in effect (equivalent of backing the
> patch out) the UDL device does not get assigned to ANY of the screens.
> 
> I want it to have its own :0.2 bit that doesn't happen.

Yes, that's another problem. Autobind=false is a step in the right
direction, but apparently not sufficient.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.x.org/archives/xorg/attachments/20191023/2e84b8f0/attachment.sig>