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