w00t On Fri, Jun 22, 2012 at 1:32 AM, Romain Pokrzywka <romain.pokrzy...@kdab.com> wrote: > Some comments on the notes in the wiki: > > * eglfs now depends on evdev. Future task is to make it compile when evdev is > absent but we are yet to see such a device (qnx?) > > Yes, we have that exact issue with Qt5 builds for QNX on BeagleBoard. > Currently we disable eglfs and use another platform plugin instead, but there > should be some proper #ifdef QT_HAVE_EVDEV blocks in there. I expect the same > issue on other non-linux unix embedded OSes like VxWorks, Integrity, > Nucleus... > > KDAB can volunteer for that one (either me or one of the guys working on QNX)
Would minimalEGL not suit your needs more then? > * cursor support hw accel on the pi, the cursor is a separate layer > > cool, will try to enable that on OMAP too Cool > * on the pi, each window is a layer. poor man’s wayland > > Awesome. Same comment as above, I'll try to add that to OMAP as well. Wicked > * linuxfb needs to be resurrected > > +10 :) I am planning on whacking this when I get back to Sunnyvale on Tuesday/Wed of next week. > I've just been thinking about that lately, now that QtQuick2 and QtWidgets > can live in parallel after all. Seems silly to have to render QtWidget based > UIs with EGLFS, which yields lower quality and often lower performance > results. amen > I'm volunteering to get that going. I might not be able to get it all done by > myself though. I have already started on this, although the existing code requires far more refactoring than originally intended and I downed tools. I think this would be great to get working for the beta. I really hate this Qt 4/5 division people are mentioning. There is little reason to backport to Qt 4, since there is very little Qt 4 functionality actually stripped from Qt 5 and source compatibility is largely a reality. This also makes this more interesting: https://bugs.webkit.org/show_bug.cgi?id=84532 although webkit might actually develop a hard OpenGL ES 2 requirement. (Might already have it) > One thing I'd love to add in there too is support for more advanced buffer > swapping options, if the platforms support it. For example flip mode can be > easily implemented on OMAP platforms. I can see this being a massive > performance gain on high resolution screens. Cool, I will try to simply map the existing QPA usage to the Qt 5 QPA design. > * openvg backend > > Interesting, especially for the i.MX boards which have a separate OpenVG > accelerator (apparently not based on OpenGL like the SGX one, so likely to > perform better). The Raspberry Pi is also meant to have a discrete (and apparently meaty) OpenVG processor that is currently lying dormant. > It wouldn't be of much use for QQ2, but would still be helpful for many > GraphicsView and Widget based apps. The extent to which this could be used is still a point of research as far as I am concerned. > Should be backported to Qt4 too. This I disagree on. > Cheers > Romain Cheers, Donald > On Friday, June 22, 2012 07:45:19 AM Girish Ramakrishnan wrote: >> Hi, >> For those who were unable to attend, I have posted notes on >> http://qt-project.org/groups/qt-contributors-summit-2012/wiki/Qt-in-Embedded >> . >> >> Let me know about comments >> Girish >> _______________________________________________ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- ------------------------------- °v° Donald Carr /(_)\ Vaguely Professional Penguin lover ^ ^ Cave canem, te necet lingendo Chasing my own tail; hate to see me leave, love to watch me go _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
