This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• sdl_rwops.changes (sdl_rwops.changes, text/plain, 2006-01-31 10:11:02 +0000, 2754 bytes)
• sdl_rwops.diff (sdl_rwops.diff, text/plain, 2006-01-31 10:12:44 +0000, 15487 bytes)
• Make use of the unused type member (SDL_RWops.diff, text/plain, 2010-10-09 09:17:11 +0000, 520 bytes)

Reported in version: 2.0.0
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-01-31 10:10:44 +0000, Sam Lantinga wrote:

Date: Tue, 24 May 2005 00:43:05 -0400
From: Antonio SJ Musumeci [email protected]
To: [email protected]
Subject: [SDL] SDL_RWops bug fixes
-- Message: 16002 -- Next: 16005 ----------------------------------------
This code with SDL-1.2.8 and CVS:

#include <stdio.h>
#include <stdlib.h>
#include <SDL.h>

int
main(int argc, char** argv)
{
char alphabet[26] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
char buffer_file[27] = {0};
char buffer_mem[27] = {0};
int rv_file;
int rv_mem;
FILE* file_ptr;
SDL_RWops* rwop_file;
SDL_RWops* rwop_mem;

file_ptr = fopen("./blah", "w");
fwrite(alphabet, 1, sizeof(alphabet), file_ptr);
fclose(file_ptr);

rwop_mem = SDL_RWFromMem(alphabet, sizeof(alphabet));
rwop_file = SDL_RWFromFile("./blah", "r");
rv_mem = SDL_RWread(rwop_mem , buffer_mem, 5, 6);
rv_file = SDL_RWread(rwop_file, buffer_file, 5, 6);
printf("From File: %d %s\n"
"From Mem: %d %s\n",
rv_file,
buffer_file,
rv_mem,
buffer_mem);
printf("Seek end of File: %d\n"
"Seek end of Mem: %d\n",
SDL_RWseek(rwop_file, 0, SEEK_END),
SDL_RWseek(rwop_mem , 0, SEEK_END));
SDL_RWclose(rwop_file);
SDL_RWclose(rwop_mem);

return 0;
}

Produces this output:

From File: 5 ABCDEFGHIJKLMNOPQRSTUVWXYZ
From Mem: 5 ABCDEFGHIJKLMNOPQRSTUVWXY
Seek end of File: 26
Seek end of Mem: 26

Attached is a patch which fixes this along with a few other
inconsistencies and bugs in SDL_rwops.c... it also enhances the API. It
should however still be compatible. Also attached is a list of all the
changes/enhancements made by this patch.

-Antonio SJ Musumeci

On 2006-01-31 10:11:02 +0000, Sam Lantinga wrote:

Created attachment 57
sdl_rwops.changes

On 2006-01-31 10:12:44 +0000, Sam Lantinga wrote:

Created attachment 58
sdl_rwops.diff

This patch mostly looks okay, but the API changes make it a good candidate for 1.3.

If you apply it, make sure you take out the part that removes the "unknown" portion of the union, which is used by custom rwops.

On 2006-01-31 10:35:15 +0000, Ryan C. Gordon wrote:

The bug fixes in that patch are already in CVS, but the rest got rejected as an API change (but he DOES make some good points...the RWops interface could stand to be enhanced for 1.3!).

--ryan.

On 2006-01-31 11:30:37 +0000, Sam Lantinga wrote:

(In reply to comment # 3)

The bug fixes in that patch are already in CVS, but the rest got rejected as an
API change (but he DOES make some good points...the RWops interface could stand
to be enhanced for 1.3!).

Indeed! Okay, thanks, we'll keep this around for review/inclusion in 1.3

On 2010-10-09 09:17:11 +0000, wrote:

Created attachment 539
Make use of the unused type member

Instead of removing the unused type member, why not make use of it? At present there is no way to tell what kind of stream is used by the SDL_RWops, and the type member seems like it is there specifically for that purpose. While determining the type of a stream is not of huge importance, I think it could be useful for people extending the RWops interface, and it's a trivial change to make.

The attached patch is against revision 4890, if that's important.

On 2013-03-13 01:12:24 +0000, Andreas Schiffler wrote:

Assigning to myself to review changes and apply fixes/suggestions.

Plan:

• bugs will be reviewed and fixes ported/applied
• test coverage will be added where applicable/possible
• any API changes will be rejected since the SDL 2.0 ABI has been locked
• the "unused type member" update will be included in a slightly modified form

On 2013-03-13 10:48:14 +0000, Andreas Schiffler wrote:

Bug status SDL 2.0 HG:
-Reading from memory was not consistant with how reading from files worked.
A file of 55 bytes stored into 'ptr' by using 6 sets of 10 bytes would copy
55 bytes into 'ptr' and SDL_RWread would return 5. But the same act done on
mem RWop would result in 50 bytes copied and 5 returned.
Added test coverage.
No repro on SDL 2.0.

-Seems that SDL_RWclose should return fclose's return value instead of 0
-1 return is by design and documented.
Added test coverage for return value of SDL_RWclose.

-Since there is no feof or ferror wrappers... if read or write return less
than requested... it was not known why. Added SDL_RWeof, SDL_RWerror, and
SDL_RWclearerr
Won't fix since ABI change.

-mem_writeconst() would return a -1... but fwrite nor mem_write would return
a -1 on an error... especially since the concept of knowing an error occured
didnt exist... return 0 now and sets flags as error.
No repro.

-since it is obvious RWops is based off stdio FILE's... it would make sense
to use the same data types.
> ftell returns a long... RWseek returns ftell so RWseek returns long
> seek's offset argument is now a long
> read and write take size_t's instead of int's and return size_t's
Already matches SDL2.0's implementation.

-where RWop was free'd in RWclose functions... appears it should have been
using SDL_FreeRW since RWFromX's use SDL_AllocRW
No repro. CR'ed that all _close functions call SDL_FreeRW.

-In unix_to_mac function... called from SDL_RWFromFile with a
const char* file = NULL would try to strlen(NULL)
No repro. Function does not exist anymore.

-No check on the malloc used in unix_to_mac... put in check.
No repro. Function does not exist anymore.

-mem_read and mem_write didnt check for overflows the same way fread/fwrite
do (at least how dietlibc impliments them)... if num or size are 0
return 0... if ((num * size) / num) != size) return 0

Misc:
-Fixed some comments in SDL_rwops.h
Skipped.

-renamed a few arguments for consistancy
Skipped.

-SDL_RWops.type is completely unused... removed.
Updated to use type.

-SDL_RWops.unknown also unused... removed.
Won't fix since ABI change.

-Added SDL_OutOfMemory error setting to any malloc's
No repro. CR'ed that all mallocs set this error.

-unknown values for 'whence' now also set RWerror
No repro. CR'ed that error is being set. Added test coverage.

Enhancements:
-Added the concept of SDL_RWeof, SDL_RWerror, and SDL_RWclearerr
Won't fix since ABI change.

-Created SDL_RWFromMallocedMem(void* ptr, size_t size)
If 'ptr' is NULL... it allocates 'size' bytes for you, otherwise
'ptr' must be from standard malloc. If you attempt to write past the
end of the buffer it will realloc the buffer. You may also treat it
like a file stream works... you can seek past the actual end and
when you attempt to write data it will realloc and copy the data. Area
between the original end and the seeked position will contain '\0''s
just as a write performed on a file which was seeked past it's end.
If realloc fails the buffer stays the same and the error flag is set.
Skipped. ABI change.

• Make use of the unused type member.
  Added defines and setting of type field.
  Added test coverage.

On 2013-03-13 11:37:35 +0000, Andreas Schiffler wrote:

Fix checked in.
http://hg.libsdl.org/SDL/rev/681820ca0e78

./testautomation --filter RWops
...
INFO: 03/13/13 16:36:36: Run Summary: Total=10 Passed=10 Failed=0 Skipped=0

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.0
Reported for operating system, platform: Mac OS X (All), PowerPC

Comments on the original bug report:

On 2006-01-29 22:41:28 +0000, Ryan C. Gordon wrote:

More Mac OS X warnings...the "deprecated" stuff is deprecated in (I think) the 10.4 SDK, which is all you get on the Intel Macs. We need to get rid of this stuff in some form sooner or later, although it does appear to work for now...at best, QuickDraw will become a slower codepath over time, probably layered on something else, the way Sound Manager eventually got layered inefficiently over CoreAudio.

Here's the gcc4 output:

SDL_QuartzVideo.m: In function 'QZ_FadeGammaOut':
SDL_QuartzVideo.m:365: warning: pointer targets in passing argument 6 of 'CGGetDisplayTransferByTable' differ in signedness
SDL_QuartzVideo.m: In function 'QZ_SetVideoWindowed':
SDL_QuartzVideo.m:808: warning: 'LockPortBits' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:1652)
SDL_QuartzVideo.m:809: warning: 'GetPixBaseAddr' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QDOffscreen.h:364)
SDL_QuartzVideo.m:809: warning: 'GetPortPixMap' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:6049)
SDL_QuartzVideo.m:810: warning: 'GetPixRowBytes' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QDOffscreen.h:376)
SDL_QuartzVideo.m:810: warning: 'GetPortPixMap' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:6049)
SDL_QuartzVideo.m:811: warning: 'GetPixDepth' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:6933)
SDL_QuartzVideo.m:811: warning: 'GetPortPixMap' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:6049)
SDL_QuartzVideo.m:812: warning: 'UnlockPortBits' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:1667)
SDL_QuartzVideo.m: In function 'QZ_LockWindow':
SDL_QuartzVideo.m:1328: warning: 'LockPortBits' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:1652)
SDL_QuartzVideo.m: In function 'QZ_UnlockWindow':
SDL_QuartzVideo.m:1333: warning: 'UnlockPortBits' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:1667)
SDL_QuartzVideo.m: In function 'QZ_DrawResizeIcon':
SDL_QuartzVideo.m:1382: warning: 'SetRect' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2401)
SDL_QuartzVideo.m:1385: warning: 'RectInRgn' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:3206)
SDL_QuartzVideo.m: In function 'QZ_UpdateRects':
SDL_QuartzVideo.m:1434: warning: 'GetPort' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:1862)
SDL_QuartzVideo.m:1436: warning: 'CreateNewPortForCGDisplayID' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:7687)
SDL_QuartzVideo.m:1441: warning: 'SetPort' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:1847)
SDL_QuartzVideo.m:1442: warning: 'LocalToGlobal' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:3705)
SDL_QuartzVideo.m:1444: warning: 'SetPort' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:1847)
SDL_QuartzVideo.m:1446: warning: 'LockPortBits' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:1652)
SDL_QuartzVideo.m:1447: warning: 'LockPortBits' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:1652)
SDL_QuartzVideo.m:1454: warning: 'SetRect' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2401)
SDL_QuartzVideo.m:1458: warning: 'SetRect' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2401)
SDL_QuartzVideo.m:1464: warning: 'CopyBits' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:3370)
SDL_QuartzVideo.m:1469: warning: 'SetPort' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:1847)
SDL_QuartzVideo.m:1474: warning: 'NewRgn' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2877)
SDL_QuartzVideo.m:1475: warning: 'NewRgn' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2877)
SDL_QuartzVideo.m:1477: warning: 'SetEmptyRgn' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:3032)
SDL_QuartzVideo.m:1482: warning: 'SetRectRgn' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:3055)
SDL_QuartzVideo.m:1484: warning: 'UnionRgn' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:3150)
SDL_QuartzVideo.m:1490: warning: 'QDFlushPortBuffer' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:7341)
SDL_QuartzVideo.m:1491: warning: 'DisposeRgn' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2997)
SDL_QuartzVideo.m:1492: warning: 'DisposeRgn' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2997)

--ryan.

On 2006-03-22 12:46:40 +0000, Max Horn wrote:

So to "fix" this, we'd have to move away from QuickDraw completly and try to use e.g. CoreGraphics directly.

I looked into this a loooong time ago (read: 10.1 :-), but back then CoreGraphics just wasn't something you wanted to use to do bitmap graphics (not to mention the docs, or the lack thereof). Maybe the situation has been improved today? Then we could indeed try to do that, and it would possibly even benefit PowerPC users.

On 2006-06-21 04:08:34 +0000, Sam Lantinga wrote:

Moving this to 1.3, since it'll involve a big overhaul of the Quartz driver, and we're going to be doing that in 1.3 anyway...

On 2006-07-25 11:02:32 +0000, Sam Lantinga wrote:

This is implemented in SDL 1.3 in subversion. The Quartz driver is gone, replaced with Cocoa+OpenGL.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: don't know
Reported for operating system, platform: Mac OS X (All), All

Comments on the original bug report:

On 2006-02-21 15:21:34 +0000, Sam Lantinga wrote:

The unicode field of key events should only be set if Unicode translation is enabled.

On 2006-06-23 00:27:48 +0000, Sam Lantinga wrote:

This is fixed in subversion.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.0
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2006-02-07 13:56:01 +0000, Ryan C. Gordon wrote:

From: Christoph Freundl [email protected]
To: [email protected]
Date: Tue, 7 Feb 2006 14:47:02 +0100
Subject: [SDL] Encoding of window captions

Hi,

seeing that there is a discussion about the encoding of Unicode input
messages, I would like to address a slightly related issue regarding
the encoding of window captions for the function SDL_WM_SetCaption().

I have problems with the display of special characters in window
captions. For example, if I like to display the German umlaut "o (o
diaeresis) I have to write it

• in ANSI encoding (or Latin1?) on Windows: "\xF6"
• in UTF-8 encoding on Mac OS X: "\xC3\xB6"
  On Linux I could not figure out a way which works reliably. Sometimes
  it works if I write the "o as plain text in the sourcecode, sometimes
  the UTF-8 encoding looks promising, but it is also possible that I
  cannot get it to work at all. From a glance at the SDL sources I see
  that it depends whether the library has been compiled with Unicode
  support in X (macro X_HAVE_UTF8_STRING) but I can see no way how to
  figure that out in my program. It also seems to me that the used
  windowmanager influences the result.

I can imagine two possible solutions for this: either, the API is
changed such that the caption for SDL_WM_SetCaption() is always in a
fixed encoding (maybe UTF-8?), but then of course recoding the string
on systems that do not support UTF-8 captions is necessary. Or, there
is a function which can tell at runtime the required encoding of
caption strings.

Well, the display of special characters in window captions is probably
also a special problem that occurs not very often, but I am interested
if there is a way to solve my problem.

Regards, Christoph

On 2006-03-12 20:35:19 +0000, Sam Lantinga wrote:

SDL_WM_SetCaption() now takes UTF-8 strings (in CVS)

Please let me know if there are any problems! :)

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• SDL_RenderTarget.patch (SDL_RenderTarget.patch, text/plain, 2006-02-01 04:44:43 +0000, 83230 bytes)
• SDL_RenderTarget.patch (SDL_RenderTarget.patch, text/plain, 2006-02-01 04:56:45 +0000, 81010 bytes)
• SDL13-rendertargetbug-and-colorbufferfloat.diff (SDL13-rendertargetbug-and-colorbu, text/plain, 2006-02-03 02:48:21 +0000, 12237 bytes)

Reported in version: 2.0.0
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-02-01 04:44:13 +0000, Sam Lantinga wrote:

SDL_RenderTarget support has been obsoleted in SDL 1.3 in favor of the Frame Buffer Object extension. However, since people developing for older systems may still fiud this useful, I'm including a cleaned up patch for it here.

On 2006-02-01 04:44:43 +0000, Sam Lantinga wrote:

Created attachment 60
SDL_RenderTarget.patch

On 2006-02-01 04:45:59 +0000, Sam Lantinga wrote:

Date: Mon, 31 Oct 2005 12:53:08 +0100 (CET)
From: Michi Hostettler [email protected]
Subject: [SDL] [SDL-1.3] RenderTargets under Windows

hi,

i've probably found the bug why sdl rendertargets
don't work under windows. if you look at SDL_wingl.c,
WIN_GL_UnlockRenderTarget, the bug is if not
(target->texture) then wglMakeCurrent(GL_hdc, GL_hrc)
is NEVER called, and the buffer is not unbound.

solution: take the call to wglMakeCurrent(GL_hdc,
GL_hrc) out of the if-block.

On 2006-02-01 04:56:45 +0000, Sam Lantinga wrote:

Created attachment 61
SDL_RenderTarget.patch

Removed unnecessary exports diff, which even now doesn't apply cleanly. :)

On 2006-02-03 02:48:21 +0000, Sam Lantinga wrote:

Created attachment 65
SDL13-rendertargetbug-and-colorbufferfloat.diff

Date: Mon, 16 May 2005 17:23:38 +0800
From: Eric Vidal [email protected]
To: [email protected]
Subject: [SDL] [PATCH] Another take at SDL 1.3 rendertarget bug +
ARB_color_buffer_float support

Hello all!

I've attached a patch to SDL 1.3 CVS and I'm requesting your comments.

This patch:

(1) Takes care of robustness issue with attributes on render target
creation. Previously the parameters will be messed up if the array is
not specified in the requested order, and fails to get the remaining
attributes if SDL_GL_RED_SIZE is specified prematurely.

Jonathan Thambidurai's patch addresses this but requires the attributes
to contain two terminating zero's at the end of the attrib array. I
relaxed this restriction by semi-intelligently detecting whether the
zero corresponded to a SDL_GL_RED_SIZE value.

Note that for this to work, the attributes have to be specified in the
enum order (however not all attributes have to be there). As Jonathan
pointed out, the very nature of the array being passed to
SDL_GL_CreateRenderTarget is problematic (and is potentially a buffer
overflow issue as well). Maybe the attribute passing should be
redesigned before it is too late?

(2) Adds support for the GL_ARB_color_buffer_float extension, which
allows floating-point color buffers to be used. Currently this
extension only works on pbuffer render targets, and only on Windows and X11.

Jonathan's previous patch included support for the NV_float_buffer
extension, and he recommended that it be scrapped once the ARB version
is commonplace. To avoid conflicts with code previously written to his
patch (and also to be consistent with the other enum names), I renamed
the attribute from SDL_GL_FLOATINGPOINT to SDL_GL_FLOATBUFFER.

NOTE: As of this writing nVidia has not yet released official drivers
for this ARB extension. The beta drivers contain it, but only on
Windows. That means I haven't tested if the X11 patch works properly
(but I've seen it to fail properly ;) ). Also, if anyone has ATI
hardware around, please check if the patch works as is on your hardware!

I've also attached a very simple program to test the float buffer
functionality. This may be included in the test/ directory for future
SDL releases, if the maintainers so wish. :)

Much thanks to Jonathan for all the help, if it isn't obvious by now. :)

--
Eric Vidal
Lecturer / Graduate Research Assistant, DISCS
Ateneo de Manila University
http://aegis.ateneo.net/evidal/

On 2007-07-03 03:04:47 +0000, Ryan C. Gordon wrote:

Closing as WONTFIX, so this bug which is here for historical purposes isn't listed as open.

--ryan.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: don't know
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2006-01-27 02:32:34 +0000, Sam Lantinga wrote:

Date: Mon, 31 May 2004 15:03:05 +0900
From: ITO Nobuaki [email protected]
Subject: [SDL] cannot enable OpenGL quadbuffer stereo mode on Linux

Hello.

I'm using SDL-1.2 on Linux box with Quadro 4 XGL. Quadro has the VESA 3pin
stereo port, and I attached the stereo shutter glasses to the card. Codes
written with GLUT could drive those glasses correctly, but SDL couldn't even
when SDL_GL_SetAttribute(SDL_GL_STEREO, 1) was called.

With some testing programs, finally I found that OpenGL stereo quadbuffer mode
would be enabled in case that glXMakeCurrent() is called properly after
glXCreateContext(). I know SDL_SetVideoMode() does call X11_GL_MakeCurrent(),
but I don't know the reason why it doesn't work.

Quick hack follows. This patch works fine with SDL-1.2.7.

--- SDL-1.2.7/src/video/x11/SDL_x11gl.c.ste 2004-02-19 02:22:09.000000000 +0900
+++ SDL-1.2.7/src/video/x11/SDL_x11gl.c 2004-05-31 13:25:04.375053196+0900
@@ -126,7 +126,6 @@

    if( this->gl_config.stereo ) {
            attribs[i++] = GLX_STEREO;

•           attribs[i++] = this->gl_config.stereo;
    }
  
    if( this->gl_config.multisamplebuffers ) {
  

@@ -212,6 +211,13 @@
return -1;
}

•   if ( ! this->gl_data->glXMakeCurrent(GFX_Display,
  

•                                        SDL_Window, glx_context) ) {
  

•           SDL_SetError("Unable to make GL context current");
  

•           return -1;
  

•   }
  

•   XSync( GFX_Display, False );  
  

•   gl_active = 1;
  

#else
SDL_SetError("X11 driver not configured with OpenGL");

On 2006-01-27 11:23:28 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2006-04-27 06:05:15 +0000, Sam Lantinga wrote:

This should be fixed in SVN.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.0
Reported for operating system, platform: Windows (All), x86

Comments on the original bug report:

On 2006-01-27 02:21:33 +0000, Sam Lantinga wrote:

Date: Wed, 19 May 2004 00:43:59 -0400
From: "David Ludwig" [email protected]
Subject: [SDL] detecting lost surfaces with SDL's DirectDraw driver

I've been running into some problems using SDL and it's DirectDraw driver.
Any assistance would be greatly appreciated...

I have an SDL application that needs to deal with video mode changes made
from Windows' Display control panel. When the resolution is changed, blits
will work fine (and not report lost surfaces), however the call to SDL_Flip
does not. The application will continue to run except that the screen,
which was created with SDL_SetVideoMode(640, 480, 0, SDL_SWSURFACE), will
not get redrawn. A few runs through the debugger indicated that SDL has a
buffer that gets blitted to the actual screen (in
sdl_dx5video.c:DX5_WindowUpdate). DirectX will indicate that the blit
failed and that it was due to a lost surface. SDL's response is to restore
the surface (through DirectDraw) and try again. The 2nd blit will also
fail, however SDL does not report this error to the application.

What I'd like to be able to do is catch the failed call to SDL_UpdateRect
and then do my own restore. Unfortunately, there does not seem to be a way
to do this, other than modifying the SDL source (which I'd be happy to do,
but would rather avoid if possible) or poking around in data structures
internal to SDL. Is there a better way to do this? Catching
WM_DISPLAYCHANGE messages seems like one possibility, however handling a
DirectDraw error seems like the better way to go.

--
David Ludwig
[email protected]

On 2006-01-27 11:23:28 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2007-02-15 05:35:32 +0000, Ryan C. Gordon wrote:

Ugh, this is a big pain.

If we lose the primary surface, IDirectDrawSurface3_Restore() fails until the resolution is changed back to the original, so it's not just a question of calling it in a loop with some sleep calls thrown in until it passes.

Likely we'd have to tear down the surface and create a new one, and probably take into account the possibility that the pixel format might change. Also, since we want to restore the data from an internal DirectDraw surface, that's probably lost too, anyhow.

I don't really want to add a DirectDraw-specific event to SDL, but the original poster is right...the simplest way to handle this is to tell the app to call SDL_SetVideoMode() again and recreate the contents of the screen surface.

What a mess. I'm flagging this as WONTFIX, since there's really no good solution here in 1.2 and it's less relevant with windib becoming primary (this problem is directx specific)...and it wouldn't hit most people anyhow.

If anyone has a better idea, please reopen the bug and discuss it.

--ryan.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• libsdl-PIC-hermes-call-dont-jump.patch (libsdl-PIC-hermes-call-dont-jump., text/plain, 2006-03-15 18:31:24 +0000, 5215 bytes)
• libsdl-hidden-nasm.patch (libsdl-hidden-nasm.patch, text/plain, 2006-05-22 01:24:07 +0000, 4094 bytes)

Reported in version: don't know
Reported for operating system, platform: All, x86

Comments on the original bug report:

On 2006-03-08 01:10:32 +0000, Sam Lantinga wrote:

Date: Tue, 7 Mar 2006 02:05:09 -0500
From: Mike Frysinger [email protected]
Subject: Re: [SDL] [patch] PIC support in Hermes

On Wednesday 01 March 2006 19:32, Mike Frysinger wrote:

rather than doing all the funky stuff with PIC, just mark all the symbols
hidden ... then you dont have to change anything else ...

you can find my patch to add elf visibility support to nasm here:
http://dev.gentoo.org/~vapier/patches/nasm-elf-visibility.patch

then simply add 'hidden' to the decl:
GLOBAL _mmxreturn:function hidden

and many of the TEXTRELs should magically vanish :)
-mike

On 2006-03-15 18:31:24 +0000, Alex Volkov wrote:

Created attachment 82
libsdl-PIC-hermes-call-dont-jump.patch

I think the proper way to resolve these TEXTREL problems is to apply the libsdl-PIC-hermes-call-dont-jump.patch mentioned on the list. This will get rid of the _mmxreturn and and _x86return labels, period. Using jumps in those cases serves no real purpose from the optimizations' point of view -- saving and reloading the return address from the stack is so cheap compared to other operations inside the loop.

On 2006-03-15 18:56:37 +0000, Mike Frysinger wrote:

maybe, but it's even cheaper to not even touch the stack

On 2006-03-20 01:45:39 +0000, Sam Lantinga wrote:

(In reply to comment # 0)

Date: Tue, 7 Mar 2006 02:05:09 -0500
From: Mike Frysinger [email protected]
Subject: Re: [SDL] [patch] PIC support in Hermes

On Wednesday 01 March 2006 19:32, Mike Frysinger wrote:

rather than doing all the funky stuff with PIC, just mark all the symbols
hidden ... then you dont have to change anything else ...

you can find my patch to add elf visibility support to nasm here:
http://dev.gentoo.org/~vapier/patches/nasm-elf-visibility.patch

then simply add 'hidden' to the decl:
GLOBAL _mmxreturn:function hidden

Can you explain to me how this fixes the problem? Doesn't the address still have to be relocated at object load?

On 2006-03-20 19:18:50 +0000, Mike Frysinger wrote:

Doesn't the address still have to be relocated at object load?

it doesnt ... that's the magic part :)

default visibility means the symbol is exported and usuable by any external program ... so currently, people could declare an extern '_mmxreturn' function in their code and then call that location (even though it'd prob crash horribly)

but since the symbol is exported, the actual address wont really be known until load time so all of the absolute references need to be fixed up at runtime

if the symbol is marked as hidden, the linker will know that the symbol is not supposed to be exported and can rewrite all references to it at link time so that it no longer exists ... so all of the 'jmp _mmxreturn' lines get rewritten with relative jump's ... thus there's nothing left to fixup at runtime

the other nice benefit is you shrink the exported symbol table a little bit so there's less symbols to process at runtime ... all such private non-static SDL functions could benefit from being marked hidden

On 2006-05-22 01:24:07 +0000, Mike Frysinger wrote:

Created attachment 132
libsdl-hidden-nasm.patch

here's the patch i posted here:
http://www.libsdl.org/pipermail/sdl/2006-March/073618.html

this will hide the symbols dynamically if the build nasm/yasm supports the hidden stuff ... in other words, this patch should be safe with both older and new versions of nasm/yasm

On 2006-06-21 03:58:16 +0000, Sam Lantinga wrote:

This is in subversion, thanks!
I tweaked the patch slightly to handle older versions of nasm, which don't support :function syntax on Win32.

On 2006-06-21 04:14:28 +0000, Mike Frysinger wrote:

erm, sorry, but i forgot to update the patch here ...

the file "common.asm" needs to be renamed to "common.inc" otherwise the build system will try and compile it into the library:

SOURCES="$SOURCES $srcdir/src/hermes/*.asm"

On 2006-06-21 04:27:42 +0000, Sam Lantinga wrote:

Got it, thanks!

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.0
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-01-30 02:43:20 +0000, Sam Lantinga wrote:

Date: Fri, 28 Oct 2005 04:47:13 -0400
From: Donny Viszneki [email protected]
Subject: [SDL] [PATCH] SDL_GetKeyRepeat

I've found it useful to fetch the key repeat state so that various
libraries for GUI elements can cooperate with the application utilizing
them (that is to say, restore the host application's key repeat state
once GUI elements no longer possess "keyboard focus.") This patch is
based on the source code release of SDL 1.2.8, but I doubt this code
has changed much.

SDL-1.2.8$ diff src/events/SDL_keyboard.c.original
src/events/SDL_keyboard.c
571a572,578

void SDL_GetKeyRepeat(int *delay, int *interval)
{
*delay = SDL_KeyRepeat.delay;
*interval = SDL_KeyRepeat.interval;
return;
}

SDL-1.2.8$ diff include/SDL_keyboard.h include/SDL_keyboard.h.original
91d90
< extern DECLSPEC void SDL_CALL SDL_GetKeyRepeat(int *delay, int
*interval);

On 2006-03-14 02:06:49 +0000, Sam Lantinga wrote:

This is in CVS, thanks!

This bug report was migrated from our old Bugzilla tracker.

Reported in version: don't know
Reported for operating system, platform: Windows (All), x86

Comments on the original bug report:

On 2006-01-27 01:30:27 +0000, Sam Lantinga wrote:

Date: Fri, 27 Feb 2004 17:25:49 -0800
From: "Stephen Anderson" [email protected]
Subject: [SDL] Win32 Mouse Acceleration

Hello,

When running under WinXP in fullscreen mode, I don't seem to have any mouse
acceleration.

On 2006-01-27 11:23:27 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2006-03-14 01:15:46 +0000, Sam Lantinga wrote:

This is "fixed" in CVS, by using the windib driver instead of DirectInput...

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• SDL-xrandr.patch (SDL-xrandr.patch, text/plain, 2006-01-29 23:15:58 +0000, 12710 bytes)
• SDL-xrandr.patch (SDL-xrandr.patch, text/plain, 2006-01-29 23:17:01 +0000, 12435 bytes)

Reported in version: don't know
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2006-01-29 23:15:42 +0000, Sam Lantinga wrote:

Date: Tue, 22 Feb 2005 17:09:16 +0900
From: Aric Cyr [email protected]
To: [email protected]
Subject: [SDL] [PATCH] XRandR video mode support
-- Message: 14676 -- Next: 14677 N -- (1/2) in thread -------------------
Seeing as I couldn't find a patch for SDL to use the XRandR (resize
and rotate) extension, I whipped one up myself. I have tested it with
a couple of the applications in the SDL test/ directory, and all
seemed to function just fine. Switching back and forth between
fullscreen and window mode caused no problems.

Since the patch current makes XRandR higher priority than the old
XVidMode extension, I added an environment variable to disable XRandR
at runtime. The patch also includes documentation for this env var.

XRandR support can also be compile-time disabled with
--disable-video-x11-xrandr when running configure (I defaulted it to
enable if the Xrandr header file is found).

I applied the patch against the latest CVS (2005-02-22 JST) with no
problem, and it seems to apply cleanly to 1.2.7 as well.

I'm interested in hearing any feedback! I am not very familiar with
the XRandR extension, and the docs/man page for leave much to be
desired. Much of my code is based on the "xrandr" application and
reading the source for libXrandr.so. If there are any errors, please
let me know.

Thanks,
Aric

On 2006-01-29 23:15:58 +0000, Sam Lantinga wrote:

Created attachment 51
SDL-xrandr.patch

On 2006-01-29 23:17:01 +0000, Sam Lantinga wrote:

Created attachment 52
SDL-xrandr.patch

Date: Tue, 22 Feb 2005 19:18:05 +0900
From: Aric Cyr [email protected]
To: [email protected]
Subject: Re: [SDL] [PATCH] XRandR video mode support
-- Message: 14677 -- Next: 14680 N -- (2/2) in thread -------------------
Here is a new and improved version of the XRandR patch.... this one is
better tested and includes two important fixes:

1. the video mode list is sorted largest to smallest, instead of
   vice-versa. This meant that some of the resolution matching
   logic had to be reversed, so set_best_resolution() changed a fair
   bit for the XRandR case.

2. freeing of the screen_config state variable was removed from
   X11_DestroyWindow() and placed into X11_FreeVideoModes(). This
   fixes a segfault for applications that destroy and recreate their
   windows and use XRandR for mode switching (i.e. UT2004).

I have only tested on an GeForce and an Radeon system in Linux. I'd
like to get this tested on a few more systems that support XRandR, so
please try it out and let me know how it goes.

On 2006-03-14 14:59:56 +0000, Ryan C. Gordon wrote:

I'm looking into this patch...probably have to clean up the dynamic X11 code a little first.

--ryan.

On 2006-03-22 06:14:15 +0000, Ryan C. Gordon wrote:

Xrandr support in now in CVS.

--ryan.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: don't know
Reported for operating system, platform: Windows (All), x86

Comments on the original bug report:

On 2006-02-08 12:14:32 +0000, Sam Lantinga wrote:

Date: Mon, 6 Feb 2006 11:41:04 -0500
From: "[email protected]" [email protected]
Subject: [SDL] ALT-F4 using DirectX

My game isn't getting SDL_QUIT when I press ALT-F4 using the DirectX
driver; it does get SDL_QUIT when I press the red X in the window.

I tracked this down to DX5_HandleMessage() in SDL_dx5events.c;
WM_SYSKEYDOWN is being trapped and ignored which causes Windows not to post
a WM_CLOSE, hence no SDL_QUIT is being generated.

The relevant code is this :

            /* The keyboard is handled via DirectInput */
            case WM_SYSKEYUP:
            case WM_SYSKEYDOWN:
            case WM_KEYUP:
            case WM_KEYDOWN: {
                    /* Ignore windows keyboard messages */;
            }
            return(0);

If I comment the WM_SYSKEYDOWN case, it falls through DefWindowProc() and
ALT-F4 starts working again.

I'm not sure about the best way to fix this. One option is handling ALT-F4
as a particular case somehow, but doesn't sound good. Another option would
be to handle WM_SYSKEYDOWN separately and breaking instead of returning 0,
so processing falls through and goes to DefWindowProc which does The Right
Thing (TM). This seems to be the minimal change that makes ALT-F4 work and
normal keyboard input continues to work.

Does this sound reasonable? Am I overlooking anything? Do I submit a patch?

--Gabriel

On 2009-09-26 23:50:04 +0000, Sam Lantinga wrote:

I'm hesitant to change behavior at this point in SDL 1.2 development. You're always welcome to catch ALT-F4 yourself and shut down the application.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: don't know
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-01-27 03:04:41 +0000, Sam Lantinga wrote:

Date: Tue, 1 Jun 2004 00:06:47 +0000 (UTC)
From: GregLee [email protected]
Subject: [SDL] surround sound

Having just bought an Audigy sound card and some
speakers, I've been looking for easy ways to get
surround sound. Alsa does 4 or 6 channel sound
straightforwardly, if you can find stuff to feed
it with. It's pretty easy to patch a couple of
SDL audio routines to get surround sound, using the
alsa driver.

I put the two small patches, an example multi-channel
.wav player (which does nothing special except ask
for the alsa driver), and example 4 and 6 channel
.wav files here:

ftp://ling.lll.hawaii.edu/pub/greg/Surround-SDL.tgz

Greg

On 2006-01-27 03:06:09 +0000, Sam Lantinga wrote:

Oh yeah, this is already in. :)

On 2006-01-27 11:23:28 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: don't know
Reported for operating system, platform: Other, x86

Comments on the original bug report:

On 2006-01-20 08:03:36 +0000, Sam Lantinga wrote:

Date: Thu, 19 Jan 2006 20:02:29 +0200
From: Vassilis Virvilis [email protected]
Subject: [SDL] Request: Please reconsider adding tag in SDL_Event

Hi,

Patch in question:

--- include/SDL_events.h 20 Aug 2004 18:57:01 -0000 1.11
+++ include/SDL_events.h 19 Jan 2006 17:35:09 -0000
@@ -214,7 +214,7 @@
} SDL_SysWMEvent;

/* General event structure */
-typedef union {
+typedef union SDL_Event {
Uint8 type;
SDL_ActiveEvent active;
SDL_KeyboardEvent key;

Reasoning:

1. Allows forward declaration of the SDL_Event union in C++. Please
   note that in plain C it is possible to forward declare it.

2. Forward declaration is good because it allows encapsulation. It hides
   the specific implementation and does not necessarily exposes SDL staff
   to my appication's namespace

3. It can't harm plain C because tags are living in a different namespace
   than typenames

4. It is already done like this in other places in SDL. Check for example
   SDL_KeySym, and SDL_.*Event structures.

5. Right now I have to include SDL/event.h from a C++ header file. See 2)

short FAQ:

Q1: The code as it is currently does not compile?
A: No it compiles fine. I just don't want to include it in my public header
if I can avoid it.

Consider the following minimal example. It is valid
C but not valid C++.

---------- cut here -----------
/* this is a forward declaration */
union Foo;

/* and here is the complete type */
typedef union {
int i;
float f;
double d;
} Foo;

int main()
{
return 0;
}
---------- cut here -----------

The error coming from g++ is
fdecl.c:7: error: conflicting declaration 'typedef union Foo Foo'
fdecl.c:1: error: 'union Foo' has a previous declaration as 'union Foo'

If you change it to
typedef union Foo {
...
} Foo;

It compiles fine under g++ 4.0.1 (Debian sarge)
------------------

Q2: Are you sure you know the difference between type and tag in C? in C++?
A: I think so. Types and tags are different animals in C, but C++ treats them
the same. Problem is: in C++ you forward declare a previously typedefed type
unless it has a tag associated with it (gross oversimplification).
------------------

Q3: I don't see a problem here.
A: Please then do it for uniformity and consistency. Consider the following
fragment from SDL sources

/* Mouse button event structure /
typedef struct SDL_MouseButtonEvent {
Uint8 type; / SDL_MOUSEBUTTONDOWN or SDL_MOUSEBUTTONUP /
Uint8 which; / The mouse device index /
Uint8 button; / The mouse button index /
Uint8 state; / SDL_PRESSED or SDL_RELEASED /
Uint16 x, y; / The X/Y coordinates of the mouse at press time *
} SDL_MouseButtonEvent;

Here both the type and the tag have the same name SDL_MouseButtonEvent. Why not
also the SDL_Event union?
------------------

Q4: For such a small patch, do you actually need all these arguments?
A: Well, I think it's the right thing to do and I am trying to prove it by
technical arguments. Since this the second time I try it I would like to have
done my best effort to be understandable, before the SDL developers shot me
down.
------------------

 .bill

On 2006-01-27 11:23:18 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.0
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-01-24 02:35:25 +0000, Sam Lantinga wrote:

We really need a way for the application to query and set refresh rates. Currently SDL uses the lowest refresh rate in many cases, for safety.

On 2006-01-27 11:23:23 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2006-06-21 04:12:47 +0000, Sam Lantinga wrote:

This API is now available in SDL 1.3, though the video drivers still need to be rewritten to support it.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.0
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-01-25 04:41:12 +0000, Mikael Eriksson wrote:

Please add a --gl-cflags and --gl-libs to the sdl-config script.
This will simplify linking with the platforms gl libraries.

On 2006-01-27 11:23:24 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2008-11-20 23:31:35 +0000, Donny Viszneki wrote:

This solution is incompatible with developers using pkg-config. To satisfy that use case, SDL ought to come with two separate pkg-config (".pc") files, one providing OpenGL linkage.

On 2009-12-14 22:10:07 +0000, Ryan C. Gordon wrote:

After discussion and consideration, we're not going to do this. We really shouldn't be adding more to sdl-config, but rather phasing it out.

--ryan.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.0
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-01-12 17:25:17 +0000, Ryan C. Gordon wrote:

So we can sanity check the final binaries for missing targets, and also so these can be programmatically discovered and chosen (environment variables don't count!).

--ryan.

On 2006-01-19 07:45:22 +0000, Sam Lantinga wrote:

*** Bug 54 has been marked as a duplicate of this bug. ***

On 2006-01-27 11:23:14 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2006-04-17 03:49:31 +0000, Max Horn wrote:

Indeed, we've had to tell too many of our users (IMHO :-) about how to use those arcane SDL_* env vars to get ScummVM working on their system. It would be so much nicer if we could provide our own configuration option for this, w/o hacking up the env vars before calling SDL code...

On 2006-05-20 00:35:45 +0000, Sam Lantinga wrote:

This is implemented in SDL 1.3:
Added SDL_GetNumVideoDrivers() and SDL_GetVideoDriver().
Replaced SDL_VideoDriverName() with SDL_GetCurrentVideoDriver()
Added SDL_GetNumAudioDrivers() and SDL_GetAudioDriver().
Replaced SDL_AudioDriverName() with SDL_GetCurrentAudioDriver()

You can already initialize specific drivers:
SDL_VideoInit(), SDL_AudioInit()

This bug report was migrated from our old Bugzilla tracker.

Reported in version: don't know
Reported for operating system, platform: Other, x86

Comments on the original bug report:

On 2006-01-24 00:27:53 +0000, Sam Lantinga wrote:

Date: Tue, 18 Mar 2003 17:52:57 +0200
From: Pasi K

On 2006-01-24 00:28:38 +0000, Sam Lantinga wrote:

From Brian Paul:
The glXReleaseBuffersMESA() function in DRI's libGL is just a no-op stub so
I'm not sure where the segfault is coming from.

I think it's clear that SDL should check the GLX extension string for
"GLX_MESA_release_buffers" and only call glXReleaseBuffersMESA() when the
extension is present.

-Brian

On 2006-01-27 11:23:21 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2006-01-31 17:08:10 +0000, wrote:

Btw, if you leave this code in, ExtensionSupported("glXReleaseBuffersMESA") is definitely wrong. ExtensionSupported looks at gl extensions (while this is glx) and the extension name is GLX_MESA_release_buffers, not glXReleaseBuffersMESA.

On 2006-03-19 03:14:32 +0000, Sam Lantinga wrote:

glXReleaseBuffersMESA has been removed.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: don't know
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-03-31 01:11:37 +0000, Sam Lantinga wrote:

Date: Wed, 29 Mar 2006 12:38:27 -0500
From: "Shane M. Walton" [email protected]
Subject: Re: [SDL] SDL_DisplayYUVOverlay() segmentation fault

I wanted to add some information and rephrase my question.

The testoverlay.c and testoverlay2.c fail when the SDL_Rect.x/y != 0.
The following occurs:

Created 64x88X3 software YV12 overlay
...
X Error failed request: BadValue (integer parameter out of range for
operation)
Major opcode of failed request: 145 (MIT-SHM)
Minor opcode of failed request: 3 (X_ShmPutImage)
Value in failed request: 0x1b8
Serial number of failed request: 40
Current serial number in output stream: 41

On 2006-04-17 01:40:18 +0000, Sam Lantinga wrote:

This is fixed in CVS.

On 2006-04-17 01:56:37 +0000, Sam Lantinga wrote:

Actually, this is active for all overlay drivers.

On 2006-04-17 02:46:47 +0000, Sam Lantinga wrote:

The clipping is done at a higher level, and the low level functions are
passed clipped rectangles. Drivers which don't support source clipping
have not been changed, so the image will be squished instead of clipped,
but at least they will no longer crash when the destination rect was out
of bounds.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Test.cpp (Test.cpp, text/plain, 2006-01-29 01:59:17 +0000, 2893 bytes)
• font.png (font.png, image/x-png, 2006-01-29 01:59:44 +0000, 4305 bytes)

Reported in version: don't know
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2006-01-29 01:59:01 +0000, Sam Lantinga wrote:

Date: Mon, 27 Dec 2004 15:09:49 +0100
From: Gaetan de Menten [email protected]
Subject: [SDL] Double buffering, DGA and SDL_DisplayFormat => problem?

Hello,

I recently noticed my current game doesn't work well with double
buffering enabled on the DGA backend (it works fine on the X11
backend). It seems like my sprites get all swapped (one sprite take
the place of another one) and some of them are slightly grabbled.

During my search for the bug, I noticed that if I didn't convert my
sprites to the display format, the bug disappeared, and if I convert
them multiple times in a row, the bug is more noticeable...

Attached is a minimal code sample and my font bitmap. That sample
first loads the font bitmap (using SDL_image), splits it in several
individual surfaces (one for each character) and then converts each of
these surfaces to the display format multiple times in a row...
Finally, it displays the first 26 characters of my font, which are
"!.0123456789:?ABCDEFGHIJK".

With the default backend (x11) , it works just fine. With the dga
backend (you have to set the SDL_VIDEODRIVER environment variable to
"dga" and run the program as root), the display looks like
"!!0022446688...". Although it seems weird to me, the result is
consistent from one run to the other (always the same result) on my
computer (might not be the case on someone else's computer).

I suppose it's much more likely the bug is in my code and not in SDL
but since I'm getting crazy with it, could someone look at it and tell
me what I'm doing wrong? It's probably something obvious that I don't
see because I've been looking at that code for too long...

For what it's worth, I'm using Debian unstable, but I tried with a
hand-compiled version of SDL too (CVS from yesterday) and the results
are the same.

-Gaetan.

On 2006-01-29 01:59:17 +0000, Sam Lantinga wrote:

Created attachment 49
Test.cpp

On 2006-01-29 01:59:44 +0000, Sam Lantinga wrote:

Created attachment 50
font.png

On 2006-05-06 11:15:19 +0000, Ga wrote:

Just in case you need more information, please direct your mails to "ged bugfactory org", I don't use the other address anymore...

On 2006-05-07 17:15:42 +0000, Sam Lantinga wrote:

I'd like to get this fixed for SDL 1.2.10 release, if possible.

On 2006-05-09 02:45:13 +0000, Sam Lantinga wrote:

This is fixed in subversion - thanks for the great test case!

This bug report was migrated from our old Bugzilla tracker.

Reported in version: don't know
Reported for operating system, platform: Windows (All), x86

Comments on the original bug report:

On 2006-01-30 01:12:16 +0000, Sam Lantinga wrote:

Date: Sun, 6 Mar 2005 17:06:20 +0100
From: Per Inge Mathisen [email protected]
Subject: [SDL] Fullscreen refresh on win32

Windows has a terrible default for fullscreen 3D apps of 60mhz refresh
rate. This can be fixed by the user by going into his driver's
control panel and forcing the refresh rate higher. However, this not a
very user friendly way about it, and in any case SDL contains no code
that could figure out this that condition has afflicted the user.

So the question is, could SDL fix this for the user? It is possible
under Windows to request a higher refresh rate. The danger is of
course that if the user has an old monitor, and you request a too high
refresh rate, the monitor could be damaged. However, I believe there
might be a way around that: Check before switching what refresh rate
the user's desktop runs in, and if our fullscreen dimensions are equal
or less than those of the desktop, use the higher refresh rate of 60
and the desktop rate.

Since most users run their desktops in the same or higher resolution
something sane, this should fix this problem for most users.

Thoughts?

An alternative is to add an SDL_GL_GetAttribute(SDL_GL_REFRESH_RATE)
option so that programs can bitch at their users at their own
convenience.

• Per

On 2006-01-30 01:14:05 +0000, Sam Lantinga wrote:

This is a really good idea, actually, and can be generally applied to all video drivers.

Of course, the first step is figuring out the current desktop refresh rate... :)

On 2006-01-30 01:56:34 +0000, Sam Lantinga wrote:

This is now implemented in CVS, thanks!

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.0
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-02-03 21:16:45 +0000, Daniel Broschart wrote:

In order to find any new joysticks that have been plugged into the system since the SDL application has been running, I have to quit the Joystick subsystem and then re-initialize it before the new joysticks will be detected.

On 2006-03-01 16:00:46 +0000, Patrice Mandin wrote:

Yes, maybe an event could be generated when a new device usable by SDL is plugged/unplugged on the system. As you said, it can be joysticks, but it could be a monitor (for example for laptops), an audio card (there are USB ones), a keyboard, a mouse, and many more.

Example: When you play solo a 2D fighting game, and a friend comes and plug his joystick, the game would announce "a new challenger is coming...".

On 2006-04-28 16:14:57 +0000, Daniel Broschart wrote:

When I execute my code on a different computer the application does not detect ANY joysticks (I have a CH Fighterstick USB, and a Belkin Nostromo n52 Speedpad) when I swap the ports that the joysticks are plugged into, and then hit the button that rescans for connected joysticks (which includes exiting and re-entering the Joystick subsystem).

On 2006-04-28 17:18:44 +0000, Daniel Broschart wrote:

I recompiled with some debugging info and found that the line 184 in SDL_mmjoystick.c:

result = joyGetPosEx(SYS_JoystickID[i], &joyinfo);

returned 167 for the joysticks after they had been swapped, which is the JOYERR_UNPLUGGED return code.

On 2006-04-28 17:29:55 +0000, Daniel Broschart wrote:

Oh, and at that line of code for all of the other joystick slots the system returned JOYERR_PARMS before and after the switch (which I assume is to be expected).

On 2006-05-13 08:26:08 +0000, Max Horn wrote:

A patch of mine for the Windows Joystick code was recently commited to CVS/SVN, which should help the issue mentioned by Daniel in comments # 2-# 4. But of course it doesn't address the (design/API) issue that is the main subject of this report.

Daniel, can you confirm this?

On 2006-10-28 20:35:48 +0000, Ryan C. Gordon wrote:

Grabbing this bug for consideration in SDL 1.3...

--ryan.

On 2009-12-15 22:37:34 +0000, Ryan C. Gordon wrote:

Changing bug priorities...

--ryan.

On 2012-01-27 10:44:24 +0000, Rodrigo Cardoso wrote:

Any news about this one?

If not, where can I start looking to make this work in Mac OS X? I need this functionality.

Thanks

On 2013-05-21 00:47:04 +0000, Sam Lantinga wrote:

This is implemented in the current SDL snapshot:
http://www.libsdl.org/tmp/SDL-2.0.zip

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Patch for Xinerama support in SDL (sdl.diff, text/plain, 2006-01-26 01:47:54 +0000, 2692 bytes)

Reported in version: don't know
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2006-01-16 15:07:13 +0000, Michael Geddes wrote:

Radeon has a built-in Xinerama mode that nearly everything else seems to be able to detect and play nicely with except for SDL.

It's the standard Xinerama problem where going fullscreen splits you across the two screens - even if the size of the application is only the size of 1 screen.

On 2006-01-26 01:47:54 +0000, Sam Lantinga wrote:

Created attachment 38
Patch for Xinerama support in SDL

Date: Thu, 13 Nov 2003 12:21:05 +0100
From: Stefan Dirsch [email protected]
Subject: [SDL] Patch for Xinerama/Fullscreen support

Hi

I made a small patch to handle fullscreen support in Xinerama in a
better way, so that the application now starts on the first Xinerama
"screen" and not any longer above all Xinerama "screens". I found
Xinerama suppport already in SDL (1.2.5), but it was disabled as it
simply doesn't work correctly.

Any discussion about my patch would be appreciated. Maybe it will be
applied (in an improved form) for future releases of SDL.

Stefan

On 2006-01-27 11:23:15 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2006-05-04 12:50:48 +0000, Sam Lantinga wrote:

This is fixed in Subversion with a complete rework of the Xinerama support.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: don't know
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-01-27 00:29:36 +0000, Sam Lantinga wrote:

Date: Mon, 23 Feb 2004 14:49:48 -0500
From: "Millaway, John" [email protected]
Subject: [SDL] SetAlpha silently fails without error for SDL_DisplayFormatAlpha

Hi,

SetAlpha silently fails without error if the surface was created with
SDL_DisplayFormatAlpha() instead of SDL_DisplayFormat(). This should be
documented or at least return an error code.

On 2006-01-27 11:23:27 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2006-03-20 01:37:47 +0000, Sam Lantinga wrote:

This is fixed in CVS:
The palette -> RGBA blit wasn't following the rule:

• RGB->RGBA:

• SDL_SRCALPHA not set:
  

•  copy RGB, set destination alpha to source per-surface alpha value.
  

Please reopen this bug if there are any other cases that aren't working correctly.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: don't know
Reported for operating system, platform: Windows (All), x86

Comments on the original bug report:

On 2006-01-17 03:35:03 +0000, Ryan C. Gordon wrote:

Date: Fri, 13 Jan 2006 18:09:45 -0500
From: mhall4400 vipmail kvcc edu
Subject: Possible SDL bug

Greetings

I believe I

On 2006-01-27 11:23:15 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2006-03-14 00:34:50 +0000, Sam Lantinga wrote:

This is fixed in CVS, thanks!

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.0
Reported for operating system, platform: Windows (All), x86

Comments on the original bug report:

On 2006-01-24 02:39:33 +0000, Sam Lantinga wrote:

Date: Sat, 9 Aug 2003 19:41:11 +0200
From: Ignacio Castano [email protected]
Subject: [SDL] Behaviour of ChoosePixelFormat

The wgl's ChoosePixelFormat function uses some kind of euristic to return
the closest match to the given pixel format descriptor, whereas both, the
ARB's ChoosePixelFormat and the glX's ChooseVisual suceed only if they find
a pixel format that matches the given attributes. Since SDL abstract those
details, your apps may have different behaviours depending on the platform
or target machine.

For example, if you request a 32bit pixel format, when only 16bits is
available, wgl will return a 16bit pixel format, while the ARB and glX code
path will fail.

It would be nice to have a consistent behaviour in different targets, and
that can be done replacing wgl's ChoosePixelFormat with your own function. I
can provide such replacement if there's enough interest.

--
Ignacio Castano
[email protected]

On 2006-01-24 02:40:21 +0000, Sam Lantinga wrote:

The following code enumerates the existing pixel formats and returns the
index of the first matching pixel format. Returns 0 if no matching pixel
format available.

static int MyChoosePixelFormat( HDC hdc, const PIXELFORMATDESCRIPTOR *
target ) {

PIXELFORMATDESCRIPTOR pfd;

int format_num = DescribePixelFormat( hdc, 1, sizeof(pfd), NULL );

int format_idx;
for( format_idx = 1; format_idx <= format_num; format_idx++ ) {

if( !DescribePixelFormat( hdc, format_idx, sizeof(pfd), &pfd ) ) {
// error?
continue;
}

if( (pfd.dwFlags & target->dwFlags) != target->dwFlags ) continue;

if( pfd.iPixelType != target->iPixelType ) continue;

if( pfd.cColorBits < target->cColorBits ) continue;
if( pfd.cRedBits < target->cRedBits ) continue;
if( pfd.cGreenBits < target->cGreenBits ) continue;
if( pfd.cBlueBits < target->cBlueBits ) continue;
if( pfd.cAlphaBits < target->cAlphaBits ) continue;
if( pfd.cAccumBits < target->cAccumBits ) continue;
if( pfd.cAccumRedBits < target->cAccumRedBits ) continue;
if( pfd.cAccumGreenBits < target->cAccumGreenBits ) continue;
if( pfd.cAccumBlueBits < target->cAccumBlueBits ) continue;
if( pfd.cAccumAlphaBits < target->cAccumAlphaBits ) continue;
if( pfd.cDepthBits < target->cDepthBits ) continue;
if( pfd.cStencilBits < target->cStencilBits ) continue;

return format_idx;
}

return 0;
};

On 2006-01-27 11:23:23 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2007-07-04 14:42:47 +0000, Sam Lantinga wrote:

At this point, I don't want to introduce a change in 1.2 that would cause an OpenGL context to fail when it didn't previously, even if it makes it more consistent across platforms.

It might be worth making a change like this in 1.3, but we would need to make a more robust pixel format choosing function - one that tries to get a closest match rather than just enforcing a minimum.

On 2007-07-04 23:15:04 +0000, Sam Lantinga wrote:

This is fixed in 1.3 in subversion revision 3150.

On 2014-03-20 00:07:01 +0000, Jānis Rūcis wrote:

Hi,

We're currently having to work around an issue in SDL2 that seems to be directly related to this old bug report. There is still some inconsistent behavior when it comes to handling attributes such as SDL_GL_MULTISAMPLESAMPLES. Requesting an excessive number of samples fails on Linux, but succeeds on Windows resulting in a context below minimum specifications:

Neverball/neverball#49

On 2018-08-06 21:20:18 +0000, Ryan C. Gordon wrote:

Hello, and sorry if you're getting dozens of copies of this message by email.

We are closing out bugs that appear to be abandoned in some form. This can happen for lots of reasons: we couldn't reproduce it, conversation faded out, the bug was noted as fixed in a comment but we forgot to mark it resolved, the report is good but the fix is impractical, we fixed it a long time ago without realizing there was an associated report, etc.

Individually, any of these bugs might have a better resolution (such as WONTFIX or WORKSFORME or INVALID) but we've added a new resolution of ABANDONED to make this easily searchable and make it clear that it's not necessarily unreasonable to revive a given bug report.

So if this bug is still a going concern and you feel it should still be open: please feel free to reopen it! But unless you respond, we'd like to consider these bugs closed, as many of them are several years old and overwhelming our ability to prioritize recent issues.

(please note that hundred of bug reports were sorted through here, so we apologize for any human error. Just reopen the bug in that case!)

Thanks,
--ryan.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• SDL-1.2.8_64.diff (SDL-1.2.8_64.diff, text/plain, 2006-01-31 10:38:18 +0000, 33788 bytes)

Reported in version: don't know
Reported for operating system, platform: Windows (XP), x86

Comments on the original bug report:

On 2006-01-31 10:37:04 +0000, Sam Lantinga wrote:

Date: Fri, 29 Jul 2005 01:52:33 +0200
From: Michael Lutz [email protected]
Subject: [SDL] Quick'n'Dirty patch for Win64

Hi,

I made an quick and dirty patch to get SDL 1.2.8 compile cleanly for
Win64 with Visual Studio 2005.

It's not really testet, but the sample seem to work. If anyone is able
to test it more thorougly, it's much apreciated.

Changes:

• Removed c_dfDIKeyboard and friends; wouldn't work otherwise.
• Many explicit typecasting to quiet the compiler.

I've got project files as well, but I don't know if I can attach zip-files.

On 2006-01-31 10:38:18 +0000, Sam Lantinga wrote:

Created attachment 59
SDL-1.2.8_64.diff

There's a lot of typecasting where the SDL types should be extended to handle 64-bit systems. We should probably support this in SDL 1.3, and change the SDL data structures accordingly.

On 2006-01-31 10:49:40 +0000, Ryan C. Gordon wrote:

Some of these changes are better than others...let me clean this one up before committing it.

--ryan.

On 2006-03-09 10:16:37 +0000, Sam Lantinga wrote:

The current CVS code should be fine on Win64 now.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: don't know
Reported for operating system, platform: Windows (All), x86

Comments on the original bug report:

On 2006-01-24 00:20:44 +0000, Sam Lantinga wrote:

Date: Thu, 13 Mar 2003 11:56:55 -0500
From: Mark Aikens [email protected]
Subject: [SDL] Sound under Windows

Hello.

A couple friends and I wrote a game using pygame (which uses SDL) and it
runs great under Linux. However, when running it under Windows, the
music breaks up. Increasing the sound buffer size makes it better but
then the latency of sound effects is terrible.

I traced the problem to the SDL directsound audio driver and modified it
slightly to fix it on my machine. The patch also fixed the breakups on
one of my friend's Windows machine. My other friend reports that the
sound quality got worse with the patch though.

I'm not a DirectSound or Windows expert so maybe someone can explain
what is going on. I've included the patch in this message.

Thanks.

-Mark

P.S. I'm not on the list so please CC me any replies.

Patch Description:
According to DirectX documentation, you're not supposed to write
between the play cursor and the write cursor, only after the write
cursor. Also enabled position notifications by default. Notifications
and polling were both tested and improved sound quality on my machine.

Patch:
--- ../SDL-1.2.5.orig/src/audio/windx5/SDL_dx5audio.c 2002-08-24 13:30:49.000000000 -0400
+++ src/audio/windx5/SDL_dx5audio.c 2003-03-07 18:48:31.000000000 -0500
@@ -37,7 +37,7 @@
#include "SDL_dx5audio.h"

/* Define this if you want to use DirectX 6 DirectSoundNotify interface */
-//#define USE_POSITION_NOTIFY
+#define USE_POSITION_NOTIFY

/* DirectX function pointers for audio */
HRESULT (WINAPI *DSoundCreate)(LPGUID, LPDIRECTSOUND , LPUNKNOWN);
@@ -261,7 +261,7 @@
/ Semi-busy wait, since we have no way of getting play notification
on a primary mixing buffer located in hardware (DirectX 5.0)
*/

•   result = IDirectSoundBuffer_GetCurrentPosition(mixbuf, &cursor, &junk);
  

•   result = IDirectSoundBuffer_GetCurrentPosition(mixbuf, &junk, &cursor);
    if ( result != DS_OK ) {
            if ( result == DSERR_BUFFERLOST ) {
                    IDirectSoundBuffer_Restore(mixbuf);
  

@@ -271,9 +271,8 @@
#endif
return;
}

•   cursor /= mixlen;
  

•   while ( cursor == playing ) {
  

•   while((cursor/mixlen) == playing) {
            /* FIXME: find out how much time is left and sleep that long */
            SDL_Delay(10);
  

@@ -299,12 +298,11 @@

            /* Find out where we are playing */
            result = IDirectSoundBuffer_GetCurrentPosition(mixbuf,

•                                                           &cursor, &junk);
  

•                                           &junk, &cursor);
            if ( result != DS_OK ) {
                    SetDSerror("DirectSound GetCurrentPosition", result);
                    return;
            }
  

•           cursor /= mixlen;
    }
  

}

@@ -353,7 +351,7 @@

    /* Figure out which blocks to fill next */
    locked_buf = NULL;

•   result = IDirectSoundBuffer_GetCurrentPosition(mixbuf, &cursor, &junk);
  

•   result = IDirectSoundBuffer_GetCurrentPosition(mixbuf, &junk, &cursor);
    if ( result == DSERR_BUFFERLOST ) {
            IDirectSoundBuffer_Restore(mixbuf);
            result = IDirectSoundBuffer_GetCurrentPosition(mixbuf,
  

@@ -498,7 +496,7 @@
static int CreateSecondary(LPDIRECTSOUND sndObj, HWND focus,
LPDIRECTSOUNDBUFFER *sndbuf, WAVEFORMATEX *wavefmt, Uint32 chunksize)
{

•   const int numchunks = 2;
  

•   const int numchunks = 8;
    HRESULT result;
    DSBUFFERDESC format;
    LPVOID pvAudioPtr1, pvAudioPtr2;
  

On 2006-01-27 11:23:21 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2006-06-23 05:05:57 +0000, Sam Lantinga wrote:

A variation on this patch is in subversion, and is ready for testing.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: don't know
Reported for operating system, platform: Windows (All), x86

Comments on the original bug report:

On 2006-01-29 15:09:12 +0000, Sam Lantinga wrote:

Date: Sun, 29 Jan 2006 20:45:57 +0100 (CET)
From: "Torsten Giebl" [email protected]
Subject: [SDL] SDL with WinDIB

Hello !

I just compiled the latest SDL CVS version
and when i try to start testsprite for example
the window opens, but i do not see any smilies flying
around. I have to explicitly start it with ./testsprite -bpp 32
to see them. When using Directx instead of WinDIB it works
without problems.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• dm-cvs-20050124144500.diff.txt (dm-cvs-20050124144500.diff.txt, text/plain, 2006-01-30 02:30:00 +0000, 7119 bytes)

Reported in version: 2.0.0
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-01-22 04:55:55 +0000, Ryan C. Gordon wrote:

It would be nice if the application can determine what the current desktop resolution is, which can be useful as a default, or at least a known-good quantity.

My current proposal looks something like this:

int SDL_GetCurrentResolution(SDL_Rect *physical, SDL_Rect *virtual);

On success, (physical) will be the physical resolution of the display at the time of the call, and (virtual) will be filled with the "virtual" resolution (i.e. - an X11 desktop bigger than the physical display that scrolls as the mouse moves around it, etc). Either parameter may be NULL, in which case that parameter won't receive a value.

returns -1 on error (unsupported, hardware error, etc)...use SDL_GetError() for reason for failure. Returns 0 on success.

Issues:

• What to do with multimonitor support?
• Is virtual resolution really useful?
• Should this report the resolution at that moment? Should it change with a successful call to SDL_SetVideoMode(..., SDL_FULLSCREEN)?
• What drivers can actually support this?

--ryan.

On 2006-01-27 11:23:20 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2006-01-30 02:13:01 +0000, Sam Lantinga wrote:

(In reply to comment # 0)

My current proposal looks something like this:
int SDL_GetCurrentResolution(SDL_Rect *physical, SDL_Rect *virtual);

How about SDL_GetDesktopResolution(...)?

Issues:

• What to do with multimonitor support?

Punt until we have multimonitor support in SDL. We'd need to be able to enumerate the attached monitors and specify which one is used in the API calls to list video modes, set video modes, and this one.

• Is virtual resolution really useful?

shrug

• Should this report the resolution at that moment? Should it change with a
  successful call to SDL_SetVideoMode(..., SDL_FULLSCREEN)?

No, it should just report the current desktop resolution, before going to fullscreen. If you're in windowed mode, and the user changes desktop resolution, it should return the new desktop resolution.

• What drivers can actually support this?

Windows can, X11 can, I presume most other systems with a desktop can do this.

On 2006-01-30 02:25:25 +0000, Sam Lantinga wrote:

Date: Tue, 22 Mar 2005 02:50:26 +0000 (UTC)
From: Marco Tarini [email protected]
Subject: [SDL] detecting current screen resolution (again!)

Let me also suggest the simplest way (from the point of view of the
library-user, not the SDL-dev) to have that: make SDL_SetVideoMode(sx,sx,bpp,flags), when

• flags includes SDL_FULLSCREEN and
• (sx,sy,bpp)==(0,0,0)
  set the fullscreen mode at the current screen bpp, size x, and y.

Also, VideoInfo would return screen res as well. BTW isn't it peculiar that it currently doesn't? I wonder if it is that nobody though that it would be useful, or if there is problem I can't see implementing it in some system.

On 2006-01-30 02:27:20 +0000, Sam Lantinga wrote:

Date: Tue, 22 Mar 2005 18:20:37 +0000
From: Jon Colverson [email protected]
Subject: Re: [SDL] detecting current screen resolution (again!)

I wrote a patch to add a function to get the current desktop resolution.
Unfortunately, it's only implemented for X11 and Windows. There was a
thread about it on this list which starts here:

http://www.devolution.com/pipermail/sdl/2005-January/thread.html# 67010
and continues in February:
http://www.devolution.com/pipermail/sdl/2005-February/thread.html# 67335

To summarise the thread:

It was widely agreed that this would be useful functionality. Some
people didn't like my API (int SDL_GetDesktopMode(int *width, int
*height)), and it doesn't allow for complete binary compatibility
(programs that use the new function can't run with earlier SDL 1.2
libs). Stephane Marchesin suggested adding the information to the
SDL_VideoInfo structure. This can't be done without breaking binary
compatibility, so will have to wait for SDL 1.3 (I don't know if there's
a schedule for that yet). Simon Roby suggested the same API as you did
above. I was not wild about it, because it makes it harder/more
error-prone to specify a fallback default resolution, which is
particularly important when the functionality isn't implemented for all
the SDL platforms/video drivers.

Sam Lantinga (lead developer of SDL) chimed in that he likes the idea of
using 0,0 in SDL_SetVideoMode to specify the desktop resolution, which
can be done now, in SDL 1.2. He also likes the idea of adding the
desktop resolution to SDL_VideoInfo at a later date.

So, it seems like it would be sensible for me to rewrite my patch to use
the 0,0 API, make sure it's documented well to minimise problems, and
accept a little ugliness in our application code which can be removed
when SDL 1.3 is available. I'll get to work on it, since Ryan just made
a call for patches, and that would seem like a good chance of getting my
code commited and in the next release.

--
Jon

On 2006-01-30 02:30:00 +0000, Sam Lantinga wrote:

Created attachment 54
dm-cvs-20050124144500.diff.txt

Here's Jon's patch to add this function to the API

On 2006-01-30 02:31:43 +0000, Sam Lantinga wrote:

Ryan, is there value to adding an API function in addition to simply adding the information to the VideoInfo structure in 1.3?

On 2006-01-30 10:28:21 +0000, Ryan C. Gordon wrote:

Adding to the structure is better, so long as it doesn't break binaries that expect it to be a certain size, which was what I was aiming to avoid...in this case, it's probably safe if you add it to the end of the struct.

--ryan.

On 2006-01-31 09:09:42 +0000, Sam Lantinga wrote:

(In reply to comment # 7)

Adding to the structure is better, so long as it doesn't break binaries that
expect it to be a certain size, which was what I was aiming to avoid...in this
case, it's probably safe if you add it to the end of the struct.

That seems reasonable. I'm tempted to add it to 1.3, since I can easily see that information followed up with requests to get/set the window position programmatically - one of the items on the 1.3 TODO list. What do you think?

On 2006-01-31 10:37:43 +0000, Ryan C. Gordon wrote:

Yeah, I think that's a good 1.3 candidate.

--ryan.

On 2006-03-15 12:46:10 +0000, Sam Lantinga wrote:

Added current_w and current_h to the SDL_VideoInfo structure, which is set to the desktop resolution during video intialization, and then set to the current resolution when a video mode is set.

SDL_SetVideoMode() now accepts 0 for width or height and will use the current video mode (or the desktop mode if no mode has been set.)

We can add something like SDL_GetDesktopResolution() for 1.3, so I'll leave this bug open, and move it to a 1.3 API request.

On 2009-02-16 20:42:20 +0000, Sam Lantinga wrote:

SDL_GetDesktopDisplayMode() is in for SDL 1.3

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• sdl_glscale.patch (sdl_glscale.patch, text/plain, 2006-01-29 00:28:13 +0000, 21911 bytes)

Reported in version: 2.0.0
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-01-29 00:27:46 +0000, Sam Lantinga wrote:

Date: Wed, 11 Aug 2004 02:23:19 +0200
From: Stephane Marchesin [email protected]
Subject: [SDL] [patch] sdl glscale backend

To use it, patch your SDL source tree, compile, install and then set the
environment variable SDL_VIDEODRIVER :
export SDL_VIDEODRIVER=glscale
It scales the picture by a factor 2 by default, but you can set your own
window size using the two env variables SDL_VIDEODRIVER_GLSCALE_X and
SDL_VIDEODRIVER_GLSCALE_Y.

This latest version avoids pixel copy/conversion most of the time, so
it's faster than the previous one (most games are playable even on my
radeon 7000 card with the free dri drivers :)

The patch is there :
http://icps.u-strasbg.fr/~marchesin/sdl/sdl_glscale.patch

On 2006-01-29 00:28:13 +0000, Sam Lantinga wrote:

Created attachment 47
sdl_glscale.patch

On 2006-06-21 04:10:29 +0000, Sam Lantinga wrote:

Stephane mentioned this is out of date, and it might be obsoleted by SDL 1.3. Moved to 1.3 so we can review it once the video drivers are rewritten.

On 2007-07-03 03:02:40 +0000, Ryan C. Gordon wrote:

I'm closing this as WONTFIX since it doesn't really apply to 1.3 now. Please reopen if this is incorrect.

--ryan.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• sdl_dx5video.diff.txt (sdl_dx5video.diff.txt, text/plain, 2006-01-27 00:14:10 +0000, 4344 bytes)

Reported in version: don't know
Reported for operating system, platform: Windows (All), x86

Comments on the original bug report:

On 2006-01-27 00:13:38 +0000, Sam Lantinga wrote:

Date: Sat, 31 Jan 2004 23:47:36 +0300
From: Dmitry Yakimov [email protected]
Subject: [SDL] Re: Minimal SDLLoop using SDL_GL_Swapbuffers freezes gfx

Hi,

I was wrong, my patch does not fix that.
The root of the problem is the same as in case of freeze while 2D
hardware page swapping. If we execute SwapBuffers without any delay
between calls, OpenGL driver should wait until hardware completes
previous frame. Driver is executed in ring0, so when it waits it
freezes all the system :-) It's better to wait in user code rather
than in driver code. That's why I wrote the patch for the same
behavior in 2D.

On 2006-01-27 00:14:10 +0000, Sam Lantinga wrote:

Created attachment 43
sdl_dx5video.diff.txt

On 2006-01-27 11:23:26 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2006-01-27 12:10:45 +0000, Dmitry Yakimov wrote:

We already added this patch.
But interesting - using the last part of patch - waiting in user code might drain batteries on notebooks. So now I do not know what evil choose - either very rary freezes or draining batteries :) Although good programmer should limit FPS manually by applying Sleep API.

--Dmitry.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• main.c (main.c, text/plain, 2006-01-29 00:32:14 +0000, 889 bytes)

Reported in version: don't know
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2006-01-29 00:31:55 +0000, Sam Lantinga wrote:

Date: Thu, 30 Sep 2004 19:23:12 +0200
From: Ivo Danihelka [email protected]
Subject: [SDL] bug: SDL_WarpMouse does not change MouseState

First call of SDL_WarpMouse() wraps mouse cursor but does not change
mouse position returned by SDL_GetMouseState(). This happends when mouse
starts outside window. The position remains [0, 0].

The second call of SDL_WarpMouse() updates mouse position to right
values.

I attached test program which wraps mouse and 10 times prints mouse
position. Start with mouse out of window and don't move it. Positions
will be [0, 0] instead of [320, 240].

System Information:
SDL 1.2.7
XFree86 Version 4.3.99.12

On 2006-01-29 00:32:14 +0000, Sam Lantinga wrote:

Created attachment 48
main.c

On 2006-01-29 00:33:10 +0000, Sam Lantinga wrote:

Date: Fri, 1 Oct 2004 12:49:05 +0200
From: Johannes Schmidt [email protected]
Subject: Re: [SDL] bug: SDL_WarpMouse does not change MouseState

If your mouse cursor is not within the SDL frame and you warp the mouse, you
get an enter notify, not a motion notify.
Therefore, SDL does not update its internal mouse state.

What's about calling SDL_PrivateMouseMotion even when getting an EnterNotify?

Regards,
Johannes

On 2006-05-07 17:15:11 +0000, Sam Lantinga wrote:

I'd like to get this fixed for SDL 1.2.10 release, if possible.

On 2006-05-09 03:20:38 +0000, Sam Lantinga wrote:

This is fixed in Subversion.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: don't know
Reported for operating system, platform: Windows (All), x86

Comments on the original bug report:

On 2006-01-27 02:19:37 +0000, Sam Lantinga wrote:

Date: Tue, 18 May 2004 17:25:53 -0500
From: "David White" [email protected]
Subject: [SDL] Keyboard Events and Shift

It seems to me that when keyboard events arrive in the SDL_KeyboardEvent structure, the keysym that arrives is based on the state of the 'shift' key at the time the event is processed, rather than the time the event happens.

In Battle for Wesnoth, which is implemented in a single thread, we have a situation where a textbox is on-screen to send messages to other players at the same time as the AI is processing. This means that sometimes a keyboard event might not be processed promptly if the AI is processing. When the keyboard event finally is processed, the user might have let go of the shift key, and a letter that was meant to be capitalized is not capitalized.

As far as I can work out from reports from users, this bug seems to be Windows-specific, as it apparently does not occur on Linux (I don't have access to a Linux machine to test on though).

Does anyone know of a way that I can get this to work, without having to use threads?

David White
Lead Developer
Battle for Wesnoth (http://www.wesnoth.org)

On 2006-01-27 11:23:27 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2006-03-14 02:33:06 +0000, Sam Lantinga wrote:

SDL calls GetKeyboardState(), which is I believe is current with the keyboard state as processed in Windows messages. This should work correctly for the windib driver, but it's possible that the keyboard state is out of sync on the windx5 driver (since all windows messages are processed before keyboard input is processed)

Can you confirm that the bug does not occur with the windib video driver?

On 2006-06-21 04:11:23 +0000, Sam Lantinga wrote:

Moving this to fixed for 1.2.10. Please reopen it if it's still active using the windib driver, or if we switch back to the directx driver by default.

On 2007-05-29 00:33:20 +0000, Mike wrote:

(In reply to comment # 3)

Moving this to fixed for 1.2.10. Please reopen it if it's still active using
the windib driver, or if we switch back to the directx driver by default.

I'm currently using libSDL 1.2.10 and the SHIFT key event detection seems to be working perfectly for everything (that I've tried) except for Windows 98. So Win2000/WinXP, MacOS, various Linux distros seem to be fine.

Is it possible I'm doing something wrong or is there something about Win98 that's special. I've set SDL_VIDEODRIVER=windib. Is that all that's necessary to override the use of the DX driver?

THanks for the help!

On 2007-07-05 23:07:47 +0000, Sam Lantinga wrote:

I tried to reproduce this using checkkeys.exe on Windows 98 and it appears to work correctly. Is there a test case that I can run to check this out?

On 2008-01-26 11:33:16 +0000, James Bellinger wrote:

Hmm. I get this exact bug too. We use the DirectX driver, though. Is that now unsupported?

On 2008-01-30 09:13:29 +0000, Mike wrote:

Sorry Sam, I missed your update a few months ago and unfortunately don't have my Win98 snapshot running at the moment, so I'm unable to create a testcase for you. If I run into this problem again, I will try checkkeys.exe and create a testcase.

James, if you're getting this same problem while using DX, perhaps it's not an SDL problem, but rather a Win98 keyboard problem...

m.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• SDL_dxjoystick.c (SDL_dxjoystick.c, text/plain, 2006-01-24 02:23:56 +0000, 14777 bytes)

Reported in version: 2.0.0
Reported for operating system, platform: Windows (All), x86

Comments on the original bug report:

On 2006-01-24 02:23:06 +0000, Sam Lantinga wrote:

Date: Sun, 15 Jun 2003 01:02:44 -0400
From: Glenn Maynard [email protected]
Subject: [SDL] DirectInput joystick code

I wrote some DX joystick code for SDL a while back. It's been in use in
StepMania for some time. I havn't had time to clean it up for inclusion,
particularly since the existing SDL code isn't set up well for using
DirectX input devices outside of the video tree and I havn't had the
urge to try to figure out how to do it right. However, the code's been
sitting in SM for too long. So, I'll attach it here in its current
state for whoever wants to use it, or clean it up for Sam (who expressed
interest in including it if it was polished up).

One issue is that it pulls in DInputCreate from the DX window code, and
assumes it's loaded. You need to initialize video, and the driver that
was used must have been DX. (It's OK if you use OpenGL, which doesn't
actually use DDraw, since it still initializes the library.)

I don't believe hats work; I don't have anything to test them with.

On 2006-01-24 02:23:56 +0000, Sam Lantinga wrote:

Created attachment 34
SDL_dxjoystick.c

On 2006-01-27 11:23:22 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2006-05-21 12:49:38 +0000, Sam Lantinga wrote:

This is in Subversion! :)

On 2006-05-21 13:30:16 +0000, Sam Lantinga wrote:

The changes have been moved to the 1.3 branch.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• ps2linux-actuators-09.patch (ps2linux-actuators-09.patch, text/plain, 2006-01-24 02:28:18 +0000, 61610 bytes)

Reported in version: 2.0.0
Reported for operating system, platform: Other, x86

Comments on the original bug report:

On 2006-01-24 02:27:46 +0000, Sam Lantinga wrote:

[SDL] Force feedback joystick actuator patch

OK, I've got it all working perfectly now. It has been tested on
PS2Linux and my pc a little too. (patch is attached)

Included in this patch:
2003-03-07

• Force feedback actuator API for SDL:
  SDL_JoystickNumActuators();
  SDL_JoystickSetActuator();
  SDL_JoystickGetActuatorType();
  SDL_JoystickGetActuatorRange();

• PS2Linux native joystick module - supporting plain digital, Analog
  and DualShock 1/2 controllers.

• PS2Linux implementation of force feedback API.

• Other joystick modules patched with dummy functions to work with the
  new API.

• testactuator.c created to test the actuator API and the PS2Linux
  implementation.

• testjoysticktext.c created to test the joystick in text mode.

• testjoystick.c modifed to return info about the actuators on the device.

• testjoystick.c added extra argv[2] to select the analog stick other
  than 0.

• testjoystick.c modified to avoid analog stick display going off the
  edge of screen (overscan issue).

• added startup printf usage help to testjoystick, and aditional
  programs by myself.

• configure.in and PS2Linux makefile.am patched to support the new
  features.

• added extra generated filenames to .cvsignore (so that "diff -X
  SDL12/.cvsignore" provides clean output).

• renamed several "Playstation 2" comments to "PS2Linux in
  configure.in (for clarity, because I have been doing some native PS2).

It has been great fun implementing all of this. Now it would be great
if more platforms were supported by this API addition. If someone else
with a force feedback joystick can code up another platform module this
would be great.

I am on ICQ 11122941 if anyone uses ICQ at all.

Cheers

JG

On 2006-01-24 02:28:18 +0000, Sam Lantinga wrote:

Created attachment 35
ps2linux-actuators-09.patch

On 2006-01-24 02:32:12 +0000, Sam Lantinga wrote:

DirectX Force Feedback Tutorial:
http://msdn.microsoft.com/archive/en-us/directx9_c_Summer_04/directx/input/tuts/tut4/tutorial4usingforcefeedback.asp

On 2006-01-24 03:26:43 +0000, Ryan C. Gordon wrote:

(Flagging as an API change.)

--ryan.

On 2006-01-27 11:23:22 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2009-02-16 20:43:42 +0000, Sam Lantinga wrote:

Force feedback support is in SDL 1.3, thanks to Edgar Simo. See include/SDL_haptic.h for details.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• sdl_patch (sdl_patch, text/plain, 2006-01-29 00:24:15 +0000, 2595 bytes)

Reported in version: don't know
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2006-01-29 00:23:17 +0000, Sam Lantinga wrote:

Date: Mon, 14 Jun 2004 12:32:12 +0200
From: Emmanuel Anne [email protected]
Subject: [SDL] patch : imps2 mouse in fbcon (raw repeater)

I don't know if this patch can be usefull or not, but since I use it, I
decided to post it here.
It simply tries to be more clever when guessing the mouse type in fbcon
(linux) by looking for the -t parameter for gpm (protocol) and the -R
(repeater). It does not try to recognize every protocol/repeater
combination but just imps2/raw because that's the combination I use here
to be able to use at the same time gpm in the console and X11 on the raw
repeater.

On 2006-01-29 00:24:15 +0000, Sam Lantinga wrote:

Created attachment 46
sdl_patch

On 2006-05-07 02:21:13 +0000, Sam Lantinga wrote:

The attached patch was pretty buggy, but I added very similar functionality to the code in subversion.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: don't know
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-03-12 20:52:35 +0000, Sam Lantinga wrote:

Date: Sun, 12 Mar 2006 14:47:34 +0100 (CET)
From: "Torsten Giebl" [email protected]
Subject: [SDL] Dummy Audio Output

Is there also a Dummy AudioOutput Driver ?

There is the DiskOut Driver, but it would be also
good for performance testing and other things to
have a Dummy AudioOutput Driver.

On 2006-03-14 04:07:24 +0000, Ryan C. Gordon wrote:

Dummy audio driver is now in CVS. export SDL_AUDIODRIVER="dummy" to use it.

It won't ever select unless SDL_AUDIODRIVER is explicitly set to "dummy", so that SDL_Init can fall through with an error if there isn't a legitimate audio device.

--ryan.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.0
Reported for operating system, platform: Linux, All

Comments on the original bug report:

On 2006-02-08 15:04:09 +0000, Patrice Mandin wrote:

Mesa has got some functions to create an OpenGL context on the frame buffer device. It should be possible to have hardware accelerated OpenGL with the proper DRI/DRM driver under Linux, without using X11.

DirectFB library also is another possibility for OpenGL on frame buffer:
http://www.directfb.org/index.php?path=Development%2FProjects%2FDirectFBGL

On 2006-02-13 14:25:59 +0000, wrote:

You may want to try this patch :
http://icps.u-strasbg.fr/~marchesin/sdl/sdl_fb_miniglx.patch
(before someone asks - yes I wrote it)

On 2006-05-05 01:55:44 +0000, Sam Lantinga wrote:

I'm confused. It looks like you're linking to X11 and GLX functions here... is that the case? If not, is there a configure.in patch that's missing somewhere?

On 2007-07-07 18:06:41 +0000, Ryan C. Gordon wrote:

It's "MiniGLX" which is basically supplies the glX API without a real X server, using the kernel DRI interfaces for 3D hardware acceleration in conjunction fbcon.

I'm not sure how well maintained this is, but if it works, it's arguably useful for an embedded thing with an ATI chip, etc.

But this definitely needs to default to disabled in the configure script if it goes in at all.

--ryan.

On 2007-07-07 20:36:46 +0000, Sam Lantinga wrote:

Let's consider this for SDL 1.3

On 2009-12-14 22:12:25 +0000, Sam Lantinga wrote:

Feel free to submit a patch for SDL 1.3, if you would like this included.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: don't know
Reported for operating system, platform: Windows (All), x86

Comments on the original bug report:

On 2006-01-31 11:27:23 +0000, Sam Lantinga wrote:

Date: Wed, 04 Jan 2006 22:20:12 +0100
From: Manuel Bilderbeek [email protected]
To: [email protected]
Subject: [SDL] PRINT (Print Screen) key event and full screen problems in wind
-- Message: 19392 -- Next: 19393 ----------------------------------------
Then the second problem. Our emulator has a way to set the output window
to 960x720 (3 times 320x240). When setting SDL to full screen, this
works fine on X11 and with the windib driver. On one of our (Windows
using) team mate's laptop, he gets a 1400x1040 resolution (with borders)
then. But, when using the windx driver, he gets an error, caused by the
fact that no surface can be created with a SDL_SetVideoMode call... A
similar thing happened on one of our other Windows team member's machine.

Normally, SDL simply does the next-larger resolution with borders, which
indeed worked for the windib driver. But it did not work for the windx
driver! So, why doesn't it work with windx, while it does work with
windib, that resolution, albeit with borders on 1400x1050?

If we modify the code and choose the nearest resolution ourselves
(1024x768), it does work on that same system.

On 2006-03-14 01:29:26 +0000, Sam Lantinga wrote:

I tried this myself, on my desktop PC, and the DirectDraw driver chose 1024x768 and centered it just fine.

I've sent Manuel e-mail asking if the bug is still active with CVS code.

On 2007-02-12 06:19:59 +0000, Ryan C. Gordon wrote:

As we're coming up on a year without hearing more on this bug, we'll assume it really was fixed at some point and flag the bug as WORKSFORME.

Please reopen if the bug is still present.

--ryan.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.0
Reported for operating system, platform: Windows (All), x86

Comments on the original bug report:

On 2006-01-29 01:23:26 +0000, Sam Lantinga wrote:

If you alt-tab away from a fullscreen SDL window, then right click on the icon in the taskbar, you won't get a menu of window actions... ?

Tested with 1.2.10 CVS code 1/28/2006

On 2006-06-24 01:08:36 +0000, Sam Lantinga wrote:

According to the MSDN documetation, the system menu is not available to windows without a caption.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwui/html/msdn_styles32.asp

Sure enough, running testwm -noframe gives a window without a system menu.

On 2006-06-24 01:39:19 +0000, Sam Lantinga wrote:

I haven't found any way that the application can detect a taskbar icon click and show a menu. Patches welcome!

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.0
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-01-21 15:17:06 +0000, Sam Lantinga wrote:

Date: Sun, 23 Feb 2003 09:45:10 +0200 (EET)
From: M Joonas Pihlaja [email protected]
Subject: [SDL] International keyboards and CTRL

Hello,

How is it possible to catch CTRL modified scandinavian keys? My
original thought was that I'd look at the modifier bits and the
unicode value. This works for ALT modified keys[1], but on this
system (Win95, SDL1.2.5) the CTRL-&# 65533;key sequence (that's CTRL-) gives a keysym structure with:

sym = 39 = ASCII '
unicode = 0
mod = 0x40 = LCTRL

CTRL-&# 65533;(CTRL-) on the other hand gives

sym = 91 = ASCII [
unicode = 27
mod = 0x40

My second related question is: is there any way to get the
unmodified but unicode converted character, and if so what is it?
Currently the unicode field for CTRL- keys is in the range
1..26, but that leaves no provision for international keys.

Best Regards,

Joonas Pihlaja

[1] Only works for left-ALT modified keys, not for AltGr modified
ones, but that's another question.

On 2006-01-21 15:18:48 +0000, Sam Lantinga wrote:

I think this will be taken care of with the keysym revamp for 1.3,
but I'll leave this open so we make sure to test it when it's in.

On 2006-01-27 11:23:19 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2009-02-16 20:41:16 +0000, Sam Lantinga wrote:

I believe this is now fixed.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• More accurate resampling (SDL_audiotypecvt.patch, text/plain, 2016-12-18 15:21:40 +0000, 8291 bytes)

Reported in version: 2.0.0
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-01-20 08:30:09 +0000, Sam Lantinga wrote:

Date: Thu, 19 Jan 2006 17:12:56 -0500
From: "Ryan C. Gordon" [email protected]
Subject: Re: [SDL] Re: (Time) Length of SDL_mixer chunks?

Second, many hardware drivers only allow power of two buffers for audio DMA,
so the final output rate would change the size of the input buffer, instead
of it being possible to calculate as a function of the input format.

But, if SDL_mixer is as good an example as any: SDL_ConvertAudio() has
uses outside of the audio callback. Perhaps we should remove the
limitation generally and have SDL_OpenAudio() fail if the sample rate
isn't a power of two? Maybe have SDL buffer data that would overflow the
hardware fragment size and give the audio callback a variable-sized
buffer when it has to make up the difference?

It seems that we should probably make this work cleanly behind the
scenes or at least give an error. Right now, people just get strange
results without any explanation as to why.

--ryan.

On 2006-01-20 08:31:22 +0000, Sam Lantinga wrote:

Let's say the audio driver gave you a DMA buffer of 4096 bytes of 16-bit
stereo audio at 48KHz, and you're trying to fill it with 16-bit stereo
audio at 44.1KHz... How many samples should you request in the callback?

On 2006-01-20 08:32:52 +0000, Sam Lantinga wrote:

Date: Fri, 20 Jan 2006 09:49:19 +0100
From: David Olofson [email protected]
Subject: Re: [SDL] Re: (Time) Length of SDL_mixer chunks?

44100 / 48000 * 4096 ==> alternating between 3763 atd 3764. (SDL
should report the maximum value, for application side buffer
allocation.)

For interpolation, you'll also need to buffer a few samples
internally, for overlap.

//David Olofson - Programmer, Composer, Open Source Advocate

On 2006-01-20 08:46:42 +0000, Sam Lantinga wrote:

Should we always call back the application with full buffer sizes at the requested format, and then keep around any extra data for the next hardware callback?

e.g.
The app requests 4096 sample buffer size at 44.1KHz, driver provides 1024 sample size at 48KHz. We do the following loop:

driver callback:
fill app sound buffer with 4096 samples
consume 940 samples filling 1024 sample sound buffer at 48KHz, leaving 3156
driver callback:
consume 940 samples filling 1024 sample sound buffer at 48KHz, leaving 2216
driver callback:
consume 940 samples filling 1024 sample sound buffer at 48KHz, leaving 1276
driver callback:
consume 940 samples filling 1024 sample sound buffer at 48KHz, leaving 336
driver callback:
consume 336 samples filling 365 samples at 48KHz
fill app sound buffer with 4096 samples
consume 605 samples filling remaining sound buffer at 48KHz, leaving 3491
...

On 2006-01-20 10:05:54 +0000, David Olofson wrote:

(In reply to comment # 3)

Should we always call back the application with full buffer sizes at the
requested format, and then keep around any extra data for the next hardware
callback?

This depends on the relation between the driver and callback buffer sizes. What you really want, for maximum reliability, is to keep the CPU load per driver buffer as even as possible. The more it varies, the greater the risk of getting drop-outs, even when the CPU load is well below 100%.

Thus, from a technical POV, it's best to call the application callback exactly once per driver buffer, asking for just the number of samples you need. Without interpolation, that's all there is to it - no intermediate buffers needed. For interpolation, you'll need to keep one or more samples from the previous buffer, but that's all.

Also note that any internal buffering adds to the latency, beyond the latency already defined by the "nominal" buffer sizes. Whenever you ask the application for samples that aren't going into the current driver buffer, you're essentially asking about the "future" - which translates to adding the number of extra samples to the total latency.

//David

On 2006-01-20 14:57:45 +0000, Patrice Mandin wrote:

(In reply to comment # 4)

(In reply to comment # 3)

Should we always call back the application with full buffer sizes at the
requested format, and then keep around any extra data for the next hardware
callback?

This depends on the relation between the driver and callback buffer sizes. What
you really want, for maximum reliability, is to keep the CPU load per driver
buffer as even as possible. The more it varies, the greater the risk of getting
drop-outs, even when the CPU load is well below 100%.

Thus, from a technical POV, it's best to call the application callback exactly
once per driver buffer, asking for just the number of samples you need.

I still wonder why it is such a big issue for you. MOD music players do that since the beginning (replaying samples at 'f1' KHz on a sound device opened at 'f2' KHz). Amiga and Atari ST soundtrackers were not running on GHz machines.

This is also a problem for me on Atari platform (and also on Amiga hardware), because the default hardware device does not support 44.1 or 48 KHz frequencies (even sub-multiples).

Programmers should not assume the audio is 44.1 (or 48), the same way that not everyone has 32 bits video mode, but 15, 16 or 24 sometimes.

On 2006-01-20 16:32:51 +0000, Alex Volkov wrote:

(In reply to comment # 3)

The app requests 4096 sample buffer size at 44.1KHz, driver provides 1024
sample size at 48KHz. We do the following loop:

driver callback:
fill app sound buffer with 4096 samples
consume 940 samples filling 1024 sample sound buffer at 48KHz, leaving 3156

SDL does not guarantee now that the app gets what it calls for (correct me if I am wrong). And I do not think that should change -- I would rather get a different buffer at a rate different from what I asked for, but have control over the buffer provided. Having SDL provide conversion routines capable of arbitrary resampling for my use is wonderful, but I would rather use them consciously than implicitly.

IMHO, the mixer (app-supplied callback) should be responsible for ensuring proper formats and rates, and SDL audio should just get the format from the driver as close as possible. But of course, having arbitrary SDL conversion functions would be nice.
If SDL audio hides the fact that it is interpolating, and it is not interpolating the way I want or need, I can get crappy sound quality. But if I (my app) is responsible for conversions -- I can choose to use SDL conv routines, or choose not to use them and use my own instead (which is what we do in our project right now -- we have own mixer).

As a side note, even a not-so-optimized C cubic interpolation for 44.1KHz stereo is not so slow right now -- it does not even take 1% of 1GHz CPU.

On 2006-01-21 08:12:07 +0000, David Olofson wrote:

(In reply to comment # 5)
[...]

I still wonder why it is such a big issue for you. MOD music players do that
since the beginning (replaying samples at 'f1' KHz on a sound device opened at
'f2' KHz). Amiga and Atari ST soundtrackers were not running on GHz machines.

Actually, it's no big issue IMHO, but supporting arbitrary audio and pixel formats and the like through emulation can be handy for quick porting.

I suppose newer Amigas and STs have more CPU power, but back in the 7.14/8 MHz days, only "nearest sample" resampling was fast enough if you actually wanted to do anything more than sound, at least with more than 4 voices. (The Amiga did 4 voices in hardware, so there was no need to do it in software for the normal 4 channel MODs.)

This is also a problem for me on Atari platform (and also on Amiga hardware),
because the default hardware device does not support 44.1 or 48 KHz
frequencies (even sub-multiples).

Well, the Amiga can do it, but only if you bypass the DMA and feed Paula with the CPU... (I did >44 kHz on my 25 MHz Amiga 3000, and even had about an A500's worth of CPU power left while doing it. :-D )

Programmers should not assume the audio is 44.1 (or 48), the same way that not
everyone has 32 bits video mode, but 15, 16 or 24 sometimes.

Good point, though I personally find the pixel format emulation rather handy for less performance critical work.

Also keep in mind that as long as you don't need custom blitters, you can just use SDL_DisplayFormat*(), and get maximum performance without having to explicitly support any pixel formats at all. As it is now, there is no corresponding solution for audio, as the "use specified format even if it means real time conversion" logic is more or less broken.

On 2006-01-21 08:28:59 +0000, David Olofson wrote:

(In reply to comment # 6)
[...]

SDL does not guarantee now that the app gets what it calls for (correct me if
I am wrong).

Actually, that depends on whether or not you specify a target SDL_AudioSpec for the second argument. If you don't, SDL_OpenAudio() will fail if it cannot provide exactly what you're asking for. There's no need to change this logic. This is just fixing what's already there, for those who want to use it.

IMHO, the mixer (app-supplied callback) should be responsible for ensuring
proper formats and rates, and SDL audio should just get the format from the
driver as close as possible. But of course, having arbitrary SDL conversion
functions would be nice.

Exactly. The conversion is nice to have whenever performance isn't critical enough to implement custom code for 15/16/24/32 pixel formats, audio resampling and whatnot.

If SDL audio hides the fact that it is interpolating, and it is not
interpolating the way I want or need, I can get crappy sound quality. But if I
(my app) is responsible for conversions -- I can choose to use SDL conv
routines, or choose not to use them and use my own instead (which is what we
do in our project right now -- we have own mixer).

As a side note, even a not-so-optimized C cubic interpolation for 44.1KHz
stereo is not so slow right now -- it does not even take 1% of 1GHz CPU.

I have some fixed point cubic interpolators too. Fast, simple and probably good enough as long as you don't need to downsample more than half an octave or so. (Then you'd need a brickwall low pass filter as well.)

BTW, if the conversion ratio is reasonably "nice" (not too many possible fractional sample positions used), one can do away with most of the interpolation code and use a precalculated circular LUT instead. However, I'm not sure it's much point on P-II and better CPUs, as a reasonably fast cubic interpolator is memory bound on those. It might make sense for lower end CPUs, though.

On 2006-01-21 11:58:29 +0000, Sam Lantinga wrote:

David, since you're familiar with audio processing, do you want to take point on this? Set it up so the audio conversion can use arbitrary frequency shifts, and then set up the audio AudioSpec format conversion to use it?

Let's implement a nearest sample version, and the cubic fixed-point whatchamathingie, chosen at compile time.

On 2006-01-21 14:05:18 +0000, Ryan C. Gordon wrote:

The only thing to consider, now that I already started this whirlwind, is that some people might be doing timing off the audio callback (or at least use it to estimate how much latency they can expect to incur, so it might be better to always have the callback fire with a constant size, and keep a small buffer inside SDL to manage the difference).

--ryan.

On 2006-01-21 14:59:12 +0000, Sam Lantinga wrote:

(In reply to comment # 10)

The only thing to consider, now that I already started this whirlwind, is that
some people might be doing timing off the audio callback (or at least use it to
estimate how much latency they can expect to incur, so it might be better to
always have the callback fire with a constant size, and keep a small buffer
inside SDL to manage the difference).

Yes, I think this is a good idea, even if it adds a small amount of latency. The reason being is that we'll only do it if the application requests that SDL do any necessary conversion (NULL in the second audio open parameter), and in that case we want to give the application exactly what they expect - e.g. a fixed size callback buffer.

In the case where the application is smart and wants to handle audio conversion themselves, if our audio conversion routine does good frequency shifting, then they can do whatever they want.

On 2006-01-22 04:44:41 +0000, David Olofson wrote:

(In reply to comment # 9)

David, since you're familiar with audio processing, do you want to take point
on this? Set it up so the audio conversion can use arbitrary frequency shifts,
and then set up the audio AudioSpec format conversion to use it?

I'm not very familiar with the SDL audio code, but I'll look into it.

Let's implement a nearest sample version, and the cubic fixed-point
whatchamathingie, chosen at compile time.

Well, I was thinking it might be nice to have it selectable at run time - but OTOH, if you're writing something that's supposed to scale to Pentiums and weaker CPUs (which is the only place a fixed point cubic interpolator isn't memory bound), you shouldn't rely on SDL's on-the-fly conversions anyway. So, a compile time option is probably fine.

On 2006-01-22 04:55:36 +0000, David Olofson wrote:

(In reply to comment # 10)

The only thing to consider, now that I already started this whirlwind, is that
some people might be doing timing off the audio callback (or at least use it to
estimate how much latency they can expect to incur, so it might be better to
always have the callback fire with a constant size, and keep a small buffer
inside SDL to manage the difference).

The problem is, there are only two ways of doing this: 1) having a separate, timer driven thread do the audio callbacks (otherwise you'd need to make an extra call or skip a call once in a while), or 2) simply rounding the application side buffer size to the nearest integer value and stick with that.

I'd say only the second alternative is viable. The only side effect is that it limits the accuracy - but we're talking about an error of around one percent worst case (minimum "safe" buffer sizes on Mac OS X and Linux/lowlatency), so it's still good enough that you won't be able to tell the difference in normal applications. (A synth may need a slight tune adjustment to play with other instruments, but a synth shouldn't need to use this feature anyway.)

On 2006-01-22 04:58:02 +0000, Ryan C. Gordon wrote:

The problem is, there are only two ways of doing this: 1) having a separate,
timer driven thread do the audio callbacks (otherwise you'd need to make an
extra call or skip a call once in a while), or 2) simply rounding the
application side buffer size to the nearest integer value and stick with that.

With the exception of MacOS Classic (where this runs in a hardware interrupt), all platforms currently use a seperate thread for the audio callback already...Sam, is this accurate?

--ryan.

On 2006-01-22 08:47:37 +0000, David Olofson wrote:

(In reply to comment # 14)

The problem is, there are only two ways of doing this: 1) having a separate,
timer driven thread do the audio callbacks (otherwise you'd need to make an
extra call or skip a call once in a while), or 2) simply rounding the
application side buffer size to the nearest integer value and stick with that.

With the exception of MacOS Classic (where this runs in a hardware interrupt),
all platforms currently use a seperate thread for the audio callback
already...Sam, is this accurate?

That's correct. (At least, it's the only way to do it on Linux, short of application driven polling from the main thread.) However, AFAIK, that thread blocks on the audio device.

The extra thread I'm talking about would have to be driven by a timer in order "fake" a fixed callback rate, so that applications can still derive their timing directly from the callback timing. If you do it from the existing audio thread, there will be N callbacks per actual audio buffer, and SDL will have to make an extra call, or skip a call, every once in a while.

On 2006-01-22 13:52:38 +0000, Sam Lantinga wrote:

That's correct. (At least, it's the only way to do it on Linux, short of
application driven polling from the main thread.) However, AFAIK, that thread
blocks on the audio device.

The extra thread I'm talking about would have to be driven by a timer in order
"fake" a fixed callback rate, so that applications can still derive their
timing directly from the callback timing. If you do it from the existing audio
thread, there will be N callbacks per actual audio buffer, and SDL will have to
make an extra call, or skip a call, every once in a while.

I think this is reasonable. Even if you had a timer thread faking the audio timing you'd still have load related problems unless it was running at real-time priority, which might not even be an option.

Let's consider adding a way to query the current actual audio playback position for 1.3

On 2006-01-25 11:19:11 +0000, David Olofson wrote:

(In reply to comment # 16)
[...]

I think this is reasonable. Even if you had a timer thread faking the audio
timing you'd still have load related problems unless it was running at
real-time priority, which might not even be an option.

Exactly. (Actually, this kind of arrangement tends to generate load problems even with RT priority on an RTOS. It's an unavoidable inherent effect of the design. Basically, just Don't Do That.)

Let's consider adding a way to query the current actual audio playback
position for 1.3

Yes, that would be very handy.

In DT-42, I rely on the callback timing and make a "guess" at how much additional buffering there is. Close enough on three of my machines here (Linux, Win2k and OS X), but that's probably just luck. :-) (The default delay compensation value can be overridden from the command line if need be.)

Anyway, I was looking at the code. Cubic interpolation does a pretty good job of resampling to higher sample rates; it behaves like a rather nice LPF at Nyqvist of the original sample rate, as desired. Free bonus, basically.

However, downsampling isn't all that fun. Though higher order interpolators do a bit better (probably because "skipped" samples still weigh into the output to some extent), one should really use a steep LPF at the input Nyqvist before the resampler to minimize aliazing caused by whatever might be above that frequency.

Then again, this is not much of an issue for 48->44.1, which is probably the most common case. If you're trying to play back 44.1 or 48 kHz audio through something that won't do more than 16 or 22.05 kHz or something, you're probably on a weak CPU, and there's not exactly countless spare cycles to spend on high quality downsampling. (And, the application should of course support the hardware sample rate, avoiding the problem entirely.)

So, do we assume that this stuff is mostly about resampling <insert odd, low sample rate here> to 44.1 or 48 kHz, and accept that downsampling upwards of an octave or more won't sound too great?

On 2006-01-25 11:55:46 +0000, David Olofson wrote:

I'm seeing some issues with the SDL_AudioCVT struct.

Although it's a bit hairy, interpolation can be done in-place, so no major problems there. However, I need somewhere to store two samples from the previous buffer. (Nicest place would be right before the current buffer, to completely avoid special cases around the interpolator.)

One way would be to make this an internal hack, but then this resampler wouldn't work in a real (application created) SDL_AudioCVT. :-/

Dirty hack idea: Abuse the filter callback array... :-) (Use the item after the cubic interpolator as a pointer to private data of some sort.)

On 2006-01-26 03:50:26 +0000, Sam Lantinga wrote:

So, do we assume that this stuff is mostly about resampling <insert odd, low
sample rate here> to 44.1 or 48 kHz, and accept that downsampling upwards of an
octave or more won't sound too great?

Sure, we can always add more options later if we want.

On 2006-01-26 03:57:42 +0000, Sam Lantinga wrote:

(In reply to comment # 18)

I'm seeing some issues with the SDL_AudioCVT struct.

Although it's a bit hairy, interpolation can be done in-place, so no major
problems there. However, I need somewhere to store two samples from the
previous buffer. (Nicest place would be right before the current buffer, to
completely avoid special cases around the interpolator.)

One way would be to make this an internal hack, but then this resampler
wouldn't work in a real (application created) SDL_AudioCVT. :-/

Dirty hack idea: Abuse the filter callback array... :-) (Use the item after the
cubic interpolator as a pointer to private data of some sort.)

Can you do it by assuming the previous two samples are the same as the first sample for resampling purposes? You'd get slight artifacts at the beginning of each buffer, but I doubt they'd be audible.

For 1.3, we can extend the conversion structure to contain an array of void* as parameters for the filter.

On 2006-01-26 05:53:38 +0000, David Olofson wrote:

(In reply to comment # 20)
[...]

Can you do it by assuming the previous two samples are the same as the first
sample for resampling purposes? You'd get slight artifacts at the beginning
of each buffer, but I doubt they'd be audible.

Well, in my experience (synths mostly), the clicking (or rather low frequency buzzing) that this generaten can be at least as annoying as the (constant) artifacts you get without interpolation. High frequency content in the audio stream may mask it to some extent, but that depends completely on the contents.

Extrapolating the missing points might improve things, though. It would make things worse with high frequencies involved, but would reduce clicks in low frequency signals where they're more audible. (What happens is actually that the error moves down a derivate or two.)

I'll try some things and see (hear) how it turns out.

On 2006-01-27 11:23:18 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2006-03-21 00:09:52 +0000, Sam Lantinga wrote:

David, any luck on this? I'd like to include it in SDL 1.2.10, if it's ready.

On 2006-03-21 04:52:33 +0000, David Olofson wrote:

Sorry, no time for (non work related) coding at this point. :-/ We're shipping the first "full" instrument today, but that doesn't mean I'm off the hook just yet...

On 2006-05-07 13:38:03 +0000, Sam Lantinga wrote:

*** Bug 156 has been marked as a duplicate of this bug. ***

On 2006-05-07 17:09:58 +0000, Sam Lantinga wrote:

I'd like to get this fixed for SDL 1.2.10 release, if possible.

On 2006-05-11 04:36:38 +0000, Sam Lantinga wrote:

It looks like David won't have time to work on this for the 1.2.10 release.

On 2007-02-22 02:23:26 +0000, Ryan C. Gordon wrote:

*** Bug 396 has been marked as a duplicate of this bug. ***

On 2007-07-07 16:51:40 +0000, Sam Lantinga wrote:

Updated for implementation in SDL 1.3

On 2009-01-10 19:26:12 +0000, Ryan C. Gordon wrote:

Reassigning bug to myself.

--ryan.

On 2009-02-16 20:40:11 +0000, Sam Lantinga wrote:

Ryan is currently working on this. Ryan, what's left to do?

On 2011-12-28 10:49:32 +0000, wrote:

This Debian bug report seems to be a manifestation of this problem, too:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460536

On 2013-05-21 00:46:18 +0000, Sam Lantinga wrote:

Ryan, can you take a look and see what's left for 2.0 release?

On 2016-01-03 21:01:30 +0000, Ryan C. Gordon wrote:

*** Bug 2649 has been marked as a duplicate of this bug. ***

On 2016-01-03 21:03:41 +0000, Ryan C. Gordon wrote:

*** Bug 2845 has been marked as a duplicate of this bug. ***

On 2016-12-18 15:21:40 +0000, Vitaly Novichkov wrote:

Created attachment 2652
More accurate resampling

I took care and fixed inaccurate and glitchy resampling myself (with causing extra clicks between chunks and an even bug in the X4 resampler where used a constant 8 instead of actual channels count). I tested it on 8000, 11025, 14700, 22050, 30000, 44100, 48000, 88200, 125121, 132300 and used stereo stream 44100. All sounds are signed 16-bit. Also did tests with the mono and 8bit sources.

The patch made based on the latest revision f6cd81aab88e.

Even that resampler worked, but a sound was glitchy and hat lot of clicks between chunks (because of inaccurate length calculation).

On 2016-12-18 17:12:12 +0000, Vitaly Novichkov wrote:

P.S. Actual patch posted at Bug 3527. This my patch is bit outdated.

On 2017-01-02 03:20:28 +0000, Sam Lantinga wrote:

Pointing at bug 3527 with Vitaly's latest patch

*** This bug has been marked as a duplicate of bug 3527 ***

On 2017-01-06 00:34:48 +0000, Ryan C. Gordon wrote:

Aww man, I was totally going to resolve this ten-year-old bug with the SDL_AudioStream stuff!

--ryan.

On 2017-01-06 06:10:02 +0000, Ryan C. Gordon wrote:

(In reply to Ryan C. Gordon from comment # 39)

Aww man, I was totally going to resolve this ten-year-old bug with the
SDL_AudioStream stuff!

And now I have: https://hg.libsdl.org/SDL/rev/329d6d46fb90

(plus some commits after that to fix up platforms that provide their own audio threads, so they use the new streamer stuff too, and other minor patches.)

--ryan.

On 2017-01-06 06:32:19 +0000, Ryan C. Gordon wrote:

(In reply to Ryan C. Gordon from comment # 40)

(In reply to Ryan C. Gordon from comment # 39)

Aww man, I was totally going to resolve this ten-year-old bug with the
SDL_AudioStream stuff!

(Eleven year old!!)

--ryan.

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• SDL-fb-open-lock.patch (SDL-fb-open-lock.patch, text/plain, 2006-01-24 01:04:40 +0000, 1762 bytes)
• SDL-fb-mousedrv-screensave.patch (SDL-fb-mousedrv-screensave.patch, text/plain, 2006-01-24 01:05:11 +0000, 2307 bytes)

Reported in version: don't know
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2006-01-24 01:01:21 +0000, Sam Lantinga wrote:

Date: Tue, 4 Mar 2003 15:05:31 -0800
From: "Jim" [email protected]
Subject: [SDL] Frame Buffer patches...

Okay I'm new at patch generation - so please tell me if there's a better
way
I could have done this.

Attached are two patch files generated with 'cvs diff -u'

SDL-fb-open-lock.patch applies to SDL_fbvideo.c
Modifies the open loop to check /dev/fb/0 found on devfs...

Modifies the lock code to return failure if the current virtual terminal

is not the one opened for frame buffer writing...
Lock would hang forever if switched away (ctrl-alt-F1) ...

SDL-fb-mousedrv-screensave.patch applies to SDL_fbevents.c
Switches default mouse mode based on SDL_MOUSEDRV - currently only
accepts PS2 - otherwise default is MS Mouse.

When the screen is switched - exisiting code (wrapped in ifdef

SAVE_SCREEN_COTENTS) would save the wrong bit of the screen....
( I run frame buffer 1600x1200, the size I requested was 800x600 - the
save would save the top 800 lines (non biased) and restore them... Adding
screen->offset fixed that )

However, if that option is not set, then a call to SDL_UpdateRect (full

screen) is made. (which may have had it's contents changed since the screen
is not entirely locked because of lock-failure patch)

Jim

On 2006-01-24 01:04:40 +0000, Sam Lantinga wrote:

Created attachment 29
SDL-fb-open-lock.patch

On 2006-01-24 01:05:11 +0000, Sam Lantinga wrote:

Created attachment 30
SDL-fb-mousedrv-screensave.patch

On 2006-01-24 01:08:28 +0000, Sam Lantinga wrote:

This might be related to bug # 49
https://bugzilla.libsdl.org/show_bug.cgi?id=49

On 2006-01-27 11:23:22 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2006-03-22 02:52:36 +0000, Sam Lantinga wrote:

These patches are in CVS, thanks!

This bug report was migrated from our old Bugzilla tracker.

Reported in version: don't know
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2006-01-27 00:20:20 +0000, Sam Lantinga wrote:

Date: Tue, 10 Feb 2004 09:31:09 -0500
From: Paul Rensing [email protected]
Subject: [SDL] Bug: mouse and cursor don't agree

I am having trouble with SDL under Linux (specifically Fedora Core 1). I
am running SDL 1.2.5. I see the problem in TuxPaint (a kid's drawing
program) and Frozen-bubbles (when using the mouse).

The problem is that, in fullscreen mode, the location of the mouse and
where the cursor is drawn don't agree. I am running on a laptop, so in
fullscreen mode, the active window is about 1/2 the screen size (screen
is 1024x768; program window is 640x480). The cursor is drawn up and to
the left of where the app thinks the mouse actually is. The offset
appears to be equal to the width/height of the black border.

I see this in two programs, so I believe it is a libsdl problem. I tried
getting SDL 1.2.6 and compiling it myself, but no change. I tried
turning off DGA mode in X; no change.

On 2006-01-27 00:20:39 +0000, Sam Lantinga wrote:

Can anyone confirm that this is active?

On 2006-01-27 11:23:26 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2006-03-20 00:53:48 +0000, Sam Lantinga wrote:

I believe this is long fixed. Go ahead and reopen it if there are new reports.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.0
Reported for operating system, platform: Windows (All), x86

Comments on the original bug report:

On 2006-01-31 13:13:05 +0000, Sam Lantinga wrote:

Date: Mon, 31 Oct 2005 12:53:08 +0100 (CET)
From: Michi Hostettler [email protected]
Subject: [SDL] [SDL-1.3] RenderTargets under Windows

hi,

i've probably found the bug why sdl rendertargets
don't work under windows. if you look at SDL_wingl.c,
WIN_GL_UnlockRenderTarget, the bug is if not
(target->texture) then wglMakeCurrent(GL_hdc, GL_hrc)
is NEVER called, and the buffer is not unbound.

solution: take the call to wglMakeCurrent(GL_hdc,
GL_hrc) out of the if-block.

On 2006-01-31 13:13:20 +0000, Sam Lantinga wrote:

Hrm, when can this happen?

On 2006-02-01 04:47:13 +0000, Sam Lantinga wrote:

This has been moved over to bug # 129

This bug report was migrated from our old Bugzilla tracker.

Reported in version: HG 2.1
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2006-01-19 16:37:46 +0000, Patrice Mandin wrote:

Along with audio input API, we could also add a video input API (using DirectShow under Windows, v4l under Linux, and so on). With it, you could use your webcam or any other camera (Eyetoy anyone?) in your SDL application.

Maybe it would also be nice to have some colorspace conversion functions in SDL, to convert images between YUV and RGB. SDL_Surface only support RGB components, and cameras support mostly YUV.

On 2006-01-27 11:23:17 +0000, Ryan C. Gordon wrote:

Setting Sam as "QA Contact" on all bugs (even resolved ones) so he'll definitely be in the loop to any further discussion here about SDL.

--ryan.

On 2006-05-04 08:30:48 +0000, Sam Lantinga wrote:

FYI, DirectShow is going away in DirectX 10...

On 2006-05-10 00:50:21 +0000, Ryan C. Gordon wrote:

What is the standard API for reading from a webcam on Windows, if DirectShow is going away? Is there one?

--ryan.

On 2006-05-10 01:07:50 +0000, Sam Lantinga wrote:

(In reply to comment # 3)

What is the standard API for reading from a webcam on Windows, if DirectShow is
going away? Is there one?

No idea. I imagine it'll be a new API under Windows Vista.

On 2009-12-14 21:56:04 +0000, Sam Lantinga wrote:

Ryan did some research on this. It's a mess and he may build a companion library that will be integrated into SDL at some point.

On 2009-12-15 22:34:31 +0000, Ryan C. Gordon wrote:

Changing bug priorities.

--ryan.

On 2013-06-04 12:44:42 +0000, Ryan C. Gordon wrote:

Hey, Sam, can we leave this bug open, on version "HG 2.1"? I'd still like this someday, as a wishlist item.

--ryan.

On 2013-06-05 02:47:48 +0000, Sam Lantinga wrote:

Sure. :)

This bug report was migrated from our old Bugzilla tracker.

Reported in version: don't know
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2006-01-30 08:13:38 +0000, Sam Lantinga wrote:

Date: Sat, 16 Apr 2005 08:39:22 +1000
From: "Eric Mangold" [email protected]
Subject: [SDL] Window manager does not show SDL window titles

Hello,

I have an issue with SDL-using applications and the sawfish window manager.

The problem is that SDL windows do not show the window caption. My gnome
panel does show the window name, but the actual sawfish window frame
shows no caption at all. All other non-SDL applications that I use work
fine.

I tried a couple other window managers, and they were able to show the
SDL window captions correctly. Though there many be other WMs that can't.

I believe the problem is that SDL is using the UTF8_STRING type for the
window's WM_NAME and WM_ICON properties. In fact, WM_NAME and WM_ICON are
supposed to set to a TEXT type, usually STRING (ISO 8859-1).
The property names _NET_WM_NAME and _NET_WM_ICON_NAME should be used to
store the UTF8_STRING versions of the window title and icon name.

You can see the properties I refer to with a command like this:
xprop|grep -e "WM.*NAME"

Please note the freedesktop.org standard:
http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2506954

This page talks a little bit about the history of these properties. Just
search down the page for "WM_NAME".
http://www.cl.cam.ac.uk/~mgk25/unicode.html

Please let me know if I can be of any assistance in resolving this issue.

Thanks,
Eric Mangold

On 2006-03-20 02:32:30 +0000, Sam Lantinga wrote:

The _NET_WM_NAME and _NET_WM_ICON_NAME support have been added to CVS. Please let me know if there are any more problems. Thanks!

This bug report was migrated from our old Bugzilla tracker.

Reported in version: don't know
Reported for operating system, platform: Windows (All), x86

Comments on the original bug report:

On 2006-01-31 11:26:09 +0000, Sam Lantinga wrote:

Date: Wed, 04 Jan 2006 22:20:12 +0100
From: Manuel Bilderbeek [email protected]
To: [email protected]
Subject: [SDL] PRINT (Print Screen) key event and full screen problems in wind
-- Message: 19392 -- Next: 19393 ----------------------------------------
Hello all,

For our SDL-powered MSX emulator (openMSX), we use a key binding to the
print-screen key (SDLK_PRINT). This works fine on e.g. Linux, but not in
Windows. Here's some quotes from durnew on IRC:

windows only reports print screen on KEYUP
not KEYDOWN
not certain how to fix that, other than document it
Diablo-D3: well, the directx driver requires a different fix
as it doesn't have a scancode for print screen
i've been trying to figure out what the deal was!
but atleast i've located the issues :)
ah, well, both drivers were broken anyway!
neither one of them is fixable
without rewriting half the library
which i imagine, is why they aren't fixed!
the windib driver issue can be half fixed :\
Quibus: windib only reports that scancode on KEYUP and directx
only contains a SYSRQ binding, SDL would have to give both SDLK_PRINT
and SDLK_SYSREQ the same values

Is there really nothing that could be done to get this working better
(or actually: working at all) in Windows?

The only way we could hack it into the windx driver, is to replace the
binding to SYSREQ with a binding to PRINT.... But that's not a good
solution of course.
Oh, and isn't this just a bug? If so, and if it's not yet in the
bugzilla, can someone please add it?

On 2006-03-14 02:06:14 +0000, Sam Lantinga wrote:

This is fixed in CVS.

This bug report was migrated from our old Bugzilla tracker.

Reported in version: don't know
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2006-01-31 09:21:03 +0000, Sam Lantinga wrote:

Date: Wed, 26 Jan 2005 05:12:03 -0500
From: Dave Ahlswede [email protected]
Subject: [SDL] Setting WM_CLASS under X11

Most X11 programs set the WM_CLASS hint based on the name of the binary
run, but SDL always seems to set it to SDL_App-- this is troublesome
with some window managers that use this hint to identify individual
programs-- Is there any reason behind the current behavior? If there
isn't, I'd strongly recommend acquiring the executable name and using
that for the class.

On 2006-01-31 09:21:41 +0000, Sam Lantinga wrote:

We have the SDL_VIDEO_X11_WMCLASS environment variable, but I agree, on platforms where we can determine the application name, we should use it.

On 2006-02-03 02:39:49 +0000, Sam Lantinga wrote:

This is implemented for Linux and (I think) FreeBSD. Thanks!