Re: Proposal on WSDISPLAYIO damage reporting IOCTL

["Jiaxun Yang" <jiaxun.yang%flygoat.com@localhost>]

在2025年5月13日周二 下午1:04，Mouse写道：
>> While implementing X11 userspace support for viogpu, I identified a
>> need for a unified WSDISPLAYIO mechanism to report framebuffer damage
>> areas to drivers.  [...]

Hi Mouse,

Thanks for your comments! Just to clarify some details:
>
> This design bothers me a little.  It feels to me like a shadow
> framebuffer with a push mechanism - with the shadow moved into the
> kernel.  This then leads me to ask: why is the shadow in the kernel
> instead of being in userland?

There is actually no shadowing happening in kernel. For viogpu driver
the VRAM is mmaped to userspace. Kernel doesn't preserve it's own copy
of framebuffer. However, it needs to be notified to trigger a scanout
to get display on hypervisor refreshed.

>
> I'd be inclined to do this with the shadow in userland, with a
> driver-specific push mechanism and no framebuffer-contents state in the
> kernel.  And this is more a question than a criticism; there may well
> be some reason I'm not aware of because I'm not familiar enough with
> the relevant pieces.  (It's been a long time since I looked at the guts
> of wscons.)  I'm looking at this solely as a potential user of the API.
>
> (Also, as a side parenthesis: I would suggest "changed" rather than
> "damaged"; especially in an X context, "damaged" tends to carry an
> implication of "display changed behind client's back, client needs to
> redraw", that is, some other mechanism changed the display and the
> client's (conceptually unchanged) contents need re-pushing.  But, here,
> we have _changed_ contents, changed by the client without anything else
> changing the display, needing pushing.)

The term damage actually comes from XDamage extension [1].

To cite:
"Damage accumulates as drawing occurs in the drawable. Each drawing operation
'damages' one or more rectangular areas within the drawable."

I think this described our situation well.

Thanks
Jiaxun

[1]: https://www.x.org/archive/X11R7.5/doc/damageproto/damageproto.txt

>
> /~\ The ASCII				  Mouse
> \ / Ribbon Campaign
>  X  Against HTML		mouse%rodents-montreal.org@localhost
> / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

-- 
- Jiaxun