<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-03-31 13:05 GMT+02:00 Tapani Pälli <span dir="ltr"><<a href="mailto:tapani.palli@intel.com" target="_blank">tapani.palli@intel.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-m_2881311896817864287HOEnZb"><div class="gmail-m_2881311896817864287h5"><br>
<br>
On 03/31/2017 10:12 AM, Tapani Pälli wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
On 03/31/2017 09:06 AM, Tapani Pälli wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
On 03/31/2017 08:24 AM, Rob Clark wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Fri, Mar 31, 2017 at 12:22 AM, Tapani Pälli<br>
<<a href="mailto:tapani.palli@intel.com" target="_blank">tapani.palli@intel.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
On 03/30/2017 05:57 PM, Emil Velikov wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
On 30 March 2017 at 15:30, Tomasz Figa <<a href="mailto:tfiga@chromium.org" target="_blank">tfiga@chromium.org</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
On Thu, Mar 30, 2017 at 11:17 PM, Emil Velikov<br>
<<a href="mailto:emil.l.velikov@gmail.com" target="_blank">emil.l.velikov@gmail.com</a>><br>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
On 30 March 2017 at 11:55, Tomasz Figa <<a href="mailto:tfiga@chromium.org" target="_blank">tfiga@chromium.org</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Android buffer queues can be abandoned, which results in failing to<br>
dequeue next buffer. Currently this would fail somewhere deep<br>
within<br>
the DRI stack calling loader's getBuffers*(), without any error<br>
reporting to the client app. However Android framework code<br>
relies on<br>
proper signaling of this event, so we move buffer dequeue to<br>
createWindowSurface() and swapBuffers() call, which can generate<br>
proper<br>
EGL errors. To keep the performance benefits of delayed buffer<br>
handling,<br>
if any, fence wait and DRI image creation is kept delayed until<br>
getBuffers*() is called by the DRI driver.<br>
<br>
</blockquote>
Thank you Tomasz.<br>
<br>
I'm fairly confident that this should resolve the crash [in<br>
swap_buffers] that Mauro was seeing.<br>
Mauro can you give it a test ?<br>
</blockquote>
<br>
<br>
Ah, I actually noticed a problem with existing code, supposedly fixed<br>
by [1], but I'm afraid it's still wrong.<br>
<br>
Current swap_buffers calls get_back_bo(), but doesn't call<br>
update_buffers(), which is the function that should be called before<br>
to actually dequeue a buffer from Android's buffer queue. Given that,<br>
get_back_bo() would simply fail with !dri2_surf->buffer, because no<br>
buffer was dequeued.<br>
<br>
</blockquote>
Right - I was wondering why we don't hit that on EGL/GBM or<br>
EGL/Wayland.<br>
>From a quick look - may be because EGL/Android drops the dpy mutex in<br>
droid_window_enqueue_buffer().<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
My patch removes update_buffers() and changes the buffer<br>
management so<br>
that there is always a buffer dequeued, starting from surface<br>
creation, unless there was an error somewhere.<br>
<br>
</blockquote>
Of the top of your head - is there something stopping us from using<br>
the same method on $other platforms?<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
[1]<br>
<a href="https://cgit.freedesktop.org/mesa/mesa/commit/src/egl/drivers/dri2/platform_android.c?id=4d4558411db166d2d66f8cec9cb581149dbe1597" rel="noreferrer" target="_blank">https://cgit.freedesktop.org/m<wbr>esa/mesa/commit/src/egl/driver<wbr>s/dri2/platform_android.c?id=4<wbr>d4558411db166d2d66f8cec9cb5811<wbr>49dbe1597</a><br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
Not that huge of an expert on the Android specifics, so just a<br>
humble<br>
request:<br>
Can we seek the code resuffle (droid_{alloc,free}_local_buff<wbr>er,<br>
</blockquote></blockquote>
<br>
Oops silly typo - s/seek/split/.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
other?) separate from the functionality changes ?<br>
</blockquote>
<br>
<br>
Sure. Thanks for suggestion.<br>
<br>
</blockquote>
Please give it a day or two for others to comment.<br>
</blockquote>
<br>
<br>
I'm trying to debug why this causes our homescreen (wallpaper) to be<br>
black.<br>
Otherwise I haven't seen any issues with these changes.<br>
<br>
</blockquote>
<br>
wallpaper seems to be a special sorta hell..  I wonder if there is<br>
somehow some sort of interaction with what I fixed / worked-around in<br>
a5e733c6b52e93de3000647d075f5c<wbr>a2f55fcb71 ??<br>
<br>
Maybe at least try commenting out the temp-pbuffer thing to get max<br>
texture size, and see if that "fixes" things<br>
</blockquote>
<br>
Can you give more details, I still live in la la land and don't know<br>
about 'temp-pbuffer thing'?<br>
<br>
</blockquote>
<br>
aa I did not recall the problem, you mean the 'dummy pbuffer' in<br>
SurfaceFlinger .. yes I will check if this is related.<br>
<br>
</blockquote>
<br></div></div>
If I take away that dummy pbuffer usage (which is useless anyway), couple of errors disappear from the log. They are:<br>
<br>
SurfaceFlinger: releasePendingBuffer failed: Unknown error -1 (1)<br>
SurfaceFlinger: releasePendingBuffer failed: Unknown error -1 (1)<br>
<br>
but otherwise the desktop still stays black, live wallpapers seem to work so there is something special about this default wallpaper. Will continue digging ..<span class="gmail-m_2881311896817864287HOEnZb"><font color="#888888"><br>
<br>
// Tapani<br></font></span></blockquote><div><br></div><div><br></div><div>Hi,</div><div><br></div><div>about the black wallpaper the only sign found in logcat is the following:</div><div><div><br></div><div>--------- beginning of main</div><div>04-02 15:09:43.148</div></div><div>...</div><div>04-02 15:10:41.710  1414  1414 E Layer   : [com.android.systemui.ImageWallpaper] rejecting buffer: bufWidth=1024, bufHeight=768, front.active.{w=1, h=1}<br></div><div><div>...</div><div>04-02 15:10:41.726  1414  1414 E Layer   : [com.android.systemui.ImageWallpaper] rejecting buffer: bufWidth=1024, bufHeight=768, front.active.{w=1, h=1}</div></div><div><br></div><div>Are the expected width and height correct?</div><div><br></div><div>In dmesg at relative dmesg timestamp around 58 seconds there is no signal/error,</div><div>just the selinux log (set to permissive):</div><div><br></div><div><div>[   58.271833] type=1400 audit(1491145841.554:192): avc: denied { ioctl } for pid=2141 comm="ndroid.systemui" path="/dev/dri/card0" dev="tmpfs" ino=7199 ioctlcmd=6467 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:device:s0 tclass=chr_file permissive=1</div><div>[   58.271879] type=1400 audit(1491145841.554:193): avc: denied { read write } for pid=2141 comm="ndroid.systemui" path="/dev/dri/card0" dev="tmpfs" ino=7199 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:device:s0 tclass=chr_file permissive=1</div></div><div><br></div><div>I hope these information may help</div><div>Mauro</div></div><br></div></div>