Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
I would like to write a very simple Linux desktop environment or a program that runs without a DE, and here is my requirements
the application or DE will be a IPTV player (as a IPTV set-top boxes)
and I want it to run directly after booting (no login screen or such things)
1- the DE will be full screen
2- no need to run any other GUI programs, just command line programs called through my application, so no need to window manager nor display manager (if possible)
3-minimal services, just want to connect to LAN and read rtp (udp) streams
4-use Qt and Qt Quick to write this DE or application, and if couldn't use openGL
5-MUST use libvlc or any other library to read and play rtp streams
6-use apt-get to install or remove packages
7- keyboard and mouse support
I am a c++ and Qt programmer and I have a good Linux administration background
if you have any idea to help write the DE or if any existing one that run directly on XWindow, please help
the DE will be used as if the PC a a normal DVB receiver to list channels and select one to view
How could I boot my Qt application as a DE and put it in /usr/share/xsessions
as /usr/share/xsessions/myDE.desktop
how to configure Qt to run without a window manager or display manager
should I use QApplication or any other class to run my app
I would like to start by saying, you should think only about Qt 5 for, and forget about Qt 4. The Qt 4 design with QWS is a bit old, and hence flawed. Qt 5 has a nice QPA (Qt Platform Abstraction) interface for easily adding platform plugins which makes the architecture robust and flexible.
how to configure Qt to run without a window manager or display manager
You can use Qt with the appropriate platform plugins, like eglfs, linuxfb, directfb, minimal, minimalegl, etc without complicated windows and display managers if you wanna have some lightweight solution.
Here you can find the list of the platform plugins that Qt 5 currently tries to support:
https://qt.gitorious.org/qt/qtbase/source/475cbed2446d0e3595e7b8ab71dcbc1ae5f59bcf:src/plugins/platforms
should I use QApplication or any other class to run my app
No, you should use QGuiApplication for this sort of thing. QApplication is for widgets based application with Qt 5, and that is the major Qt version you should use for this.
That being sad, Qt Quick 2 rendering depends on the availability of the OpenGL api, so you need to have that in place for your information. That does not necessarily mean hardware acceleration with GPU. Having a software based implementation of the open standard is also fine.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 2 years ago.
The community reviewed whether to reopen this question 5 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
OpenGL and Windows Remote don't play along nicely.
Solutions for this are dependent on the use case and answers are fragmented across the vast depths of the net.
This is a write-up I wish existed when I started researching this, both for coders and non-coders.
Problem:
A RDP session of Windows does not expose the graphics card, at least not directly. For instance you cannot change the desktop resolution and GraphicsCard drivers usually just disable their setting menus. Starting a OpenGL context higher than v1.1 fails because of this. The, especially in support IRCs, often suggested "Don't use WindowsRemote" is unfortunately not an option for many. In many corporate environments Windows Remote is a constantly used tool and an app has to work there as well.
Non-Coder workarounds
You can start the OpenGL program, allowing it to see the graphics card, create an opengl context and then connect via WindowsRemote. This always works, as Windows remote just transfers the window content. This can be accomplished by:
A batch script, that closes the session and starts the program, allowing you to connect to the program already running. (Source)
Using VNC or other to remote into the machine, start the program and then switch to Windows Remote. (Simple VNC programm, also with a portable client)
Coder workarounds
(Only for OpenGL ES)Translate OpenGL to DirectX. DirectX works under Windows Remote flawselly and even has a Software rendering fallback built into DX11 if something fails.
Use the ANGLE Project to do this at run-time. This is what QT officially suggests you do and how Chrome and Firefox implement WebGL. (Source)
Switch to software rendering as a fall back. Some CAD software like 3dsMax does this for instance:
Under SDL2 you can use SDL_CreateSoftwareRenderer (Source)
Under GLFW version 3.3 will release OSMesa (Mesa's off screen rendering), in the mean time you can build the Github version with -DGLFW_USE_OSMESA=TRUE, but I personally still struggle to get that running (Source)
Directly use Mesa's LLVM pipe for a fast OpenGL implementation. (Source)
Misc:
Use OpenGL 1.1: Windows has a built in implementation of OpenGL 1.1 and
earlier. Some game engines have a built in fall back to this and thus
work under Windows Remote.
Apparently there is a middle-ware, that allows for even OpenGL 4 over Windows Remote, but it's part of a bigger package and is a commercial solution. (Source)
Any other solutions or corrections are greatly appreciated.
[10] Nvidia -> https://www.khronos.org/news/permalink/nvidia-provides-opengl-accelerated-remote-desktop-for-geforce-5e88fc2035e342.98417181
According to this article it seems that now RDP handles newer versions of Direct3D and OpenGL on Windows 10 and Windows Server 2016, but by default it is disabled by Group Policy.
I suppose that for performance reasons, using a hardware graphics card is disabled, and RDP uses a software-emulated graphics card driver that provides only some baseline features.
I stumbled upon this problem when trying to run Ultimaker CURA over standard Remote Desktop from a Windows 10 client to a Windows 10 host. Cura shouted "cannot initialize OpenGL 2.0 context". I also noticed that Repetier Host's "preview" window runs terribly slow, and Repetier detects only an OpenGL 1.1 card. Pretty much fits the "only baseline features" description.
By running gpedit.msc then navigating to
Local Computer Policy\Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Remote Session Environment
and changing the value of
Use hardware graphics adapters for all Remote Desktop Services sessions
I was able to successfully run Ultimaker CURA via with no issues, and Repetier-Host now displays OpenGL 4.6, and everything finally runs fast as it should.
Note from genpfault:
As usual, this Policy is kept in the HKLM registry group in
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services
Set REG_DWORD:bEnumerateHWBeforeSW to 1 to turn ON using GPUs in RDP.
OpenGL works great by RDP with professional Nvidia cards without anything like virtual machines and RemoteFX. For Quadro (Quadro 4000 tested) you need driver 377.xx. For M60 you can use the same driver. If you want to use last driver with M60, you have to change the driver mode to WDDM mode (see c:\Program Files\NVIDIA Corporation\NVSMI\nvidia-smi.1.pdf). It is possible that there are some problems with licensing in this last case.
Some people recommend using "tscon.exe" if you can: https://stackoverflow.com/a/45723167/32453 or using a scheduler to do it on native hardware: https://stackoverflow.com/a/41839102/32453 or creating a group policy:
https://community.esri.com/thread/225251-enabling-gpu-rendering-on-windows-server-2016-windows-10-rdp
maybe copy opengl32.dll (or opengl64.dll) to your executable's dir: https://blender.stackexchange.com/a/73014 and newer version of the dll: https://fdossena.com/?p=mesa/index.frag
Remote Desktop and OpenGL does not play very well. When you connect to a Windows box the OpenGL Driver is unloaded and you end up with software emulation of OpenGL.
When you disconnect from the Windows box the OpenGL driver is not reloaded. This causes issues when you are running tests on the machine as you have to physically login to the machine to reset the drivers.
The solution I ended up using was to:
Disable Remote Desktop.
Delete all other software for remote desktop access. Because if it's used for logging in remotely the current set of drivers loaded may be messed up.
Install NoMachine
NoMachine is my personal favourite (when it does not play up) for a number of reasons:
Hardware acceleration of compression (video of desktop).
Works on Windows and Linux.
Works well on low-bandwidth connections especially if the client and server have the necessary hardware for compression of the data stream.
On Linux you get your desktop as you last left it when you were sitting in front of the machine.
On Windows it does not affect OpenGL.
currently free for personal and commercial use. Do check the licence in case it's changed.
When NoMachine plays up it hogs the CPU but this happens rarely. It is however in active development
Others to consider:
TurboVNC
TightVNC
TeamViewer - only free for personal use.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I want to develop some application that could work with drone.
I looking on the SDK of DJI and i don't understand how can i develop to their drone - because i want to write a code that can make the fly by self according to the information that the drone send to my application - and my application will send the flying commands
is it possible ?
Can i found some drone that i can write a code that will work on the drone himself and not only on my 'ground station' ?
for example - if i want to write a code that enable two drone to talk each other i need to write a protocol that will embedded on the drone.
Beside DJI that i rad about their SDK - is there are more drone brand that i can write a code to their drone ?
You would need to create a mobile app (either Android or iOS) and include DJI's mobile SDK to control the drones. The SDK already supports the flying commands.
DJI has a developer platform called Matrice 100. In this platform, we can bring your own computer (like Raspberry Pi or some other computer on a board) and run DJI provided onboard SDK to execute your programs.
There are a few other drone brands that support programming using SDK. A simple google search can help.
I think I can give some more details than the validated answer, so I hope that might be helpful.
DJI currently has an Android and iOS SDK. You can control the drone from your application using it (tell the drone to takeoff, go to a waypoint, take a picture, take a video, etc).
(Note that the following solutions are not sorted. It might depend on your needs)
If you get a 3DR Solo, you can write code on the drone directly. The preferred way for that would be to use DroneKit Python. DroneKit also works on Android, but will probably not be released on iOS (see the post from the 3DR Staff here). The Solo is very cool because you can simply SSH into its embedded Linux.
Still using DroneKit, you can build your own drone around the Pixhawk flight controller.
Parrot has an SDK for their drones, but you cannot run code on the drone itself. The interesting point is that their SDK is in C, with wrappers for Android and iOS.
If you get a Matrice from DJI, you can put your own controller (e.g.Raspberry Pi) on it and use the so-called onboard SDK from DJI.
Still using the onboard SDK, you can build your drone around the A3.
Using the mobile SDK from DJI, you can build your drone around the A2.
That is actually the same as 2, right?
I want to work on application that should give me mobile device look but the application will run on linux based device.
I need access to port which I have checked creating qt application ,now with use of this i want to create UI to be run on linux touch device.
i have experience on qt of about 7 month i have most of the basic knowldege of qt , but now i want to go in detail and advance.
so need help and idea what i should install to add mobile device look in qt application without qt quick.
which version will be best.
how i can add virtual keyboard in application.
the idea is to develop a qt application with mobile look and feel along with communication with hardwares.
You can take a look at VirtualKeyboard. It's a virtual keyboard for touch-screen applications. It would compile normally with Qt 4 and 5.
As stated in Alternatives for Virtual Keyboards one other option is to use Maliit. It works with both widgets and QML and supports Qt 4 and 5.
Finally a search on google or browsing qt-apps.org would give you some results.
I only write QML app with Qt 5.1.1 running on Mac & Windows.
Anyone know what's the version of Qt for Embedded System integrated in the uclinux?
Do the Qt on uclinux support QML? Do I need to re-implement the UI with Qt widgets in C++ to run it on the uclinux?
First and foremost, please do not ask several subquestions in a question.
Anyone know what's the version of Qt for Embedded System integrated in the uclinux?
There is no such a thing. Qt 5 is meant to be well supported for embedded, too, without external third-party projects.
That being said, you may ask Digia about their embedded plans, like Boot2Qt and so on.
Do the Qt on uclinux support QML?
That is the wrong question around. The correct question is whether Qt/QML suppports uclinux. I do not think this will work off-hand, no. You will probably start writing a custom mkspecs file for your scenario and fix lots of issues.
Do I need to re-implement the UI with Qt widgets in C++ to run it on the uclinux?
That would probably be even worse as they are having a lot of overhead in terms additional layer. What I would suggest is to forget about QML for now, and try to bring up a simple screen with QScreen.
As stated, I do not think even that will work off-hand, but if you are enthusiastic, you could get it work.
Since Qt 5 has a hard dependency on the standard library these days, your first task is to get that building againt your mmu-free uclibc. There was some discussion about that here.
But honestly, you may be better off with some lightweight gui framework that supports framebuffer for rendering. Qt is big and not properly tested on minimal systems.
Has anyone built a Qt S60 app (3rd edition, FP2) that plays (streaming or local) video?
I want to play video 'in' a widget, not with (say) QDesktopServices.
I know there's documentation about how to do this with Symbian, such as here and here but I'm still stuck.
(Apologies in advance for cross-posting: I've asked elsewhere, but with no success.)
Qt 4 includes a suite of multimedia APIs called Phonon, which allow you to do just this. They are currently being implemented for Symbian - while the Qt for S60 "Tower" pre-release
does not include support for Phonon on Symbian, Qt 4.6 will do.
In the meantime, your only option is to use the Symbian MMF APIs directly. Specifically, your video widget - or an object owned by it - will need to create an instance of CVideoPlayerUtility, and therefore will need to implement MVideoPlayerUtilityObserver. The video player API requires the client to provide an RWindow in which to display the video - this can be obtained by calling QWidget::winId(), which returns a CCoeControl* pointer. You can therefore obtain a window handle by calling
RWindow& window = *static_cast<RWindow*>(widget->winId()->DrawableWindow())
All in all however, playing video from a Qt app (or indeed any app) on Symbian currently requires quite a lot of work - especially if you want to support dynamic re-sizing and/or re-positioning of the video content. Note also that the way in which Qt is currently implemented on Symbian means that moving other widgets (partially or completely) on top of the video widget will not work correctly - the video will continue to appear on top. This is due to the fact that calling QWidget::winId() currently doesn't cause Qt to create a native Symbian window, and will be rectified in 4.6.
In summary, unless you are in a hurry to do this, it is probably better to wait for the 4.6 beta which is due in a few weeks time.