Re: [hatari-devel] Strange timestamp issue |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] Strange timestamp issue
- From: Thomas Huth <th.huth@xxxxxxxxx>
- Date: Thu, 1 Aug 2024 11:27:27 +0000
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1722511650; bh=4URa9uq0HbBBgu2GIG/VotzYEiAewhDsifjgZlJBa9k=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding:From; b=QMw0TsHMDuQG417u6QEPkJiRsh7wpD7ySx0gA8/hPvNMptCAJNYAlawDfBQ3enzbN n1N09GOTtxmEHF3lZE/xhdzF2ZFELMUxwISIWRsn5b3XxZkbj/cJiuXsHh547g1wvG TgsQn5mEP+miKiMmjekH9kv5oWewP8bpW81Mf3vBV44XsoJRLXeBpOEHUsFhwlya3o jgOrfdvohHg4UHdB8W3jz64VQxc0gdoYk4MUx7a98o+PWSw9kHcU36sJ3fe+Xf9RvW geqnhjjzxH+jGMKUZrk27dkdDkmjC8k5EIeu2fTAYA5EbeVTyMsZVtO+iXaDnsKIjq pjTO19bxmGQNw==
Am Sun, 28 Jul 2024 10:10:40 +0200
schrieb Uwe Seimet <Uwe.Seimet@xxxxxxxxx>:
> > > I see, but also here I would like to ask the Hatari team: Is it possible to
> > > have a non-default option that improves the mouse pointer handling for
> > > users that do not run software with their own mouse cursor routines?
> >
> > I guess it would be possible to implement some hacks for this ... you'd
> > either need some kind of driver on the Atari side (maybe an .ACC) that
> > somehow polls the mouse position from Hatari and then sets the GEM mouse
> > to the same position, or Hatari could try to mess with the Line-A variables
> > to read and/or set the mouse position on the Atari side.
> >
> > Anyway, you also need to consider that the window might be scaled and that
> > there are borders in some screen modes, so you often also can't get a
> > straight 1:1 mapping between the host mouse position and the GEM mouse.
> > The problems are certainly solvable, but it's certainly a bit of work. Feel
> > free to send patches if you've got enough spare time to look into this!
>
> Thank you for explaining where the problems are. I'm afraid addressing this
> is out of scope for me for several reasons.
Thinking about this for a while, it might already help to generate
additional mouse movement events when we detect that the mouse curser
leaves and re-enters the window. Could you please try whether something
like this works for you:
diff a/src/main.c b/src/main.c
--- a/src/main.c
+++ b/src/main.c
@@ -498,9 +498,8 @@ bool Main_ShowCursor(bool show)
/**
* Handle mouse motion event.
*/
-static void Main_HandleMouseMotion(SDL_Event *pEvent)
+static void Main_HandleMouseMotion(int dx, int dy)
{
- int dx, dy;
static int ax = 0, ay = 0;
/* Ignore motion when position has changed right after a reset or TOS
@@ -511,9 +510,6 @@ static void Main_HandleMouseMotion(SDL_Event *pEvent)
return;
}
- dx = pEvent->motion.xrel;
- dy = pEvent->motion.yrel;
-
/* In zoomed low res mode, we divide dx and dy by the zoom factor so that
* the ST mouse cursor stays in sync with the host mouse. However, we have
* to take care of lowest bit of dx and dy which will get lost when
@@ -549,6 +545,7 @@ void Main_EventHandler(void)
SDL_Event event;
int events;
int remotepause;
+ static int mleave_x = -1, mleave_y = -1;
do
{
@@ -595,7 +592,7 @@ void Main_EventHandler(void)
break;
case SDL_MOUSEMOTION: /* Read/Update internal mouse position */
- Main_HandleMouseMotion(&event);
+ Main_HandleMouseMotion(event.motion.xrel, event.motion.yrel);
bContinueProcessing = true;
break;
@@ -681,10 +678,19 @@ void Main_EventHandler(void)
case SDL_WINDOWEVENT_ENTER:
case SDL_WINDOWEVENT_FOCUS_GAINED:
bAllowMouseWarp = true;
+ if (mleave_x != -1)
+ {
+ int new_x, new_y;
+ SDL_GetMouseState(&new_x, &new_y);
+ Main_HandleMouseMotion(new_x - mleave_x,
+ new_y - mleave_y);
+ mleave_x = mleave_y = -1;
+ }
break;
case SDL_WINDOWEVENT_LEAVE:
case SDL_WINDOWEVENT_FOCUS_LOST:
bAllowMouseWarp = false;
+ SDL_GetMouseState(&mleave_x, &mleave_y);
break;
}
bContinueProcessing = true;
?
Thanks,
Thomas