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.
Related
I am trying to make a PyQt application work as the other Qt applications I have on my system (i am on KDE plasma on linux).
A notable difference is that in the application I am making the accelerator character for the menu entries always appears underlined while in all the other Qt applications I have on my system the underlining only appears when the ALT key is pressed (e.g. in KDE okular). I see that other PyQt application seem to have the same behavior as mine (e.g., spyder).
The Qt reference guide says that Qt should automatically manage the underlining according to the platform integration, but this does not seem to be the case with my PyQt app.
Does someone know why this is the case and how to obtain the platform standard behavior?
I'm trying to port an OpenGL application from Windows to Linux.
I'm stuck at a call to glSwapInterval which doesn't sound windows specific, but doesn't seem to exist on Linux. What include am I missing?
Check for the GLX_EXT_swap_control extension and use glXSwapIntervalEXT().
Using something like GLEW (via glxew.h, see the "Platform Specific Extensions" section) makes the extension loading process easier.
There is no such thing as glSwapInterval (...), because this is fundamentally a window system operation. OpenGL splits the task of managing windows and other platform-specific operation up into separate window APIs, which include WGL (Microsoft Windows), GLX (X11), EGL (OpenGL ES and some other systems) and CGL (OS X).
Because of this split between the core API and window system API, this function will be prefixed with something other than gl, just as SwapBuffers is. On Linux chances are you are using X11, so look for glXSwapIntervalEXT (...).
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'd like to develop my own app based on a arm-linux system, using QT.
I'd like my app to support multi-touch functions. And I'd like to know if it is possible. If so ,please let me know which version of Linux kernel I should use.
Linux started supporting Microsoft's Multi-touch protocol from kernel 3.8 onwards.
The reference is here:
https://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt
Addendum
http://www.ptrackapp.com/apclassys-notes/embedded-linux-multitouch/
has arm multi-touch tutorial for iPhones but it applies equally to Android.
The hid-multitouch in linux supports a whole bunch of panels:
See
http://lxr.free-electrons.com/source/drivers/hid/hid-multitouch.c
for details
Addendum 2
Multi touch support has been somewhat there since 2.6 Ubuntu had multi touch support in its distribution in 2010.
Microsoft Multi-touch protocol support started in 3.8. Chrome OS support started in kernel v3.9. X.org server had multi touch support built into it in 2011.
Run command:
chromium --enable-pinch
for context menu
create shortcut application (.desktop)
/home/"your user"/.local/share/applications
OR
support all aplications
search:
multi touch compiz plugin
https://www.youtube.com/watch?v=rY-85BUqWgY
I am thinking of kicking off a JavaFX project on my 64-bit Windows 7 machine. What I am doing is designing a full-screen console application. It's not interactive aside from a barcode scanner.
I'm designing this for what I think would be an Ubuntu laptop or some other Linux variation, although a different Windows OS is a possibility too (as well as 32 bit). From what I understand Java FX version 2.x has made great advancements in portability from its predecessor, but I wanted to ask the community here what their experience was in deploying JavaFX apps.
Have you had success using them on a variety of different architectures? What are some problems you have encountered?
Checkout EstiMate for an example of an all-in-one jar which is runnable via double click.
https://bitbucket.org/atill/estimate/downloads
It requires Java7u10 installed. I plan to make a proper installer for it later on, using the javafx maven plugin. https://github.com/zonski/javafx-maven-plugin. I haven't tested it on Linux or Mac but it does work across winXP 32bit and 64bit windows7.
As long as your barcode scanner works the same on ubuntu as on win and you are not using any external libraries, you won't notice the difference between those systems from your app.
I found installing oracle JRE on ubuntu the most difficult task. (with JRE_HOME, etc.) Even on Archlinux was easier than ubuntu.
Nevertheless, once the JRE is set, your app will run even on Raspberry Pi (which is ARM not x86)
Remember about file system differences between systems.