Olivier Michel

> Is it a good practice as it will introduce a bug in master? I mean we won't merge this PR until the other PR fixing the issue is merged,...

I just fixed the problem. However, it remains a little problem with the controller path which is not found. I believe one way to fix it would be to compute...

We also have the same problem for the robot `window` and the `controllerArgs` parameters. I propose to set the `window` to `` and `controllerArgs` to `[]`.

I am done with the implementation: the `controller` and `window` fields are set to ``. However, I didn't change the `controllerArgs` for several reasons: - It doesn't harm to leave...

I added a message for robots to warn that the controller/window fields will be set to generic. I believe the remote control problem is not critical. We could possibly add...

I found a more elegant fix for the E-puck and Darwin-op robots: if the window is set to `` or ``, the remote control library is not initialized, thus no...

That's is strange... Can you try to to set `export QT_USE_PHYSICAL_DPI=1` and run Webots again? Alternatively, can you also try `export QT_SCALE_FACTOR=2`? Also can you try to remove `QT_ENABLE_HIGHDPI_SCALING` from...

Maybe [this one](https://github.com/cyberbotics/webots/commit/88e8b517af05661aa55d7e7e2209ba12e04bb894) broke it? Can you try to revert it?

Or removing [these lines](https://github.com/cyberbotics/webots/blob/master/src/webots/launcher/webots-linux.sh#L39-L43)?

Unfortunately, I am running out of ideas... That's strange the bug doesn't show up with R2022a... A big change we did between R2022a and R2022b is the [upgrade to Qt6](https://github.com/cyberbotics/webots/pull/4189)....