Skip to content

L
libSDL
Switch branch/tag
  1. 22 Mar, 2006 10 commits
  3. 21 Mar, 2006 13 commits
  5. 20 Mar, 2006 3 commits
    • Sam Lantinga's avatar
      ------- Comment #8 From Sergey Svishchev 2006-03-19 12:35 [reply] ------- · 625655e2
      Sam Lantinga authored 
      I've made a similar patch to BSD-specific USB driver, please review it too.

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401563
      625655e2
    • Sam Lantinga's avatar
      Fixed bug #113: · 4c3dfbcf
      Sam Lantinga authored 
      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

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401562
      4c3dfbcf
    • Sam Lantinga's avatar
      Fixed bug #90 · ed659a7d
      Sam Lantinga authored 
      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.

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401561
      ed659a7d
  7. 19 Mar, 2006 7 commits
    • Sam Lantinga's avatar
      Fixed bug #84 · ec2060c8
      Sam Lantinga authored 
      Actually implemented banked update for SVGAlib

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401560
      ec2060c8
    • Sam Lantinga's avatar
      Fixed bug #89 · ac4f3287
      Sam Lantinga authored 
      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

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401559
      ac4f3287
    • Sam Lantinga's avatar
      Fixed bug #84 · 877556f5
      Sam Lantinga authored 
      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

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401558
      877556f5
    • Sam Lantinga's avatar
      Left the debug code more explicit · d21bbd6c
      Sam Lantinga authored 
      --HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401557
      d21bbd6c
    • Sam Lantinga's avatar
      Fixed bug #79 · 5d285ff9
      Sam Lantinga authored 
      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...

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401556
      5d285ff9
    • Sam Lantinga's avatar
      Fixed bug #4 · 9b2bff03
      Sam Lantinga authored 
      [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

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401555
      9b2bff03
    • Sam Lantinga's avatar
      Fixed bug #166 · 505a5846
      Sam Lantinga authored 
      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.

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401554
      505a5846
  9. 18 Mar, 2006 2 commits
  11. 17 Mar, 2006 1 commit
  13. 16 Mar, 2006 1 commit
  15. 15 Mar, 2006 3 commits
    • Sam Lantinga's avatar
      Added current_w and current_h to the SDL_VideoInfo structure, which is set to... · ab022a89
      Sam Lantinga authored 
      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.)

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401549
      ab022a89
    • Sam Lantinga's avatar
      Fixed bug #33 · 5ab18443
      Sam Lantinga authored 
      Mike Frysinger wrote:
> with libsdl-1.2.9, some games (like bomberclone) started
> segfaulting in Gentoo
[...snip...]
> the last change in the last hunk:
[...snip...]
> if i change the statement to read:
> (table[which].blit_features & GetBlitFeatures()) == GetBlitFeatures()
> bomberclone no longer segfaults on my box

Alex Volkov wrote:
> The test "(table[which].blit_features & GetBlitFeatures()) ==
> table[which].blit_features)" is correct, and the previous
> "(table[which].cpu_mmx == SDL_HasMMX())" was actually broken.

I think there is potentially a slightly different cause of the above problem.
During the introduction of the Altivec code, the blit_table struct field
'alpha' got changed from a straightforward enum to a bitmask, which makes
perfect sense by itself. However, now the table driven blitter selection code
in SDL_CalculateBlitN() can choose the wrong blitters when searching for a
NO_ALPHA blitter because of the following code:
    int a_need = 0;
    ...
    (a_need & table[which].alpha) == a_need &&
When searching through the normal_blit_2[] table, a SET_ALPHA blitter (like
Blit_RGB565_ARGB8888) can now be selected instead of a NO_ALPHA one, causing
alpha channel bits to appear in a non-alpha destination surface. I suppose this
could theoretically be an indirect cause of the segfault mentioned above.

I *think* this can be fixed by changing to
    int a_need = NO_ALPHA;

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401548
      5ab18443
    • Sam Lantinga's avatar
      From: "Alex Volkov" · 3f36d970
      Sam Lantinga authored 
      Date: Thu, 10 Nov 2005 21:53:40 -0500
Subject: [SDL] BUG[?]: 32bpp RGBA->RGB colorkey blit, no SDL_SRCALPHA

It seems there is either a documentation vs. reality mismatch or a real bug
in SDL_blit_N.c:BlitNtoNKey().
The exact blit in question is a 32bpp RGBA->RGB, where RGBA has SDL_COLORKEY
and *no* SDL_SRCALPHA flags. The doc in SDL_video.h states:
* RGBA->RGB:
*     SDL_SRCALPHA not set:
*       copy RGB.
*       if SDL_SRCCOLORKEY set, only copy the pixels matching the
*       RGB values of the source colour key, ignoring alpha in the
*       comparison.

BlitNtoNKey(), however, forgets to "ignore alpha in the comparison". The
documentation makes perfect sense, so I think it is the code that is faulty.

The attached patch corrects the code.

--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%401547
      3f36d970