Mon, 20 Mar 2006 07:31:36 +0000 Fixed bug #113:
Sam Lantinga <slouken@libsdl.org> [Mon, 20 Mar 2006 07:31:36 +0000] rev 1558
Fixed bug #113: Date: Sat, 16 Apr 2005 08:39:22 +1000 From: "Eric Mangold" 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
Mon, 20 Mar 2006 06:37:58 +0000 Fixed bug #90
Sam Lantinga <slouken@libsdl.org> [Mon, 20 Mar 2006 06:37:58 +0000] rev 1557
Fixed bug #90 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.
Sun, 19 Mar 2006 19:03:40 +0000 Fixed bug #84
Sam Lantinga <slouken@libsdl.org> [Sun, 19 Mar 2006 19:03:40 +0000] rev 1556
Fixed bug #84 Actually implemented banked update for SVGAlib
Sun, 19 Mar 2006 12:05:16 +0000 Fixed bug #89
Sam Lantinga <slouken@libsdl.org> [Sun, 19 Mar 2006 12:05:16 +0000] rev 1555
Fixed bug #89 Date: Sun, 23 Oct 2005 16:39:03 +0200 From: "A. Schmid" <sahib@phreaker.net> Subject: [SDL] no software surfaces with svgalib driver? Hi, I noticed that the SDL (1.2.9) svgalib driver only makes use of linear addressable (framebuffer) video modes. On older systems (like one of mine), linear addressable modes are often not available. Especially for cards with VESA VBE < 2.0 the svgalib vesa driver is unusable, since VESA only supports framebuffering for VBE 2.0 and later. The changes necessary to add support for software surfaces seem to be relatively small. I only had to hack src/video/svga/SDL_svgavideo.c (see attached patch). The code worked fine for me, but it is no more than a proof of concept and should be reviewed (probably has a memory leak when switching modes). It also uses the vgagl library (included in the svgalib package) and needs to be linked against it. -Alex
Sun, 19 Mar 2006 12:04:40 +0000 Fixed bug #84
Sam Lantinga <slouken@libsdl.org> [Sun, 19 Mar 2006 12:04:40 +0000] rev 1554
Fixed bug #84 Date: Sun, 23 Oct 2005 16:39:03 +0200 From: "A. Schmid" <sahib@phreaker.net> Subject: [SDL] no software surfaces with svgalib driver? Hi, I noticed that the SDL (1.2.9) svgalib driver only makes use of linear addressable (framebuffer) video modes. On older systems (like one of mine), linear addressable modes are often not available. Especially for cards with VESA VBE < 2.0 the svgalib vesa driver is unusable, since VESA only supports framebuffering for VBE 2.0 and later. The changes necessary to add support for software surfaces seem to be relatively small. I only had to hack src/video/svga/SDL_svgavideo.c (see attached patch). The code worked fine for me, but it is no more than a proof of concept and should be reviewed (probably has a memory leak when switching modes). It also uses the vgagl library (included in the svgalib package) and needs to be linked against it. -Alex
Sun, 19 Mar 2006 10:48:48 +0000 Left the debug code more explicit
Sam Lantinga <slouken@libsdl.org> [Sun, 19 Mar 2006 10:48:48 +0000] rev 1553
Left the debug code more explicit
Sun, 19 Mar 2006 10:41:49 +0000 Fixed bug #79
Sam Lantinga <slouken@libsdl.org> [Sun, 19 Mar 2006 10:41:49 +0000] rev 1552
Fixed bug #79 Implemented snd_pcm_sw_params_set_start_threshold() and snd_pcm_sw_params_set_avail_min() in the ALSA 0.9 driver. This doesn't actually change any latency for me, but it's the right thing to do...
Sun, 19 Mar 2006 06:31:34 +0000 Fixed bug #4
Sam Lantinga <slouken@libsdl.org> [Sun, 19 Mar 2006 06:31:34 +0000] rev 1551
Fixed bug #4 [Note: I'm applying this patch since it's a cleaner version of what's already implemented, and supports this controller on older kernels. I'll ask to make sure this doesn't break on the new kernels where it's no longer necessary] Date: Mon, 21 Mar 2005 09:41:11 -0500 From: Chris Nelson Subject: SDL Patch Hey, Ryan. I submitted the following patch about a year ago. It's just a simple patch for the linux port, to make multiple joysticks each appear to SDL as their own device, if they are on the same USB port (specifically, these guys <http://www.consoleplus.co.uk/product_info.php?pName=super-joybox-5-quad-joypad-converter>, which allow 4 Playstation2 controllers to be accessed via a single USB port). Without this patch, SDL pretty much drops the ball, and reports that there are 4 joysticks available when less than that number are plugged in. My work built upon the work of another person with the same device. When I submitted the patch to the list, he tested it, but it didn't work for him, so the patch was never accepted. Maybe about 3 times in the past year, I've tried to email the guy, to see if he couldn't run my new version, complete with debug code to diagnose the problem he was having. He never got back to me. So, I'm attaching the patch. I wish I knew why it didn't work for him, but I've been using it for the last year with no problems. Let me know if you need any more information, or have any ideas as to how I could test it. I'd like to see it in the tree, but I want to make sure it works. -Chris
Sun, 19 Mar 2006 05:27:22 +0000 Fixed bug #166
Sam Lantinga <slouken@libsdl.org> [Sun, 19 Mar 2006 05:27:22 +0000] rev 1550
Fixed bug #166 From the autoconf obsolete macros documentation: Macro: AC_CANONICAL_SYSTEM Determine the system type and set output variables to the names of the canonical system types. See section Getting the Canonical System Type, for details about the variables this macro sets. The user is encouraged to use either AC_CANONICAL_BUILD, or AC_CANONICAL_HOST, or AC_CANONICAL_TARGET, depending on the needs. Using AC_CANONICAL_TARGET is enough to run the two other macros. From the documentation for the canonical environments: case $target in i386-*-mach* | i386-*-gnu*) obj_format=aout emulation=mach bfd_gas=yes ;; i960-*-bout) obj_format=bout ;; esac Note that the above example uses $target because it's taken from a tool which can be built on some architecture ($build), run on another ($host), but yet handle data for a third architecture ($target). Such tools are usually part of a compiler suite, they generate code for a specific $target. However $target should be meaningless for most packages. If you want to base a decision on the system where your program will be run, make sure you use the $host variable.
Sat, 18 Mar 2006 22:42:09 +0000 Implemented RISC OS and OS/2 desktop resolution code (thanks to Alan and Doodle)
Sam Lantinga <slouken@libsdl.org> [Sat, 18 Mar 2006 22:42:09 +0000] rev 1549
Implemented RISC OS and OS/2 desktop resolution code (thanks to Alan and Doodle)
(0) -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 tip