<div dir="ltr"><div dir="ltr"><br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 2, 2022 at 4:17 AM Tvrtko Ursulin <<a href="mailto:tvrtko.ursulin@linux.intel.com">tvrtko.ursulin@linux.intel.com</a>> wrote:<br></div><div dir="ltr" class="gmail_attr"><br></div><div class="gmail_attr">For some reason I has missed this. Thanks Tvrtko for pointing this out.</div><div class="gmail_attr"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 01/12/2022 22:03, Zanoni, Paulo R wrote:<br>
> Hi<br>
> <br>
> I was given a link to <a href="https://patchwork.freedesktop.org/series/111494/" rel="noreferrer" target="_blank">https://patchwork.freedesktop.org/series/111494/</a><br>
> but can't seem to find it on the mailing list, so I'll reply here.<br>
> <br>
> On Thu, 2022-08-25 at 08:46 +0200, Maarten Lankhorst wrote:<br>
>> Frontbuffer tracking in gem is used in old drivers, but nowadays everyone<br>
>> calls dirtyfb explicitly. Remove frontbuffer tracking from gem, and<br>
>> isolate it to display only.<br>
> <br>
> Ok, but then how can the Kernel know if the user space running is an<br>
> "old driver" or a new one? Assuming everybody is following the new<br>
> policy is at least risky.<br></blockquote><div><br></div><div>Agree. This is a very old problem. That won't go away simply.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> (crazy idea: have an ioctl for user space to tell whether it knows how<br>
> to DirtyFB and another where it can even say it will never be touching<br>
> frontbuffers at all)<br></blockquote><div><br></div><div>To be honest we had this "crazy" idea back there. But we thought that the</div><div>frontbuffer tracking would be easiest than new api...</div><div>We were wrong... and we probably need this now if we want to remove the</div><div>frontbuffer tracking.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> Also, when I wrote igt/kms_frontbuffer_tracking, it was agreed that<br>
> whatever was there was a representation of the "rules" of the<br>
> frontbfuffer writing contract/API. And I see on the link above that the<br>
> basic tests of kms_frontbuffer_tracking fail. If<br>
> kms_frontbuffer_tracking requires change due to i915.ko having changed<br>
> the frontbuffer writing rules, then we should do it, and possibly have<br>
> those rules written somewhere.<br>
> <br>
> But then, having the Kernel change expectations like that is not<br>
> exactly what I learned we should be doing, because it's the recipe to<br>
> break user space.<br>
> <br>
> I'm confused, please clarify us a little more. More sentences in the<br>
> commit messages would be absolutely great.<br>
<br>
Right, +1 - we need to be sure there aren't some binaries, running in a <br>
distro somewhere, or whatever, which rely on this and then we are not <br>
allowed to break them. As minimum at least we need an audit and versions <br>
to know how old libraries/programs we are talking about here ie. when <br>
did everyone stop relying on implicit tracking.<br>
<br>
Regards,<br>
<br>
Tvrtko<br>
</blockquote></div></div>