You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reported in version: HG 2.0 Reported for operating system, platform: Linux, x86_64
Comments on the original bug report:
On 2012-09-28 04:01:43 +0000, Sik wrote:
Trying to get the cursor position using SDL_GetMouseState will return the cursor at window coordinates 0,0 (top left corner) if the cursor hasn't moved at all (e.g. window was created and the cursor hasn't moved yet). This gets fixed as soon as the cursor makes any move.
I suppose the easiest (and proper) fix would be to query the current cursor position at initialization.
Using Ubuntu 11.04 x86-64, no idea if this also affects other platforms.
PS: if the cursor is not positioned inside the window it gets detected properly by SDL_GetMouseFocus (didn't check how coordinates are handled in this case). Possibly not relevant, but it's probably a good idea to remark.
On 2013-04-23 21:52:51 +0000, (disabled) Jørgen Tjernø wrote:
It sends a SDL_MouseMotion event when the app starts (gain focus in EnterNotify and also in LeaveNotify) and when the mouse is not used.
I have seen that while trying to remove synthetics events in bug 4690.
But the SDL_GetMouseState always give (0, 0) as a position on x11. Whatever SDL version I use. So I wonder if this is really fixed ?
(or probably, I have a wrong test case)
If not fixed, maybe we don't need to send MouseMotion event in x11/{Enter,Leave}Notify.
(or we should add it for others like wayland, and other).
On 2019-07-30 17:49:35 +0000, Ryan C. Gordon wrote:
(Sorry if you get several emails like this, we're marking a bunch of bugs.)
We're hoping to ship SDL 2.0.11 on a much shorter timeframe than we have historically done releases, so I'm starting to tag bugs we hope to have closed in this release cycle.
Note that this tag means we just intend to scrutinize this bug for the 2.0.11 release: we may fix it, reject it, or even push it back to a later release for now, but this helps give us both a goal and a wishlist for the next release.
If this bug has been quiet for a few months and you have new information (such as, "this is definitely still broken" or "this got fixed at some point"), please feel free to retest and/or add more notes to the bug.
--ryan.
On 2019-09-20 20:47:37 +0000, Ryan C. Gordon wrote:
We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).
As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!
Thanks,
--ryan.
On 2019-09-20 20:48:40 +0000, Ryan C. Gordon wrote:
We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).
As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!
Thanks,
--ryan.
On 2019-10-09 17:53:42 +0000, Ryan C. Gordon wrote:
So this isn't perfect, but this fixes most of the issue:
The test case in Attachment # 3876 now will report a 0,0 position in the first call to SDL_GetMouseState(), but once the event loop runs and X11 sends an EnterNotify ("the cursor is inside the window") event, the state is corrected.
In short, the first call still reports 0,0, but it no longer stays at 0,0 until you move a mouse.
I think this is Good Enough, as SDL is correctly reporting the mouse is outside the window until X11 tells it otherwise, which is does once the event queue catches up.
Reopen if this is still not okay, please.
--ryan.
On 2019-10-10 15:04:01 +0000, Sylvain wrote:
Hello Ryan,
Thanks for fixing !
I think I re-opened this issue because I noticed there was a curious Mouse Motion event sent when the app gained focus.
This event is sent to fix SDL_GetMouseState,
but we don't really want the event otherwise, there might be no mouse interaction, but only a touch screen or maybe the focus is gained with Ctrl+Tab switching.
Maybe we should just add an internal call to a function to set the mouse state and remove this Send_MouseMotionEvent.
The text was updated successfully, but these errors were encountered:
This bug report was migrated from our old Bugzilla tracker.
These attachments are available in the static archive:
Reported in version: HG 2.0
Reported for operating system, platform: Linux, x86_64
Comments on the original bug report:
On 2012-09-28 04:01:43 +0000, Sik wrote:
On 2013-04-23 21:52:51 +0000, (disabled) Jørgen Tjernø wrote:
On 2019-07-10 11:37:25 +0000, Sylvain wrote:
On 2019-07-11 11:26:52 +0000, Sylvain wrote:
On 2019-07-30 17:49:35 +0000, Ryan C. Gordon wrote:
On 2019-09-20 20:47:37 +0000, Ryan C. Gordon wrote:
On 2019-09-20 20:48:40 +0000, Ryan C. Gordon wrote:
On 2019-10-09 17:53:42 +0000, Ryan C. Gordon wrote:
On 2019-10-10 15:04:01 +0000, Sylvain wrote:
The text was updated successfully, but these errors were encountered: