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 (...).
Related
Out of private / experimental interest, I've been writing low-level cross-platform UI functionality with .NET Standard 2.0, and implemented creating a window
on Windows (via WinAPI P/Invoke) and
on Linux with an X11 server (via Xlib/libX11 P/Invoke).
So far I can run the X11 code nicely on Linux with MonoDevelop, but I thought it would be useful to develop for an X server running on Windows (like Cygwin/X or Xming X Server).
For that however, I require an Xlib Windows DLL which I can P/Invoke to, as .NET Core only supports Windows DLLs on Windows platforms (AFAIK).
Before I get myself into the trouble of "porting" the Xlib source to compile with MSVC++, I wonder if there is any project available which already creates an Xlib Windows DLL, or if any such compiled DLL is readily available somewhere?
I found a X11.dll as part of some commercial X server from the mid-1990s for Windows NT, except I don't remember which X server product however. I do know, however, that it'll do what you want.
It's 32-bit, but you can use this DLL: https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/segin-utils/X11.dll
I used it to produce a 32-bit Windows build of a window manager I had worked on years ago: https://github.com/segin/matwm2
Build: https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/segin-utils/matwm2.exe
If I can figure out how to upload release artifacts to GitHub, I'll probably archive these files there.
In our system, we write the code on C++ without using Qt libraries.Actually, we write the on Windows machine, but finaly, this code must to be rebuilded for Linux Embedded machine. At first stage we did it successfully with Makefile-s, but "old style debugging" with gdb utility killed us. So I want to use Qt Creator to debug the application.
I successfully use Qt Creator to build all libraries and applications for ARM machine(of couse I have an ARM toolchain). But I cannot remotely debug the system.
I do not understand, what I do wrong.
The questions:
1. For system debuging, do I need Qt Libraries buld for ARM machine? (as I wrote above, I do not use Qt Libraries for my applications or for my libraries)
2. Do I need to redefine Mkspec for ARM compiler?
Thanks, Slava
You generally don't need Qt libraries for your system to use Qt Creator as a debugger frontend for your plain C++ program on an embedded device. However, if you use qmake as a build system, the associated Qt version must (roughly) match your target.
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'm developing a cross-mobile platform framework using C as base. Then i will make some wrappers for each specific platform (like ios, android, bb). One of my targets platform is firefox-os. I de like to know if will be possible to use c libs in firefox-os, but i couldn't find anything about it.
If you look at the following Firefox OS architecture document it should answer your questions:
https://wiki.mozilla.org/B2G/Architecture
For example, under Gaia it says, "Its only interface to the underlying operating system is through Open Web APIs, which are implemented by Gecko." That means that Javascript is the only interface you have to lower-level calls provided they are available via the Open Web APIs.
A workaround would be compiling your C code to JavaScript with emscripten. Firefox will implement asmjs in the near future, so the compiled code will probably be very performant (since emscripten will target asmjs as output).
Let's say I have an application which I compiled under cygwin, and I want to distribute that application without having the user to install cygwin. Would it be enough to package the executable and the cygwin DLL?
Things have changed. The Cygwin libraries are now under the Lesser GPL (v3), which makes it possible to bundle them with applications that fall under a wide range of licenses, from FOSS to proprietary.
What stands in the way is that the POSIX emulation in Cygwin takes things a little too far from the perspective of native Windows applications.
This is where my Cygnal project comes in. Cygnal stands for CYGwin Native Application Library: it is a drop-in compatible fork of Cygwin which changes, or in some cases simply re-configures, the behaviors of certain functionality in order to conform with native conventions of the Windows platform.
A basic "Hello, World" Cygwin program requires two libraries. A GCC run-time called cyggcc_s-1.dll and the Cygwin DLL cygwin1.dll. The Cygnal project provides a replacement for the latter. (A 32 bit build is available for download).
One glaring area of incompatibility between the Cygwin POSIX view of the world and Windows is path handling. The Cygwin view of the filesystem is through a fake / root directory, and its own internal "mount table" which provides spaces like /cygdrive, /proc and /dev. Cygnal does away with all that. Paths are Win32 paths. The current working directory behaves like the Windows current working directory. Drives are associated with current directories, and drive relative paths like D:foo.txt work under Cygnal. Under Cygnal, /dev and /proc are still available: they are accessed as the special prefixes dev:/ and proc:/. It is not permitted to chdir into these: that would not be native! Under Cygnal, if you chdir to D:\wherever then your current drive is the D drive, and the paths /foo or \foo refer to D:\foo. Cygwin's master POSIX root directory is gone.
Yet, with Cygnal, you can continue to use the POSIX functionality, making it possible to develop cross-platform programs that have less code that is switched based on platform, compared to maintaining a port using MinGW or Microsoft Visual C/C++.
For example: you can write a Win32 console application using VT100 codes and termios. The same code will run on Unixes. No need to use the Win32 console API on Windows and VT100/termios on a POSIX system.
Another example: for threading, you can just use POSIX threads. pthread_create to start a thread, pthread_mutex_lock to lock a mutex and so on. Your program doesn't need a portability abstraction for threads which translates to Win32 or POSIX; you just use the POSIX and that's it.
The uname function in Cygnal reports the sysname with a CYGNAL prefix rather than CYGWIN. By means of this, your program can tell that it's running on Cygnal rather than Cygwin (or any other POSIX platform). Thus you can make any necessary adjustments: for instance, if your program needs /dev/null, on Cygnal it can look for dev:/null instead.
Does your application actually need any Cygwin provided Posix emulation? If not, you can compile it with the -mno-cygwin flag and it won't depend on cygwin at all, but will be a native Windows application. Often, you only need a real shell (bash) to configure and build your application, but you don't actually need the Posix functionality of Cygwin.
Another alternative is MSYS + MinGW, which is a light-weight fork of Cygwin. This provides a compilation environment which produces native Windows apps by default.
A third option would be to use the MinGW compilers from Cygwin itself. They should be available via the normal Cygwin package manager. Then you would configure the project for a cross-compile using the MinGW compilers.
Normally, yes. Be sure to install the Cygwin DLL in a public location though (Windows\System32), this DLL behaves very badly when multiple versions of it are loaded on the same machine.
You could try to compile everything as static. That should allow you to run everything without the need of the the libs (since they are already in your binary).
But this will also mean that it might not work an all platforms if cygwin would need a different or newer dll.