Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

SDL_GetMouseState always returns (0,0) before moving the mouse the first time #2303

Closed
SDLBugzilla opened this issue Feb 11, 2021 · 4 comments
Closed

SDL_GetMouseState always returns (0,0) before moving the mouse the first time #2303

SDLBugzilla opened this issue Feb 11, 2021 · 4 comments
Assignees
@slouken
Milestone
3.x

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: 2.0.8
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2016-11-11 14:28:47 +0000, Andre wrote:

Created attachment 2611
MWE

I have a problem with SDL_GetMouseState: I want to get the initial mouse coordinate before the user moves the mouse the first time, but the function only returns (0,0) regardless of the actual mouse position.

I have attached a MWE that shows my problem. The first line that is printed is always "init: 0, 0". I expected it to give the actual coordinates.

This behavior can be reproduced under Linux 2.28.2 with GNOME shell 3.22.1 and the X window system. It works fine under Windows 7.

How to reproduce:

Run my attached program. Then remember the position of the window. Close the program. Then move the mouse into the position where the window was created last time. Start the program again.

Now you can see that the initial call of SDL_GetMouseState always returns (0,0) although the mouse is somewhere else inside the window.

On 2018-04-10 04:38:40 +0000, Thums wrote:

I have the same problem, SDL_GetMouseState always returns (0,0) until the mouse is moved for the first time since the program was opened.

Tested on Arch Linux, kernel 4.15.14-1 under i3wm.

Calling SDL_PumpEvents before obtaining the mouse state changes nothing.
@slouken slouken removed the bug label May 11, 2022
@Svalorzen
Copy link

Hi, it seems I have the same issue; I compiled the example and the same happens on my system (Lubuntu 20.04). I discovered this issue as I was having a problem using the LOVE2d framework, that uses SDL under the hood.

Is this indeed not a bug or is it something else? Note that SDL_GetGlobalMouseState seems to work fine; the issue only happens when the window pops up under the cursor, and the cursor has not moved yet.

@slouken slouken added this to the 3.0 milestone Nov 21, 2022
@slouken slouken self-assigned this Nov 21, 2022
@slime73
Copy link
Contributor

slime73 commented Nov 21, 2022

Do you know which version of SDL you're using? (if you're using the love AppImage it should be a fairly recent version I think.) There was this other bug report #674 which had at least a partial fix committed in 2019: cf092ec

@Svalorzen
Copy link

Svalorzen commented Nov 21, 2022 •
edited

My local SDL library prints 2.0.10, I installed it using apt:

Package: libsdl2-dev
Version: 2.0.10+dfsg1-3
Priority: optional
Section: universe/libdevel
Source: libsdl2
Origin: Ubuntu

I guess that's before the patch? My LOVE2d is version 11.4, but as I also installed that using a package, it's likely that the SDL version used is the same..

At this point I might try to update my system to 22.04 and see what happens with the updated libsdl.

@slime73
Copy link
Contributor

slime73 commented Nov 21, 2022

Yeah it's probably just depending on the existing SDL package you have installed already (2.0.10), I'd try updating to the latest (2.24).

@slouken slouken closed this as completed Nov 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@slouken slouken

Labels
None yet
Projects
None yet
Milestone
3.x
Development

No branches or pull requests
4 participants
@slime73 @Svalorzen @slouken @SDLBugzilla