On 05.08.2016 02:31, Bridgman, John wrote: >> -----Original Message----- >> From: dri-devel [mailto:dri-devel-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf >> Of Daniel Vetter >> >> Another option for entirely fake outputs would be vkms.ko, similar to >> vgem.ko. With the simple display driver it should be fairly easy to a simple >> fake kms driver with just 1 crtc/encoder/connector/plane, all virtual, >> up&running. Needs a few lines to implement dumb mmap on top of shmem >> (but nothing else, since the driver never reads the buffer), plus prime >> import/export scaffolding. One module option (could even adjust at >> runtime) to configure how many drm_device instance there should be. >> Output configuration could be done by injecting a suitable EDID plus forcing >> the connector state (we have interfaces for that already, and iirc even patches >> to expose them all in sysfs). >> >> I'd say if you really want entirely fake/virtual outputs that go exactly nowhere >> at all, vkms.ko would be the cleanest approach. And that would have lots of >> use-cases outputs of just what you need, for e.g. testing kms helpers/ioctls >> and other nice things. > > FWIW I don't think we ever plan to have virtual outputs that go nowhere > - the display content just might go out via VNC or a compressed > streaming interface rather than through a local display controller. We might be getting into semantics territory here, but I'd say the virtual KMS output still goes "nowhere" in that case, since it's not involved in the remote display. I'm afraid this kind of setup might not be useful for proprietary OpenGL driver bringup though, as long as that uses its own libGL and GLX infrastructure. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
