[Interest] Compiling QT5
Hi all, I'm new to this list and also new to Qt5. I recently downloaded the beta1 and compiled it for an OMAP4 platform according to the following instructions: http://gpupowered.org/node/8 (originally for the alpha) and http://www.slideshare.net/prabindh (except for some tiny patches, looks straightforward in my view). I strictly followed the instructions, compiled qtbase/qtjsbackend/qtdeclarative/qt3d/qtmultimedia and all seemed to work (TI OGLES2 examples, most QT examples, QML demos, Qt3D demos, etc.). More precisely, I configured qtbase with: export BUILD_PATH=/home/stylon/prj/build ./configure --prefix=$BUILD_PATH/usr -release -make libs -xplatform linux-arm-gnueabi-g++ -opengl es2 -confirm-license -opensource -no-xcb -no-wayland -force-pkg-config -make examples -make demos -verbose The rest was just cd dir qmake make make install as mentioned on the pages above. I even wrote a small QML script myself to test animations and although I noticed some tearing and non-smooth animations, all was working fine in principle. Due to the little jerky animations I changed the hardcoded refreshRate for eglfs from 60 to 50 and tried to recompile, but recompilation already failed. I then tried to start from scratch on the instructions from prabindh and now I always get the following error message when compiling qtdeclarative: indy:qtdeclarative 2505 make cd src/ ( test -f Makefile || /home/stylon/prj/qt/qtbase/bin/qmake /home/stylon/prj/qt-everywhere-opensource-src-5.0.0-beta1/qtdeclarative/src/src.pro -o Makefile ) make -f Makefile make[1]: Entering directory `/home/stylon/prj/qt-everywhere-opensource-src-5.0.0-beta1/qtdeclarative/src' cd qml/ ( test -f Makefile || /home/stylon/prj/qt/qtbase/bin/qmake /home/stylon/prj/qt-everywhere-opensource-src-5.0.0-beta1/qtdeclarative/src/qml/qml.pro -o Makefile ) make -f Makefile Project ERROR: Unknown module(s) in QT_PRIVATE: v8 make[1]: *** [sub-qml-make_first-ordered] Error 2 make[1]: Leaving directory `/home/stylon/prj/qt-everywhere-opensource-src-5.0.0-beta1/qtdeclarative/src' make: *** [sub-src-make_first] Error 2 BTW, /home/stylon/prj/qt is a link to /home/stylon/prj/qt-everywhere-opensource-src-5.0.0-beta1. As you can see above, the install directory is /home/stylon/prj/build/usr and in /home/stylon/prj/build/usr/mkspecs/modules I do see qt_v8.pri, but strace'ing the call of qmake in the qtdeclarative/src/qml directory above shows that qmake instead looks at /home/stylon/prj/qt/qtbase/mkspecs/modules where only the qtbase configurations can be found. /home/stylon/prj/qt/build/usr is never being accessed at all. Any idea what I do wrong (now)? Any idea why compilation of qt5 worked once? I don't know anything about qmake, but overall it looks strange to me that qmake from qtbase/bin should be able to know the configuration of v8 from qtjsbackend at all the way I configured it now, but I can't see how to configure it differently. Anybody else seeing the same error? At least I found it twice on the web via Google, but without mentioning any solution. Thanks best, Stephan ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Qt5/OMAP4/EGLFS: Strange animation behaviour
Hi, some background first: for some little project I'm planning to prototype a custom UI. I got interested in Qt5, because of QML + Javascript. The OMAP4 platform I use (a modified Kindle Fire, but very similar to the Pandaboard) offers EGL/OGLES2 and I got some drivers running from TI directly on LinuxFB without XCB. I couldn't use their latest drivers SDK (only OMAP3), but please ask TI that question why they stopped delivering a driver SDK for their OMAP4 suddenly about a year ago. Qt5 compiles fine now against those drivers (see my previous post) and demos/examples run. Since then I also got extension stuff, e.g. from http://qt.gitorious.org/qtplayground/scenegraph to compile and run. The EGL/OGLES2 demos from TI run smoothly, despite some little tearing here and there. Only OGLES2Water seems to stutter about once a second, but let's take that as an exception. The TI driver is also configured for 4 buffers (!). There's a little tool provided that tells you how many buffers it manages to allocate and depending on how much memory is being reserved at boot time, I do see that it allocates also 1, 2, 3 buffers. From the TI demos I conclude that the driver seems to buffer, but don't always swap buffers correctly at VSYNC time. Although with some demos (e.g. OGLES2ChameleonMan) it's pretty hard to find any tearing. Now here's my problem: with unmodified Qt5 I don't get *any* smooth animation. As far as I understood Gunnar's blog posts at http://blog.qt.digia.com/blog/author/gunnar/ this should not happen with Qt5/eglfs, except maybe when I use Javascript, block the main thread with something else or run processes in the background. But none of the latter is the case. So, I digged a bit deeper. Here's what I tried: 1. according to Gunnar's post, Qt5 tries to predict animation states for the time a buffer is being displayed. So, I tried to find out what refresh rate Qt5 assumes and it's indeed hard-coded to 60Hz and not being overloaded by eglfs (see qplatformscreen.cpp, eglfs should be corrected to ask the driver for the display's refresh rate in my view). The Kindle Fire does some strange pixel-clock initialization and at the end seems to fall back to something very close to 50Hz. So, I changed that in the code = but, no effect at all. 2. I tried the stuff at http://qt.gitorious.org/qtplayground/scenegraph. The examples in the animators/test directory I did run with qmlscene. By default all of them are stuttering a lot, no matter wether it's the RenderThread or MainThread animation. Surprisingly, this changes once I hit the Block button. That starts an infinite javascript loop in the main thread. All of a sudden the RenderThread animation is perfectly smooth and the MainThread animation becomes sufficiently smooth, but just not as perfect as the RenderThread animation. Surprisingly, the process does not exceed 25% CPU even when running that Javascript loop, but without it uses 10%. I would expect ~0% without (most animations just update a single property) and 100% with that Javascript loop. And... I would have expected the animations to be smooth without the block loop and stuttering when it's running. 3. I did a tiny prototype qml animation and that runs really perfectly smooth using qmlscene on a MacBook Air (that's why we all love macs, right :-) ). Running the same on my platform stutters like the stuff from that playground scenegraph. Using RT objects and the Javascript main thread blocker loop improves smoothness a little bit, but not comparably as smooth as in the scenegraph demo. If Gunnar is listening to this list: I've no idea what is going on here :-). It actually behaves so much against all my predictions (except the TI demos) that I'm a bit puzzled. But maybe we can find out why it behaves so strange. Qt5 is not mandatory for my little project, so I could move forward with plain EGL/OGLES2, but using QML + Javascript would make things for me a lot easier. Thanks best, Stephan ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt5/OMAP4/EGLFS: Strange animation behaviour
Hi Samuel, Am 15.11.2012 um 13:24 schrieb Samuel Rødal samuel.ro...@digia.com: On 11/15/2012 11:07 AM, Stephan Kanthak wrote: Hi, some background first: for some little project I'm planning to prototype a custom UI. I got interested in Qt5, because of QML + Javascript. The OMAP4 platform I use (a modified Kindle Fire, but very similar to the Pandaboard) offers EGL/OGLES2 and I got some drivers running from TI directly on LinuxFB without XCB. I couldn't use their latest drivers SDK (only OMAP3), but please ask TI that question why they stopped delivering a driver SDK for their OMAP4 suddenly about a year ago. Qt5 compiles fine now against those drivers (see my previous post) and demos/examples run. Since then I also got extension stuff, e.g. from http://qt.gitorious.org/qtplayground/scenegraph to compile and run. The EGL/OGLES2 demos from TI run smoothly, despite some little tearing here and there. Only OGLES2Water seems to stutter about once a second, but let's take that as an exception. The TI driver is also configured for 4 buffers (!). There's a little tool provided that tells you how many buffers it manages to allocate and depending on how much memory is being reserved at boot time, I do see that it allocates also 1, 2, 3 buffers. From the TI demos I conclude that the driver seems to buffer, but don't always swap buffers correctly at VSYNC time. Although with some demos (e.g. OGLES2ChameleonMan) it's pretty hard to find any tearing. Now here's my problem: with unmodified Qt5 I don't get *any* smooth animation. As far as I understood Gunnar's blog posts at http://blog.qt.digia.com/blog/author/gunnar/ this should not happen with Qt5/eglfs, except maybe when I use Javascript, block the main thread with something else or run processes in the background. But none of the latter is the case. So, I digged a bit deeper. Here's what I tried: 1. according to Gunnar's post, Qt5 tries to predict animation states for the time a buffer is being displayed. So, I tried to find out what refresh rate Qt5 assumes and it's indeed hard-coded to 60Hz and not being overloaded by eglfs (see qplatformscreen.cpp, eglfs should be corrected to ask the driver for the display's refresh rate in my view). The Kindle Fire does some strange pixel-clock initialization and at the end seems to fall back to something very close to 50Hz. So, I changed that in the code = but, no effect at all. 2. I tried the stuff at http://qt.gitorious.org/qtplayground/scenegraph. The examples in the animators/test directory I did run with qmlscene. By default all of them are stuttering a lot, no matter wether it's the RenderThread or MainThread animation. Surprisingly, this changes once I hit the Block button. That starts an infinite javascript loop in the main thread. All of a sudden the RenderThread animation is perfectly smooth and the MainThread animation becomes sufficiently smooth, but just not as perfect as the RenderThread animation. Surprisingly, the process does not exceed 25% CPU even when running that Javascript loop, but without it uses 10%. I would expect ~0% without (most animations just update a single property) and 100% with that Javascript loop. And... I would have expected the animations to be smooth without the block loop and stuttering when it's running. 3. I did a tiny prototype qml animation and that runs really perfectly smooth using qmlscene on a MacBook Air (that's why we all love macs, right :-) ). Running the same on my platform stutters like the stuff from that playground scenegraph. Using RT objects and the Javascript main thread blocker loop improves smoothness a little bit, but not comparably as smooth as in the scenegraph demo. Are you doing export QML_FORCE_THREADED_RENDERER=1? Because afaik without that you won't get the threaded renderer. Most issues I've seen with animations have been due to not using the threaded renderer. I didn't had much time to test yesterday, but that was a big step forward. The stuttering is gone and now tearing is a bit more obvious, but it's close to smooth. At least with eglfs. Minimalegl seems to behave differently. The animations there still show some more jumps, but overall they seem to run faster compared to eglfs with that env variable being set. You might also want to try the customcontext renderer from ssh://codereview.qt-project.org:29418/playground/scenegraph.git See my post, I already did :-). Although I still have to try again using the RenderThread stuff + that env variable in my own little QML application. After building and doing make install there you should be able to use it by doing export QMLSCENE_DEVICE=customcontext or running with --device=customcontext That's great info. I already wondered how customcontext gets used and I obviously didn't use it yet :-). If it's a timing issue you might also try QML_FIXED_ANIMATION_STEP=1 I will try all this on Monday
Re: [Interest] Qt5/OMAP4/EGLFS: Strange animation behaviour
Hi Prabindh, first hand info, that's very well appreciated :-) Am 16.11.2012 um 05:29 schrieb Sundareson, Prabindh pr...@ti.com: I couldn't use their latest drivers SDK (only OMAP3), but please ask TI that question why they stopped delivering a driver SDK for their OMAP4 suddenly about a year ago. I cannot really comment on why, but am glad you got it working even with that older release. Don't ask for the little hassles I went through :-). I already tried to get something working from drivers released by linaro/ubuntu which are newer, but unfortunately there are missing pieces (the release seems to include files for xcb/dri only). From the TI demos I conclude that the driver seems to buffer, but don't always swap buffers correctly at VSYNC time What Linux kernel version and package/distribution are you using ? If you can dump the environment log from script in below page, I can perhaps answer your VSYNC query: http://processors.wiki.ti.com/index.php/SGXDbg#Baselining_the_current_SGX_driver_environment Here you go: WSEGL settings [default] #WindowSystem=libpvrPVR2D_FRONTWSEGL.so #WindowSystem=libpvrPVR2D_FLIPWSEGL.so WindowSystem=libpvrPVR2D_LINUXFBWSEGL.so #WindowSystem=libpvrPVR2D_BLITWSEGL.so -- ARM CPU information Processor : ARMv7 Processor rev 3 (v7l) processor : 0 BogoMIPS: 599.13 processor : 1 BogoMIPS: 594.13 Features: swp half thumb fastmult vfp edsp thumbee neon vfpv3 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x1 CPU part: 0xc09 CPU revision: 3 Hardware: OMAP4430 Revision: 0010 Serial : -- SGX driver information Version 1.6.16.4117 (release) /home/stylon/prj/system/Graphics_SDK_4_04_00_03/GFX_Linux_KM System Version String: SGX revision = 1.2.0 -- Framebuffer settings fbset: not found -- Rotation settings 0 -- Kernel Module information Module Size Used byNot tainted bufferclass_ti 4712 0 omaplfb11507 0 pvrsrvkm 145076 2 bufferclass_ti,omaplfb -- Boot settings quiet mem=456M@0x8000 init=/init vram=10M omapfb.vram=0:10M vyres=1800 omapfb.vyres=1800 -- Linux Kernel version Linux localhost 2.6.35.7+ #47 SMP PREEMPT Tue Nov 6 23:12:37 CET 2012 armv7l GNU/Linux Please note that the kernel is pretty similar to the one Amazon released. I could have moved to 3.x already, but wanted to stay a bit more stable first. It still contains a lot of Android stuff, although I don't use the original pvrsrvkm, but instead the recompiled one from the driver package. regards Prabindh Thanks already best, Stephan -Original Message- From: interest-bounces+prabu=ti@qt-project.org [mailto:interest-bounces+prabu=ti@qt-project.org] On Behalf Of Stephan Kanthak Sent: Thursday, November 15, 2012 3:37 PM To: interest@qt-project.org Subject: [Interest] Qt5/OMAP4/EGLFS: Strange animation behaviour Hi, some background first: for some little project I'm planning to prototype a custom UI. I got interested in Qt5, because of QML + Javascript. The OMAP4 platform I use (a modified Kindle Fire, but very similar to the Pandaboard) offers EGL/OGLES2 and I got some drivers running from TI directly on LinuxFB without XCB. I couldn't use their latest drivers SDK (only OMAP3), but please ask TI that question why they stopped delivering a driver SDK for their OMAP4 suddenly about a year ago. Qt5 compiles fine now against those drivers (see my previous post) and demos/examples run. Since then I also got extension stuff, e.g. from http://qt.gitorious.org/qtplayground/scenegraph to compile and run. The EGL/OGLES2 demos from TI run smoothly, despite some little tearing here and there. Only OGLES2Water seems to stutter about once a second, but let's take that as an exception. The TI driver is also configured for 4 buffers (!). There's a little tool provided that tells you how many buffers it manages to allocate and depending on how much memory is being reserved at boot time, I do see that it allocates also 1, 2, 3 buffers. From the TI demos I conclude that the driver seems to buffer, but don't always swap buffers correctly at VSYNC time. Although with some demos (e.g. OGLES2ChameleonMan) it's pretty hard to find any tearing. Now here's my problem: with unmodified Qt5 I don't get *any* smooth animation. As far as I understood Gunnar's blog posts at http://blog.qt.digia.com/blog/author/gunnar/ this should not happen with Qt5/eglfs, except maybe when I use Javascript, block the main thread with something else or run processes in the background. But none of the latter is the case. So, I digged a bit deeper. Here's what I tried: 1. according to Gunnar's post, Qt5 tries to predict animation states for the time a buffer is being displayed. So, I tried to find out what refresh rate Qt5 assumes
Re: [Interest] Qt5/OMAP4/EGLFS: Strange animation behaviour
Hi Donald, On 11/19/2012 10:54 PM, Donald Carr wrote: On top of all of this, I saw weird partial updates on all the OMAP SGX based devices I tested against Qt 5. I have a beagle board video uploaded which shows the screen broken up into 4 discrete quadrants which are alternately updated. I did make good progress this evening :-). The TI demos do all tear. I now traced it down to no vsync at all! My assumption was that these demos do instead use vsync, but in fact they don't. Only OGLES2ChameleonMan did not seem to tear, but I think only by chance, as the frame rate it uses to predict animation was almost exactly matching 3 times the frame update frequency. I actually tried a couple of things, but finally explicitly waiting for VSYNC within the OMAP display subsystem (DSS) does perfectly vsync all demos (an now I've proof for the Kindle Fire's 50Hz panel, too :-) )! I'll try to test that on qt5/eglfs tomorrow. Unfortunately, in the 2.6.35 kernel that I'm using OMAP DSS does not yet handle the generic FBIO_WAITFORVSYNC, but instead uses own ioctls. I've seen that more recent omap kernels also catch FBIO_WAITFORVSYNC. I'm not sure wether other framebuffer drivers handle this in the same way. Best, Stephan ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt5/OMAP4/EGLFS: Strange animation behaviour
Hi Prabindh, that one went out too quickly... :-) I think my last posting wasn't that precise. The TI package I'm using clearly lacks VSYNC support for OMAP4. None of the SDK demos runs at a constant frame rate (some at 150+ fps), none of them uses a blocking vsync ioctl (simply ltrace/strace and you'll noice). On the other hand, the kernel 2.6.35 that I'm using does have working VSYNC and it would be as easy to fix as adding that ioctl to eglSwapBuffers(). That's basically what I've done to both PVRShell from the SDK and Qt5Beta1. Switching to the flip chain driver simply removed the single remaining tearing line, which certainly makes, because that's exactly what I assume would happen witha single buffer+ vsync. Taking into account the info from Samuel's post it's obvious that the TI driver is simply lacking VSYNC support for OMAP4, something that could be fixed by some hacks to Qt5 or other apps, but should rather be fixed in the driver (or user-level library stub). Best, Stephan On 20.11.2012, at 13:30, Sundareson, Prabindh pr...@ti.com wrote: Good to know that the flip mode solved the issue. You might want to update to a later kernel revision and check. Vsync handling is more complex than it appears, over fb drivers. regards Prabindh -Original Message- From: interest-bounces+prabu=ti@qt-project.org [mailto:interest-bounces+prabu=ti@qt-project.org] On Behalf Of Stephan Kanthak Sent: Tuesday, November 20, 2012 1:32 PM To: interest@qt-project.org Subject: Re: [Interest] Qt5/OMAP4/EGLFS: Strange animation behaviour Hi Prabindh, couldn't wait, so I already tried yesterday, but then went to bed :-). It worked immediately! I added an ioctl(fbdev, WAITFORSYNC) to qt/qtbase/src/platformsupport/eglconvenience/qeglplatformcontext.cpp and after that all animations were butter smooth immediately. I also noticed that there was constant tearing somewhere close to the top of the display. After adding ioctl(fbdev, WAITFORSYNC) to PVRShell.cpp I had the same tearing already on all SGX demos and already noticed that I was still using the LINUXFB driver that doesn't use the flip chain. So, everything is perfectly smooth now, except maybe when I enable FSAA in complex scenes, but most likely the SGX core bows quickly then :-). The only remaining question is, why does the egl driver not wait for vsync? I think that's what also the PVR demos assume. Some of them run at high frame rates, but should instead never exceed the displays refresh rate. Or is there a known bug for OMAP4 with the driver release I use? I've found a post on some Google group from January this year: https://groups.google.com/forum/#!topic/pandaboard/Ig7VrOU_zW8 where someone notices exactly the same with that driver release (Pandaboard, FBDEV = no vsync on eglSwapBuffers). According to that thread, the Linaro/Ubuntu driver seems to use it, but only under certain circumstances. Although I know now how to hack it, any idea? I also feel like this thread should move now to either some TI-SXG- or -dev mailing list, or is it fine to finish the discussion here? Best, Stephan On 11/20/2012 03:21 AM, Sundareson, Prabindh wrote: Did you try flipwsegl, as specified in below link ? From your last log, you were using linuxfbwsegl. http://processors.wiki.ti.com/index.php/SGXDbg#Vertical_Tearing Note: - Moving to flip will reduce the framerate - If you still see tearing with flip, ensure you really have 3 flipbuffers allocated, and the fb driver really waits for vsync. There were issues with older versions of fb that did not properly support waiting for vsync, atleast on OMAP3. regards Prabindh -Original Message- From: interest-bounces+prabu=ti@qt-project.org [mailto:interest-bounces+prabu=ti@qt-project.org] On Behalf Of Stephan Kanthak Sent: Tuesday, November 20, 2012 6:40 AM To: Donald Carr Cc: interest@qt-project.org Subject: Re: [Interest] Qt5/OMAP4/EGLFS: Strange animation behaviour Hi Donald, On 11/19/2012 10:54 PM, Donald Carr wrote: On top of all of this, I saw weird partial updates on all the OMAP SGX based devices I tested against Qt 5. I have a beagle board video uploaded which shows the screen broken up into 4 discrete quadrants which are alternately updated. I did make good progress this evening :-). The TI demos do all tear. I now traced it down to no vsync at all! My assumption was that these demos do instead use vsync, but in fact they don't. Only OGLES2ChameleonMan did not seem to tear, but I think only by chance, as the frame rate it uses to predict animation was almost exactly matching 3 times the frame update frequency. I actually tried a couple of things, but finally explicitly waiting for VSYNC within the OMAP display subsystem (DSS) does perfectly vsync all demos (an now I've proof for the Kindle Fire's 50Hz panel, too :-) )! I'll try to test
Re: [Interest] unable to cross-compile my Qt 5 program for BeagleBoard-xM
Hi Steve, I'm posting this back on the mailing list as this is probably info that others find useful, too. On 11/21/2012 04:53 AM, VStevenP wrote: I would like to ask your opinion... Is it best to install the Qt cross-compiled output directly to the root of the ext3 fs on the micro-SD card? I'm trying to understand the most desirable workflow. For now, I set my configure prefix to point to a 'staging' directory. So the Qt 5 Beta 2 cross-compiled output went there. Then, I copied all the needed shared objects from that QT cross-compile output lib dir and also from the arm toolchain lib dir into /usr/lib on the micro-SD card. Then, when I ran my program on the BB, it resolved all the shared libraries. Is this how you do it, too? Yes, inspired by buildroot which I also use to compile some libraries (e.g. alsa, dbus, gstreamer, etc.), I install everything to a staging directory first (still includes all dev files) and then create a separate stripped filesystem from that by simple copy. For the root filesystem I use mksquashfs as it's then compact, fast and easy to flash in one single piece. The only problem I have right now is that I did not know where to copy the QPA platform plugins onto the card, so my program can not detect the eglfs plug-in. Qt5 installs them to staging/usr/plugins and that's where they end up on the target filesystem, too. The trick is to create a qt.conf in the directory of your final executable (e.g. qmlscene) that points to the base QTDIR. I placed mine into staging/usr/bin next to qmlscene: [Paths] Prefix = /usr/ All this is most likely documented somewhere, but I found out a bit by trial and error :-). Best, Stephan ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt5/OMAP4/EGLFS: Strange animation behaviour
Hi all, I promised to get back on this, once Prabindh and I find out more about the real issues: 1. I got this working cleanly for Qt5 + LinuxFB/EGL + OMAP4 using (the rather old) TI SGX driver release 4.04.00.03 by adding a get_update_mode() callback to the appropriate panel driver in the kernel (2.6.35.7). Thanks to Prabindh to point me in the right direction. There's no fix needed for the OMAP4 SDP panel-taal.c driver in the kernel, but all other panel drivers do need fixes! People working on a similar track than me may have bumped into this same problem and should inspect the appropriate panel driver code. Donald, if you tried the same as me, it's definitely worth looking at the panel's driver, fix was pretty simple. This also removed the need for any vsync user-level code via ioctl, so not a single change needed for Qt5 (I still have to try OMAP4 video acceleration in QtMultimedia). 2. Android driver SDKs seem to not test for the panel driver's update mode. That's what confused me initially as on Android and the original Kindle Fire everything is smooth. The logic there is hard-wired and in my view the same behaviour could be applied to the non-Android SDK. This is an alternative way of fixing the problem, but I personally prefer fixing the kernel's panel drivers. In case TI does not want to publish a new driver for OMAP4 to support LinuxFB/EGL, it seems the Linux community can continue to maintain this separately as the SDK is licensed under CC license. I'm strictly not volunteering here, but TI may have reasons to not help us much on this. 3. for LinuxFB/EGL (and that also includes Qt5 to some extent) it's impossible to move to a newer version of the DDK, as Ubuntu/Linaro only releases the DRM part of the driver and I couldn't get Android drivers working at all. I suspect it's mostly due to absolute paths being compiled into all libs, so /system/..., but I failed at all attempts to patch them. Finally there could also be linkage problems that I didn't see yet. All in all my conclusions are that you can get this working, but only with some considerable effort on a bit outdated software packages. I can document what I did somewhere and I most likely will when I find time for that. But there's still some bitter taste left as the main problem seems to be due to not much maintained driver SDK / kernel code. I would love to move on to the latest driver version, but LinuxFB/EGL is simply not supported by the non-Android SDKs anymore. So, I may as well continue to check the Android SDK path again. Best, Stephan On 11/21/2012 09:26 AM, Samuel Rødal wrote: On 11/21/2012 09:17 AM, Stephan Kanthak wrote: Hi Samuel, On 11/21/2012 08:43 AM, Samuel Rødal wrote: On 11/20/2012 09:12 PM, Stephan Kanthak wrote: Hi, one final word to this list on my fix. I think that the fix I did to Qt5 is not in good shape to be integrated. My fix interfaces directly with OMAP-specific ioctl's to a linux framebuffer device in code that is generic to all egl platforms. I'll continue to discuss this first with Prabindh from TI to find out more about where to best fix this. Maybe I'm also not using the TI driver to its best, but I already tried hard to understand the problem in more general. For eglfs we have a solution for device / device-family specific work-arounds, they're the QEglFSHooks, in src/plugins/platforms/eglfs/qeglfshooks.h beforeSwapBuffers() and/or afterSwapBuffers() could be added to the hooks for instance, so that you could put your work-around in a file specified by a custom mkspec. As an example, ee mkspecs/devices/linux-rasp-pi-g++ for the hooks used on the raspberry pi, qeglfshooks_pi.cpp, enabled by setting the EGLFS_PLATFORM_HOOKS_SOURCES variable in the qmake.conf in the same directory. That's indeed a good suggestion. I already noticed those hooks when I inspected the mkspecs files in linux-rasp-pi-g++, but yet didn't take the time to fully understand the concept. But it does make sense to me now. In order to make that lean clean, I assume it's best to also create a separate directory for my config in mkspecs/devices, right? So far, I was using the default linux-arm-gnueabi-g++. Yep. -- Samuel ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt5/OMAP4/EGLFS: Strange animation behaviour
Hi Samuel, On 12/10/2012 11:40 AM, Samuel Rødal wrote: On 12/10/2012 11:31 AM, Stephan Kanthak wrote: ... continue to check the Android SDK path again. Which Android SDK part would that be? You might be interested in http://qt-project.org/wiki/Korhal I just remembered another reason why using TI's Android SGX libs may be a bad idea: you have to link your whole system libs against Google's bionic libc. I failed to get buildroot / openbricks working in such environment. Best, Stephan ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] can qt.conf be put in a common location?
On 01/29/2013 06:34 AM, Thiago Macieira wrote: On segunda-feira, 28 de janeiro de 2013 19.44.18, VStevenP wrote: Is it possible to specify a shared location for qt.conf using an environment variable? It's being a bit of a pain to put a qt.conf file in the app dir for every Qt example installed on my target system. If I could specify a location where the file could be found, I wouldn't have to create a qt.conf for every Qt example I want to run on the target. Why do you need a qt.conf in the first place? qt.conf is supposed to be used for an application that can be installed to an arbitrary location. If you're building an entire system, you should simply configure the system correctly. I bumped into the same problem as StevenP a while ago (I think we even talked about it here already before). As I didn't find a reference to configure my system correctly, can you please let us know what the correct way would be? I also failed to find out how to precompiled paths for Qt are being determined and they're still set to wrong default locations for me, so that's why I also still stick to configuring my application via qt.conf. No big deal for me as there is only one, but others may have more problems. In my view, the qt.conf mechanism could very well use a QT_CONF environment variable override just for convenience as it's no big deal to just check an environment variable prior to looking for qt.conf in the current directory. That's what I had expected after the need to set some QT_QPA_... env variables to get things working for the first time. Best, Stephan ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Status of project Korhal
Hi, a few months ago I came here with some OMAP4 related issues that I got fixed my way. Samuel pointed me to project Korhal and while I didn't try it immediately I now found the time to try it (and I also like the idea). Yet I didn't get beyond some compiler issues as soon as it hits the first Qt source code, but I think I can fix that. As I may want to port the code also to Android 4.2.1 I would like to know what the status of that project is. Is there anybody who I can ask for details (beyond the blog/wiki entries that are there)? If successful I may be able to provide a 4.2.1 setup for the original Kindle Fire, just in case someone is interested in that (hardware is pretty similar to the mid-age Pandaboards, so it's likely that'll work quickly, too). Would the project Korhal repository be the right place for that? Best, Stephan ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
