we have developed QT application in QT5 over raspberry pi, in the application, there is multiple classes.
Application runs very well while that classes's ui over screen for long time, but certain classes's ui scrren comes over screen application gets hang after 2/3/4 hrs(sometimes works very well here also).
Our application uses full-duplex asynchronous serial communication in background, but that remains active even RPI gets hanged(we checked that over putty).
our set is - rpi3B model, rpi official 7 inch screen(via ribbion cable), microcontroller in background
Related
I am starting a QGuiApplication (Qt 5.12) and using a remote desktop connection to a Windows 10 PC. Everything works fine while the remote desktop connection is open, but when I disconnect and let the application run during the week-end, I can see in the logs that it stops processing Qt events (mostly network related in my case). The last thing the logs show is an "activation change" event.
When I connect again after the weekend, the Qt event loop starts again (the logs show again "Activation Change event") and of course there is a huge amount of queued events and the application gets in a non responding state (I am logging the number of Qt events queue in the loop using qGlobalPostedEventsCount).
This used to work correctly but stopped working, I think due to an update of Windows on the machine (maybe same root-cause than this thread ?).
Is this the expected behavior for applications when the windows remote connection is terminated? Is there a known fix for this?
I have not managed to properly fix the issue. As a work-around, using Microsoft "Remote Desktop" application instead of using the "Remote Desktop Connection" application avoids the issue.
Qt Quick WebGL Streaming is a technology by which any Qt Quick ("QML") application can display its user interface to a user connecting via a web browser. All you have to do is to start the application like this on the host:
./my-qml-program -platform webgl:port=8080
This works, but is limited by design so that only one user can be connected at the same time and see the user interface. As the reason for this, they quote problems with user input, with querying the GPU, and with security (source).
Initially, the Qt developers wanted to support multiple users in WebGL streaming by serving multiple windows from one process:
How will concurrency be supported? Like does each connection get it's own QGuiApplication, or is there only one? […] You create a single QGuiApplication and different windows. There is a signal to notify when new clients connect to the HTTP server. When the signal is emitted, you create a different QWindow. The windows are independent (source)
Now however, the developers want to support multiple users in WebGL streaming by launching one process per user.
We are working in decoupling the HTTP Server from the plugin
A dedicated HTTP Server application will be provided
Instead of running all the users in the same process a new process will be spawned per user
The new process will handle the web socket
(source)
"Decoupling the HTTP Server from the plugin" would mean replacing it with QHttpServer:
I have planned some use-cases for this [QHttpServer] module: Change the current embedded web server (and WebSockets) in the WebGL plugin to make it easy to create your own custom solutions based on the plugin. (source)
So far, no solution has been implemented. What is the simplest way to implement support for multiple users in Qt WebGL streaming myself, without waiting for Qt to implement this?
Here is a solution that uses the load balancer Pen to make a Qt application accessible via WebGL streaming to multiple users at the same time. It forwards an incoming connection to one of multiple Qt processes running on the same host, each of which running its own embedded web server. This kind of forwarding is exactly the job of a load balancer, just that it usually distributes connections to multiple hosts.
Caveat: In my tests, WebGL streaming in Qt 5.12.3 is fast enough for real use only in the local network, not over Internet. So you can't use it to "convert a Qt application into a web application on the cheap".
Instructions
These instructions apply to Ubuntu 19.10, 20.04 and other Debian based distributions.
Install the Qt application on your web host.
Install the Qt WebGL platform plugin on your web host. It is not contained in the Ubuntu 19.10 distribution, for example. In such a case, you'd have to compile and install it yourself. Under Ubuntu Linux, the result should be the following file:
/usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqwebgl.so
Start multiple processes of the Qt application. Each should serve one port with Qt WebGL streaming. Here we start three processes, but you can start as many as fit into your memory.
nohup myapplication -platform webgl:port=8080 &
nohup myapplication -platform webgl:port=8081 &
nohup myapplication -platform webgl:port=8082 &
Install the load balancer Pen.
sudo apt install pen
Start the load balancer. Note that with pen 80 … it is started so that the users only have to enter a simple URl such as http://example.com/ into their web browser to visit the application. If port 80 is already in use, you can choose any other port (say, 9090), start the load balancer with pen 9090 … and then let users visit a URL like http://example.com:9090/. Also note the :1:1 suffix for each server process listed, telling pen to only connect at most one client to one process.
pen 80 localhost:8080:1:1 localhost:8081:1:1 localhost:8082:1:1
Test the setup. To test, visit the associated URL http://example.com/ from multiple devices. You shoud be served one process of the application on each device. It is not possible to see two processes in two parallel browser tabs on the same device – pen would then try to connect the second such tab to the same Qt process as the first tab because the request comes from the same IP address. As a result, you'd see a spinning wheel in the second tab, because Qt processes only allow one connection each for WebGL streaming.
Improvements
This solution could be further improved by starting the Qt processes only on demand, once a client connects. This should be possible with systemd socket activation.
A question about registering BLE notification on android:
I am developing an app that once the android device detects our beacon/ble hardware, should write something to one of the writable characteristics of that hardware.
Trying to understand, on the android app side how can I register some intent to be called when a ble connection was made to the android framework.
since a broadcast receiver registered in manifest can no longer launch my app and android background services policy was changed, this can't be done. so..
I am trying to use JobScheduler which was designed to be launched based on criteria. this can launch a JobService to do the job.
When the app is in foreground or background this seems to be working.
The thing is, I need to be notified when the app is not running (Not even in background)
I'm developing a qml UI using Qt Quick 2D Renderer on an ARM embedded device which runs linux. The device has a LCD screen and some standby mode when it is inactive.
For some reasons (network needs to stay active), suspend to RAM is not an option. However, to lower the power consumption in standby mode it would be good to stop the UI rendering. Can this be achieved with some Qt API?
Connect directly (Qt::DirectConnection) to the QQuickWindow::beforeRendering() signal. That will be in the render thread, the program can wait there on your mutex/condition_variable. GUI thread is unlocked during this step so the application logic will continue working.
http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html
Can probably also override the whole sequence by using QQuickRenderControl.
An Eclipse RCP application crashes in the jprofilerti.dll code once I move the app from relatively idle status to full operation.
Some initial profile results are available back on the remote GUI session. This suggests that the configuration of Jprofiler GUI, Jprofiler agent, and network settings is ok.
I wonder if the crash occurs due to buffer overruns. I ask because the network link between the remote JVM and the near laptop JProfiler GUI is very poor with a very low effective bit rate. Is it possible that the target JVM will crash if the remote GUI is too slow about consuming buffered profiling data?