<div dir="ltr"><div dir="auto"><div>Hello Thiago,</div><div><br></div><div>Thanks a lot for your quick response. We shall use backend instead of using wayland compositor.</div><div>In one of the programs where we are using Qt 5.6.3 widgets based on kernel 4.14, the DRM driver replaces the fbdev driver on TI AM335x.</div><div><br></div><div>As mentioned in 

<a href="https://doc.qt.io/archives/qt-5.6/embedded-linux.html">https://doc.qt.io/archives/qt-5.6/embedded-linux.html</a>, DRM dumb buffer is not supported in Qt 5.6  but only from Qt 5.9.</div><div>Does it mean we cannot use LinuxFB as QPA backend using Qt 5.6.3 or /dev/fb1 could still be used to make use of DRM APIs for rendering?</div><div><br></div><div>If so, there are two options as QPA backends in terms of eglfs and DirectFB. But in case of Qt Widgets using eglfs as QPA backend, it falls back to fbdev being deprecated(/dev/fb0 legacy systems) </div><div>as there is no attribute to set to use eglfs or OpenGL using Qt Widgets,right?</div><div><br></div><div>Please let me know if we need to enable any kernel config options to make use of eglfs and DirectFB build using Yocto even if we configure Qt 5.6.3 with the QPA?</div><div><br></div><div>Best Regards,</div><div>Ramakanth</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 19 Jun, 2020, 21:55 Thiago Macieira, <<a href="mailto:thiago.macieira@intel.com" target="_blank">thiago.macieira@intel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thursday, 18 June 2020 22:13:07 PDT Ramakanth Kesireddy wrote:<br>
> Could you please let me know if it is recommended to use Wayland for single<br>
> Qt client application using QWidget on embedded board with EGLFS or<br>
> hardware accelerated rendering? As we cannot use EGLFS which fallsback to<br>
> fbdev with existing QWidget application, does it makes sense to use Wayland<br>
> to improve performance?<br>
<br>
In a Wayland system, you must have: <br>
 - exactly one compositor (which doesn't use Wayland)<br>
 - zero or more applications using Wayland<br>
<br>
But that only makes sense if you have two or more. If you have only one, <br>
there's no need to launch the compositor to composite that single <br>
application's output. Just have the application output directly to whatever <br>
the compositor was using as a backend.<br>
<br>
Which is also the exception: when the backend of the compositor is not <br>
something directly supported by Qt.<br>
<br>
-- <br>
Thiago Macieira - thiago.macieira (AT) <a href="http://intel.com" rel="noreferrer noreferrer" target="_blank">intel.com</a><br>
  Software Architect - Intel System Software Products<br>
<br>
<br>
<br>
_______________________________________________<br>
Interest mailing list<br>
<a href="mailto:Interest@qt-project.org" rel="noreferrer" target="_blank">Interest@qt-project.org</a><br>
<a href="https://lists.qt-project.org/listinfo/interest" rel="noreferrer noreferrer" target="_blank">https://lists.qt-project.org/listinfo/interest</a><br>
</blockquote></div></div></div>
</div>