SDL 1.2.8 Prerelease

I’m working on packaging up SDL 1.2.8 for release.
Please let me know if there are any problems with it ASAP!
http://www.libsdl.org/cvs/SDL-1.2.8.tar.gz

(Note: the archive in the URL above is not the final release archive!)

Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment

I’m working on packaging up SDL 1.2.8 for release. Please let me know if
there are any problems with it ASAP!
http://www.libsdl.org/cvs/SDL-1.2.8.tar.gz

(Note: the archive in the URL above is not the final release archive!)

Great! New SDL release soon! :slight_smile:

I’m sending small fix for BeOS, which prevents filling up SDL’s message
queue too fast.
Without it, SDL receives “key down” messages from BeOS code, for each key
repeat (BeOS handles key repeats itself, and application can check if
received “key down” message from BeOS is first time key down, or if it’s
repeat, and which repeat it is). Since there is no way for “sdl driver” to
turn off “default” SDL’s key-repeat mechanism, they were working both at
the same time (and queue could be filled up very fast).
So this patch removes handling “key down” message from BeOS if it’s
key_repeat “type”.

THX
Regards
ahwayakchih
-------------- next part --------------
— SDL-1.2.8/src/video/bwindow/SDL_BWin.h- Mon Dec 13 08:54:34 2004
+++ SDL-1.2.8/src/video/bwindow/SDL_BWin.h Tue Dec 14 11:14:10 2004
@@ -425,11 +425,13 @@
{
/* mouse up doesn’t give which button was released,
only state of buttons (after release, so it’s always = 0),

  •   			which is is not what we need ;]
    
  •   			which is not what we need ;]
      			So we need to store button in mouse down, and restore
      			in mouse up :(
    
  •   			mouse up is (similarly to mouse down) send only when
    
  •   			no more buttons are down */
    
  •   			mouse up is (similarly to mouse down) send only for
    
  •   			first button down (ie. it's no send if we click another button
    
  •   			without releasing previous one first) - but that's probably
    
  •   			because of how drivers are written?, not BeOS itself. */
      		int32 buttons;
      		int sdl_buttons = 0;
      		if (msg->FindInt32("buttons", &buttons) == B_OK) {
    

@@ -471,6 +473,11 @@
{
int32 key;
int32 modifiers;

  •   		int32 key_repeat;
    
  •   		/* Workaround for SDL message queue being filled too fast because of BeOS own key-repeat mechanism */
    
  •   		if (msg->FindInt32("be:key_repeat", &key_repeat) == B_OK && key_repeat > 0)
    
  •   			break;+
      		if (msg->FindInt32("key", &key) == B_OK && msg->FindInt32("modifiers", &modifiers) == B_OK) {
      			SDL_keysym keysym;
      			keysym.scancode = key;

I’m working on packaging up SDL 1.2.8 for release. Please let me know if
there are any problems with it ASAP!
http://www.libsdl.org/cvs/SDL-1.2.8.tar.gz

(Note: the archive in the URL above is not the final release archive!)

Great! New SDL release soon! :slight_smile:

I’m sending small fix for BeOS, which prevents filling up SDL’s message
queue too fast.
Without it, SDL receives “key down” messages from BeOS code, for each key
repeat (BeOS handles key repeats itself, and application can check if
received “key down” message from BeOS is first time key down, or if it’s
repeat, and which repeat it is). Since there is no way for “sdl driver” to
turn off “default” SDL’s key-repeat mechanism, they were working both at
the same time (and queue could be filled up very fast).
So this patch removes handling “key down” message from BeOS if it’s
key_repeat “type”.

THX
Regards
ahwayakchih
-------------- next part --------------
— SDL-1.2.8/src/video/bwindow/SDL_BWin.h- Mon Dec 13 08:54:34 2004
+++ SDL-1.2.8/src/video/bwindow/SDL_BWin.h Tue Dec 14 11:14:10 2004
@@ -425,11 +425,13 @@
{
/* mouse up doesn’t give which button was released,
only state of buttons (after release, so it’s always = 0),

  •   			which is is not what we need ;]
    
  •   			which is not what we need ;]
      			So we need to store button in mouse down, and restore
      			in mouse up :(
    
  •   			mouse up is (similarly to mouse down) send only when
    
  •   			no more buttons are down */
    
  •   			mouse up is (similarly to mouse down) send only for
    
  •   			first button down (ie. it's no send if we click another button
    
  •   			without releasing previous one first) - but that's probably
    
  •   			because of how drivers are written?, not BeOS itself. */
      		int32 buttons;
      		int sdl_buttons = 0;
      		if (msg->FindInt32("buttons", &buttons) == B_OK) {
    

@@ -471,6 +473,11 @@
{
int32 key;
int32 modifiers;

  •   		int32 key_repeat;
    
  •   		/* Workaround for SDL message queue being filled too fast because of BeOS own key-repeat mechanism */
    
  •   		if (msg->FindInt32("be:key_repeat", &key_repeat) == B_OK && key_repeat > 0)
    
  •   			break;+
      		if (msg->FindInt32("key", &key) == B_OK && msg->FindInt32("modifiers", &modifiers) == B_OK) {
      			SDL_keysym keysym;
      			keysym.scancode = key;

I’m working on packaging up SDL 1.2.8 for release. Please let me know if
there are any problems with it ASAP!
http://www.libsdl.org/cvs/SDL-1.2.8.tar.gz

(Note: the archive in the URL above is not the final release archive!)

Great! New SDL release soon! :slight_smile:

I’m sending small fix for BeOS, which prevents filling up SDL’s message
queue too fast.
Without it, SDL receives “key down” messages from BeOS code, for each key
repeat (BeOS handles key repeats itself, and application can check if
received “key down” message from BeOS is first time key down, or if it’s
repeat, and which repeat it is). Since there is no way for “sdl driver” to
turn off “default” SDL’s key-repeat mechanism, they were working both at
the same time (and queue could be filled up very fast).
So this patch removes handling “key down” message from BeOS if it’s
key_repeat “type”.

---- PATCH -----

— SDL-1.2.8/src/video/bwindow/SDL_BWin.h- Mon Dec 13 08:54:34 2004
+++ SDL-1.2.8/src/video/bwindow/SDL_BWin.h Tue Dec 14 11:14:10 2004
@@ -425,11 +425,13 @@
{
/* mouse up doesn’t give which button was released,
only state of buttons (after release, so it’s always = 0),

  •   			which is is not what we need ;]
    
  •   			which is not what we need ;]
      			So we need to store button in mouse down, and restore
      			in mouse up :(
    
  •   			mouse up is (similarly to mouse down) send only when
    
  •   			no more buttons are down */
    
  •   			mouse up is (similarly to mouse down) send only for
    
  •   			first button down (ie. it's no send if we click another button
    
  •   			without releasing previous one first) - but that's probably
    
  •   			because of how drivers are written?, not BeOS itself. */
      		int32 buttons;
      		int sdl_buttons = 0;
      		if (msg->FindInt32("buttons", &buttons) == B_OK) {
    

@@ -471,6 +473,11 @@
{
int32 key;
int32 modifiers;

  •   		int32 key_repeat;
    
  •   		/* Workaround for SDL message queue being filled too fast because of 
    

BeOS own key-repeat mechanism */

  •   		if (msg->FindInt32("be:key_repeat", &key_repeat) == B_OK && 
    

key_repeat > 0)

  •   			break;+
      		if (msg->FindInt32("key", &key) == B_OK && 
    

msg->FindInt32(“modifiers”, &modifiers) == B_OK) {
SDL_keysym keysym;
keysym.scancode = key;

THX
Regards
ahwayakchih

Well, this is definitely not a bug in SDL, but it is in the category “any
problem”.

I am working at a computer pool at university.
I do not know their procedure of compiling and installing linux kernels, but
the kernel headers at my pc still contain some dummy values.
The actual problem is that linux/version.h contains wrong values (no version
info, but some error messages about not yet configured kernel sources).

This file is included here (as a new work around for 2.6.9) since revision
1.9:

src/cdrom/linux/SDL_syscdrom.c, line 41
#include <linux/version.h>

That means:
I can’t compile SDL without modifying the source or pray that the admins may
understand my problem.

Perhaps someone knows an easier workaround …

Regards,
Johannes

< http://libufo.sourceforge.net > The OpenGL GUI ToolkitAm Dienstag 14 Dezember 2004 01:58 schrieb Sam Lantinga:

I’m working on packaging up SDL 1.2.8 for release.
Please let me know if there are any problems with it ASAP!
http://www.libsdl.org/cvs/SDL-1.2.8.tar.gz

Sam,

I found a minor problem. If you don’t use the correct settings
for DSP audio (like an unsupported number of channels), and the
DSP code exits, it will not let you reopen it.

The solution is to add DSP_CloseAudio(this); before each return -1 in
the error case.

This appears when trying to use 6 channel audio with DSP - it
returns an error due to fragment size not being a power of 2. My
code will then try a different number of channels.

Bill May

Sam Lantinga wrote:

I’m working on packaging up SDL 1.2.8 for release.
Please let me know if there are any problems with it ASAP!
http://www.libsdl.org/cvs/SDL-1.2.8.tar.gz

(Note: the archive in the URL above is not the final release archive!)

Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed…
Name: sdl.diffs
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20041214/ce3c0cc7/attachment.txt

Well, this is definitely not a bug in SDL, but it is in the category “any
problem”.

I am working at a computer pool at university.
I do not know their procedure of compiling and installing linux kernels, but
the kernel headers at my pc still contain some dummy values.
The actual problem is that linux/version.h contains wrong values (no version
info, but some error messages about not yet configured kernel sources).

This file is included here (as a new work around for 2.6.9) since revision
1.9:

src/cdrom/linux/SDL_syscdrom.c, line 41
#include <linux/version.h>

That means:
I can’t compile SDL without modifying the source or pray that the admins may
understand my problem.

Perhaps someone knows an easier workaround …

Does it work if you add
#undef KERNEL
before the line containing #include <linux/version.h> ?

If it doesn’t, send me your /usr/include/linux/version.h

Stephane

I’m sorry everyone for triple post.
Something was not right with maillist - as i didn’t receive confirmation
then, only now - after 24 hours :slight_smile:

Regards
ahwayakchih

Sorry guys, mailing list hiccough. The BeOS patch got in, but others
didn’t, and will be added to CVS shortly.

Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment

[…]

This file is included here (as a new work around for 2.6.9) since
revision 1.9:

src/cdrom/linux/SDL_syscdrom.c, line 41
#include <linux/version.h>

That means:
I can’t compile SDL without modifying the source or pray that the admins
may understand my problem.

Perhaps someone knows an easier workaround …

Does it work if you add
#undef KERNEL
before the line containing #include <linux/version.h> ?

If it doesn’t, send me your /usr/include/linux/version.h

My version.h contains just some CPP error messages:Am Mittwoch 15 Dezember 2004 19:15 schrieb Stephane Marchesin:

/*

  • Dummy file include/linux/version.h that gets replaced when the
  • kernel is configured for the first time.
    */

#error “The kernel sources in /usr/src/linux are not yet configured.”
#error “Please run ‘make cloneconfig && make dep’ in /usr/src/linux/”
#error “to get a kernel that is configured like the running kernel.”
#error “Alternatively, you can copy one of the config files”
#error “arch/$ARCH/defconfig.* to .config, and run”
#error “‘make oldconfig && make dep’ to configure the kernel”
#error “for that configuration.”

Regards,
Johannes

< http://libufo.sourceforge.net > The OpenGL GUI Toolkit

Johannes Schmidt wrote:

My version.h contains just some CPP error messages:

/*

  • Dummy file include/linux/version.h that gets replaced when the
  • kernel is configured for the first time.
    */

#error “The kernel sources in /usr/src/linux are not yet configured.”
#error “Please run ‘make cloneconfig && make dep’ in /usr/src/linux/”
#error “to get a kernel that is configured like the running kernel.”
#error “Alternatively, you can copy one of the config files”
#error “arch/$ARCH/defconfig.* to .config, and run”
#error “‘make oldconfig && make dep’ to configure the kernel”
#error “for that configuration.”

That’s the Suse kernel sources…
I think the only way out is to add a test in ./configure

Stephane

Attached is a patch (it works for me[TM]) which adds a CheckLinuxVersion() to
configure.in and a check for HAVE_LINUX_VERSION_H to
src/cdrom/linux/SDL_syscdrom.c.

Regards,
Johannes

< http://libufo.sourceforge.net > The OpenGL GUI Toolkit
-------------- next part --------------
A non-text attachment was scrubbed…
Name: linux_version.diff
Type: text/x-diff
Size: 803 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20050322/19cccaa2/attachment.diffOn Saturday 18 December 2004 13:59, Stephane Marchesin wrote:

#error “The kernel sources in /usr/src/linux are not yet configured.”
#error “Please run ‘make cloneconfig && make dep’ in /usr/src/linux/”
#error “to get a kernel that is configured like the running kernel.”
#error “Alternatively, you can copy one of the config files”
#error “arch/$ARCH/defconfig.* to .config, and run”
#error “‘make oldconfig && make dep’ to configure the kernel”
#error “for that configuration.”

That’s the Suse kernel sources…
I think the only way out is to add a test in ./configure