RFC: drm/virtio: Dummy virtio GPU

[Gerd Hoffmann]

> > No.
> >
> > First, what is wrong with vkms?
> The total lines of vkms driver is 1.2k+.

Which is small for a drm driver.

> I think it doesn't work along
> itself to provide things like  mmap on prime fd? (I tried it months
> ago).

Seems vkms only supports prime import, not prime export.
Maybe vgem works for you?

> And more, my "dummy virtio"
> device actually doesn't really depends on drm system so it's easier to
> back port to old kernel.

It depends on the virtio driver, which in turn *does* depend on drm
system.  So you have a indirect instead of a direct dependency.  I still
don't see the point ...

> > Second, if you really want something simple with the minimal set of drm
> > features possible you can write a rather small but still self-contained
> > driver when using all the drm helpers (shmem, simple display pipe) we
> > have these days.  Copy cirrus, strip it down: drop modesetting code,
> > drop blit-from-shmem-to-vram code, drop pci probing.  Maybe add module
> > options for max/default video mode.  Done.
> I need features like prime export/import, mmap on prime fd etc.

The shmem helpers support that just fine.

> And I'd like the code could work on different kernel version. So if go
> with this ways, the actually add more maintain cost in the long term?

Depends on which kernel version you need.  Backporting to 5.4-lts should
be easy, 4.4-lts lacks alot of the drm helpers though.

> > What is the use case btw?
> We have images works well under qemu + virtio vga, we'd like to run
> these images on public cloud service like Google GCE directly.

What do these images need a drm device for?
It seems not to be hardware-accelerated rendering.
It also seems not to be a virtual display.

cheers,
  Gerd