On Wed, Feb 14, 2018 at 3:39 AM, Daniel Stone <dan...@fooishbar.org> wrote:
> On 13 February 2018 at 22:15, Jason Ekstrand <ja...@jlekstrand.net> wrote:
> > On Tue, Feb 13, 2018 at 10:48 AM, Daniel Stone <dan...@fooishbar.org>
> >> On 9 February 2018 at 23:43, Jason Ekstrand <ja...@jlekstrand.net>
> >> For actual scanout, the kernel very specifically demands that if the
> >> BO is X-tiled, then set_tiling be called with TILING_X. This applies
> >> even if we explicitly allocate with MOD_X_TILED and pass that in via
> >> drmModeAddFB2WithModifiers: there is an explicit check for
> >> !!(bo_tiling == TILING_X) == !!(modifier == MOD_X_TILED).
> You missed this bit. Suggested fixup: https://hastebin.com/xikopobiza
I was really hoping I'd read wrong. I'm going with "that's a kernel bug".
Modifiers is supposed to separate tiling from the BO. Tying them back
together in drmModeAddFB2WithModifiers is wrong. This is especially true
since SET_TILING is an inherently racy operation and we really need to stop
using it entirely.
If what you wrote above really is immutably true, then this patch is dead.
What's the failure mode here? We just don't flip? Or the compositor wigs
out and crashes?
mesa-dev mailing list