On 01/12/2022 22:03, Zanoni, Paulo R wrote:
Hi
I was given a link to https://patchwork.freedesktop.org/series/111494/
but can't seem to find it on the mailing list, so I'll reply here.
On Thu, 2022-08-25 at 08:46 +0200, Maarten Lankhorst wrote:
Frontbuffer tracking in gem is used in old drivers, but nowadays everyone
calls dirtyfb explicitly. Remove frontbuffer tracking from gem, and
isolate it to display only.
Ok, but then how can the Kernel know if the user space running is an
"old driver" or a new one? Assuming everybody is following the new
policy is at least risky.
(crazy idea: have an ioctl for user space to tell whether it knows how
to DirtyFB and another where it can even say it will never be touching
frontbuffers at all)
Also, when I wrote igt/kms_frontbuffer_tracking, it was agreed that
whatever was there was a representation of the "rules" of the
frontbfuffer writing contract/API. And I see on the link above that the
basic tests of kms_frontbuffer_tracking fail. If
kms_frontbuffer_tracking requires change due to i915.ko having changed
the frontbuffer writing rules, then we should do it, and possibly have
those rules written somewhere.
But then, having the Kernel change expectations like that is not
exactly what I learned we should be doing, because it's the recipe to
break user space.
I'm confused, please clarify us a little more. More sentences in the
commit messages would be absolutely great.
Right, +1 - we need to be sure there aren't some binaries, running in a
distro somewhere, or whatever, which rely on this and then we are not
allowed to break them. As minimum at least we need an audit and versions
to know how old libraries/programs we are talking about here ie. when
did everyone stop relying on implicit tracking.
Regards,
Tvrtko
