I made a patch for this bug that causes a “beep” sound every time Alt hotkeys are used in windowed Windows apps:https://bugzilla.libsdl.org/show_bug.cgi?id=2669
OSX: Removed joysticks wrongly marked as closed when they are not.
Just filed the bug with a patch included:https://bugzilla.libsdl.org/show_bug.cgi?id=2738
Cheers!------------------------@RodrigoRodrigoR - twitter.com/RodrigoRodrigoR chibatacreations.com
I’ve got a patch that would be nice to get in to 2.0.4:https://bugzilla.libsdl.org/show_bug.cgi?id=2718
It’s for an annoying bug on OS X where, if you Cmd+Tab away from an
I tested the fix on 10.6 and 10.10.
Thanks,
icculus
February 1, 2015, 6:08pm
47
I’ll try to get all these patches in today.
–ryan.On 02/01/2015 12:18 AM, RodrigoCard wrote:
Also, This one is just a simple fix to build SDL for OSX if HAPTIC isCant build without Haptic Support on OSX (includes patch) · Issue #1632 · libsdl-org/SDL · GitHub
Mouse Buttons X1/X2 don’t work as expected on Linux/X11 (don’t generate
opened 11:24PM - 10 Feb 21 UTC
closed 11:24PM - 10 Feb 21 UTC
duplicate
# This bug report was migrated from our old Bugzilla tracker.
These attachments… are available in the static archive:
* [Simple test to print the mouse button number (sdl_mousebuttontest.c, text/plain, 2015-01-27 17:31:53 +0000, 1470 bytes)](https://bugzilla.libsdl.org/attachment.cgi?id=2006)
**Reported in version:** 2.0.3
**Reported for operating system, platform:** Linux, x86_64
# Comments on the original bug report:
On 2013-12-16 12:12:02 +0000, Stijn van Drongelen wrote:
> See http://hg.libsdl.org/SDL/file/405d84eedad8/src/video/x11/SDL_x11events.c#l711:
>
> case ButtonPress:{
> int ticks = 0;
> if (X11_IsWheelEvent(display,&xevent,&ticks)) {
> SDL_SendMouseWheel(data->window, 0, 0, ticks);
> } else {
> SDL_SendMouseButton(data->window, 0, SDL_PRESSED, xevent.xbutton.button);
> }
> }
> break;
>
> case ButtonRelease:{
> SDL_SendMouseButton(data->window, 0, SDL_RELEASED, xevent.xbutton.button);
> }
> break;
>
> In the case of my own Logitech M570 mouse, which apparently has 20 buttons, X calls my "up" and "down" button 8 and 9. Because SDL blindly copies these IDs, the documentation of SDL_MouseButtonEvent.button ("may be one of SDL_BUTTON_*") is now meaningless. Users who depend on this to mean that button can only be one of those five values (e.g. the Haskell bindings for SDL2, a work in progress) will end up crashing.
>
> I suppose the documentation needs to reflect that .button may be something else than described in SDL_BUTTON_*.
On 2013-12-19 13:23:30 +0000, Turo Lamminen wrote:
> The behavior is also different between platforms. I have a Logitech MX518 with three extra buttons (back, forward and home). SDL 2.0.1 reports them as follows:
>
> Windows reports back & forward as 4 & 5 as documentation says. Home is not reported at all.
>
> Mac OS X 10.8 reports back & forward as 4 & 5 and home as 6. Documentation is misleading.
>
> Linux (Debian testing) reports back & forward as 8 & 9 and home as 10. Totally different from both documentation and also from other platforms.
On 2015-01-27 17:29:03 +0000, Daniel Gibson wrote:
> I can confirm this behavior, on both Linux Mint 17.1 KDE and Debian Wheezy with XFCE. Also with two different mice: Logitech MX518 and some cheap Gigabyte Mouse).
> I tested with SDL2 2.0 (I think) on Wheezy and 2.0.2 and latest HG (9319:ad4f430cc9f5) on Mint.
>
> Both report the "forward"/"back" buttons (aka X1 and X2) as 8 and 9.
> One additional button on the MX518 (zoom or something?) is reported as 10.
>
> I think it's an actual bug that X1 and X2 are not reported as SDL_BUTTON_X1 and SDL_BUTTON_X2 in the SDL_MouseButtonEvent.
>
> I have no idea why the "Importance" was set to "API change" - the API docs may be unclear on what happens when pressing a mouse button > X2, but documenting that wouldn't change/break the API - and neither would fixing this bug.
> Thus I changed it to "major".
>
> From the code it's not surprising that this happens: In
> SDL_x11events.c "static void X11_DispatchEvent(_THIS)", "case ButtonPress:"
> there is some mousewheel magic that I haven't looked closely at and then:
> SDL_SendMouseButton(data->window, 0, SDL_PRESSED, xevent.xbutton.button);
> (Similar for ButtonRelease)
>
> So the xevent.xbutton.button value is just used unchanged to generate the SDL event.
> But AFAIK X11 buttons 4 and 5 are used for horizontal scrolling and 6 and 7 for vertical scrolling - so it kinda makes sense that the next "real" (non-wheel) button gets the value 8.
> Not sure if X11 always assigns it like this or only with [XYZ]AxisMapping enabled...
>
> Apart from this problem, the documentation should indeed be more clear about SDL_MouseButtonEvent.button's value that can not only take the given constants but can be > SDL_BUTTON_X2 (I guess everything up to 32 or so should be ok for the SDL_BUTTON() macro/ SDL_GetMouseState()).
On 2015-01-27 17:31:53 +0000, Daniel Gibson wrote:
> Created attachment 2006
> Simple test to print the mouse button number
On 2015-02-01 13:08:23 +0000, Stijn van Drongelen wrote:
> > I have no idea why the "Importance" was set to "API change" - the API
> > docs may be unclear on what happens when pressing a mouse button >
> > X2, but documenting that wouldn't change/break the API - and neither
> > would fixing this bug. Thus I changed it to "major".
>
> In my opinion, updating the documentation of a C library does change
> the the API, because the documentation _is_ the API. There is nothing
> on the language level to give a complete and thorough description of
> the API, so you have to document it separately to even have an API
> in the first place.
>
> I don't mean to start a debate on "what is an API", but I think that
> I saw that importance tag a year ago and thought it was fitting for
> the reason stated above.
On 2015-02-01 18:44:07 +0000, Daniel Gibson wrote:
> Well, that is not completely unreasonable, but mapping the events to the existing SDL_BUTTON_X1/2 constants would at least fix most of this bug and comply with the API (in contrast to the current behavior).
>
> I can however imagine that the maintainers ignored this bug because they assumed this issue demanded breaking the API and didn't want to break the API anytime soon.
>
> In this particular case I'd prefer "API breakage" by mentioning that more buttons can be supported but just don't have predefined constants vs waiting for the next major API-breaking SDL release to support more than 5 buttons.
> Especially because the implementation already does that anyway and it doesn't change any function interfaces or anything.
On 2015-02-01 20:54:48 +0000, Luke wrote:
> Possible dupe here:
> https://bugzilla.libsdl.org/show_bug.cgi?id=2472
On 2015-02-02 07:50:22 +0000, Daniel Gibson wrote:
> Yeah, pretty sure it's the same bug.
On 2015-02-19 05:30:52 +0000, Ryan C. Gordon wrote:
>
> Marking this as a dupe of Bug # 2472 (which has more discussion, too).
>
> *** This bug has been marked as a duplicate of bug 2472 ***
Not sure if this is a showstopper, but I think it is bad and it would be
Cheers,
On 02/01/2015 12:18 AM, RodrigoCard wrote:
Also, This one is just a simple fix to build SDL for OSX if HAPTIC isCant build without Haptic Support on OSX (includes patch) · Issue #1632 · libsdl-org/SDL · GitHub
I’ll try to get all these patches in today.
–ryan.
SDL mailing listlists.libsdl.org http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
2015-02-01 15:22 GMT-03:00, Daniel Gibson :
Mouse Buttons X1/X2 don’t work as expected on Linux/X11 (don’t generatedescription for SDL_MouseButtonEvent.button is misleading · Issue #1282 · libsdl-org/SDL · GitHub is bad and it would be
Dunno, but I believe that X reports those two buttons as 8 and 9
Yeah, that’s what’s happening, but SDL should translate them to the
Cheers,
2015-02-01 15:22 GMT-03:00, Daniel Gibson <@Daniel_Gibson>:
Mouse Buttons X1/X2 don’t work as expected on Linux/X11 (don’t generatedescription for SDL_MouseButtonEvent.button is misleading · Issue #1282 · libsdl-org/SDL · GitHub is bad and it would be
Dunno, but I believe that X reports those two buttons as 8 and 9
Here’s one more: Patch for dead keys on Windows:
opened 11:53PM - 10 Feb 21 UTC
closed 11:53PM - 10 Feb 21 UTC
# This bug report was migrated from our old Bugzilla tracker.
These attachments… are available in the static archive:
* [SDL_windowevents.c patch to fix dead keys (dead-keys-fix.patch, text/plain, 2015-01-06 00:32:50 +0000, 1466 bytes)](https://bugzilla.libsdl.org/attachment.cgi?id=1984)
**Reported in version:** HG 2.1
**Reported for operating system, platform:** Windows 7, x86_64
# Comments on the original bug report:
On 2015-01-06 00:32:50 +0000, Elisée Maurer wrote:
> Created attachment 1984
> SDL_windowevents.c patch to fix dead keys
>
> When inputting text, dead-keys are currently not handled correctly on Windows with the latest SDL2 tip as well as the 2.0.3 release.
>
> Using a French AZERTY keyboard, when I type the `^` key followed by `e` key to compose the `ê` character, I erroneously get two SDL_TEXTINPUT events, one with the `^` character and one with the `e` character.
>
> I've looked at the history for SDL_windowsevents.c and there's been some back-and-forth with several methods for handling text input:
>
> * r8142 removed any handling of WM_CHAR because keyboard input was being handled through WM_KEYDOWN along with ToUnicode since r7645.
>
> * But using ToUnicode actually breaks dead-keys (googling for "ToUnicode dead keys" reports many horror stories of people trying to work around that and failing).
>
> * It seems like r7645 introduced a double-fix: it fixed WM_CHAR to properly handle Unicode, and also (unnecessarily?) added text input handling to WM_KEYDOWN. Later, r8142 removed the WM_CHAR stuff instead of the WM_KEYDOWN stuff.
>
> The attached patch restores handling of text input through WM_CHAR and removes it from WM_KEYDOWN. I've tested it with French, English and Russian layouts and it seems to do its job. Obviously, with such matters, it's still a risky change.
On 2015-02-10 09:50:10 +0000, wrote:
> *** Bug 2747 has been marked as a duplicate of this bug. ***
On 2015-02-17 22:55:59 +0000, wrote:
> Comment on attachment 1984
> SDL_windowevents.c patch to fix dead keys
>
> Shouldn't the conversion of the wParam in WM_CHAR be optional?
On 2015-02-19 11:44:37 +0000, Elisée Maurer wrote:
> Optional? Based on what?
On 2015-02-19 14:13:13 +0000, wrote:
> Well, for example the original jedi knight games pre-SDL used the raw wParam directly so that it could support other languages (Not full unicode) down the line. And I'm not sure if translating them to utf8 here will break that or not.
>
> https://github.com/JACoders/OpenJK/blob/master/codemp/win32/win_wndproc.cpp#L470
On 2015-02-21 13:59:23 +0000, Elisée Maurer wrote:
> Would any games developed with SDL2 still want to do anything other than Unicode these days? Maybe I didn't understand what you're suggesting.
On 2015-02-21 14:32:55 +0000, wrote:
> Of course there are, think of the many old games or source ports that use SDL. They would still be using char not wchar_t for compatibility.
On 2015-02-21 16:43:44 +0000, wrote:
> Maybe it will still work, I'm not sure. Just trying to keep the old compat with languages that the original JKA does support when this does get fixed in SDL2.
On 2015-02-21 18:45:09 +0000, Elisée Maurer wrote:
> Can you build SDL2 with the patch and try it with one of the games you think might break and report?
>
> Or are you concerned about possible future SDL2 ports? If that's the case, then IMHO it's best to worry about that when those ports do happen. The porter can ship their own build of the library (like I'm doing until this patch lands) and submit another patch to make the conversion optional if it is indeed required, right? It'd be premature to add some kind of way to switch now if there's no confirmed use case.
On 2015-02-22 03:26:35 +0000, wrote:
> Unfortunately I will not be able to do so, going to be on vacation for next couple of weeks. (I imagine this might be resolved by then?) Even so, I don't actually have hg, so unless there's a git mirror of the most up to date main repo I probably wouldn't even be able to do so anyway.
>
>
> Also, I am a US Keyboard user so I wouldn't be able to exactly test the Russian layouts etc other than windows-1252 alt codes.
On 2015-03-11 14:45:40 +0000, wrote:
> This does work in terms of fixing alt codes on Windows.
>
> Needs slight modification with recent patch to check return value of the convert function.
>
> I had someone say they still cannot input russian with it though. (We convert back to utf32 same as ioquake3)
On 2015-04-07 04:57:58 +0000, Ryan C. Gordon wrote:
>
> (sorry if you get a lot of copies of this email, I'm marking several bugs at once)
>
> Marking bugs for the (mostly) final 2.0.4 TODO list. This means we're hoping to resolve this bug before 2.0.4 ships if possible. In a perfect world, the open bug count with the target-2.0.4 keyword is zero when we ship.
>
> (Note that closing a bug report as WONTFIX, INVALID or WORKSFORME might still happen.)
>
> --ryan.
On 2015-05-28 16:04:33 +0000, Sam Lantinga wrote:
> Unicode text support has been fixed/broken so many times... This patch is how the code used to work, but there were bugs that caused us to change it to the current code.
>
> After 2.0.4 is released, let's hammer this out once and for all. We'll reopen all the Unicode text entry bugs, get everyone involved who can test it, and let them duke it out. :)
On 2015-06-25 18:58:48 +0000, Sam Lantinga wrote:
> Fixed, thanks!
> http://hg.libsdl.org/SDL/rev/02273530b7bf
>
> We tested Russian on Windows 7 and it worked here.
>
> We'll have to come back to bug 1876 with Khmer in the future.
(Off-topic: What’s up with the mailing list archive? I’ve posted about
-EthanOn 02/01/2015 01:08 PM, Ryan C. Gordon wrote:
I’ll try to get all these patches in today.
–ryan.
slime
February 1, 2015, 8:39pm
52
Oh, is it ?mob Ryan with patches? day? Very well.
In Linux, touch finger coordinates are in pixels rather than normalized to [0, 1] like they should be. Here?s a bugzilla, including a patch provided by someone: Touch event coordinates not consistent between Android/IOS and X11 · Issue #1279 · libsdl-org/SDL · GitHub
I made an improved workaround patch for the window-focus-on-close issues in OS X. It fixes the focus transfer when the ?About? window is closed: Mac: closing a window doesn't transfer focus to the next one · Issue #850 · libsdl-org/SDL · GitHub
Here?s a small patch to prefer modern APIs (when available) rather than deprecated ones for a couple cases in OS X: [Patch] Mac: update some internal code to use modern codepaths rather than deprecated functionality, when available · Issue #1750 · libsdl-org/SDL · GitHub
And of course my big iOS patch, which I expect will take more than a bit longer to look over: https://bugzilla.libsdl.org/show_bug.cgi?id=2798On Feb 1, 2015, at 2:08 PM, Ryan C. Gordon wrote:
I’ll try to get all these patches in today.
–ryan.
SDL mailing listlists.libsdl.org http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
If we’re all posting patches then here are a couple that would be good
"Fix Key and Textinput event order on X11 (issue introduced post-2.0.3)"https://bugzilla.libsdl.org/show_bug.cgi?id=2748
"X11+IBus: SDL2 should post SDL_TEXTEDITING when preedit is cancelled byhttps://bugzilla.libsdl.org/show_bug.cgi?id=2844
icculus
February 2, 2015, 6:55am
54
(Off-topic: What’s up with the mailing list archive? I’ve posted about
Dreamhost is having problems with it; not sure what specifically. It
The eventual goal is to move all this infrastructure off Dreamhost to
–ryan.
Also off topic:
I’m not very good with bugzilla, but it doesn’t seem very good as a
Just brainstorming, but would any of the following help the sdl dev process?
a policy that patches from outside contributors should be sent to a
a separate code review web app for posting patches
a new bug status in bugzilla, “please review” or “pull request” or something.
Cheers,
