<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 14, 2018 at 3:39 AM, Daniel Stone <span dir="ltr"><<a href="mailto:daniel@fooishbar.org" target="_blank">daniel@fooishbar.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
On 13 February 2018 at 22:15, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br>
> On Tue, Feb 13, 2018 at 10:48 AM, Daniel Stone <<a href="mailto:daniel@fooishbar.org">daniel@fooishbar.org</a>> wrote:<br>
</span><span class="">>> On 9 February 2018 at 23:43, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br>
</span><span class="">>> For actual scanout, the kernel very specifically demands that if the<br>
>> BO is X-tiled, then set_tiling be called with TILING_X. This applies<br>
>> even if we explicitly allocate with MOD_X_TILED and pass that in via<br>
>> drmModeAddFB2WithModifiers: there is an explicit check for<br>
>> !!(bo_tiling == TILING_X) == !!(modifier == MOD_X_TILED).<br>
<br>
</span>You missed this bit. Suggested fixup: <a href="https://hastebin.com/xikopobiza" rel="noreferrer" target="_blank">https://hastebin.com/<wbr>xikopobiza</a><br>
</blockquote></div><br></div><div class="gmail_extra">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.<br><br></div><div class="gmail_extra">If what you wrote above really is immutably true, then this patch is dead.<br><br></div><div class="gmail_extra">What's the failure mode here?  We just don't flip?  Or the compositor wigs out and crashes?<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">--Jason<br></div></div>