[Interest] Qt5/OMAP4/EGLFS: Strange animation behaviour

Stephan Kanthak stylon at gmx.de
Mon Dec 10 11:31:13 CET 2012


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 at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20121210/71087a7c/attachment.html>


More information about the Interest mailing list