You can install the Clutter tests by installing libclutter-glx-1.0-examples. Then running a section of the test suite: $ test-interactive test_cairo_flowers PVRDRIInit2D: PVR2D device index (0) PVRDRIMakeCurrentGC: GLMakeCurrentGC failed (3) Clutter-CRITICAL: Unable to initialize Clutter: the OpenGL version could not be determined [exits] Is my image broken, or is this a problem with the binary DRI driver and open Mesa library interaction?
Nitin, my guess it this is not cedartrail specific. Can you work with Ross to get the cairo tests and verify that you can get this working with other binary graphics driver boards? Kishore, Rahul, can you follow-up with Ross regarding cedartrail specifically? I'm treating this as a meta-intel must fix for 1.3. This indicates to me that Ross may have been correct about the binary driver with mismatched mesa GL libraries.
I will check this libclutter-glx-1.0-examples test with crownbay BSP which has EMGD binary graphics driver. I don't have the cedartrail hardware with me. Nitin
I tried the cairo tests from with the test-interactive program from libclutter-glx-1.0-examples on the crownbay hardware, and I did not see any issues with running these tests.
to be more specific I tried these tests: cairo_clock & cairo_flowers
Rahul looked at the issue. He noticed that correct files are getting packaged in the image. So looks like this is issue with the binary PVR driver.
Rahul, any further details on it? At least we need to know if the issue will get fixed before 1.3 release or not.
Nitin, I am going to try out the tests and look at it now. Will give you a update mid next week.
Hi Rahul, Add this line to your local.conf EXTRA_IMAGE_FEATURES += "tools-testapps libclutter-glx-1.0-examples" and then build the core-image-sato image and when booted the image on the h/w, in the graphical user interface open a terminal to run these commands: $ test-interactive test_cairo_flowers $ test-interactive test_cairo_clock Nitin
I got the seame error messages on Clutter tests as Ross. However the Cedar Trail PVR driver release notes states the following: "Very limited support for OpenGL API ("big GL"). The release notes also indicate that OpenGLES is supported. I assume these clutter tests are trying to use OpenGL API and not OpenGLES (going by the error messages). Should we then even expect these clutter tests to pass ?
GL is certainly limited, but it somewhat works. On MeeGo, GL apps apps like Google Earth and Neverball work. I guess the right thing to do now is to try something like Google Earth on the same hardware with both MeeGo and Poky. (as you say, GL on CDT is very limited, don't consider this a high priority bug)
Rahul, so what is the status of this issue for 1.3 release? I see no solution to the issue. And in that case, we need to add information regarding this issue in the 1.3 release document. Thanks, Nitin
Nitin, I am getting zero support from PVR driver team, so I dont see this issue being fixed with 1.3 Release. Anyhow the issue may just be a result of this driver limitation of only very limited support for OpenGL. As far as 1.3 release document is concerned, does it make sense to indicate something more generic, such as the statement below from the PVR driver release notes ..as opposed to a list of specific Apps that may not work with this driver ?. "Very limited support for OpenGL API ("big GL"), I can send you the driver release notes. Thanks Rahul
Re-iterating the brokenness of GL is probably very wise.
I emailed Joe Konno, who I worked with during MeeGo for CDT. He said: ---- Yes, Cedarview big GL blows-- though unsupported throughout development, the big GL driver was, demanded by stakeholders, thus its inclusion in the packages for MeeGo and Ubuntu. I agree that it's fragile at best and ought not be targeted by developers. There is a hard dependency on some of the internal Mesa data structures within the actual source code. Le sigh. Traditionally, each major version of Mesa has tweaked some of these data structures in some way, requiring source code tweaks. Yes, it's as bad as it sounds-- there are branches for each major version of Mesa we supported during development. Thus, each release of the Cedarview gfx driver must be coupled to a particular version of Mesa. To add forward compatibility would require revisiting the driver architecture. I don't see that happening. For the MeeGo-packaged driver, hard dependency on Mesa 7.9 For the Canonical-packaged driver for Precise (12.04), Mesa 8.0.1 (-ish) --- So if we want to enable GL on CDT (and I expect the same holds for EMGD) we need another version of Mesa available.
I think at one point I had Mesa 7.9 for this BSP, but had not tried clutter then. Will try it out again.
Currently with recent commits (as below) the image is not booting when built with either the MESA-DRI 8.0.4 (currently in meta-intel) or after modifying my local copy with MESA-DRI 7.9 . meta-intel: Oct 29: 76d2942087d7563ae42f0bea6d97460ee2561f3e poky: Oct 29: e9e3285e1397cfd2d34f4eb7b5aa59311eea861d Looks like some recent commit/s has caused it to break.
Rahul, I see you are not using the danny branch of poky. Danny is YP 1.3. Also MES_DRI should not affect bootability. So clearly you are hitting on some other issue in the poky master. Nitin `
Presumably you're hitting udevd failures - it's broken when booting through an initramfs.
I tried MESA 7.9 with Poky Danny branch. The clutter tests still had the same failure. One thing I noticed was that 'glxinfo' command does not give any mesa version info, though it is supposed to (as per examples I found on the web). Perhaps its just a glxinfo version issue ?
Since the issue has persisted even with MESA 7.9, it looks like the root problem may be as indicated in the statement below in the ReleaseNotes: "Very limited support for OpenGL API ("big GL"). Let me know if others on this list are OK with me to close this issue with "Resolved Wont be fixed" status.
cedar-trail require the 3.0 kernel and it has been removed from the 1.4 release. Closing as INVALID as it doesn't apply to the 1.4 release.