Cockpit Standalone needs to be the selected window for controller to work

I have noticed that the Cockpit standalone app requires it to be the selected window for the controller/joystick commands to work. This means that if using other apps eg Sonar View, Ping Viewer etc and you click on the other apps, the controller input feed is lost in Cockpit.
I use a number of external apps simultaneously and there is no issue with QGC, only Cockpit.
Running Windows 11 and Cockpit v1.3.2

Hi @3dMB -
@rafael.lehmkuhl can confirm, but I believe this is a fundamental limitation of Electron based applications like Cockpit, and what your experiencing is expected…

Actually @tony-white this should not be the case. The standalone version should only lose connection to the joystick if you minimize the application. Alt-tabbing from it, and even interacting with another application should not affect the joystick connection.

I just tested this here on macOS and it’s working as expected.

@3dMB can you confirm you’re not minimizing Cockpit?

I will also try to get to a Windows computer in the meantime.

I can confirm that I am not minimising. The control stops working when Cockpit is maximised and I click on another application, whether it be Edge for BlueOS, Sonar View, Ping Viewer, RDC, etc.

@3dMB I just tested again on a macOS, specifically maximizing Cockpit, and that’s indeed what’s causing the difference in behavior!

When you have Cockpit maximized (instead of just as a large window), alt-tab will cause lose of focus (and lose of joystick connection in consequente). If you have it just as a large window and alt-tab it, you won’t lose focus.

@tony-white is confirming if the behavior on Windows is the same.

For the moment, I will ask you not to maximize Cockpit, but only to have it as a large (but not maximized) window. For the future (probably first semester of 2025) we are talking already about a dedicated backend that bypasses the Gamepad API and can thus be used even without focus.

Can confirm what Marcus is mentioning, experiencing the same issues when i click on Sonarview, i lose control of the joystick even tho i shows it’s still connected to Cockpit. Not handy whilst working around platform jackets in a strong currents.

Hi @Seair -
Is cockpit maximized when this occurs? Have you tried making the window less than full screen, but large, and then alt-tab to sonarview?
Alternatively, you can embed SonarView into the Cockpit view via an iframe widget and the URL for SonarView (found in available services.)

Unsure if it was maximised at the time, shall have the sub set up over the weekend and test it again with your suggestions.

Thanks

More problems with Cockpit today when in the water - everything thus far has been when the ROV is on the bench.
I booted up the ROV and did out of water tests to make sure Cockpit was working with controller. Tests were arm/disarm & camera tilt. Although sonar view was open, it was not selected and no sonar was active on it.
ROV goes in the water, works for a short moment, then loses control for a minute or so, then gains control, then loses control again - then I started recording on my phone.
After being unable to regain control in Cockpit I closed it down and fired up QGC which worked immediately.
Photo video showing cockpit not working etc, then the transition to QGC

Anyone have anything further on this? @tony-white @rafael.lehmkuhl Hoping the video shows something helpful of the issue?

Hi @3dMB -
Please test with the latest version of Cockpit, version 1.4 fixed a memory leak (full change log here) that may be related to the behavior you showed a video of. We’re already onto version 1.4.1, so it’s always a good idea to check if you’re using the latest version if you encounter an issue!

Thanks Tony. I was using the latest version of the time, updated the day before - although think this was of the 1.3 generation. I will try the 1.4 generation. Thank you

@3dMB it would be really helpful if you can get us a feedback about the problem being solved or not for 1.4.0+. We had more users reporting the same, and I expect this fix in the memory leak to help a lot on performance, specially for those using extra hardware like sonars (the leak was related to number of messages in the MAVLink channel).

of course - always happy to be pro-active with feedback. I hope to be in the water next around Christmas week, but will carry out some more bench tests before then - this time while running Sonarview as you think the external applications are part of the problem