[RFC] Virtual CRTCs (proposal + experimental code)
ihadzic at research.bell-labs.com
Wed Nov 23 21:59:05 PST 2011
On Wed, 23 Nov 2011, Dave Airlie wrote:
> So another question I have is how you would intend this to work from a
> user POV, like how it would integrate with a desktop environment, X or
> wayland, i.e. with little or no configuration.
First thing to understand is that when a virtual CRTC is created, it looks
to the user like the GPU has an additional DisplayPort connector.
At present I "abuse" DisplayPort, but I have seen that you pushed a patch
from VMware that adds Virtual connector, so eventually I'll switch to that
naming. The number of virtual CRTCs is determined when the driver loads
and that is a static configuration parameter. This does not restrict the
user because unused virutal CRTCs are just like disconnected connectors on
the GPU. In extreme case, a user could max out the number of virtual CRTCs
(i.e. 32 minus #-of-physical-CRTCs), but in general the system needs to be
booted with maximum number of anticipated CRTCs. Run-time addition and
removal of CRTCs is not supported at this time and that would be much
harder to implement and would affect the whole DRM module everywhere.
So now we have a system that booted up and DRM sees all of its real
connectors as well as virtual ones (as DisplayPorts at present). If there
is no CTD device attached to virtual CRTCs, these virtual connectors are
disconnected as far as DRM is concerned. Now the userspace must call
"attach/fps" ioctl to associate CTDs with CRTCs. I'll explain shortly how
to automate that and how to eliminate the burden from the user, but for
now, please assume that "attach/fps" gets called from userland somehow.
When the attach happens, that is a hotplug event (VCRTCM generates it) to
DRM, just like someone plugged in the monitor. Then when XOrg starts, it
will use the DisplayPort that represents a virtual CRTC just like any
other connector. How it will use it, will depend on what the xorg.conf
says, but the key point is that this connector is no different from any
other connector that the GPU provides and is thus used as an "equal
citizen". No special configuration is necessary once attached to CTD.
If CTD is detached and new CTD attached, that is just like yanking out
monitor cable and plugging in the new one. DRM will get all hotplug events
and windowing system will do the same thing it would normally do with any
other port. If RANDR is called to resize the desktop it will also work and
X will have no idea that one of the connectors is on a virtual CRTC. I
also have another feature, where when CTD is attached, it can ask the
device it drives for the connection status and propagate that all the way
back to DRM (this is useful for CTD devices that drive real monitors, like
So now let's go back to the attach/fps ioctl. To attach a CTD device this
ioctl must happen as a result of some policy. That can be done by having
CTD device generate UDEV events when it loads for which one can write
policies to determine which CTD device attaches to which virtual CRTC.
Ultimately that becomes an user configuration, but it's no different from
what one has to do now with UDEV policies to customize the system.
Having explained this, let's take your hotplug example that you put up on
your web page and redo it with virtual CRTCs. Here is how it would work:
Boot up the system and tell the GPU to create a few virtual CRTCs. Bring
up Xorg with no DisplayLink dongles in it. Now plug in the DisplayLink.
Once the CTD driver loads as the result of the hotplug (right now UDLCTD
is a separate driver, but as we discussed before, this is a temporary
state and at some point its CTD function should be merged wither with
UDLFB or with your UDL-V2) CTD function in the driver generates an UDEV
event. The policy directs UDEV to call run the program that issues the
ioctl to perform attach/fps. Attach/fps of the UDLCTD is now a hotplug
event and DRM "thinks" that a new connector changed the status from
disconnected to connected. That causes it to query the modes for the new
connector and because it's the virtual CRTC, it lands in the virtual CRTC
helpers in the GPU driver. Virtual CRTC helpers route it to VCRTCM, which
further routes to it to CTD (UDLCTD in this case). CTD returns the modes
and DRM gets them ... the rest you know better than me what happens ;-)
So this is your hotplug demo, but the difference is that the new desktop
can use direct rendering. Also, everything that would work for a normal
connector works here without having to do any additional tricks. RANDR
also works seamlessly without having to do anything special. If you move
away from Xorg, to some other system (Wayland?), it still works for as
long as the new system knows how to deal with connectors that connect and
Everything I described above is ready to go except the UDEV event from
UDLCTD and UDEV rules to automate this. Both are straightforwar and won't
take long to do. So very shortly, I'll be able to show the hotplug-bis.
More information about the dri-devel