Commit Graph

546 Commits

Author SHA1 Message Date
Sam Lantinga
834ab350e5 Fixed bug 3644 - Wayland touch event support
Moritz Bitsch

Attached is a small patch which enables multitouch events on Wayland.
2017-08-21 11:19:38 -07:00
Ryan C. Gordon
f5a38f234b x11: specify event mask for buttons when grabbing pointer (thanks, Stas!).
This fixes a strange corner case (notes appended below), and should be
safe to do anyhow.

Fixes Bugzilla #3674.

"I did more tests.
It appears the bug only happens if there is
another window on the screen that has "always
on top" property. For me it is xawtv - it is
always opened in a screen corner. Closing
xawtv or removing "always on top" property
from it makes the problem to go away.
Plus, it doesn't appear like the buttons are
not delivered at all. It appears that instead
the button presses are delivered on some mouse
positions, but not delivered when you move the
mouse to other part of the window... So this is
really weird and is likely somewhere deep in the
Xorg.
Maybe somehow it happens that the cursor is
actually above the xawtv window, but, because
my app uses grab, it is not visible there, and
in that case the events are not delivered to
my app?
But with my patch the button events are
always delivered flawlessly, it seems.

Hmm, and that indeed seems to explain my problem:
if the mask is set properly and my app uses
grab, then, even if the mouse is above some
other window, the events would still be delivered
to the grabbing app, which is what actually wanted
because my app uses relative mouse mode, so it
doesn't know the pointer can cross some other window
(my app draws the pointer itself).
So my current theory is that my patch only enforces
the mouse grab, which otherwise can be tricked by
some other window preventing the button events
delivery (but motion events are still delivered
via xinput2, which makes it all look very obscure)."
2017-08-21 00:42:06 -04:00
Ryan C. Gordon
5574b43376 x11: Pass generic XEvents by pointer instead of copying to stack for XInput2. 2017-07-31 12:22:18 -04:00
Ryan C. Gordon
01e0d8fc85 opengl: Add support for [GLX|WGL]_ARB_create_context_robustness.
This patch was originally written by Marc Di Luzio for glX and enhanced by
Maximilian Malek for WGL, etc. Thanks to both of you!

Fixes Bugzilla #3643.
Fixes Bugzilla #3735.
2017-08-19 15:02:03 -04:00
Alex Szpakowski
3d0f521be5 iOS 10: Work around screen bounds orientation bug. Fixes bugs #3465 and #3505. 2017-08-18 23:23:30 -03:00
Alex Szpakowski
a0a09f646c Improve iOS keyboard demo code a bit. 2017-08-15 22:53:57 -03:00
Alex Szpakowski
2e4248ed44 Address a compiler warning. 2017-08-15 18:29:47 -03:00
Sam Lantinga
e83764a5e0 Fixed bug 2137 - SDL Message Boxes don't cope with fixed width fonts (in windows at least)
Pegasus Epsilon

With the system dialog font set to Arial or Tahoma or another variable-width font, everything works just as expected. When using a fixed-width font, like Courier or DejaVu Sans Mono, the text gets cut off. Example screenshots attached.
2017-08-14 23:45:06 -07:00
Sam Lantinga
1d0584d558 Hopefully fixed Wayland build 2017-08-14 21:35:16 -07:00
Sam Lantinga
a4cfa93670 Fixed bug 2293 - Precise scrolling events
Martijn Courteaux

I implemented precise scrolling events. I have been through all the folders in /src/video/[platform] to implement where possible. This works on OS X, but I can't speak for others. Build farm will figure that out, I guess. I think this patch should introduce precise scrolling on OS X, Wayland, Mir, Windows, Android, Nacl, Windows RT.

The way I provide precise scrolling events is by adding two float fields to the SDL_MouseWheelScrollEvent datastructure, called "preciseX" and "preciseY". The old integer fields "x" and "y" are still present. The idea is that every platform specific code normalises the scroll amounts and forwards them to the SDL_SendMouseWheel function. It is this function that will now accumulate these (using a static variable, as I have seen how it was implemented in the Windows specific code) and once we hit a unit size, set the traditional integer "x" and "y" fields.

I believe this is pretty solid way of doing it, although I'm not the expert here.

There is also a fix in the patch for a typo recently introduced, that might need to be taken away by the time anybody merges this in. There is also a file in Nacl which I have stripped a horrible amount of trailing whitespaces. (Leave that part out if you want).
2017-08-14 21:28:04 -07:00
Sam Lantinga
fb835f9e3b Fixed bug 2330 - Debian bug report: SDL2 X11 driver buffer overflow with large X11 file descriptor
manuel.montezelo

Original bug report (note that it was against 2.0.0, it might have been fixed in between):  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733015

--------------------------------------------------------
Package: libsdl2-2.0-0
Version: 2.0.0+dfsg1-3
Severity: normal
Tags: patch

I have occasional crashes here caused by the X11 backend of SDL2. It seems to
be caused by the X11_Pending function trying to add a high number (> 1024)
file descriptor to a fd_set before doing a select on it to avoid busy waiting
on X11 events. This causes a buffer overflow because the file descriptor is
larger (or equal) than the limit FD_SETSIZE.

Attached is a possible workaround patch.

Please also keep in mind that fd_set are also used in following files which
may have similar problems.

src/audio/bsd/SDL_bsdaudio.c
src/audio/paudio/SDL_paudio.c
src/audio/qsa/SDL_qsa_audio.c
src/audio/sun/SDL_sunaudio.c
src/joystick/linux/SDL_sysjoystick.c


--------------------------------------------------------

On Tuesday 24 December 2013 00:43:13 Sven Eckelmann wrote:
> I have occasional crashes here caused by the X11 backend of SDL2. It seems
> to be caused by the X11_Pending function trying to add a high number (>
> 1024) file descriptor to a fd_set before doing a select on it to avoid busy
> waiting on X11 events. This causes a buffer overflow because the file
> descriptor is larger (or equal) than the limit FD_SETSIZE.


I personally experienced this problem while hacking on the python bindings
package for SDL2 [1] (while doing make runtest). But it easier to reproduce in
a smaller, synthetic testcase.
2017-08-14 20:22:19 -07:00
Sam Lantinga
aebe17d34f Fixed bug 2344 - CHECK_WINDOW_MAGIC should include __FILE__ and __LINE__
Martin Gerhardy

just for easier debugging issues in the own code...

SDL_CreateRenderer should maybe also use this macro

Ryan C. Gordon

I'll go one better: it should have an SDL_assert().
2017-08-14 16:34:54 -07:00
Sam Lantinga
f142a7961e Fixed bug 2441 - SDL_DuplicateSurface
Rainer Deyke

I've written a small patch that adds a small SDL_DuplicateSurface function to SDL.  I've written the function as part of a larger (as yet unfinished) patch, but I think this function is useful enough that it merits inclusion in SDL on its own.
2017-08-14 13:37:14 -07:00
Sam Lantinga
362d549690 Fixed bug 2500 - X11: SDL tries (and fails) to hide foreign windows
Alvin

I'm interested in this bug as well. I have experienced it when trying to embed an SDL_Window into a FLTK application. To do this, I create a FLTK window (window inside a window - think video player) and then use SDL_CreateWindowFrom() on the inner most window's Xlib Window*. After which, I create a renderer.

In my situation I am using the FLTK GUI toolkit.

What I have experienced is that the SDL_CreateRender() will recreate the window in order to properly setup OpenGL capability. As part of this process, the window is hidden and a call is executed that waits indefinitely for an acknowledgement that the window was indeed unmapped. This is where my program hangs.

Please correct me if I am wrong, but should SDL2 not make Xlib calls that effect the Xlib Window in this situation (e.g. When SDL_CreateWindowFrom() is used)? The toolkit being used typically assumes responsibility and, I presume, tracks all Xlib Windows it creates.

On line src/video/SDL_video.c:1372 the comment associated with setting SDL_WINDOW_FOREIGN reads:

  /* Can't destroy and re-create foreign windows, hrm */

Since I do not know the reason for hiding the window in the first place, the attached patch simply does not wait for a response when X11_XWithdrawWindow() and X11_XMapRaised() are issued by X11_HideWindow() and X11_ShowWindow(), respectively. I presume that the GUI toolkit (GTK, FLTK, etc.) has or will consume the acknowledging event as it is managing the Xlib Window (or it thinks it is).

I have tested the patch against hg 5c645d037de2 and I have successfully tested:
* Embedding the SDL_Window inside a FLTK application.
* Calling SDL_SetWindowSize() when FLTK resizes the window (e.g. dragging cursor on the edge of the window).
* Filling the renderer's default target blue and drawing a red fill square at the centre (exciting, I know!)
* Calling SDL_Quit() when the application terminates

I do not receive any Xlib erorr messages (BadWindow, etc.) in any of those situations.
2017-08-14 10:28:47 -07:00
Sam Lantinga
de91b1248f Fixed bug 3745 - specify SDLCALL as the calling convention for API callbacks
Patches contributed by Ozkan Sezer
2017-08-14 06:28:21 -07:00
Sam Lantinga
eb06aba8ae Fixed bug 3742 - minor warning fixes 2017-08-13 21:16:58 -07:00
Sam Lantinga
3cae0c38d2 Fixed bug 3746 - remove SDLCALL attribute from SDL_BlitFunc() funcptr
Ozkan Sezer

The attached patch removes SDLCALL attribute from SDL_BlitFunc() funcptr.

As far as I can see, *SDL_BlitFunc() is completely internal to SDL with
no specific calling convention requirements.  The actual functions assigned
to SDL_BlitFunc seem to not have any calling conventions specified. So,
easy solution is simply removing the strict calling convention from the
type.
2017-08-13 21:09:00 -07:00
Sam Lantinga
e54eede265 Provide the correct state of the on-screen keyboard to the API (patch from Sylvain) 2017-08-13 21:05:15 -07:00
Sam Lantinga
6ee661398d Fixed bug 3235 - Make the Android window creation similar to iOS' window creation
Sylvain

Here's a patch.
It tries to get the hint first. Resizable will allow any orientation. Otherwise it uses width/height window.

setOrientation method is splitted in static and non-static, so that it can be overloaded in a user subclass.

Some artefact observed :
surfaceChanged() can be called twice at the beginning. When the phone starts in portrait and run a landscape application.
2017-08-13 20:55:59 -07:00
Sam Lantinga
6ef1a25d18 Fixed bug 3751 - DirectFB linux_input disabled by default
Clayton Craft

linux_input module is disabled by default, despite the comments in source code that it is otherwise:

src/video/directfb/SDL_DirectFB_video.c:
    devdata->use_linux_input = readBoolEnv(DFBENV_USE_LINUX_INPUT, 0);       /* default: on */

src/video/directfb/SDL_DirectFB_video.h:
    #define DFBENV_USE_LINUX_INPUT      "SDL_DIRECTFB_LINUX_INPUT"      /* Default: on  */

When using the directfb driver, the linux_input module is suppressed unless the SDL app is started with "SDL_DIRECTFB_LINUX_INPUT=1" set in the environment. I recall seeing at one point that the directfb folks recommended using linux_input over the other input drivers, but I am having trouble locating this recommendation. In any case, I believe that this should really be defaulted to 'on' since it's vastly superior to the other dfb input drivers!
2017-08-13 20:51:08 -07:00
Sam Lantinga
78865effb5 Fixed compiler warning 2017-08-13 20:38:06 -07:00
Sam Lantinga
c87e1d525c Fixed bug 2841 - Hint to set resource id for window icon
Alexey

Seems to be a missing functionality. I want to set an icon from RC file. I cant pass MAKEINTRESOURCE(X) string to SDL_RegisterApp() cause string returned by MAKEINTRESOURCE string is not actually a string and SDL_strlen will crash. Moreover LoadImage seems to be loading wrong icon size. LoadIcon seems to be fine.
2017-08-13 14:15:52 -07:00
Ryan C. Gordon
18cceb5ce0 x11: Patched to compile. 2017-08-13 01:00:01 -04:00
Ryan C. Gordon
0a1b905b6c x11: Fix message box titles with Unicode chars on some window managers.
Fixes Bugzilla #2971.
2017-08-13 00:58:23 -04:00
Alex Szpakowski
9be597a0d6 iOS: Fix app orientation when creating a landscape fullscreen window with the device currently in portrait orientation. 2017-08-12 22:16:04 -03:00
Sam Lantinga
059d9e4627 Fixed bug 2950 - wrong axes values are set on joystick initialization
Edward Rudd

Device: Logitech Rumble Gamepad F510 in Xinput mode.

Upon opening the joystick the values of the axes are queried via PollAllValues are not actually set on the device all the time.

This can easily be seen in the testjoystick or testgamecontroller test programs,as the testjoystick shows all axes in the center until one 'tickles' the triggers., and the testgamecontroller will show the triggers as 'on' until on 'tickles' the triggers.

Upon further research the culprit is the SDL_HINT_JOYSTICK_ALLOW_BACKGROUND_EVENTS hint. In the default value events are ignored until there is an active window, Thus in cases where the joystick system is initialized and controllers opened before the initial window is created & focuses, the initial values will be incorrect.

Here is my current workaround in the game I'm working on porting..

SDL_SetHint(SDL_HINT_JOYSTICK_ALLOW_BACKGROUND_EVENTS, "1");
SDL_GameController* gamepad = SDL_GameControllerOpen(index);
SDL_SetHint(SDL_HINT_JOYSTICK_ALLOW_BACKGROUND_EVENTS, "0");
2017-08-12 17:41:59 -07:00
Sam Lantinga
7bab2913c2 Fixed Windows build 2017-08-12 17:01:14 -07:00
Sam Lantinga
05facb3d4e Fixed bug 2979 - SDL_ConvertSurface does not convert color keys consistently
Edmund Horner

When a 16-bit "565 format" surface has a colour key set, it will blit with correct transparency.  If, however, it has its colour key set then is converted to a 32-bit ARGB format surface, the colour key in the converted image will not necessarily be the same pixel value as the transparent pixels.  It may not blit correctly, because the colour key does not match the right pixels.

In my case, with an image using 0xB54A for transparency, the colour key was converted to 180,170,82; but the corresponding pixels (with the same original value) were converted to 180,169,82.  Blitting the converted image did not use transparency where expected.

I have attached a test case.  The bug has been replicated on both x86_64 Linux (SDL 2.0.2), and 32-bit MS C++ 2010 on Windows (SDL 2.0.0).
2017-08-12 16:59:00 -07:00
Sam Lantinga
d226594fcc Workaround for bug 3049 - SDL_Init(SDL_INIT_VIDEO) - XDM authorization key matches an existing client!
malferit

Hello, I began a little program with SDL2 on Linux in C, and when I call SDL_Init(SDL_INIT_VIDEO) I get an error and this is printed in the console:

XDM authorization key matches an existing client!

I searched through Internet, and found that some people suggest to run 'xhost +' or to specify this in /etc/X11/xdm/xdm-config:

DisplayManager*authName:        MIT-MAGIC-COOKIE-1

I don't think an end user needs to know that...

But what bothered me is that first I started this little program in Pascal using the Freepascal compiler and it works. In freepascal you only use some thin header bindings in Pascal and then it links with the dynamic SDL library, so I don't understood why it worked with Freepascal and not in C.

I run ldd to the two generated applications:

Application in C:

	linux-gate.so.1 (0xffffe000)
	libSDL2-2.0.so.0 => /usr/lib/libSDL2-2.0.so.0 (0xb76ac000)
	libpthread.so.0 => /lib/libpthread.so.0 (0xb766e000)
	libc.so.6 => /lib/libc.so.6 (0xb74e2000)
	libm.so.6 => /lib/libm.so.6 (0xb74a0000)
	libdl.so.2 => /lib/libdl.so.2 (0xb749a000)
	librt.so.1 => /lib/librt.so.1 (0xb7491000)
	/lib/ld-linux.so.2 (0xb77b3000)

Application compiled with Freepascal:

	linux-gate.so.1 (0xffffe000)
	libSDL2-2.0.so.0 => /usr/lib/libSDL2-2.0.so.0 (0xb762a000)
	libX11.so.6 => /usr/lib/libX11.so.6 (0xb74f3000)
	libc.so.6 => /lib/libc.so.6 (0xb7367000)
	libm.so.6 => /lib/libm.so.6 (0xb7325000)
	libdl.so.2 => /lib/libdl.so.2 (0xb731f000)
	libpthread.so.0 => /lib/libpthread.so.0 (0xb7305000)
	librt.so.1 => /lib/librt.so.1 (0xb72fc000)
	libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb72dc000)
	libXau.so.6 => /usr/lib/libXau.so.6 (0xb72d9000)
	libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb72d3000)
	/lib/ld-linux.so.2 (0xb7755000)

It seems that Freepascal is linking with libX11, libxcb, libXau and libXdmcp .

Linking my C application with libxcb solved the problem (linking with libXau and/or libXdmcp without libxcb didn't work). Linking with X11 links all the other libraries and works as well.

So I fill this bug report mainly to let you know about this. I don't know if it is a problem that can be solved on the libSDL side or not, but at least I hope it will help.

Hi, some tests:

1. Disabled XDM. Login in console and running 'startx'. The program works without having to link with X11.

2. Enabled XDM. Added 'DisplayManager*authName: MIT-MAGIC-COOKIE-1' to /etc/X11/xdm/xdm-config.The program works without having to link with X11.

3. Enabled XDM without 'DisplayManager*authName: MIT-MAGIC-COOKIE-1' in /etc/X11/xdm/xdm-config . I get the authentication error unless I link with X11.
2017-08-12 16:48:46 -07:00
Sam Lantinga
45cec28bc4 Fixed bug 3058 - Slight mistake in GetWindowStyle in SDL_windowswindow.c
Coriiander

There's a slight mistake in the function "GetWindowStyle" found in file "SDL_windowswindow.c".

When a window is marked to be resizable, the resizable style is being added regardless of whether the window has a border or not. While for some arcane, hidden semantics this can be ok, it's still inconsistent in this case.
2017-08-12 16:44:00 -07:00
Sam Lantinga
e3f3a757f3 Fixed bug 3158 - SDL display window scrambled over VNC
Witek Jachimczyk

I'm using SDL to develop a video viewer for MATLAB.  The window is scrambled while using thightVNC with its default mode of RGB656.

SDL does not correctly recognize the pixel mode.


I found a solution for this problem.  The solution involves modifying
SDL/src/video/SDL_pixels.c

Adding the following "if statement" under case 16: of SDL_MasksToPixelFormatEnum resolves the issue:

        if (Rmask == 0x003F &&
            Gmask == 0x07C0 &&
            Bmask == 0xF800 &&
            Amask == 0x0000) {
            return SDL_PIXELFORMAT_RGB565;
        }

I hope that this helps someone.  I took me a while to figure it out.
2017-08-12 16:02:33 -07:00
Sam Lantinga
4a9c6f0a14 Fixed bug 3173 - SDL_GL_GetAttribute overwrites error code from SDL_GL_GetProcAddress
Yann Dirson

When SDL_GL_GetProcAddress returns in error, the cause of the error is overwritten
in GL_GL_GetAttribute, reporting to the user "Failed getting OpenGL glGetString entry point", whereas the original "OpenGL library not loaded" never makes it
to the user.

Pushed a fix to:
f94cb13708


Note that the "OpenGL library not loaded" error looks like no root cause either,
and I'm still puzzled by the code path used: I'm forcing opengles2 renderer on
the x11 video driver on a rpi2, as in https://bugzilla.libsdl.org/3169, and although I now know that I must force the use of the RPI video driver instead
of the x11 one, I suspect even more accurate info can be given to user.
2017-08-12 15:55:54 -07:00
Sam Lantinga
1a5441451c Fixed bug 3309 - SDL_ConvertSurface adds AlphaMod when input surface has ColorKey
Sylvain

Let's you have a SDL_Surface that has ColorKey, but no Alpha Modulation.
When this surface is duplicated with SDL_ConvertSurface function, the result has ColorKey and Alpha Modulation (BLEND, and Opaque 255).

I think SDL_ConvertSurface should strictly keeps the input format.


example
=======

SDL_Surface *input; // ... Set up a surface with ColorKey and no AlphaMod

SDL_Surface *output = SDL_ConvertSurface(input, input->format, input->flags);

// "output" surface has a ColorKey but *also* AlphaMod (BLEND, and Opaque 255).
2017-08-12 15:21:26 -07:00
Sam Lantinga
47c2c7d585 Cleaned up WindowsScanCodeToSDLScanCode() so VKeytoScancode() always takes precedence for the keys it handles and the rest of the logic is easier to read. 2017-08-12 12:56:28 -07:00
ouned
34769abd46 prefer virtual keycodes over scancodes for extended keys 2017-06-03 09:13:08 +02:00
Sam Lantinga
c086251266 Fixed bug 3128 - Removing all the static variables from android SDLActivity and accompanying JNI calls.
owen

I removed all the static variables from SDLActivity.java

Updated all the SDL_android.c jni calls as well

I added a new function to SDL_android.c/ h
void Android_JNI_SeparateEventsHint(const char* c);

This is called by SDL_androidtouch.c so that this TU doesn't need to call any JNI functions.
2017-08-12 12:24:59 -07:00
Sam Lantinga
78c84e7029 Fixed part of bug 3227 - patch for multiple buttons at the same time not working
Philipp Wiesemann

There is another problem with the current implementation which maybe should be fixed first (to prevent some work). It was written as if it would get the number of a button from the Java side but actually it gets the state of all buttons. That is why it should not work if more than one button is pressed at once.
2017-08-12 08:06:16 -07:00
Sam Lantinga
b425050baf Fixed compiler warnings on Visual Studio 2013 2017-08-12 00:04:46 -07:00
Sam Lantinga
79a846d486 Fixed bug 3334 - SDL_ShowMessageBox uses wrong index and accesses un-allocated memory
romain.lacroix

For the windows implementation of SDL_ShowMessageBox() : ./src/video/windows/SDL_windowsmessagebox.c:345 WIN_ShowMessageBox()

The implementation in 2.0.4 uses "button index" for parameter "id" of function AddDialogButton().

It then expects the value provided in param wParam of function MessageBoxDialogProc() to be a valid index of a button.

It uses this value to index in the array of buttons when DialogBoxIndirect() returns (line 474 : *buttonid = buttons[which].buttonid;)

However, when dismissing this box with Escape, the return value of DialogBoxIndirect will be SDL_MESSAGEBOX_BUTTON_ESCAPEKEY_DEFAULT (=2) which is not always a valid index of array buttons.

When the array buttons has a length less or equal than 2, the memory access is invalid; I can see that the value written to *buttonId is uninitialized memory (random value).

The fix I propose : use value "buttonid" (field of button) for parameter "id" of AddDialogButton(), then copy return value of DialogBoxIndirect() in *buttonid. This way, we will not use an out-of-bounds index in array buttons.
2017-08-11 19:42:39 -07:00
Sam Lantinga
1da252c2d8 Fixed crash in bug 3367 - RGBA_FROM_PIXEL macro can't handle SDL_PIXELFORMAT_ARGB2101010
Simon Hug

The RGBA_FROM_PIXEL macro in src/video/blit.h [1] is not designed to work with more than 8 bits per channel and the ARGB2101010 format makes it read outside of the array bounds causing access violations. This can happen during blitting with the BlitNtoNPixelAlpha and SDL_Blit_Slow functions.

When SDL_InitFormat tries to calculate the loss of the channels [2], the Uint8 will wrap around and it will end up at 254 for the 10-bit channels. Clearly way over the 9 entries of the SDL_expand_byte array. (Not that a signed integer would help.) Then the macro tries to access the lookup table with the channel value which could be up to 1023. If the previous indirection didn't cause an access violation this one will.

I guess it's not worth modifying this macro for a format that only a few will use. It will only make the other blitters slower. I don't have good ideas to solve this issue.

Attached is a test case that does three blits. A copy one that work and the two that use the functions mentioned above.

[1] https://hg.libsdl.org/SDL/file/cd1994d4f3c6/src/video/SDL_blit.h#l303
[2] https://hg.libsdl.org/SDL/file/cd1994d4f3c6/src/video/SDL_pixels.c#l540
2017-08-11 18:56:41 -07:00
Sam Lantinga
96305832bc Fixed bug 3702 - Clear error messages of SDL_LoadObject for optional libraries
Simon Hug

Some code in SDL loads libraries with SDL_LoadObject to get more information or use newer APIs. SDL_LoadObject may fail, set an error message and SDL will continue with some fallback code. Since SDL will overwrite the error or exit the function with a return value that indicates success, the error form SDL_LoadObject for the optional stuff might as well be cleared right away.
2017-08-11 10:21:19 -07:00
Sam Lantinga
6e1b11bae4 Fixed bug 3714 - Windows: SDL_WINDOW_FULLSCREEN_DESKTOP broken on 3 monitor setup w/ DPI scaling
Eric Wasylishen 2017-07-26 18:42:58 UTC
I set up an (admittedly exotic) 3-monitor setup, and when I enter fullscreen-desktop on the middle display (#2), the SDL window is off center. (covers half of monitor #2 and most of monitor #3).

The displays are arranged from left to right:

Display #1 (main): 2880x1800, 200% scaling
Display #2: 1920x1200, 150% scaling
Display #3: 1920x1080, 100% scaling

SDL display bounds:
INFO: Bounds: 1440x900 at 0,0
INFO: Bounds: 1281x801 at 1921,0  (these are incorrect)
INFO: Bounds: 1920x1080 at 4800,0

Correct bounds reported by calling EnumDisplayMonitors and printing the LPRECT param of the callback:
1440x900 at (0, 0)
1280x800 at (2880, 0)
1920x1080 at (4800, 0)

It seems like you need 3 displays to reproduce this, and the left two need DPI scaling, and the 3rd display needs to have a different scale factor than the others.

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

SDL: current hg (11235:6a587b9e0ec8)
Windows 10, Version 10.0.15063 Build 15063
Tested with testdraw2 and testgl2, and pressing alt+enter to enter fullscreen desktop.

This patch reworks SDL_windowsmodes.c to use EnumDisplayMonitors instead of EnumDisplayDevices, so we always have an HMONITOR for each SDL display.

With access to an HMONITOR, we can get the monitor bounds in virtual screen coordinates the proper way, by calling GetMonitorInfo. (whereas the original code was doing some calculations - e.g. "data->DeviceMode.dmPosition.x * data->ScaleX" - to try to get virtual screen coordinates. These worked in simple cases, but failed in more complex cases like this bug)

The one potential problem with my patch is, the ChangeDisplaySettingsEx docs say that you're supposed to get the display name from EnumDisplayDevices, but I'm getting the display name from GetMonitorInfo now.
2017-08-11 10:18:45 -07:00
Sam Lantinga
a05522a089 Fixed bug 3723 - Possible double free in kmsdrm init code on certain errors
Simon Hug

KMSDRM_VideoInit allocates and frees some connectors and encoders but doesn't set the pointer to NULL after freeing. The cleanup code at the end may free one of those garbage pointer should an error happen in the initialization.
2017-08-11 10:05:45 -07:00
Sam Lantinga
843293bed0 Fixed bug 3701 - WM_TOUCH message may cause calls to null if touch functions are not properly loaded
Simon Hug

When WIN_WindowProc processes the WM_TOUCH message, it doesn't check if the touch functions have been properly loaded and may call a NULL pointer. It's probably an extremely rare case, but here's a patch that adds some checks anyway.
2017-08-09 20:26:16 -07:00
Ryan C. Gordon
69092c7e47 haiku: Fixed compiler warning. 2017-08-09 18:30:48 -04:00
Ryan C. Gordon
a412ba0d75 haiku: Patched SDL_bopengl.cc to compile on x86-64 Haiku.
Fixes Bugzilla #3729.
2017-08-09 01:01:41 -04:00
Ryan C. Gordon
d5215d9df9 Fixed up some compile warnings and errors on x86-64 Haiku. 2017-08-09 00:56:05 -04:00
Philipp Wiesemann
27de835dd2 emscripten: Fixed compiler warnings about integer to pointer conversions.
Found by buildbot.
2017-08-05 22:10:55 +02:00
Philipp Wiesemann
711df8a989 emscripten: Fixed compiling without OpenGL support. 2017-08-05 22:10:48 +02:00
Philipp Wiesemann
f216b446aa kmsdrm: Fixed crashes if allocating memory failed. 2017-08-05 22:10:36 +02:00