Re: [hatari-devel] Synching host mouse position to Atari mouse position

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

This is a multi-part message in MIME format.

Hi,

On 11/4/19 11:57 AM, Thomas Huth wrote:
> Am Fri, 1 Nov 2019 00:09:45 +0200
> schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> > I did small patch inspired by recent OSEX header being added to
> > EmuTOS to support for synching host mouse position with TOS mouse
> > position for Aranym...
> >
> > Attached patch syncs host mouse to Atari mouse position whenever
> > mouse enters Hatari window and when window resolution changes.
> >
> > It requires line-A base to be known, which is the case when
> > cartridge code is used, i.e. either GEMDOS HD or VDI mode is
> > enabled (and that user hasn't disabled mouse warping).
> >
> > Otherwise things are as earlier.
> >
> > Is this something I could push to Hatari, or is not working
> > without GEMDOS HD or VDI emulation too strange for users?
>
> Looks dangerous. If a program takes over the full memory and uses its
> own mouse handler, you might get completly wrong values from the ST
> memory.

I'm not so concerned about programs overwriting those line-A
variables, but TOS interrupt handler for updating them being
stopped.

Fortunately majority of demos use just keyboard, and games
joystick.

Of those that use mouse, how common it's for them to use their
own mouse handler?  And more importantly, could it be detected
so that warping can be (temporarily) disabled?

Are there any non-demo/non-game programs which would have their
own mouse handler, e.g. Cubase and its RTOS?


Nicolas, you've fixed IKBD emulation for some demos, any
comments on detecting changed mouse handler?


> If we really want to include such a thing (I'm really not sure
> whether we should), you need to add more sanity checks here (e.g.
> whether x and y is within range of the display)

Attached is updated patch which does that check and also fixes
issues with the (already existing) mouse warping done on
resolution switches.

I changed warping to be done only when Hatari has/gets keyboard
focus.  This fixes bad warping for Hatari windows that are covered
by other windows, when using click-to-focus windowing policy.

I couldn't come up any way to fix it for focus-follows-mouse
windowing policy, as there's no portable method for finding out
whether Hatari window is fully visible, so I just documented
that in the manual page.


> and maybe also add an option to disable this feature.

It's behind the already existing --mousewarp option, which
is enabled by default.


	- Eero