I'm designing a user interface for a large touchscreen device running Linux. What would be the best toolkit/developer kit/SDK to use? The only requirement is that its able to run on a semi-low performace device, and that there is a Linux version.
Nice-to-haves would be build in support for effects/animations and a modern look-and-feel, but they are not necessary.
I'm looking at Adobe Flex/AIR already, but I'm not sure if the device will meet the minimum specs.
Try QTopia (http://trolltech.com/products/qtopia)
It's from the same stable as the popular Qt desktop toolkit.
I agree with Mopoke, QTopia is what you want.
It has support from some graphics hardware (2d and 3d), and can also use the kernel framebuffer device if that's all you need.
It's based on Qt, a very well-designed object-oriented GUI framework
It's available for both open-source and commercial projects, although closed-source projects need to pay a license fee.
You should check out whatever tool-kits are used for the Chumby. It's a completely open-source Linux device (open schematic, open source software, etc) with a very rich user-interface (color touch-screen, builtin wifi, USB ports, etc). I believe it's user-submitted "applications" are Adobe Flex/Flash based but there are a variety of open "hacks" including a port of Quake that can be easily downloaded and run.
You can try Disko.
Check out Clutter.
QTopia is indeed a good option; others are DirectFB, and of course X11 generally running Matchbox.
CodeTyphon can let you easily code, visually design and cross compile GUI touch screen applications for embedded linux.
http://www.pilotlogic.com/sitejoom/index.php?option=com_content&view=article&id=96&catid=68&Itemid=147
Related
This may be a foolish question but I've been searching around for some time and don't see a clear answer. I've seen several microcontrollers advertised as running Unix-like software (Linux, Ubuntu) for example, the BeagleBone Black and Arduino Yun. Can someone please explain to me the benefit of this? So far I've used a couple of microcontrollers like the Arduino Uno/Duo, Freescale FRDM and STM32 Discovery which either didn't have this feature or I was not aware of it. I'm starting to see it more and more on newer microcontrollers so I'd like to know what it brings to the table.
Full disclosure: I've had minimal exposure to UNIX and its variants so far so please talk slowly and use small words =)
Hope to hear from you,
Yusif Nurizade
You get complex drivers already included Linux for free (USB, internet protocols, storage media and file systems).
You can use lots of free software for the things not included in the kernel.
It is simpler to develop software on a full OS (easier to debug, look what is going on, change the configuration, etc etc).
The drawback is that the real-time capabilities are generally worse than for some small RTOS, and it needs more resources (a couple of megabytes memory).
In the heart of all Android and iphone is a Embedded Linux System. Without getting too deep
Linux + Java = Android
BSD Unix variant + C/C++/Object C = iOS
Now if you get deeper the above two statement can be argued for accuracy
All Android devices run on ARM based microprocessors. Beaglebone is one such open source hardware platform with can run Android as well as Embedded Linux distribution and even a Ubuntu.
Now (IMHO) Ubuntu is primarily for desktop and server application. Many of the popular computer server farms uses Ubuntu.
Now STM32 is a ARM based CORTEX-M micro control. Once again (IMHO) is mostly used for bare metal embedded applications. I have hard that FreeRTOS can be ported to TM4C123 ARM Cortex-M TM4C123.
Now the advantages of using Linux base micro controller architecture are
OS is free for the most part
Larger community of users
The industry is moving towards open source
Lot of free resources get up to speed
Disadvantage are
Learning curve is pretty steep
Expect to stumble and fall a few time
Below to two good resources to learn Beaglebone open source development
Beaglebone
Introduction to Beaglebone development by Derek Molloy of Dublin City University
HTH and good luck
Upon considering the driver side implementation for DirectX API on windows systems for modern video cards I was wondering why this implementation is not available on non-windows system, most notably linux.
Since there is an obvious absence of this functionality I can only assume there is a good reason which I am blind to, but in my primitive understanding I simply see the DirectX calls as no more than function entry points on the hardware device. And for the record I am not referring to a compatibility layer (most notably WINE, a project I am amazed by every single day) but a library making direct hardware calls.
Is it possible to create an open source version of directx? Would it be possible but obscenely difficult?
AFAIK, the DirectX contains 3 parts
Vendor driver (provide low level API defined by DX)
DirectX library (use low level API defined by DX to access hardware, provide DirectX API)
Software (use DirectX API, ex. game)
There are no driver providing the low level API defined by DX on linux, so even it is possible to provide the DirectX library, but it won't work without proper vendor driver, and I can't see if there is any vendor is going to create one for their hardware platform.
Why not just use OpenGL? It supports all the functionality that DirectX does. Do you have a specific reason to use DirectX? As for a reason, Microsoft made DirectX and I guess they didn't see any need to allow it to run on Linux.
You can run DirectX games in Linux using Wine. You can program XNA on Linux using MonoGame. But all of these use OpenGL to provide hardware-accelerated rendering. AFAIK, OpenGL has been (and probably will be) the only option on Linux for the foreseeable future.
Is it possible to write your own DirectX implementation? Sure - but it involves writing drivers, proprietary knowledge and probably too much cost for anyone to REALLY benefit from it.
EDIT: These days, DXVK is a very real and performant way to run DirectX applications on Linux.
DirectX is a suit of API's:
Direct3D (drawing 3D graphics)
DirectX Graphics Infrastructure (enumerating adapters and monitors and managing swap chains)
Direct2D (drawing 2D graphics)
DirectWrite (fonts)
DirectCompute (GPU Computing)
DirectSound3D (playback of 3D sounds)
DirectX Media (DirectAnimation for 2D/3D web animation, DirectShow for multimedia playback and streaming media, DirectX Transform for web interactivity, and Direct3D Retained Mode for higher level 3D graphics)
DirectX Diagnostics (tool for diagnosing and generating reports on components related to DirectX, such as audio, video, and input drivers)
DirectX Media Objects (support for streaming objects such as encoders, decoders, and effects)
DirectSetup (installation of DirectX components, and the detection of the current DirectX version)
DirectX components deprecated, but still supported
DirectDraw
DirectInput
DirectPlay
DirectSound
DirectMusic
As you can see many parts of the DirectX suit of API's would need to be rewritten with functionality for Drivers written for Linux. Also some parts of the DirectX suit are likely going to make calls to the Windows OS and that code would have to rewritten for a Linux machine without infringement of the copy-written parts of either DirectX or the Windows OS.
Yes you could write a open source API suit which does the same kind of thing as DirectX for Linux, however without a great knowledge of sound and graphic drivers/support by their manufactures for Linux, it would be a very hard task to do.
However if you question was more of a "Can I get/write something to be able to run games and programs made with DirectX to run on Linux?" in it's meaning, in short no due to more likely copyright infringement.
Your question is wrong in 2019. DXVK is an implementation of D3D11 and D3D10 implementation for Linux using Vulkan and Wine
Also mesa has native Direct3D 9 implementation but in my knowledge, no one uses it except wine
The work to create a port for DirectX would create the same problems as you encounter in WINE. It will never be the same as on Windows. Derived from that principle you would have to look into OpenGL and related multi-platform libraries.
At this very moment WINE would be your closest medium if you want to accomplish something with DirectX code you already have. Then again, I'm not sure in what manner Visual Studio or plain typing would get you closer yo a fluent environment. The WINE libraries aren't that far from native, but there always exists emulation, what is acceptable to a certain point in my honest opinion.
If I look at how superbly Final Fantasy XIV ran on full settings on my iMac (2011) I think it's not that bad to rely on WINE's implementation. The game exactly rendered as on Bootcamp (Windows) on my iMac.
If you really want to make work on this front you could try to ask WINE Devs at their forums or mailing lists how you could maybe use the implementation of their DirectX compatibility only and use that in your project. Where you maybe can call libraries instead of requesting DirectX through Windows-emulated system calls.
Edit: I fully agree with user956030's answer too.
DirectX is a propriety products designed for Microsoft targets, so for this to happen would be very unusual
There are two other pieces of software that come to mind, SDL and OpenGL
OpenGL provides the hardware alternative to DirectX, and SDL works with OpenGL to provide the software support you would expect from DirectX
Since 2020, Microsoft has been working to port DirectX 12 to WSL2, which is being done in this repository. In a mailist, Steve Pronovost commented that they might work to port this driver to Linux to have it running natively.
However, in order to do this, they would need to implement the driver on top of the kernel's DRM stack, which itself needs to be modified if they want to keep the driver similar to the Windows one and have related APIs.
There is some effort being done in the Mesa library as well, to support D3D12 within itself, the main purpose being to optimize server-sided GPU calculations that are heavily used in machine learning algorithms.
Even though this is great, it's unlikely that we will ever see any advantage running Windows games on Linux with that driver. The open source community would only have the upper ground if more games start supporting Vulkan, which is faster and better than DirectX, there had been experiments where using DXVK on Windows would be faster than DirectX 9 or even 11, such as the one mentioned here, but DXVK tends to be less reliable and more prone to errors and crashes.
I'm moving from windows programming (By windows programming I mean using Windows API) to Linux Programming.
For programming Windows, the option we have is Win32API (MFC is just a C++ wrapper for the same).
I want to know if there is something like Linux API (equivalent to WINAPI) that is exposed directly to the programmer? Where can I find the reference?
With my little knowledge of POSIX library I see that it wraps around part of Linux API. But what about creating GUI applications? POSIX doesn't offer that. I know there are tons of 3rd party Widget toolkits like gtk, Qt etc. But I don't want to use the libraries that encapsulates Linux API. I want to learn using the "Core Linux API".
If there are somethings that I should know, please inform. Any programmer who is familiar with both Windows & Linux programming, please map the terminologies of Linux world so that I can quickly move on.
Any resources (books,tutorials,references) are highly appreciated.
I think you're looking for something that doesn't exactly exist. Unlike the Win32 API, there is no "Linux API" for doing GUI applications. The closest you can get is the X protocol itself, which is a pretty low level way of doing GUI (it's much more detailed and archaic than Win32 GDI, for example). This is why there exist wrappers such as GTK and Qt that hide the details of the X protocol.
The X protocol is available to C programs using XLib.
What you must understand is that Linux is very bare as to what is contained within it. The "Core" Linux API is POSIX and glibc. Linux is NOT graphical by default, so there is no core graphics library. Really, Windows could be stripped down to not have graphics also and thus not have parts of the win32 API like GDI. This you must understand. Linux is very lightweight compared to Windows.
For Linux there are two main graphical toolkits, GTK and Qt. I myself prefer GTK, but I'd research both. Also note that GTK and Qt exist for Windows to, because they are just wrappers. If you go take a look at the X protocol code for say xterm, you'll see why no one tries to actually creating graphical applications on top of it.
Oh, also SDL is pretty nice, it is pretty bare, but it is nice if your just needing a framebuffer for a window. It is portable between Linux and Windows and very easy to learn. But it will only stretch so far..
Linux and win aren't quite as different as it looks.
On both systems there exists a kernel that is not graphical.
It's just that Microsoft doesn't document this kernel and publishes an API that references various different components.
On Unix, it's more transparent. There really is a (non-GUI) kernel API and it is published. Then, there are services that run on top of this, optionally, and their interfaces are published without an attempt to merge them into an imaginary layer that doesn't really exist.
So, the lowest GUI level is a the X Window System and it has a lowest level library called Xlib. There are various libraries that run on top of this one, as you have noted.
I would highly recommended looking at the QT/C++ UI framework, it's arguably the most comprehensive UI toolkit for any platform.
We're using it at work developing cross platform apps that run on windows, osx and linux.
It also runs on Nokia's smart phone Operating System Maemo which has recently been merged with Intel's Moblin Linux OS, now called MeeGo.
This is going to sound insane since you're asking about "serious" stuff like C++ and C (and the "core linux API"), but you might want to consider building in something else. For instance:
Java Swing (many people love it! Others hate it and call it obsolete)
Mono GTK# (C# or VisualBasic or whatever you want, lots of people say it's pretty cool, but they're not not that many people)
Adobe AIR (ActionScript, you might hate it)
Titanium (totally new and unproven, but getting a lot of buzz in the iPhone world, at least)
And many other possibilities, some of which let you work on multiple platforms at once.
Sorry if this answer is not at all what you're looking for. The "real" answers on Linux are "pick a toolkit," which is also no answer at all :)
Have a look at Cairo. This something roughly similar to GDI+ and is under the hood of some of of the few usable GUI programs for Linux i.e. Firefox or Eclipse (SWT). It wraps most the natsy and ancient Linux stuff for you into a nice API that runs on most Linux installations without locking you into a entire subsystems like GTK or QT.
There is also the docs for the two different desktop platforms: Gnome and KDE that might help you down that road.
I'm getting started developing with OpenGL ES on ARM/Linux, and I would like to draw something full-screen but don't know where to start.
I'm not developping on iPhone, nor Android. This is a Linux/OpenGL ES question.
I know it's possible to draw on the framebuffer with OpenGL ES without any library but I don't find any resources about that topic, could you help me?
I don't have any code to show how to do it but basicly you use de framebuffer device as the target of OpenGL|ES operations.
Are you developing with an embedded platform as a target? If so, you could use software implementations on your host system and then the actual driver on the embedded device.
There is a small project for supporting OpenGLES 1.1 on linux called dlges. You could also try mesa.
I imagine that the driver itself might have a header for OpenGL that you could look at and see if it supports OpenGLES calls. Alternatively, you could set up function pointers to make your OpenGL Code look more like OpenGL ES.
Good luck!
Don't forget that desktop Linux comes with OpenGL, not OpenGLES! They're similar but not quite compatible. If you want to do work on OpenGLES on a desktop Linux platform, ARM or otherwise, you'll need an OpenGLES emulator library. Sorry, can't recommend any, I'm looking for one myself.
OpenGLES just handles the process of drawing stuff into the window. You also need a windowing library, which handles the process of creating a window to draw stuff into, and an event library, which deals with input events coming back from the window.
SDL will provide both of the last two, as will a bunch of other libraries. Khronos themselves have standardised on EGL as the windowing library and OpenKODE as the event library... but I don't actually know where to get open source implementations of these for Linux. (I work for a company that does EGL and OpenKODE for embedded platforms, so I've never needed to find an open source version!)
ARM offers few GPUs that support OpenGL 2.0. You can find some examples and and emulator that runs on linux on the Mali Developer site.
Of course that's mostly to target ARM GPUs, but I am pretty sure it could be used to examine OpenGL ES programming possibilities.
Here is a tutorial showing how to use SDL in combination with OpenGL ES. It's for the OpenPandora platform, but since that runs Linux, it should be applicable on the desktop if you can get the proper library versions.
Use of SDL is more or less standard with this kind of programming, in Linux. You can of course go the longer route and open the window yourself, attach a GL rendering context and so on, but usually it's easier to learn the relevant parts of SDL. That also gives you easy-to-use API:s for input reading, which is almost always necessary.
You can use PowerVR SDK for Linux http://community.imgtec.com/developers/powervr/graphics-sdk/
There are a lot of samples.
In windows, what does Flash use under the hood?
It's a relatively simple question which I can never find the answer to. Is it GDI (for windows VM implementations) or something else?
You don't need to go into any of the new GPU acceleration features of Flash. I just really want to know the inner workings because it's NEVER discussed.
On 64-bit Linux, the Flash plugin does not link against SDL (according to ldd). It does, however, link against GTK, GDK, and Cairo. It appears, therefore, that it is using either Cairo or raw Xlib calls to do its drawing on Linux.
I don't know on Windows. Flash tends to have minimal dependencies, but Direct-X may be standard enough that they use it. With some kind of a process examiner to tell you what libraries a process has loaded, you could examine a simple web browser embedding Flash and see what system facilities are actually in use.
DirectX mostly. It's hard to achieve good graphics performance with GDI.
I agree with george, GDI is very bad for speed. DirectX for Windows and SDL or similar for Linux (note this is an assumption!). In that sense it probably uses a layer that communicates with the native graphics subsystem on whatever platform it's running on.