Re: DRM/KMS: vmwgfx driver is now available

[PHO <pho%cielonegro.org@localhost>]

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.