Thanks for the confirmation.
Actually I wasn't expecting the eglfs_viv[_wl] stuff to even work with
current releases of the Vivante blob, but after a short test it does
indeed work (however performance appears to be much worse than using
eglfs_kms). Anyway, I don't really see a reason for
Bummer that the software stack says GNOME.
https://developer.puri.sm/Librem5/Software_Reference.html#software-reference
If I were Qt (I'm not) I'd look at preparing my own software stack... Who ever got the Nokia N9 (MeeGo) code? I loved that phone!
Sent: Wednesday, September 11,
On 11 Sep 2019, at 14:53, Zeno Endemann via Development
mailto:development@qt-project.org>> wrote:
Hi,
So unless I misunderstand something, for the i.MX8 NXP/Vivante changed their
proprietary graphic stack significantly. The framebuffer and X11 driver are
deprecated, only Wayland will be
Hi,
Yes, it is a trend to move away from basing EGL/OpenGL implementations on top
of the (deprecated) fbdev, and instead move onto drm. Sometimes, and I suspect
this is the case with Vivante as well, vendors offer both variants of the
drivers. With eglfs this means the backend has to be
Hi,
So unless I misunderstand something, for the i.MX8 NXP/Vivante changed
their proprietary graphic stack significantly. The framebuffer and X11
driver are deprecated, only Wayland will be supported, and they have
switched from the Linux framebuffer interface to (a fork of) libdrm.
I was
Hi,
Qt 5.12.5 is released today, see https://www.qt.io/blog/qt-5.12.5-released
Big thanks to everyone involved!
br,
Jani Heikkinen
Release Manager
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
On 2019-08-23 10:31, Mutz, Marc via Development wrote:
If that's the case, shouldn't we run, not walk, to replace our
internal uses with std::mutex + std::condition_variable to have only
one mutex?
Since it _is_ the case, I've sat down and ported QReadWriteLock from
QMutex + QWaitCondition to
