Mart?n Golini
I'm having a very slow initialization of the video subsystem that locks the window creation for about 500 ms ( tested in at least 4 different systems ). What i found is that X11_InitModes_XRandR is using XRRGetScreenResources, that explicitly ask to poll the hardware for changes. This is not really necessary since if the data is already available you can use XRRGetScreenResourcesCurrent.
I attached a tentative patch that fix this issue. With the patch there's no lock when the subsystem is initialized and the window creation is instant in my applications. The patch only uses XRRGetScreenResourcesCurrent in X11_InitModes_XRandR but it could be potentially used in X11_GetDisplayModes and X11_SetDisplayMode.
bastien.bouclet
When creating two surfaces and blitting them onto the other, SDL's internal reference counting fails, and one of the surfaces is not freed when calling SDL_FreeSurface.
Example code :
SDL_Surface *s1 = SDL_CreateRGBSurfaceWithFormat(0, 640, 480, 32, SDL_PIXELFORMAT_ARGB8888);
SDL_Surface *s2 = SDL_CreateRGBSurfaceWithFormat(0, 640, 480, 32, SDL_PIXELFORMAT_ARGB8888);
SDL_BlitSurface(s1, NULL, s2, NULL);
SDL_BlitSurface(s2, NULL, s1, NULL);
SDL_FreeSurface(s2);
SDL_FreeSurface(s1);
With this example, s1 is not freed after calling SDL_FreeSurface, its refcount attribute is still positive.
This also seems to fix the follow-up issue in bug #3719, whereby the initial fix caused the SDL window to move, after transitioning from fullscreen to windowed-mode
This is necessary because the Raspberry Pi is a strange beast, that believes
it has OpenGL support (through glX?) but generally has GLES2 support.
So when using the raspberry video target, we need to force this to default
to a GLES2 context, or by default SDL_CreateWindow() will fail, deep down
when it tries to load the proper GL library.
Fixes testsprite2 (and basically everything else that wasn't testgles2) when
run on a Raspberry Pi without a X server.
Please note that other targets might also need this filled in, the Raspberry
Pi is just the most prominent and readily-available System-On-A-Chip style
thing on my desk. :)
Romain Tisserand
Using KMS/DRM driver from WIP SDL2.0.6 on Linux/ARM SoC RockChip RK3328 (ARM Mali 450 MP2 GPU).
The current code is using GBM_BO_FORMAT_XRGB8888 as GBM buffer format specifier.
The Mali driver (it has been confirmed some other vendor implementations too) expects GBM_FORMAT_XRGB8888.
The Mesa implementation is actually handling both values as the same, but it's not implemented like this into every gbm.h vendor header.
https://github.com/ideak/mesa/blob/master/src/gbm/backends/dri/gbm_dri.c
So with stock SDL2 on my card (Mali vendor implementation), it does not work, eglCreateWindowSurface fails, and gbm_is_format_supported fails too (with the BO variant).
It runs fine with GBM_FORMAT_XRGB8888.
Here is a link of the gbm.h from Mali user-space driver :
https://github.com/rockchip-linux/libmali/blob/rockchip/include/gbm.h
This is necessary because we need to see if GLES compat extensions exist.
All of this code (including ShouldUseTextureFramebuffer()) should be
revisited after 2.0.6 ships; ideally we don't make throwaway contexts if
we can avoid it...but maybe we can't. I hear Vulkan is pretty cool.
Fixes Bugzilla #3725.
benjamin.feng
Probable underlying cause: https://bugzilla.libsdl.org/show_bug.cgi?id=3124#c5
"If you download and build the HID Calibrator sample you can see that these are totally legitimate HID devices (except for inverting the Y-axis of joysticks, which is contrary to the HID specification but does make them more compatible with games compiled expecting XBOX controllers)."
Colin Barrett
Using the pre-built x86 devel libs from here:
https://www.libsdl.org/release/SDL2-devel-2.0.5-VC.zip
If I have:
SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 2);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 0);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_FLAGS, SDL_GL_CONTEXT_DEBUG_FLAG);
and I'm using ANGLE/(a GL driver that doesn't provide an ES2 context) such that SDL_EGL_CreateContext is called by SDL_GL_CreateContext, I get the error "Could not create EGL context (context attributes are not supported)" and no context is created.
Looking at the code in SDL_EGL_CreateContext - if gl_config.flags is non-zero, it looks like the code in the section guarded with "#ifdef EGL_KHR_create_context" should be executed - but it apparently isn't.
Is it possible this section hasn't been compiled into the pre-built libraries? If I build SDL2.dll myself using the Visual C++ solution (VS2015 Community Update 3) then the call succeeds as I expect
bastien.bouclet
When exiting a "fullscreen space" on OS X, windows don't go to their defined "windowed mode size", but go back to their previous size.
Steps to reproduce:
1. Create a windowed mode SDL window
2. Toggle it to fullscreen with the SDL_WINDOW_FULLSCREEN_DESKTOP flag
3. While in fullscreen, change the windowed mode size using SDL_SetWindowSize
4. Toggle the window back to windowed mode
Expected result:
- The window has the size specified during step 3.
Actual result:
- The window has the size specified when creating the window in step 1.
Attached is a minimal reproduction test case.
The attached test case works as expected on X11 and Windows.
Ozkan Sezer
fix windows build after revision 11382: commit 2026e42e377a renamed
_SDL_msctf_h to SDL_msctf_h_ . SDL_windowskeyboard.c relies on that
macro, so update it accordingly.
Ozkan Sezer
Since the Vulkan merge, building against a Mac OS X SDM older than
10.11 fails in SDL_cocoametalview.m because Metal.framework is not
present. There is no conditional compiling in SDL_cocoametalview.m
either, so --disable-video-vulkan doesn't help with anything. (The
configury doesn't check darwin for x86_64 either, but it's another
story.)
I cross-build against 10.8 SDK on linux using clang-3.4.2 and this
is a problem for me. Will this be fixed?
Simon Hug
This issue actually raises the question if this API change (requirement of initialized audio subsystem) is breaking backwards compatibility. I don't see the documentation saying it is needed in 2.0.5.
"Major changes, roughly in order of appearance:
- Use float math everywhere, instead of promoting to double and casting back
all the time.
- Conserve sound energy when downmixing any channel into two other channels.
- Add a QuadToStereo filter. (The previous technique of reusing StereoToMono
never worked, since it assumed an incorrect channel layout for 4.0.)
- Add a 71to51 filter. This removes just under half of the cases the previous
code would silently break in.
- Add a QuadTo51 filter. More silent breakage fixed.
- Add a 51to71 filter, removing another almost-half of the silently broken
cases.
- Add 8 to the list of values SDL_SupportedChannelCount will accept.
- Change SDL_BuildAudioCVT's channel-related logic to handle every case, and
to actually fail if it fails instead of silently corrupting sound data and/or
crashing down the road."
(Note that SDL doesn't otherwise support 7.1 audio yet, but hopefully it will
soon and the 7.1 converters are an important piece of that. --ryan.)
Fixes Bugzilla #3727.
David Brady
When I attempted to make a mapping file for Android gamepads, I quickly discovered that most of the ones that I have here show up as the same device (Broadcom Bluetooth HID), meaning that it was impossible to make mappings on Android, since every device looked the same.
This patch will check for the existence of the getDescriptor function added in Jelly Bean, and use it if it's there. The Android Dashboard says that the majority of Android phones should support this function, and doing it this way will not force us to bump up our API version.
Clayton Craft
The default path used by directfb for libGL is different than the default path used by x11 in SDL2:
./src/video/directfb/SDL_DirectFB_opengl.c:
path = "libGL.so";
./src/video/x11/SDL_x11opengl.c:
#define DEFAULT_OPENGL "libGL.so.1"
On at least one distro (Alpine Linux), libGL.so is not created (or more accurately the symlink to libGL.so.1 is not created). For consistency, the 'path' variable in SDL_DirectFB_opengl.c should patch the DEFAULT_OPENGL in SDL_x11opengl.c ("libGL.so.1")
Error message was:
[mvk-info] MoltenVK version 0.18.2. Vulkan version 1.0.51.
[***MoltenVK ERROR***] VK_ERROR_INITIALIZATION_FAILED: On-screen rendering requires a view that is backed by a layer of type CAMetalLayer.
2017-08-28 02:17:29.579 testvulkan[95627:1716939] ERROR: SDL_Vulkan_CreateSurface(): vkCreateMacOSSurfaceMVK failed: VK_ERROR_INITIALIZATION_FAILED
David Ludwig
I've created a new set of patches. I am happy to create more, if it would help.
One version only copies 'size'.
A second version copies both 'size' and 'silence'. When looking over the documentation for SDL_OpenAudio in SDL_audio.h, it mentioned that both 'size' and 'silence' were things that SDL_OpenAudio would calculate.
Regarding *both* patches, I did notice that SDL 1.2 appears to have always modified desired's size and silence fields. The SDL wiki, at https://wiki.libsdl.org/SDL_OpenAudio#Remarks , does note:
Carlos
We would like to add a switch (define) that allows us to compile Angle statically with SDL. That is, getting rid of the OpenGL DLL. Usually you need OpenGL to be loaded dynamically as DLL because implementation is provided by the system but no need with Angle.
Only 2 files need modification and it shouldn't affect current behaivor:
include/SDL_egl.h and src/video/SDL_egl.c, as in here
https://github.com/native-toolkit/sdl/pull/10/files
The flag name could be SDL_VIDEO_STATIC_ANGLE (instead of NATIVE_TOOLKIT_STATIC_ANGLE) as discussed here https://github.com/native-toolkit/sdl/pull/10
We have tested this with both Windows and UWP, using NME engine (https://github.com/haxenme/nme).
Releated issue: https://bugzilla.libsdl.org/show_bug.cgi?id=1820
Sylvain
Hi! here's a patch for that with two class loaded regarding API level.
Test both case : before API 11 and after.
I also remove now unused GetSystemServiceFromUIThread() and minor clean-up (haptic warning prototype).
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)."
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.
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.
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).
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.
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().
Leonardo
Structure SDL_gestureTouch gets reallocated for every new added gesture but its never freed.
Proposed patch add the function SDL_GestureQuit() that takes care of doing that and gets called when TouchQuit is called.
Gabriel Jacobo
Thanks for the patch. I think it needs a bit of extra work though, looking at the code in SDL_gesture.c , I see that SDL_numGestureTouches only goes up, I think the right fix here involves adding SDL_GestureDelTouch (hooked into SDL_DelTouch) as well as SDL_GestureQuit (as you posted in your patch).
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.
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.
UX-admin
I am compiling with the Sun Studio 12 u2 compiler. There are multiple issues with the build, but this particular issue appears to be that it is illegal to declare a union of a struct of floats and a float. While GCC 4.8.1 does not flag this as an error, Sun Studio is much more standards compliant and strict, halting further compilation with an error.
afwlehmann
Sorry for re-opening, but it turns out that the current interval is indeed not updated. I've just checked the source code of the 2.0.3 release again:
163 if (current->canceled) {
164 interval = 0;
165 } else {
166 interval = current->callback(current->interval, current->param);
167 }
168
169 if (interval > 0) {
170 /* Reschedule this timer */
171 current->interval = interval; // <-- this line is missing
172 current->scheduled = tick + interval;
173 SDL_AddTimerInternal(data, current);
174 } else {
According to the documentation: "The callback function is passed the current timer interval and the user supplied parameter from the SDL_AddTimer() call and returns the next timer interval. If the returned value from the callback is 0, the timer is canceled."
If I understand the text correctly, then the current interval should in fact be updated according to the returned value. Otherwise there would be a discrepancy between the next time for which the timer is actually re-scheduled and the value that's passed to the callback once the timer fires again.
This could be fixed by adding line #171.
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.
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.
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!
Jimb Esser
Note: This is using DirectInput, I have to disable XInput as that causes all but the first 4 controllers to be completely ignored by SDL (I can find no way to reconcile XInput devices with DirectInput devices, otherwise I would make a patch that accepts the fifth and later controllers with DirectInput...). XInput does not seem to have the problem below, only DirectInput.
I plug in 3 identical wireless Xbox 360 controllers, call them J1, J2, J3. Direct Input shows them as having GUIDs G1, G2, G3. I unplug J1, then J2 and J3 show up as having GUIDs G1 and G2! Not so "unique"... I start my SDL app when just J2 and J3 are plugged in, and open J2 and J3. Then I plug in a new controller, SDL sees that now G3 exists, assigns that a new SDL joystick instance ID, which I request to be opened, but G3 at this point is J3, which I already had opened! So I end up with two instances of J3 opened, and none of J1. "Re-"opening G1 would get the actual handle to the newly attached controller, but there's no current way to know this. This is clearly a bug or poor design in DirectInput or my wireless receiver drivers, but is a showstopping bug for my 8-20 player games (as soon as any one controller runs out of battery or goes to sleep and gets turned back on, suddenly things are busted requiring a restart (or, at least, a reinitialization of all controllers - the game can't go on)).
The solution I found is to use HID paths instead of GUIDs to uniquely identify joysticks. GUIDs are still needed to open a controller, however I have added code to re-find the GUIDs for all joysticks whenever a new joystick is attached or removed. This does now require opening of all joysticks (instead of just enumerating them), though if your app, like mine, is opening all of them anyway so that any can press a button to join, that doesn't change much (although perhaps they joysticks should be kept open in this case, instead of closed and re-opened). If your app only ever opens one joystick, this will do more work at startup than it did previously.
Jonas Kulla
This eliminates the need to manually compile in SDL_main_android.c.
Instead, add "-lSDL2main -Wl,-u,SDL_main_dummy" when linking.
I don't know how the nkd-build process works, but unless it was
for some reason linking libSDL2main.a it should be unaffected.
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.
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");
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).
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.
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.
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.
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.
Daniel Gibson
AZERTY keyboard layouts (which are the default layouts in France and Belgium) don't have the number keys (1, 2, ..., 9, 0) in the first row of keys, but ?, &, ?", ', (, -, ?_, ??), = (with small differences between the France and Belgian variants). Numbers are reached via shift.
On Linux and OSX, SDL seems to use the corresponding ISO 8859-1 codes (231 for ?232 for ?tc) as SDL_Keycode (but no SDK_* constants exists for those values!), while on Windows SDL seems to map those keys to SDLK_1, SDLK_2 etc, like you'd get on QWERTY.
I don't know how other platforms behave.
So we have two problems:
1. At least on Linux and OSX invalid/undefined SDL_Keycodes are returned
2. Different platforms behave differently (Windows vs Linux/OSX)
It's unclear what behavior is desired: Should SDL_* constants for those keys be introduced (and Windows behavior changed accordingly)?
Or should all platforms behave like Windows here and use the existing SDLK_1, ..., SDLK_0 keycodes?
This bug on the mailing list:
https://forums.libsdl.org/viewtopic.php?t=11555 (my post about Linux/Windows)
https://forums.libsdl.org/viewtopic.php?t=11573 (Tim Walters discovered the same problem on OSX about 1.5 weeks later).
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).
Simon Hug
The bug is in the GL_ResetState and GLES_ResetState functions which get called after a new GL context is created. These functions set the cached current color to transparent black, but the GL specification says the initial color is opaque white.
The attached patch changes the values to 0xffffffff to reflect the initial state of the current color. Should the ResetState functions get called anywhere else in the future, this probably has to call the GL functions itself to ensure that the colors match.
