I am running Qt 5.4.2 on a Tegra 3 with a Yocto compiled Angstrom image. Unfortunately the Tegra only has proprietary drivers and they are forcing me to use X11 for hardware acceleration. I therefore had to build Qt with XCB instead of EGLFS.
My problem is that I am seeing tearing on some QML 2 animations on the device that are not visible on my PC. I am wondering if there is anything I can do to try and get rid of this tearing? I have read that QT_QPA_EGLFS_FORCEVSYNC might help but unfortunately I can't use EGLFS and doubt if it will be of any use.
EDIT:
I have noticed that "QSGContext::initialize: stencil buffer support missing, expect rendering errors" as well as "Qt Warning: Could not find a location of the system's Compose files. Consider setting the QTCOMPOSE environment variable." come up when the application is started. Could they be related to the problem?
Related
I have managed to build a set of mesa libraries that together with a dummy xserver can run an OpenGL application on a machine with no GPU using openswr without relinking or changing any code in the application on a machine with a pre-existing Xorg installation. I'm using Linux on x64 (centos 7 to be specific)
The mesa build instructions I used are the following:
http://openswr.org/build-linux.html
Now I'm trying to set up a build process for this for machines without XOrg installed to start with for various reasons I won't go into detail on. Since there are some back and forth dependencies between the XOrg build process and mesa it becomes a dance involving building the right XOrg and mesa modules with the right parameters.
I have reached a point where I'm stuck.
It seems like mesa won't build gallium if dri is enabled. I.E if I remove the line --disable-dri from the mesa configure command line from the openswr example it won't work giving the following error.
:configure: error: Xlib-based (Gallium) GLX cannot be built with DRI
enabled
On the Xorg side, using a mesa without dri, building xserver with the --disable-dri flag, the configure script works but the build fails with the following error:
glxdriswrast.c:39:10: fatal error: GL/internal/dri_interface.h: No
such file or directory #include
(suggesting there are parts of xserver still referring to dri headers even if disabling it using --disable-dri).
Anyone have any idea what the right combination of flags to get all of this working? I'm not married to using openswr, llvmpipe is probably good enough for me in case it makes things easier.
I was doing some cross compiling of a Qt5.2 application for an ARM based target (TI AM335x EVM) and it was failing to display anything on my platform. After doing some google’ing I found that if I launched it with:
./helloworld -platform eglfs
it would show up (full screen, but it worked)!
I started looking at all the platform options, I found:
android, eglfs, linuxfb, minimalegl, windows, xcb, cocoa, ios, offscreen, qnx, directfp, kms, minimal, openwfd
I’m wondering what they are for. I assume, for example, that if I wanted to run my application on an Android device I’d have to pass -platform android, but they’re not all obvious to me.
Is there a listing anywhere of when each of these parameters should be used?
For example, what does eglfs stand for? And why did I need to use that where as linuxfb didn’t work? (I would have thought the linux frame buffer was how I wanted to launch my application since it was running on embedded linux)
If the linuxfb plugin doesn't work, then possibly you didn't correctly configure the framebuffer device on your system. Maybe a directf layer is already running, so you may want to try the directfb plugin instead.
If you wish to avoid having to specify the platform option when you run the executable, you can pass the default one to configure when you build Qt.
The plugins can be described as follows:
Linux plugins - those use Linux-specific input devices and various output devices
eglfs - Uses the OpenGL ES in fullscreen mode. There's no other way since OpenGL has no concept of a window manager.
directfb (not directfp) - Uses the linux frame buffer with OpenGL ES via the directfb layer (see also wikipedia). Integrates into the directfb windowing.
linuxfb - Uses the linux frame buffer in fullscreen mode. There's no other way since linuxfb has no concept of a window manager.
kms - Uses linux kernel modesetting API in fullscreen mode. There's no other way since DRM has no concept of a window manager.
openwfd - Uses an openwfd Wifi display in fullscreen mode. There's no other way since openwfd has no concept of a window manager.
Platform-independent plugins - could be made to run on any OS
xcb - Runs on an X11 server and is integrated into the X11 windowing environment. Generally it won't behave correctly without a window manager running as well. Can be made to work on Windows, given a Windows implementation of xlib, if you want to, say, serve applications from a Windows server to X11 thin terminals (typically Unix boxes).
offscreen - Renders to an offscreen buffer. Useful for rendering to custom displays.
minimal - A minimalistic backing store that optionally dumps the virtual screen to a file. Implements the bare minimum of functionality just to demonstrate how to start writing a platform plugin.
Other platform-specific plugins
android - Uses the Android APIs and is integrated into the Android environment.
windows - Uses the WINAPI and is integrated into the Windows windowing environment.
cocoa - Uses the Cocoa APIs and is integrated into the OS X windowing environment.
iOS - Uses the iOS toolkits and is integrated into the iOS environment.
qnx - Uses the QNX APIs and is integrated into the QNX photon windowing environment.
I just replied in the TI forums to the same query. If eglfs is functional and linuxfb is not, please file a bug in JIRA with qt-project.org, as both eglfs and linuxfb in AM335x use the linux framebuffer. eglfs (when used with a widget application) uses dirty-rectangle approach with a fullscreen display. Also move to QML if possible when on Qt5.
PS: you can export QT_QPA_PLATFORM=eglfs (or linuxfb) on the target to avoid setting the platform everytime you invoke the application. (http://doc.qt.io/qt-5/embedded-linux.html)
Probably the most noteworthy addition since the accepted answer was written is Qt's wayland platform, apparently since Qt 5.11 (in official binaries). Enabled now by default on Fedora 31+... which can be a little troublesome for some apps. Red Hat had to implement a fallback list.
I am working on Qt application in the linux Desktop enviromet. Most desktop Linux uses xwindows to display onto the screen.
But now I want to try my hands on DirectFB on my desktop. Related to which i have some questions :---
1> Can i make my desktop QT application to make use of DirectFB to run my QT application .
2> If yes then do i have to disable xwindow server on my desktop first Or directfb can run simultaneously.
3> Also is it the right way to configure QT for using directFB .
http://qt-project.org/doc/qt-4.8/qt-embeddedlinux-directfb.html
http://qt-project.org/wiki/DirectFBAndQt
4> How does Qt and directFB & openGL works together. Is this how communication flow occurs :---
Qt ----> OpenGL ----> DirectFB --> screen
5> Also if i install Directfb library then will it automatically come to know how to communicate with video h/w driver ?
http://en.wikipedia.org/wiki/DirectFB
Please suggest on these points.
try to inform the display plugin your Qt application should use
./qt-app -display directfb
DirectFB can create windows over X, but you need to configure it to do so (XNest or something like it)
Probably yes
Don't know
Nope, you need a plugin backend for your platform. When dealing with custom boards, usually the vendor ships the code needed to build such component
The Qt library is able to draw either on X11 or on the framebuffer without the need of the (additional) DirectFB layer. Recent versions of the library also have OpenGL support. Adding such a layer would just be a waste of time/memory/cpu.
I'm some familiar with Cocos2d and Cocos2dx.
But only I worked in Mac, I know which is possible work with this engine (Cocos2dx) in Windows, but I don't know if is possible develop a game on Linux.
By the way:
I'm not talking about a port, I want develop a Videogame multiplataform on Linux.
Would be great know the way of how start my game on Linux.
Thanks!
While I haven't tried it, cocos-2dx is, according to their documentation, is usable on Linux although my understanding is that this means one can build android projects using cocos2d on Linux.
In terms of where to start, I've used both SFML and SDL as both are well supported on Linux. Both are cross platform although SDL supports a wider range of platforms - I have an SDL2 game in progress that runs on Linux and android for instance whereas SFML does not yet have android or iOS support. Coming from cocos2d though I think you'll find the SFML API easiest to pick up.
As a fair warning, the landscape is a bit confusing at present because both SFML and SDL have a popular stable release (1.6 for SFML and 1.2 for SDL) with one API along side a popular development release (2.0 for SFML and 1.3/2.0 for SDL) that has a similar but not identical API. This is particularly noticeable with SDL where the documentation for 1.2 is much better than the documentation for the development API. In terms of choosing one over the other, the stable releases are precisely that - stable. In both cases the development releases have been under way for some time so if you are willing to dig for documentation a bit and ask questions it's worth getting the new features.
There is book that provides a nice introduction to Linux game development that, while dated, might be a good first step if this is your first outing with games on Linux, especially if you decide to use SDL Programming Linux Games.
Update:
I saw the directions here and after (roughly) following them cocos2dx does build on my Ubuntu 12.04 x64 machine. The "Set up Environment" directions seem sound but the makefile information appears to be out of date as there is no build_linux.sh instead there is a make-all-linux-project.sh. After this finished pulling in missing deps and building I changed into the samples/HelloCpp/proj.linux directory and ran make. This created a HelloCpp binary in samples/HelloCpp/proj.linux/bin/debug. Running that popped a HelloWorld cocos2d screen. According to the output the verison is:
cocos2d-x debug info [cocos2d: cocos2d-2.1beta3-x-2.1.0]
That said, I don't see a lot of documentation for the linux port and most of the related community entries seem to be out of date so you may find more support from using one of the libraries I already mentioned.
Download cocos2d-x project there is a test sample games which compiles on all platform android, windows, iOS , Windows Phone ...See you are going to code in c++ that's it then whether you build it in linux or any other platform doesnt matter for cocos2d-x kind of engine
so i suggest start with the sample projects of cocos2d-x .... and as you want to do it in linux ...make something then compile it in linux like I do ...
I have a ARM11 based hardware board which runs a Linux kernel ver. 2.6.21.5-cfs-v19. I have my application running on this ARM-LINUX board. To do source level debugging, of my application I used to use gdb from command prompt of the linux board, that was with some earlier version of the board linux version.
With this version 2.6.21.5-cfs-v19, I dont have a related version of gdb for the board. I tried to look around to get gdb for this version of linux and arm port of it, but without much success. Can anyone point me where I can get either an independant executable for gdb for above mentioned os and board configuration or source for the same, which I may try compiling for that target.
-AD.
Sometime ago I published an article about cross-target debugging with GDB and GDBServer. The target processor there is PPC7450, but it's rather detailed, so maybe you'll find it useful.
You might have some luck using OpenEmbedded. If there's no precompiled version you can use right away, setting up an OE-cross compile environment is not that hard.
Another option could be to install gdb-server on the board, like described in this blogpost.