On 7/16/23 04:19, Taylor R Campbell wrote: > Amazing! Cool, I'll take a look.
Yes please!
Some quick questions before I've looked much into details (so don't take the questions too seriously; the answers might be obvious and I might be barking up the wrong tree): 1. Did you reimplement an allocator for the dma_pool_* API? Should it use vmem(9) instead or can that not handle the requests that it needs?
Yes I reimplemented it but it's probably far from efficient. And I didn't know the existence of vmem! Lol, I should have used it.
2. What's up with the restore_mode property? Does anything set it? What's the protocol? Why isn't this needed by all the other drivers, which can already gracefully handle exiting X?
vmwgfxfb sets it and vmwgfx uses it. It's not needed as long as X gracefully exits, because it calls WSDISPLAYIO_SMODE ioctl to revert the mode back to WSDISPLAYIO_MODE_EMUL. But if X crashes or is killed by SIGKILL, the only way to perform a cleanup is to do something in the drm_driver::lastclose callback. That's why.
3. Why all the logic in vmwgfxfb.c duplicating genfb? Why not just use genfb via drmfb, like the other major drm drivers use (i915, radeon, nouveau, amdgpu)?
Because vmwgfx does not, and can not use drm_fb_helper. The helper assumes that you can just allocate a framebuffer in VRAM and map it to a virtual address. The VMware GPU appears to support this operation mode too, but the vmwgfx driver isn't capable of doing it. So I had to allocate a framebuffer in the system memory and ask the driver to upload dirty areas to the GPU every time something changes in the buffer.