Hi,
On tiistai 05 toukokuu 2015, Douglas Little wrote:
I have noticed for some time that Hatari grabs & teleports the host mouse
pointer when the emulated machine changes video resolution.
If I remember it correctly, it was a problem with no good solution.
When resolution is changed:
- TOS centers mouse, at least if change is done on GEM desktop
- Hatari needs to re-create new SDL surface with new size:
- the new window can be positioned elsewere (not controlled by Hatari)
- window manager (naturally) doesn't re-position mouse
So as a result host mouse is completely out of sync with Atari mouse.
If you happen to be developing code which runs under the emulator and
changes resolution, it can steal the mouse while you're typing or doing
other stuff in the host.
I think it was Laurent who kludged around the problem by forcing
mouse move when resolution is changed, but I do agree that it's
very annoying when one wants to do something else while Hatari
runs.
(If one is actually using Hatari, it's fine.)
It can also interfere with the emulated session
(depending on what you're doing of course) - sometimes such that it's
necessary to reboot and try again.
Can you describe this problem more in detail?
I am wondering if this is really necessary and can it be fixed? or made
into an option?
Option is always possibility. What the others think about this?
(At one point I hacked the source to stop grabbing the mouse completely -
for profiling purposes - because grabbing focus back from the host after
a resolution change allowed the camera to accidentally move by some
amount each time, which upset the profiling starting conditions.
Unfortunately my hacks were just simple #ifdefs scattered around so the
host retains the mouse always...).
Currently Warp is done in following places:
- Cold reset
- Falcon resolution change
- Dialog exit (restore mouse where it was when emulation was paused)
- Eero