| Summary: | (Patch) More bits for SDL_MouseMotionEvent.state | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Gerry JJ <trick> |
| Component: | events | Assignee: | Sam Lantinga <slouken> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | enhancement | ||
| Priority: | P2 | ||
| Version: | HG 2.0 | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: | SDL_MouseMotionEvent 32-bit button state | ||
Good patch, thanks! http://hg.libsdl.org/SDL/rev/c74f5dbcfd23 |
Created attachment 1142 [details] SDL_MouseMotionEvent 32-bit button state The state bitmask in SDL_MouseMotionEvent is stored in an Uint8. Unfortunately this doesn't actually have room for 8 buttons because SDL skips 4 button indices after the third mouse button (at least here on Linux x86-64, probably related to wheel handling?), so it's really just enough to track 4 buttons. For example, on a Logitech MX310 mouse I've got, even though the mouse has 6 buttons total, the left and right side buttons and extra middle button have indexes 8, 9 and 10, and the last two won't fit in the 8 bit button state. The source of the button state (in SDL_Mouse) is already 32-bit, and the state field in SDL_MouseMotionEvent is 32-bit aligned and followed by three 8-bit padding fields. So simply changing the SDL_MouseMotionEvent state to an Uint32 and removing the padding fields fixes this, and I think it should be binary compatible, at least for little endian. Issues: - Not binary compatible for big endian =P - Is it ok to use all padding fields for this? (Maybe make it Uint16 instead?)