> > 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
