Hi!
I'm currently working on a remoting KMS backend, and now I thought it
would be a good time to get some feedback on a very rough design:
The idea is that we want to be get enough information on the backend
side of KMS to be able to remote the display system over VNC or
something similar. Initially I'd plug in an open-source VNC server as
the "reference" user-space.
The solution should be general enough to plug into any driver, including
VKMS, either mirroring an existing crtc/connector or adding a virtual
one. The driver would typically only have to implement an efficient
readback command, optionally with a diff-map or damage rect that tracks
changed content for the VNC server to be able to do its work efficiently.
This would all be forwarded to a user-space interface and protocol with
a slightly more elaborate user-space event-mechanism than the one we
have in drm now. In particular we want to be able to read partial
events, and resume event reading after a partial event. We would also
want to be able to send commands either through an ioctl() or using
write(). Current test code is using write().
Since the VNC server in our application typically will be system-wide,
we need to resurrect a control-node functionality. I was trying to use
sysfs attributes for this, but while sysfs supports rudimentary poll
functionality. It's a bit too rudimentary and tracking client lifetime
becomes racy. Perhaps control nodes renamed to "remoting" nodes or
something similar. It might be that masters want to attach a VNC server
to their current display and in that case we probably would want to
expand primary nodes with this functionality as well.
Now to the open-source problem. As mentioned, the reference user-space
will be a solution based on libvncserver. In fact there will be a small
user-space interface library that libvncserver can interact with,
similar to libdrm. However, I envision in the long run VMWare would be
interested to use other remoting protocols with closed source protocol
encoders, using the open source reference library. In theory, this
solution would also allow for simple (open- or closed source) user-space
display drivers, very similar to DisplayLink's evdi solution, even if
that's not a use-case VMWare is currently interested in.
Thoughts and comments appreciated.
/Thomas
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
