2.0.4 bug wrap

Sylvain_Becker · July 21, 2014, 6:49am

Hello,

This is not a showstopper bug, but may be important : I notice events
1] in Android and IOS.

github.com/libsdl-org/SDL

Touch event coordinates not consistent between Android/IOS and X11

opened 11:23PM - 10 Feb 21 UTC

closed 11:23PM - 10 Feb 21 UTC

SDLBugzilla

# This bug report was migrated from our old Bugzilla tracker. These attachments… are available in the static archive: * [patch to normalize coordinates of touch event (patch_normalize_coordinates.diff, text/plain, 2013-12-16 21:03:27 +0000, 2762 bytes)](https://bugzilla.libsdl.org/attachment.cgi?id=1498) * [patch logical size touch event (patch_logical_size_touch_event.diff, text/plain, 2014-07-20 11:03:28 +0000, 1151 bytes)](https://bugzilla.libsdl.org/attachment.cgi?id=1779) **Reported in version:** HG 2.1 **Reported for operating system, platform:** Linux, x86_64 # Comments on the original bug report: On 2013-12-14 22:38:40 +0000, Sylvain wrote: > Hello, > > On Android and IOS, it seems touch event coordinates are within [0; 1] > whereas, with X11, it seems to be in pixels. (0,0) is the upper left corner of the window. > > It would be nice to have a generic convention (whatever the convention !) > > I wanted to submit a patch modifying the X11 stuff, but : > > In the X11_HandleXinput2Event, the "xevent.xany.xwindow" has not match in the list of "videodata->windowlist[i]". > > Something like this is ok with exactly 1 window: > > int window_w, window_h; > SDL_WindowData *data = videodata->windowlist[0]; > SDL_GetWindowSize(data->window, &window_w, &window_h); > > then dividing when sending the events : > > xev->event_x / (float) window_w > xev->event_y / (float) window_h > > > Maybe : > - making rect intersection is maybe too much processing for only touch events ... > - what would happen with 2 or more windows ? > - what would happen with 0 window :) On 2013-12-16 13:43:46 +0000, Gabriel Jacobo wrote: > XIDeviceEvent has a "Window event" member, doesn't that one match the SDL_WindowData.xwindow member? > > You'd also probably need to crop coordinates in addition to scaling them (substract window.x and window.y from event_x and event_y). > > Also: http://www.x.org/releases/X11R7.7/doc/inputproto/XI2proto.txt > > Section "Touch device modes" (roughly absolute vs relative coordinates) should be taken into account, I don't think it is right now. On 2013-12-16 21:03:27 +0000, Sylvain wrote: > Created attachment 1498 > patch to normalize coordinates of touch event On 2013-12-16 21:10:53 +0000, Sylvain wrote: > Indeed, the "window event" did the trick ! > So, here's a (temporary) patch to normalize the coordinates. > > > I am having a look at the "Touch device modes". You are right, the "mode" field is not used by SDL. I can write something for that ! On 2013-12-17 01:37:23 +0000, Gabriel Jacobo wrote: > I think you also need to consider the window offset (x,y coordinates) when normalizing the touch coordinates. On 2013-12-17 07:35:54 +0000, Sylvain wrote: > No, the (event_x, event_y) coordinates are relative to the upper left corner of the window. So (0, 0) *is* the upper left corner. > > > which is ok with the documentation you pointed : > --------- > [[events-deviceevent]] > ... > event_x > event_y > The position of the pointer in screen coordinates relative to the > event window (16.16 fixed point). > --------- > > > Notice that the event may belong to a Window and be outside of it (for instance, when start touching inside a window, then going outside of it). > It leads to coordinates <0 or >1 when the touch is outside the window. On 2014-07-11 01:43:44 +0000, Alex Szpakowski wrote: > That doesn't match the behaviour of some other operating systems. > In OS X, the positions of the touch events are in the coordinate space of the touch device, rather than the SDL window. That means the coordinates are always within [0; 1] no matter what, and if for example the touch device is a trackpad, (0, 0) will be sent if I touch the top-left corner of the trackpad. On 2014-07-16 06:32:21 +0000, Sylvain wrote: > I am fine with any solution as long as this is generic/uniform for all platforms :) > > > What's your trackpad? I have a laptop with a trackpad and it behaves exactly like a mouse on linux. I have no difference with the mouse. But maybe this is because I don't explicitly open the touch device! > > > Also, what I think of the issue is that coordinates could be expressed in at least three different reference frames. > > raw frame: > example: > - coordinates of the mouse within the screen (screens?) (like global mouse state ?) > - coordinates of the finger within the screen(s). > - coordinates within a hardware tablet. > ... > > window frame: > - coordinates translated to the window (if any!). > > renderer (logical) frame: > - coordinates converted to the renderer frame (also if any, and also maybe several renderer could be attached to the same window). > > > Also: > For each frame, the coordinates could be relative or not. I mean scaled to be expressed within [0; 1]. So that [0; 1]x[0; 1] matches the frame boundaries. > > Also: > In some (corner) case, it seems possible to have the focus on one Window, and the finger going outside that window without losing focus. The window is still capturing the event (which is fine). So events should not be truncated to the window/renderer boundaries. > > > My point of view is that only the renderer frame matters :). But this is because I am using the SDL renderer, and I know this is possible not to use it. And also not to use window at all. > > Maybe: > we should only provide raw coordinates? > Had function(hint) for always converting the coordinates to Window Frame? > Had function(hint) for always converting the coordinates to Rendered Frame? > > Or to make this implicit like : if we have a window we convert to window frame, and if we have a renderer, we convert to renderer frame. (This seems this is the case currently?) > > Maybe a boolean inside the event structure to tell if the coordinates are within [0; 1] or not? > Maybe an enum to tell if the coordinate are in Raw, Window or Renderer frame? On 2014-07-20 11:03:28 +0000, Sylvain wrote: > Created attachment 1779 > patch logical size touch event > > In addition, here's a patch, to have the fingertouch event scaled to renderer logical size. On 2014-07-24 04:21:26 +0000, Alex Szpakowski wrote: > I believe the most sensible option (and the one which matches the behaviour of SDL on other operating systems) is to make touchscreen events local to the window (i.e. (0, 0) at the top left of the window's inner frame), and touch device events which don't have a screen local to the device ((0, 0) at the top left of the device.) Touch screen events shouldn't be sent if the finger is outside of the SDL window. > > Whether touch events in general should be affected by a SDL_Renderer is outside the scope of this issue, I think. You could make a new one for that! On 2014-07-24 06:36:27 +0000, Sylvain wrote: > - With this patch the event are local to the window! (0, 0) is the top-left corner. > - They are within [0; 1] (that's the point of the patch, which only affects X11 / Xinput2!). > > (but they still can be outside the windows as it was possible before). > > > Sorry, but I am not sure to understand your issues. > Also, what is the "trackpad" you are talking about ? On 2017-10-12 07:08:43 +0000, Sylvain wrote: > duplicate of bug 3871 On 2017-10-12 15:38:26 +0000, Sam Lantinga wrote: > The touch coordinate normalization is in: > https://hg.libsdl.org/SDL/rev/d94abaa07d8e > > Thanks!

There is a patch to convert them to [0; 1] on X11. (note: it might
break some trackpad)
And also a patch to convert the fingertouch coordinates to the Logical
Render size, if needed. (I haven’t tested it on android, but I will do
it).

Patches are tested to be working on linux/x11.

The idea is that there are more and more touch-screens on desktops,
laptops and that it would be better if the same events on different
platform were using the same convention.

Cheers,
Sylvainfrom my touch-screen were in pixels, whereas there were scaled to [0;

On Tue, Jul 15, 2014 at 6:23 PM, Sam Lantinga wrote:

Hey everyone, we’d like to release 2.0.4 early next month.

Please try out the latest snapshot and report any regressions to
bugzilla.libsdl.org:
http;//www.libsdl.org/tmp/SDL-2.0.zip

If you have long standing or showstopper bugs that you’d like addressed,
please reply to this thread with a link to a bug report. If there isn’t a
patch already hopefully the community will jump on and take a look.

Cheers!

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
Sylvain Becker

Leonardo_Guilherme · July 21, 2014, 3:26pm

Hello,

I’d like to see bug SDL_RenderSetClipRect doesn't work properly when use SDL_RenderSetLogicalSize · Issue #1245 · libsdl-org/SDL · GitHub fixed.
It is a showstopper to anyone who uses logical size and clipping rectangle
as it doesn’t consider the logicalsize x/y when set. Everytime black bars
are needed (desired ratio != screen ratio), the clipping rectangle gets
misplaced.

I wrote a patch for the OpenGL(ES(2)) renderer (which is attached to the
bug), but I couldn’t test if DirectX renderers has the same problem.

2014-07-21 3:49 GMT-03:00 Sylvain Becker <sylvain.becker at gmail.com>:> Hello,

This is not a showstopper bug, but may be important : I notice events
from my touch-screen were in pixels, whereas there were scaled to [0;
1] in Android and IOS.

Touch event coordinates not consistent between Android/IOS and X11 · Issue #1279 · libsdl-org/SDL · GitHub

There is a patch to convert them to [0; 1] on X11. (note: it might
break some trackpad)
And also a patch to convert the fingertouch coordinates to the Logical
Render size, if needed. (I haven’t tested it on android, but I will do
it).

Patches are tested to be working on linux/x11.

The idea is that there are more and more touch-screens on desktops,
laptops and that it would be better if the same events on different
platform were using the same convention.

Cheers,
Sylvain

On Tue, Jul 15, 2014 at 6:23 PM, Sam Lantinga wrote:

Hey everyone, we’d like to release 2.0.4 early next month.

Please try out the latest snapshot and report any regressions to
bugzilla.libsdl.org:
http;//www.libsdl.org/tmp/SDL-2.0.zip

If you have long standing or showstopper bugs that you’d like addressed,
please reply to this thread with a link to a bug report. If there isn’t a
patch already hopefully the community will jump on and take a look.

Cheers!

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
Sylvain Becker

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

meklu · July 21, 2014, 7:45pm

Hey,

the software renderer most definitely has the same issue, as well as some
others of its own:

github.com/libsdl-org/SDL

Problems with software renderer when SDL_SetRenderLogicalSize set

opened 11:42PM - 10 Feb 21 UTC

closed 11:42PM - 10 Feb 21 UTC

SDLBugzilla

# This bug report was migrated from our old Bugzilla tracker. These attachments… are available in the static archive: * ~~[Example showing the problem (sdl_software_renderer_logical_size_problems.cpp, text/x-c++src, 2014-07-16 10:40:08 +0000, 3914 bytes)](https://bugzilla.libsdl.org/attachment.cgi?id=1761)~~ * ~~[Example showing the problem (sdl_software_renderer_logical_size_problems.cpp, text/x-c++src, 2014-07-16 11:50:54 +0000, 3928 bytes)](https://bugzilla.libsdl.org/attachment.cgi?id=1762)~~ * [Screenshot of bug (bug.png, image/png, 2014-07-16 11:52:11 +0000, 17873 bytes)](https://bugzilla.libsdl.org/attachment.cgi?id=1763) * ~~[SetLogicalSize patch (sdl-sw-logicalsize.patch, text/plain, 2014-07-17 10:49:05 +0000, 7756 bytes)](https://bugzilla.libsdl.org/attachment.cgi?id=1767)~~ * ~~[Example showing the problem (sdl_software_renderer_logical_size_problems.cpp, text/plain, 2014-07-17 11:49:09 +0000, 3949 bytes)](https://bugzilla.libsdl.org/attachment.cgi?id=1769)~~ * ~~[SetLogicalSize patch - v2 (sdl-sw-logicalsize.patch, text/plain, 2014-07-18 21:02:38 +0000, 8402 bytes)](https://bugzilla.libsdl.org/attachment.cgi?id=1774)~~ * [Example showing the problem (sdl_software_renderer_logical_size_problems.cpp, text/x-c++src, 2014-07-18 22:33:42 +0000, 4026 bytes)](https://bugzilla.libsdl.org/attachment.cgi?id=1775) * ~~[SetLogicalSize patch - v3 (sdl-sw-logicalsize.patch, text/plain, 2014-07-18 23:04:33 +0000, 8418 bytes)](https://bugzilla.libsdl.org/attachment.cgi?id=1776)~~ * [SetLogicalSize patch - v4 (sdl-sw-logicalsize.patch, text/plain, 2014-07-19 16:52:45 +0000, 7878 bytes)](https://bugzilla.libsdl.org/attachment.cgi?id=1777) * ~~[Patch for current SDL2 version (patch_for_2646.diff, text/plain, 2016-04-03 00:33:50 +0000, 754 bytes)](https://bugzilla.libsdl.org/attachment.cgi?id=2405)~~ * [SetLogicalSize patch - v5 (SetLogicalSize patch - v5.diff, text/plain, 2016-04-03 00:44:32 +0000, 1230 bytes)](https://bugzilla.libsdl.org/attachment.cgi?id=2406) **Reported in version:** HG 2.0 **Reported for operating system, platform:** Linux, x86_64 # Comments on the original bug report: On 2014-07-16 10:40:08 +0000, Damian Kaczmarek wrote: > Created attachment 1761 > Example showing the problem > > When SDL_RenderSetLogicalSize is set the behavior of software renderer is buggy: > > Couple of problems: > 1) Weird software renderer texture contraption while rendering textures on edges > 2) Software renderer does not add black borders at all which makes it not viable to use with resizeable windows at all. > > Also there is an accidentally discovered problem with black borders on hardware renderer - see Hardware window # 2 in the demo > > > Note: requires latest HG since the test is based on other bugs being fixed > > > Compile and run with: > g++ sdl_software_renderer_logical_size_problems.cpp -lSDL2 && ./a.out On 2014-07-16 11:50:54 +0000, Damian Kaczmarek wrote: > Created attachment 1762 > Example showing the problem On 2014-07-16 11:52:11 +0000, Damian Kaczmarek wrote: > Created attachment 1763 > Screenshot of bug On 2014-07-17 10:49:05 +0000, Melker Narikka wrote: > Created attachment 1767 > SetLogicalSize patch > > (Note that this patch also includes patches 1754 and 1755 from bug # 2198.) > > This patch seems to fix the behaviour of the test case. > > I also added these lines to the test case after the RenderCopy call to > test the RenderCopyEx clipping (which this patch addresses as well): > > SDL_SetTextureColorMod(semiTransparentTexture, 255, 0, 255); > SDL_RenderCopyEx(renderer, semiTransparentTexture, &a, &b, 45.0, NULL, SDL_FLIP_NONE); > SDL_SetTextureColorMod(semiTransparentTexture, 255, 255, 255); On 2014-07-17 11:49:09 +0000, Damian Kaczmarek wrote: > Created attachment 1769 > Example showing the problem > > Updated test case to show problems when rendering the texture at x < 0 On 2014-07-18 21:02:38 +0000, Melker Narikka wrote: > Created attachment 1774 > SetLogicalSize patch - v2 > > Here's an updated patch that should work, mostly at the very least. There's a weird offset issue with this patch with RenderCopyEx and rotated surfaces though, where I'm getting results that are (1px, 2px) off. This might be due to lossy integer arithmetic. On 2014-07-18 22:21:52 +0000, Damian Kaczmarek wrote: > Thanks for the latest patch. It is much better but I still find a lot of issues .. need to think how to update the test code. On 2014-07-18 22:33:42 +0000, Damian Kaczmarek wrote: > Created attachment 1775 > Example showing the problem > > Two problems, first see the difference of rendering at the beginning of the rendering code. The rectangle is displayed well .. kind of shifted at the beginning. Second problem is triggered by playing with the size of the window with the mouse, lots of artifacts are being created when resizing the software windows with the mouse. On 2014-07-18 23:04:33 +0000, Melker Narikka wrote: > Created attachment 1776 > SetLogicalSize patch - v3 > > I was supposed to make the if/elif/else blocks if+if/else. Hmm, here I thought I had done just that. Anyway, that addresses the shifted rectangle issue, which was caused by ignoring some fairly important offsets when the rectangle was rendered at negative coordinates. > > As for the visual artifact issue, I think that's due to not clearing the renderer between frames. I'm getting some really nasty window damage when resizing the hardware-backed renderer[1]. Curiously enough, the software renderer doesn't do this on my system... > Is this similar to what you're seeing? > > [1] http://i.imgur.com/9tBag9t.png On 2014-07-18 23:11:49 +0000, Damian Kaczmarek wrote: > I confirm the newest patch fixes the shift. For me hardware renderer works properly and only software leaves the window damage [1] I am using NVIDIA blob drivers. > > [1] http://x.rushbase.net/ebb4c6f9a824f424944497e1f78572b560f13c7e/damage.png On 2014-07-19 16:52:45 +0000, Melker Narikka wrote: > Created attachment 1777 > SetLogicalSize patch - v4 > > Here's an updated patch with some silliness removed. Should behave identically to v3. On 2016-04-03 00:33:50 +0000, Roberto Prieto wrote: > Created attachment 2405 > Patch for current SDL2 version > > Minimum patch file for fixing this bug on current SDL2 version (as of 29-March-2016), based on SetLogicalSize patch - v4 On 2016-04-03 00:44:32 +0000, Roberto Prieto wrote: > Created attachment 2406 > SetLogicalSize patch - v5 > > (Now with the right format) > > Minimum patch file for fixing this bug on current SDL2 version (as of 29-March-2016), based on SetLogicalSize patch - v4. > > It passed the example attached to this bug report and the issues I found during my developement. > > Many thanks to the original author (Melker Narikka)!!! > > Cheers > Roberto On 2017-08-14 05:50:41 +0000, Sam Lantinga wrote: > Fixed, thanks! > https://hg.libsdl.org/SDL/rev/42b62c737891

The patch there handles this by getting the intersecting rectangle of the
viewport and the clipping rectangle.

I’d say there’s a good chance that this needs to be done for (at least some
of) the other renderers as well, although
I haven’t checked the code.

Also, should the user be expected to clear the renderer to get neat black
bars, or should that be handled implicitly by
the renderer? Different configurations produce different results in regards
to the behaviour of the unrendered area, especially when resizing.
On my Intel/Mesa laptop, the software renderer (with the patch from the bug
report) will render the black boxes reliably,
yet produces garbage with the OpenGL renderer. On my desktop with the
nVidia blob, however, the behaviour is inverse:
the software renderer produces lots of garbage, but the OpenGL equivalent
shows none. This is with the same shared library on both machines.–
Melker Narikka

On Mon, Jul 21, 2014 at 6:26 PM, Leonardo Guilherme < leonardo.guilherme at gmail.com> wrote:

Hello,

I’d like to see bug SDL_RenderSetClipRect doesn't work properly when use SDL_RenderSetLogicalSize · Issue #1245 · libsdl-org/SDL · GitHub
fixed. It is a showstopper to anyone who uses logical size and clipping
rectangle as it doesn’t consider the logicalsize x/y when set. Everytime
black bars are needed (desired ratio != screen ratio), the clipping
rectangle gets misplaced.

I wrote a patch for the OpenGL(ES(2)) renderer (which is attached to the
bug), but I couldn’t test if DirectX renderers has the same problem.

meklu · July 24, 2014, 1:35pm

Hey!

I’d really appreciate it if this were merged, since it’s been sitting idly
by for a good while:
https://bugzilla.libsdl.org/show_bug.cgi?id=2343--
Melker Narikka

On Tue, Jul 15, 2014 at 7:23 PM, Sam Lantinga wrote:

Hey everyone, we’d like to release 2.0.4 early next month.

Please try out the latest snapshot and report any regressions to
bugzilla.libsdl.org:
http;//www.libsdl.org/tmp/SDL-2.0.zip

If you have long standing or showstopper bugs that you’d like addressed,
please reply to this thread with a link to a bug report. If there isn’t a
patch already hopefully the community will jump on and take a look.

Cheers!

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

slime · July 30, 2014, 5:33pm

A crash bug on OS X was introduced since 2.0.3?s release, it?d be great to get that fixed before 2.0.4 goes live: Mac: SDL_DestroyWindow crashes if the window is FULLSCREEN_DESKTOP and has a large windowed-mode size · Issue #1587 · libsdl-org/SDL · GitHub

At the very least it would be good to get more eyes on the issue so we can come up with a usable fix.

I also have a small patch to fix compilation when SDL_syswm.h is included in modern Objective-C (or Objective-C++) code on OS X and iOS: https://bugzilla.libsdl.org/show_bug.cgi?id=2641On Jul 15, 2014, at 1:23 PM, Sam Lantinga wrote:

Hey everyone, we’d like to release 2.0.4 early next month.

Please try out the latest snapshot and report any regressions to bugzilla.libsdl.org:
http;//www.libsdl.org/tmp/SDL-2.0.zip

If you have long standing or showstopper bugs that you’d like addressed, please reply to this thread with a link to a bug report. If there isn’t a patch already hopefully the community will jump on and take a look.

Cheers!

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

icculus · July 30, 2014, 6:16pm

This one is in, thank you. I’ll take a look at reproducing the other issue.

–ryan.On 7/30/14, 1:33 PM, Alex Szpakowski wrote:

A crash bug on OS X was introduced since 2.0.3?s release, it?d be great
to get that fixed before 2.0.4 goes live:
[…snip…]
I also have a small patch to fix compilation when SDL_syswm.h is
included in modern Objective-C (or Objective-C++) code on OS X and iOS:
[Patch] Mac/iOS: SDL_SysWMinfo struct can't be created in ObjC files which use ARC · Issue #1563 · libsdl-org/SDL · GitHub

Alvin_Beach · July 30, 2014, 7:28pm

If this bug [PATCH] X11: SDL tries (and fails) to hide foreign windows · Issue #1444 · libsdl-org/SDL · GitHub could be
addressed prior to releasing 2.0.4 it would be great. It’s certainly
not a show stopper though! It has a couple of patches that could fix
the issue. I am willing to make any corrections, test and submit new
patches if that makes it easier.On Tue, Jul 15, 2014 at 1:23 PM, Sam Lantinga wrote:

Hey everyone, we’d like to release 2.0.4 early next month.

Please try out the latest snapshot and report any regressions to
bugzilla.libsdl.org:
http;//www.libsdl.org/tmp/SDL-2.0.zip

If you have long standing or showstopper bugs that you’d like addressed,
please reply to this thread with a link to a bug report. If there isn’t a
patch already hopefully the community will jump on and take a look.

Cheers!

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

soulz · July 31, 2014, 4:50pm

If this bug Windows: SDL_GetWindowSize report wrong value after Fullscreen -> Window toggle. · Issue #1588 · libsdl-org/SDL · GitHub could be
addressed prior to releasing 2.0.4 it would be great.

I’ve attached a suggested patch for it.

Cheers,On Tue, Jul 15, 2014 at 09:23:56AM -0700, Sam Lantinga wrote:

Hey everyone, we’d like to release 2.0.4 early next month.

Please try out the latest snapshot and report any regressions to
bugzilla.libsdl.org:
http;//www.libsdl.org/tmp/SDL-2.0.zip

If you have long standing or showstopper bugs that you’d like addressed,
please reply to this thread with a link to a bug report. If there isn’t a
patch already hopefully the community will jump on and take a look.

Cheers!

–
Regards,
Andreas

Phil_Hassey · July 31, 2014, 5:02pm

I’ve submitted patches for two iOS bugs. ?I’d appreciate if these were reviewed for 2.0.4.

https://bugzilla.libsdl.org/show_bug.cgi?id=2661?-?Screen size incorrect when changing orientations and resuming
[patch] SDL_IsScreenKeyboardShown doesn't respond to keyboard being dismissed · Issue #1581 · libsdl-org/SDL · GitHub - SDL_IsScreenKeyboardShown doesn’t respond to keyboard being dismissed?

Both patches are short and simple.

Thanks!
-PhilOn Thursday, July 31, 2014 10:50 AM, Andreas wrote:

On Tue, Jul 15, 2014 at 09:23:56AM -0700, Sam Lantinga wrote:

Hey everyone, we’d like to release 2.0.4 early next month.

Please try out the latest snapshot and report any regressions to
bugzilla.libsdl.org:
http;//www.libsdl.org/tmp/SDL-2.0.zip

If you have long standing or showstopper bugs that you’d like addressed,
please reply to this thread with a link to a bug report. If there isn’t a
patch already hopefully the community will jump on and take a look.

Cheers!

If this bug Windows: SDL_GetWindowSize report wrong value after Fullscreen -> Window toggle. · Issue #1588 · libsdl-org/SDL · GitHub could be
addressed prior to releasing 2.0.4 it would be great.

I’ve attached a suggested patch for it.

Cheers,

–
Regards,
Andreas

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

timmcd · July 31, 2014, 9:50pm

A couple of important issues that should really be addressed:

https://bugzilla.libsdl.org/show_bug.cgi?id=2650

https://bugzilla.libsdl.org/show_bug.cgi?id=2655

Cheers

tehcloud · August 5, 2014, 9:44pm

Seems to be broken on OpenBSD 5.5 right now. I just tried to compile SDL from hg:> Warning, configure.in is out of date

#(cd /root/SDL && sh autogen.sh && sh configure)
/bin/sh build-scripts/updaterev.sh
CC build/SDL_render_gl.lo
In file included from include/SDL_opengl.h:80,
from /root/SDL/src/render/opengl/SDL_render_gl.c:28:
include/SDL_opengl_glext.h:412: error: redefinition of typedef ‘PFNGLBLENDCOLORPROC’
/usr/X11R6/include/GL/gl.h:1739: error: previous declaration of ‘PFNGLBLENDCOLORPROC’ was here
include/SDL_opengl_glext.h:413: error: redefinition of typedef ‘PFNGLBLENDEQUATIONPROC’
/usr/X11R6/include/GL/gl.h:1740: error: previous declaration of ‘PFNGLBLENDEQUATIONPROC’ was here
/root/SDL/src/render/opengl/SDL_render_gl.c: In function ‘GL_CreateRenderer’:
/root/SDL/src/render/opengl/SDL_render_gl.c:493: warning: dereferencing type-punned pointer will break strict-aliasing rules
/root/SDL/src/render/opengl/SDL_render_gl.c: In function ‘GL_RenderDrawLines’:
/root/SDL/src/render/opengl/SDL_render_gl.c:1127: warning: declaration of ‘y1’ shadows a global declaration
/usr/include/math.h:233: warning: shadowed declaration is here
Makefile:399: recipe for target ‘build/SDL_render_gl.lo’ failed
gmake: *** [build/SDL_render_gl.lo] Error 1

Robotic-Brain · August 9, 2014, 7:27pm

I would like to see https://bugzilla.libsdl.org/show_bug.cgi?id=2655
merged in, since it fixes several issues with the OSX coordinate system

Sik_the_hedgehog · August 10, 2014, 1:27pm

Ugh, not again /o
https://bugzilla.libsdl.org/show_bug.cgi?id=1658#c4

Alex_Baines · August 10, 2014, 1:41pm

There are some patches at
https://bugzilla.libsdl.org/show_bug.cgi?id=2662 that could be good to
review & include before the release.

Alex.

Luke_Groeninger · August 13, 2014, 6:17am

I actually just ran into this bug in 2.0.3:

github.com/libsdl-org/SDL

SDL_GetWindowPosition() always returns (0, 0) in fullscreen

opened 11:05PM - 10 Feb 21 UTC

closed 11:05PM - 10 Feb 21 UTC

SDLBugzilla

# This bug report was migrated from our old Bugzilla tracker. **Reported in ver…sion:** HG 2.0 **Reported for operating system, platform:** All, x86_64 # Comments on the original bug report: On 2013-08-31 23:35:42 +0000, Daniel Gibson wrote: > When I have a window on my second (right) screen, the position I get from SDL_GetWindowPosition() is something like (2151, 276), as I would expect - my first (left) screen has a resolution of 1920x1200, so the screen right of it should start with x=1920. > > SDL_GetWindowPosition however always returns (0,0) as Window position, which is also quite obvious from the implementation: > "if (window->flags & SDL_WINDOW_FULLSCREEN)" it just sets x and y to 0, because > "/* Fullscreen windows are always at their display's origin */" > > This is of course inconsistent: In windowed mode the function returns a global (across all displays) coordinate, but in fullscreen mode the coordinate on the display it's on.. I guess this is a SDL1.2 leftover? > > SDL_Window.x and .y contained the expected values (1920, 0), by the way, so at least on my platform (Linux/X11/xrandr) always returning those would be correct. > > By the way, SDL_GetWindowBounds(SDL_Window*, SDL_Rect*) that works analogous to SDL_GetDisplayBounds() would be nice :) On 2013-08-31 23:38:34 +0000, Daniel Gibson wrote: > (In reply to Daniel Gibson from comment # 0) > > SDL_GetWindowPosition however always returns (0,0) as Window position, which > > is also quite obvious from the implementation: > > This should have been "In fullscreen mode SDL_GetWindowPosition() however always returns (0,0) as Window position, ..." On 2015-09-13 04:09:50 +0000, Alex Szpakowski wrote: > This should be fixed with this commit: https://hg.libsdl.org/SDL/rev/cfeb59daba69

Certainly not critical, but it would be useful if this behaved consistently
with the rest of the API.On Sun, Aug 10, 2014 at 7:41 AM, Alex Baines wrote:

There are some patches at
A few small issues with the Ibus IME code · Issue #1583 · libsdl-org/SDL · GitHub that could be good to
review & include before the release.

Alex.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

snake5 · August 13, 2014, 8:07am

This bug is somewhat critical for certain countries/keyboard layouts (probably not the biggest ones though): https://bugzilla.libsdl.org/show_bug.cgi?id=2455

There is no patch because even though the issue is extremely simple to fix (either TranslateMessage is removed and its behavior reproduced fully or ToUnicode is replaced with WM_CHAR handling), there’s the problem of me not knowing if either fix would break something. The original author of the change clearly had something in mind when WM_CHAR handling was partially replaced with ToUnicode and the related code, and if I could know what that was, I would most likely be able to make a patch myself.------------------------
SGScript scripting engine (http://www.sgscript.org)

icculus · August 22, 2014, 3:03am

You should need the ibus header file (from a package like libibus-dev),
a kernel compiled with inotify support (which you most likely have),
and also to compile SDL with DBus support (which should happen by default).

libibus-dev is installed on the Linux buildbots (as of right now), so
we’ll get some basic coverage on this code now.

–ryan.

icculus · August 22, 2014, 3:10am

I just fixed this a day or two ago, making the FreeBSD and OpenBSD
buildbots happy again. If this is still giving you trouble, please let
me know!

–ryan.On 8/5/14, 5:44 PM, tehcloud wrote:

Seems to be broken on OpenBSD 5.5 right now. I just tried to compile SDL
from hg:

RodrigoCard · August 25, 2014, 8:00pm

this one https://bugzilla.libsdl.org/show_bug.cgi?id=2704
an edge case, but not that uncommon (as you see, I found another person who had the same problem)
as people tend to have gamepads of the same brand, I think…------------------------
Rodrigo Cardoso Rocha
@RodrigoRodrigoR - twitter.com/RodrigoRodrigoR
Chibata Creations - chibatacreations.com

Eric_Wasylishen · September 15, 2014, 6:20pm

Hi,
Wondering if anyone else could try reproducing this: https://bugzilla.libsdl.org/show_bug.cgi?id=2713

SDL_WINDOW_FULLSCREEN produces a cropped window on Windows 8 w/ DPI scaling on above 100%. The test case is easy, just set 150% scaling in Windows settings, log out and log back in, run testgl2 included with SDL’s source, and press Ctrl+Enter to go fullscreen, and the drawing will be off-center.

Would be interested if it is just my computer or happens on other versions of Windows too.

Thanks,
Eric