PDA

View Full Version : Raspberry Pi / QT5 - mouse focus on application AND in background operating system



mstew
14th June 2016, 02:54
Hello

I am writing an application to be run on Raspberry Pi 3 with Debian based Raspbian distribution. The application uses QT 5.6 and I am developing and cross compiling on a Windows system.

The application is a full-screen graphical user interface with touch screen.

When I run the application, everything works as expected, however mouse (touch screen) events/gestures such as clicking buttons, dragging etc also appear to be functioning behind the application. I find that when I close the application, icons have shifted, dialogs have been opened etc.

This doesn't appear to happen with non-QT applications so I was wondering if anyone here might know what is going on and how to stop it?

Kind Regards,
m

anda_skoa
14th June 2016, 09:23
Very strange, that sounds like a standard X11 setup.

Does this also happen when the application's window is not full screen?

Cheers,
_

mstew
15th June 2016, 00:59
Yes as far as I know it's a standard X11 setup. It uses a window manager "based off of LXDE" which I take to mean it has undergone a few cosmetic changes to make it fit the Raspberry Pi theme but nothing major (as far as I know).

Also yes it does happen no matter how I configure the application window - full screen or otherwise.

I am currently doing this:

MainWindow w;
w.setWindowFlags( Qt::Window | Qt::WindowStaysOnTopHint | Qt::FramelessWindowHint);
w.setWindowState( Qt::WindowFullScreen | Qt::WindowActive);
w.show();
w.raise();

I have tried all manner of combinations but the mouse issue seems to remain.

A couple things I have noticed that may help diagnose the issue:

Mouse cursor when application is not loaded shows a black pointer, and disappears after a couple seconds without motion.
Mouse cursor when application is not loaded can be moved by touch screen and by external USB mouse.
Mouse cursor when application is loaded is a different shape white pointer, always initializes its location to the top left, and always persists.
Mouse cursor when application is loaded cannot be moved by touch screen, but can be moved by external USB mouse.



This hints to me that QT libs are partially overriding the x11/window manager control of mouse events but also continuing to pass events behind the application.

Also worth noting that when I compile the same application for Windows 10 using QT 5.6, the application works fine.

Correction: I use QT 5.5 for cross compiling on Raspberry Pi.

Regards
m

mstew
15th June 2016, 04:34
Ok I've done more digging

This is the guide I used to build QT
http://visualgdb.com/tutorials/raspberry/qt/embedded/

There is an option "-opengl es2" that is described "“-opengl es2″ option that configures Qt to use the Raspberry Pi framebuffer directly instead of the X11 system.".

It looks like eglfs is the default platform when executing my program and is designed to operate without a windowing system.

Additionally I was not able to build with -qt-xcb and so XCB is not currently an option.

Does this mean I need to recompile QT without -opengl es2 so that I can still access gui desktop features outside my app?

anda_skoa
15th June 2016, 08:46
I am currently doing this:

MainWindow w;
w.setWindowFlags( Qt::Window | Qt::WindowStaysOnTopHint | Qt::FramelessWindowHint);
w.setWindowState( Qt::WindowFullScreen | Qt::WindowActive);
w.show();
w.raise();

That looks really complicated, are you sure you need this?
Wouldn't a simple


w.showFullscreen();

Be sufficient, like on any other X11 based desktop?



There is an option "-opengl es2" that is described "“-opengl es2″ option that configures Qt to use the Raspberry Pi framebuffer directly instead of the X11 system.".

No, this configures which kind of OpenGL to use, in this case OpenGL ES2 and not "Desktop OpenGL".

The platform adapter module is selected through the -qpa switch. You want -qpa xcb



It looks like eglfs is the default platform when executing my program and is designed to operate without a windowing system.

Yes, looks that way. For running the Qt application as the only UI on the device.
Also only for programs that don't need support for windows such as dialogs.



Additionally I was not able to build with -qt-xcb and so XCB is not currently an option.

I am pretty sure the Rasphian system has XCB libraries, no need for Qt's copy.



Does this mean I need to recompile QT without -opengl es2 so that I can still access gui desktop features outside my app?
No, you need to build with the XCB platform plugin enabled.

Cheers,
_

mstew
15th June 2016, 21:57
anda_skoa, thank you so much for your input!


That looks really complicated, are you sure you need this?
Wouldn't a simple
Qt Code:
Switch view


w.showFullscreen();

To copy to clipboard, switch view to plain text mode
Be sufficient, like on any other X11 based desktop?

You are right, "w.showFullscreen();" should suffice. The excessive code I have is just a result of desperation to try solve this mouse issue but I see now it should not be needed.



No, this configures which kind of OpenGL to use, in this case OpenGL ES2 and not "Desktop OpenGL".

Ok so “-opengl es2″ option is simply described wrong in the link to the guide I used. I will leave this option as it is unrelated.



I am pretty sure the Rasphian system has XCB libraries, no need for Qt's copy.

Yes it seems to. At least I can include <xcb/xcb.h> with no issues but when I run with eglfs I'm not sure how it operates.

FYI, before when I tried to build with QT with the suggested "-qt-xcb" it failed. I did not check why at the time, but maybe I was missing some dev libraries. I have installed all the recommended libraries from this link:
http://doc.qt.io/qt-5/linux-requirements.html
So maybe now the -qt-xcb option should work...but it seems like I can leave it as -no-xcb and link to libs.



The platform adapter module is selected through the -qpa switch. You want -qpa xcb

I used the available "qt-everywhere-opensource-src-5.5.0". Is it normal that XCB is not default when building this?

By using this platform switch when building QT, can I still use QT to build my application to run eglfs, i.e. is there a qmake flag to change it?

Currently the platform options I have when executing my program currently are "eglfs, linuxfb, minimal, minimalegl, offscreen.".


Regards

Mikael

anda_skoa
16th June 2016, 10:39
Ok so “-opengl es2″ option is simply described wrong in the link to the guide I used. I will leave this option as it is unrelated.

It is likely a requirement for building the eglfs QPA so its presence might trigger a different default if the -qpa switch is not explicitly setting a different one.



Yes it seems to. At least I can include <xcb/xcb.h> with no issues but when I run with eglfs I'm not sure how it operates.

Not sure what you mean.
You don't need XCB if you are using eglfs, but you don't want to use eglfs, you want to use XCB.



I used the available "qt-everywhere-opensource-src-5.5.0". Is it normal that XCB is not default when building this?

It would be the default on Desktop Linux but the device config for the RPi might have a different default.



By using this platform switch when building QT, can I still use QT to build my application to run eglfs, i.e. is there a qmake flag to change it?

It should be possible to build both QPA plugins, but why would you want to build the eglfs one if you don't need it anyway?

Cheers,
_

mstew
16th June 2016, 21:24
Not sure what you mean.
You don't need XCB if you are using eglfs, but you don't want to use eglfs, you want to use XCB._

To clarify, this was a separate piece of code I used to test the inclusion, not the app that I am working on.


It would be the default on Desktop Linux but the device config for the RPi might have a different default._

I'll have to look into the config files. I didn't think the guide I used changed much but like you say the '-opengl es2' may have triggered the default platform change.


It should be possible to build both QPA plugins, but why would you want to build the eglfs one if you don't need it anyway?

I don't. I Just thought if I try and fail to get XCB working, at least I can revert to EGLFS, though I can always keep my current qt build in a separate folder..

Cheers
m