I have configured my system to use LVDS, but when I try to run a JavaFX program it emits the following error: com.sun.glass.ui.monocle.GLException: 0x3003: Could not get EGL surface Interestingly *any* sample program in /opt/fsl-gpu-sdk stops with ERROR: demo setup failed with: eglCreateWindowSurface(m_hDisplay, m_hConfig, hWi ndow, nullptr) failed with error code 12291 at source/FslDemoHostEGL/EGLDemoHost .cpp(504) Being 0x3003 is equal to 12291 it indicates it is the same error. My assumption is that something is wrong in my platform setup, but obviously I don't know what.
Can you please test the 16bpp fix proposed here https://community.freescale.com/message/587654#587654 Gesendet von meinem FP2 mit Tapatalk
ATM it is set to 32... https://github.com/UDOOboard/linux_...-udoo/arch/arm/boot/dts/imx6q-udoo-lvds15.dts Gesendet von meinem FP2 mit Tapatalk
I have this error with kodi because of using resolution 1366x768. IPU needs X and Y by modulo 8 and 1366 is not. But I was using kernel >4.0.
I somehow assume it is a matter of the sample programs trying to use the wrong framebuffer. I see the code tries to access fbGetDisplayByIndex(0). Would the LVDS be display 0? There is only one display connected.
AFAIK there are two framebuffers one is the one for the display on the otherone you can paint as an overlay Gesendet von meinem FP2 mit Tapatalk
Here you'll find some basic information: http://trac.gateworks.com/wiki/Yocto/Video_Out Gesendet von meinem FP2 mit Tapatalk
From the mentioned page: Device Registration Display Framebuffer Video First HDMI fb0, fb1 video16, video17 Second CVBS fb2, fb3 video18, video19 Third LVDS fb4 video20 Fourth Off - - But I presume that this is device specific, on UDOO there is only fb0 and fb1.
From the above page: The displays can have different orders. If you register HDMI as the first fb HDMI will be on /dev/fb0 It looks like the first two framebuffers have overlay support: Maybe the information stored in sysfs do shed some lights:
I guess video=mxcfb0:dev=ldb,LDB-WXGA,if=RGB24,bpp=32 means that the lvds (dev=ldb) is mapped on the first framebuffer.
The same page mentiones a fb-test image. Maybe it could be included in the Yocto image? How to Output a Test Pattern In order to display something, you can run a utility called fb-test. To display a variety of colors, making sure the display is unblanked, type the following and hit return: fb-test -f 0 This utility is useful as you can test a variety of colors and patterns. Also note: Since framebuffers are just raw pixel information in memory, you can perform many low levels tasks such as directly copying the raw data with a cp /dev/fb0 /tmp/image. Or writing raw data back with cp /tmp/image /dev/fb0. This contributes to their continued fame. You can also use gstreamer's fbdevsink element to sink to a framebuffer device.
Although... I guess the fb itself is correct. If I tell JavaFX to use pure software rendering it is able to draw to the screen.
You can build the fb_test command with, I'll add this to the image Code: MACHINE=udooqdl bitbake fb-test
In the same thread there is a remark that in the kernel build configuration Vivante GPU support should be enabled. Does our build have that?
Yes, Vivante GPU support is activated. Otherwise the Qt5 stuff would not work... I'll be at Embedded World tomorrow and had some problems with u-boot port for the Seco SBC A62 I hope I can debug those issues during the weekend.
Btw it looks like the suggestion made by @vpeter did the trick for @Maurice But there are still some issues with JavaFx. Anyway @Francesco told me at Embedded world, that the latest Vivante driver broke compatibility with the LVDS 15" Panel. Maybe it worth to try with the updated DeviceTree. I am unable to test this because I have no LVDS display by hand
What Buildsystem are you using? OpenWrt? Yocto builds are based on 5.0.11.p7.4 can you provide a test image with p4.5 to @Maurice so he can test his JavaFX app? Gesendet von meinem FP2 mit Tapatalk