After the new update, QEMU’s just… worse than it used to be. Why does it now try to grab my mouse? When I click on the QEMU window, it confines my mouse to the window borders. It also sometimes doesn’t let me move the window with super+drag, the window’s square now instead of matching the watch resolution, and if I run pebble install –emulator flint –logs QEMU will close if I press CTRL+C. I don’t want to have to wait for QEMU to start up every time I reinstall the app. Is there a reason for all these changes? Or is it just things that happened because of the QEMU version update? It would be nice if all those behaviours got reverted.
1 Like
This is because the emulator now supports touch. Mouse is used to simulate touch events.
We’ll take a look at these, but if you want to fix the bug and submit a PR, it might be faster since you already seem to have something in mind for how to improve it for your workflow.
1 Like
Surely you don’t need to capture the mouse to receive touch inputs though, right? And the sigterm closing QEMU thing definitely seems like a bug
1 Like
Also now I get this popup every time QEMU opens. Which wouldn’t be so bad except QEMU closes every time I quit from a --logs command
1 Like
good question - again we’ll take a look at it when we have a moment but it’s 100% open source sw so if you’d like to dive in right away and fix it, you might get it fixed even before we have a chance to take a look!
1 Like
Hi Flynn, most of the issues seem to be linux specific (I cannot replicate them on macOS) sorry about that! I’ll try to replicate them on my Linux machine and try to fix that!
re: qemu closing when you press ctrl+c when using install –logs: that already happened with the old emulator so this isnt new behavior
1 Like
That definitely didn’t happen for me before 
is it supposed to happen?
1 Like
yes it is, and i need 20 characters so hello
1 Like
Huh. Why is that the case? Seems odd that you’d want to close QEMU ever. It also is inconsistent. If the app fails to install, QEMU won’t close even though that’s a case where you’d close it anyway to reset it. The way I used to use it is I would keep the QEMU window open and resized larger on a second monitor and install with --logs. I can no longer do that and now the next-best thing I’ve figured out is running build and install, then running pebble logs&then running install again so I get logs. Which is… markedly more annoying and something I need to do every time QEMU crashes or I close it now 
additionally it seems to be failing to install the app more frequently now but that’s not something I can confirm for sure
1 Like
It happens here only if I start QEMU with the --logs parameter. And as far as I remember this was always the case?
My workaround is to run e.g. pebble install --emulator flint to start QEMU (without the --logs parameter), and only use the --logs parameter when qemu is already running. In this case Ctrl+C doesn’t close QEMU.
1 Like
Huh. Well at any rate it’s not as important anymore since I need to kill/wipe QEMU to install the app anyway 
Maybe I was just special before since I never saw that behaviour until now
1 Like
Maybe it depends on your system / configuration?
I’m curious on what OS and what versions of QEMU / Pebble Tool / Pebble SDK do the “mouse problems” occur?
For info: it seems to work well here on Debian Stable (Trixie) with Pebble Tool v5.0.34 and SDK v4.9.169.
1 Like
Mouse capture only happens on latest SKI, 4.9.169. It’s intentional behaviour that might (hopefully) get reverted though!
2 Likes
I also wanted to chime in to add that the VNC mode for the emulator, like in the vscode extension, no longer works it seems.
Ah yeah I’ve seen two other people report the same. There’s an error about a missing keymap file if I remember correctly?
1 Like