> 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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
