Re: Proposal on WSDISPLAYIO damage reporting IOCTL

> While implementing X11 userspace support for viogpu, I identified a
> need for a unified WSDISPLAYIO mechanism to report framebuffer damage
> areas to drivers.  [...]

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?

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 ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B