*snip*<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
>> Reviewed-by: Kristian Høgsberg <<a href="mailto:krh@bitplanet.net">krh@bitplanet.net</a>><br>
><br>
><br>
> I briefly tested these patches on RV350 and it fixes the problem here<br>
> <a href="https://bugs.freedesktop.org/show_bug.cgi?id=52267" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=52267</a><br>
> I did notice that the last frame of the last instance of weston is 'flashed'<br>
> during the fade-in when running the next instance of weston.<br>
<br>
</div></div>Since Jakob added gbm_bo_write support now, I think you're now (for<br>
the first time) using hw cursor instead of gl cursor.  The flicker<br>
could be the RV350 flickering when we enable the hw cursor after the<br>
fade finishes.  You can try adding return NULL; early in<br>
drm_output_prepare_cursor_surface() to disable hw cursor and see if<br>
that's the case.<br>
<span class="HOEnZb"><font color="#888888"><br>
Kristian<br>
</font></span></blockquote></div><br>This does not seem to be the case. When weston starts, the last frame from the last instance of weston is shown, then during fade-in, it is all black. Specifically, it's black for about a half second and then weston appears when the fade-in is nearly complete and you can tell damage from the fade animation is still happening because the cursor is slower. Subsequent fades work fine. If switched to X and back to tty, it then shows garbage from the pixels of whatever X was showing.<br>
<br>Scott<br>