3 ms·
> I really don't see why it would need a new protocol. You'll need API to remap the Drawable to the scanout plane from a compositor on a per-frame basis (so wh
by audidude 3y ago
> I really don't see why it would need a new protocol.
You'll need API to remap the Drawable to the scanout plane from a compositor on a per-frame basis (so when submitting the CRTC) and the compositor isn't in control of the CRTC. So...
- AshamedCaptain 3y agoThis assumes it would be the role of the window manager or compositor rather than the server who decides that, which I didn't think that way. But I guess it'd make sense (policy vs mechanism). "per-frame basis" I don't see why and it just mirrors Wayland concepts. Still, as protocols go, it's quite a minor change, and one applications don't necessarily have to support.
- play_ac 3y agoThe server doesn't have enough information to do it because it doesn't know anything about window management. At best it could use a heuristic to guess, but one of the reasons Wayland combines the server and the compositor is so that we don't need to pile heuristics into the X server and drivers any more. Nothing in Xorg is a minor change because it has to be tested with every window manager and compositor before you can even think about merging.