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
