On Tue, 14 Feb 2023 22:10:35 +0200 Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > On Tue, Feb 14, 2023 at 08:45:00PM +0100, Sebastian Wick wrote: ... > > We also have to figure out how a user space which doesn't > > know about the new property behaves when another client has set that > > property. If any property which currently might change the pixel > > values is used, we can't expose the entire color pipeline because the > > kernel might have to use some element in it to achieve its magic > > conversion. So essentially you already have this hard device between > > "old" and "new" and you can't use the new stuff incrementally. > > That problem exists with any new property. Old userspace and new > userspace may interact badly enought that nothing works right. > In that sense I think these props might even be pretty mundane > as the worst you might get from setting the infoframe wrong is > perhaps wrong colors on your display. > > To solve that particular problem there has been talk (for years) > about some kind of "reset all" knob to make sure everything is > at a safe default value. I have a feeling there was even some > kind of semi-real proposal in recent times, but maybe I imgained > it? I've been talking about that too, but I think it all collapsed into "let's just fix all KMS apps to always set all KMS properties" which results in patches like https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/952 It does not seem to be a serious enough problem for anyone to put in the work. And why would it be, when you can easily fix it in your own project like that Weston example. The Weston example is not even representative, because I did it before I saw any real problems. Other musings have been in the direction that maybe logind (since it opens DRM devices for you) should save the full KMS state on the very first open after a reboot, and then KMS applications can ask logind what the boot-up state was. This is a variation of "save all KMS state from the moment you launch, and use that as the base if you ever let something else touch KMS in between". You also never see the problem to begin with, if you never let something else touch KMS in between, so that already makes the problem rare outside of the tiny set of compositor developers. Thanks, pq
Attachment:
pgpUIHO5Ix0yT.pgp
Description: OpenPGP digital signature
