Re: [Development] QtCS: Qt Embedded
Hi Laszlo, On Fri, Jun 22, 2012 at 2:16 PM, Laszlo Papp wrote: > On Fri, Jun 22, 2012 at 6:45 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. > > Great! I have few comments from my side: > > 1) Please do not forget the QtSerialPort project we have been working > on. I see no mentionings about that. > There was no representative from the serial port project in the discussion :) > I think serial port management is a crucial part of many existing > embedded boards and systems (just mentioning rpi via gadget serial > driver, beagleboard, pandaboard and so forth). Therefore, this should > also be a fundamental part of the vision. Luckily enough, we have a > good team around focusing on that, and can propose to a mature add-on > soon from playground. > Indeed. I think out-of-the-box working serial port management would be awesome. We should have pre-configured serial port settings for each device. > 2) Pandaboard (including the ES version) is not mentioned, but it has > been working fine for me as well. Our company has been using that > daily for business goals, so I would definitely put that there as > supported. I am sure, it is not just us. I would even say, it is > probably more appealing recently than the beagleboard. > Supported == whatever we have managed to get around working in mkspecs/devices. I actually have pandaboard spec here - https://codereview.qt-project.org/#change,25365. I just haven't gotten around to polishing it. > 3) I find the onboard build important as well. Perhaps I can focus > more on that, if you do not find this ability that important as the > cross-build. This is pretty much the common way for ready-made OSes I > worked with, like ubuntu-arm, arch-arm and so forth. It fits better to > many people's workflow including me. > Yes, we could use with help here. Currently, we (as in Donald, Johannes and myself) have been only focusing on xcompilation support and not on-board compilation support. -device currently assumes xcompilation. It would be great to have it also support on-host compilation out of the box. Thanks, Girish ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: Qt Embedded
On Friday 22 June 2012 11:09:25 ext Donald Carr wrote: > The Raspberry Pi is also meant to have a discrete (and apparently > meaty) OpenVG processor that is currently lying dormant. This turns out not to be the case after all. In the OpenVG session, we were informed that the Raspberry Pi does actually use the same silicon for OpenGL ES and OpenVG. There is no magical gain in performance from running GLES and VG in parallel :/ (Apparently there was some confusion with dispman, which is completely separate.) There are other chips that have separate VG silicon, or even no GLES at all, so there is still a strong usecase for OpenVG. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: Qt Embedded
On Friday, June 22, 2012 02:09:25 AM Donald Carr wrote: > w00t > > On Fri, Jun 22, 2012 at 1:32 AM, Romain Pokrzywka > > 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? Yeah, very true. Forget my comment 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. > Great, let's try to sync in July when I'm back in the Bay. > > 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. > Ah, even more interesting then, indeed > > 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. > hmm, probably because it's not trivial to backport, and since Qt5 isn't that much of a departure from Qt4 after all. Agreed in second thought. > > 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-Embed > >> ded . > >> > >> 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: Qt Embedded
w00t On Fri, Jun 22, 2012 at 1:32 AM, Romain Pokrzywka 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
Re: [Development] QtCS: Qt Embedded
On Fri, Jun 22, 2012 at 1:46 AM, Laszlo Papp wrote: > On Fri, Jun 22, 2012 at 6:45 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. > > Great! I have few comments from my side: > > 1) Please do not forget the QtSerialPort project we have been working > on. I see no mentionings about that. > > I think serial port management is a crucial part of many existing > embedded boards and systems (just mentioning rpi via gadget serial > driver, beagleboard, pandaboard and so forth). Therefore, this should > also be a fundamental part of the vision. Luckily enough, we have a > good team around focusing on that, and can propose to a mature add-on > soon from playground. > > 2) Pandaboard (including the ES version) is not mentioned, but it has > been working fine for me as well. Our company has been using that > daily for business goals, so I would definitely put that there as > supported. I am sure, it is not just us. I would even say, it is > probably more appealing recently than the beagleboard. > > 3) I find the onboard build important as well. Perhaps I can focus > more on that, if you do not find this ability that important as the > cross-build. This is pretty much the common way for ready-made OSes I > worked with, like ubuntu-arm, arch-arm and so forth. It fits better to > many people's workflow including me. I have raised with Ossi that I would like to add a separate rule for compiling build tools for the target. There are some complexities, like requiring a (never tested) on target mkspec which the target qmake would have to use. I would find this very useful in generating images for the Raspberry Pi; compiling Qt on the Pi would be insane, but compiling minor Qt projects on the Pi is entirely feasible and it would be nice if I didn't actually have to have 2 separate compiles of Qt in order to get both the libs and the tools to compile on target. Cheers, Donald > Best Regards, > Laszlo Papp > ___ > 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
Re: [Development] QtCS: Qt Embedded
On Fri, Jun 22, 2012 at 6:45 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. Great! I have few comments from my side: 1) Please do not forget the QtSerialPort project we have been working on. I see no mentionings about that. I think serial port management is a crucial part of many existing embedded boards and systems (just mentioning rpi via gadget serial driver, beagleboard, pandaboard and so forth). Therefore, this should also be a fundamental part of the vision. Luckily enough, we have a good team around focusing on that, and can propose to a mature add-on soon from playground. 2) Pandaboard (including the ES version) is not mentioned, but it has been working fine for me as well. Our company has been using that daily for business goals, so I would definitely put that there as supported. I am sure, it is not just us. I would even say, it is probably more appealing recently than the beagleboard. 3) I find the onboard build important as well. Perhaps I can focus more on that, if you do not find this ability that important as the cross-build. This is pretty much the common way for ready-made OSes I worked with, like ubuntu-arm, arch-arm and so forth. It fits better to many people's workflow including me. Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: Qt Embedded
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) * cursor support hw accel on the pi, the cursor is a separate layer cool, will try to enable that on OMAP too * 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. * linuxfb needs to be resurrected +10 :) 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. I'm volunteering to get that going. I might not be able to get it all done by myself though. 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. * 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). It wouldn't be of much use for QQ2, but would still be helpful for many GraphicsView and Widget based apps. Should be backported to Qt4 too. Cheers Romain 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
Re: [Development] QtCS: Qt Embedded
Very useful, thanks a lot for taking the time to write those down! Romain 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
Re: [Development] QtCS: Qt Embedded
On Fri, Jun 22, 2012 at 7:45 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 Whoops, sent too soon. Feel free to ask any questions/comments/clarifications either on the list or in person (should be easy to find me since there are hardly any indians around :-)). Girish ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QtCS: Qt Embedded
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
