[PATCH 00/13] drm/amdgpu: Add virtual display feature.
Michel Dänzer
michel at daenzer.net
Fri Aug 5 01:15:55 UTC 2016
On 05.08.2016 02:31, Bridgman, John wrote:
>> -----Original Message-----
>> From: dri-devel [mailto:dri-devel-bounces at lists.freedesktop.org] 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
More information about the amd-gfx
mailing list