'Magic Mouse untrap' not working (works in RTG with caveat)
Closed this issue · 15 comments
With RTG not used, this doesn't seem to work. Tested against git trees amiberry v6.1.4 (on x86-64) & v5.6.6 (on rpi4) -- all machines running their respective releases of debian 12 (+updates to current).
Expected behavior is to untrap mouse and relinquish to host control. should mouse pointer move outside emulated window -- of course, windowed mode must be enabled to observe this on the linux desktop (X/xfce4). Observed behavior is mouse pointer always remains captured by emulation window -- clicking MMB does still relinquish mouse control to host correctly.
A further note wrt v6.1.4/x86-64 is that when RTG is enabled + virtual mouse driver stuffs, the 'untrap' function does actually work ; the issue here is both the host & native mouse pointers are visible (no matter what host/native/both widgets are set) ...but I suspect that's another issue --- the untrap function should work in 'native' screenmodes irrespective.
TIA
I cannot recreate this - if you have Windowed mode and that option enabled, pushing the mouse pointer to the edge eventually takes it outside the window, as expected.
Perhaps it can be improved a bit, since I see that the system mouse pointer is not in the same position as the emulated Amiga pointer, which means that sometimes you have to move it more than you think before it's released outside the edge of the window, but it does work, in all cases.
After looking at winuae (under WINE), I see the problem. In winuae, the 'magic mouse untrap' widget is unavailable, unless 'virtual mouse driver' is selected first.
In amiberry, it's possible to enable 'magic mouse untrap' regardless of the 'virtual mouse driver' setting. In GUI/input helptext, nothing identifies this requirement for 'virtual mouse driver' to be enabled first, for 'magic mouse untrap' to work.
Would it be feasible to disable the 'magic mouse untrap' widget, until 'virtual mouse driver' is selected? (aka. the way winuae handles it)
Note: it seems mouse tracking only broken in vertical plane? https://www.youtube.com/watch?v=wZfa3YxwQB8
@giantclambake
You can enable Magic Mouse as the untrap mode in WinUAE, without virtual mouse driver being selected:
@midwan ... indeed, mea culpa...I think the decades of heavy metal (lead) proximity are failing my short term memory (dendrites =) ...clearly, it's cursor mode that's defined that way.
So...question: Is magic mouse untrap dependent on virtual mouse driver being enabled in amiberry? That appears to be the case here on x86-64/preview.
Btw, commit 609df76 fixes the mouse issue.
No, it's not depending on that option - it works with and without it, but differently of course.
If virtual mouse is enabled, you have absolute positioning of the mouse pointer, so the Amiga pointer appears in the same location as the Linux pointer. Moving it to the edge and outside of it, is pretty straightforward.
When it's not enabled however, Relative mouse movement is used. This means that the Linux pointer is restrained in one position and instead reports relative motion, which triggers the movement of the Amiga pointer that you see. So, even when the Amiga pointer appears to be at the edge, the Linux pointer is not there, which means that it takes more effort to release it (the mouse has to travel more).
I'm not sure if this can be improved yet, as it's related to how SDL2 impements relative/absolute movement. But of course, if I can find a way to improve it, I will. :)
It still does work however.
Thanks for the detail ~ this helps confirm we're on the 'same page' as it were ;) That said, I cannot get it to work here at all, without virtual mouse driver being enabled, so I'm curious as to the cause.... mind you, it's not a big issue because 'manual mouse untrap' with MMB works ...but still....
I decided to change tack, and downloaded the latest Pimiga 4.0 offering ...very few will notice as default config is RTG in fullscreen, but, if you load up another uae.conf file to test magic mouse untrap, it doesn't work there either.
Then one is tempted to muse that perhaps it's a debian thing, seeing as all instance here share that base?
So I started a LFS 11.3 instance and compiled amiberry v6.2.0 there... this is a long way different from the debian builds, SDL2 is v2.28.2 and using iceWM (to exclude xfce4)...Xorg 21.1.7 ....and it doesn't work there either =)
However, that machine is a bit slower than this thing, and it's using the intel HD4600 IGP.... and I can actually see something. If I'm scrolling the mouse to the left or right in serious fashion trying to get magic mouse to untrap (and by serious fashion, I'm talking repeated 20cm swipes at the mouse), very occasionally and for the briefest of moments, I do see the host cursor outside the emulator window, but it's almost immediately 'snapped back' inside the emulator window, regaining the amiga pointer focus...ie; I can see the mouse pointer snapping back to the left, even though I'm physically scrolling right with the mouse. It looks like the untrap action happens, but pointer is immediately retrapped by emulation before host takes control. It's easy enough to reproduce if you want a vid ;)
I think the other machines are too fast to even notice this more than a very occasional shimmer near mouse pointer.
Definitely odd =)
I agree it's not ideal.
SDL2 will restrain the mouse pointer to the center of the window, when Relative mouse mode is enabled. That means that we have to detect when the emulated pointer is at the edge of the screen, and then try to release it if it moves outside of it - which can be tricky when it's being forced back to the center.
Perhaps it's best to only allow this option when absolute movement is used (Virtual mouse driver).
It's the only way I've been able to get the 'magic' part happening here ;)
In saying that however, it comes with it's own little startup quirk... https://www.youtube.com/watch?v=p_2JYQ_si_Q
It is as it appears -- host/native mouse pointer confusion.... until mouse position moves outside SDL window (which triggers magic mouse at the same time in theory), then it works correctly. Is that some veiled clue as to why it's misbehaving?... (and yes, I did think to check on the LFS box incase it was a nvidia driver thang, alas same there).
If emulation is started with magic mouse untrap enabled -> F12 -> enable Virtual mouse driver -> Resume ... applies cleanly ... it's only when both are enabled at emulation start, you see the above quirk.
The other thing I notice, is that virtual mouse driver is tracking the host mouse movement, even though the emulator window isn't active/doesn't have focus... https://www.youtube.com/watch?v=SheaDwdKDRc
That's the expected behavior with Virtual Mouse and Magic Mouse enabled. ;)
Ahh, ok... thanks ;)
It's the only way I've been able to get the 'magic' part happening here ;)
In saying that however, it comes with it's own little startup quirk... https://www.youtube.com/watch?v=p_2JYQ_si_Q
It is as it appears -- host/native mouse pointer confusion.... until mouse position moves outside SDL window (which triggers magic mouse at the same time in theory), then it works correctly. Is that some veiled clue as to why it's misbehaving?... (and yes, I did think to check on the LFS box incase it was a nvidia driver thang, alas same there).
If emulation is started with magic mouse untrap enabled -> F12 -> enable Virtual mouse driver -> Resume ... applies cleanly ... it's only when both are enabled at emulation start, you see the above quirk.
Yeah, that's a cosmetic bug indeed. The event that changes the cursor is only triggered when you Enter the window, so if your pointer is already on top of it when it opens, it won't get triggered.
I'll try to fix that. :)
This should be OK now in preview, but please test and confirm when you get a chance.
If it works as expected, I can merge it in master as well. :)
Actually, this seems pretty harmless to merge, so I'm doing that :)
Tested and working as expected - TY ;)