MAC OSX event problem

I’ve recently noticed that the keyboard event behavior has changed. I
think it was after I upgraded to 10.1.5.

Previously KEYUP and KEYDOWN events happened as expected. Now I get a
stream of keydown events while the key is pressed and on release I get a
stream of KEYUP events until another event is received eg a mouse move.

SDL_KEYDOWN <----- key pressed
SDL_KEYDOWN
SDL_KEYDOWN
SDL_KEYDOWN
SDL_KEYDOWN
SDL_KEYDOWN <----- key released
SDL_KEYUP
SDL_KEYUP
SDL_KEYUP
SDL_KEYUP
SDL_KEYUP
SDL_KEYUP
SDL_KEYUP
SDL_KEYUP
SDL_KEYUP
SDL_KEYUP
SDL_KEYUP <----- mouse move

I haven’t changed anything in my code or SDL. I haven’t messed with
enable repeat, in fact I tried to disable them as per the docs but it
made no difference. Any body else seen this?

Henry

Henry wrote:

I’ve recently noticed that the keyboard event behavior has changed. I
think it was after I upgraded to 10.1.5.

Previously KEYUP and KEYDOWN events happened as expected. Now I get a
stream of keydown events while the key is pressed and on release I get
a stream of KEYUP events until another event is received eg a mouse move.

I just went and checked, and my SDL game does not exibit this behavior.
All is normal. I am running 10.1.5.

                                                    -ray skoog

damn:)On Saturday, June 22, 2002, at 03:02 PM, Ray Skoog wrote:

I just went and checked, and my SDL game does not exibit this behavior.
All is normal. I am running 10.1.5.

Henry wrote:

damn:)

I just went and checked, and my SDL game does not exibit this
behavior. All is normal. I am running 10.1.5.

If you have it in a project builder format I’d be willing to compile and
run it. Just send me (and not the list) the tar.gz direct. It’s 10:00
here, if you get it to me my perhaps 1:00 I’ll run it tonight.

                                                        -ray> On Saturday, June 22, 2002, at 03:02  PM, Ray Skoog wrote:

Thanks for the offer, but it’s a bit big to email. I’ll do some hunting
around and if I can’t find where I’ve screwed up I might take you up on
your offer.

HenryOn Saturday, June 22, 2002, at 05:47 PM, Ray Skoog wrote:

If you have it in a project builder format I’d be willing to compile
and run it. Just send me (and not the list) the tar.gz direct. It’s
10:00 here, if you get it to me my perhaps 1:00 I’ll run it tonight.

I’ve recently noticed that the keyboard event behavior has changed. I
think it was after I upgraded to 10.1.5.

I didn’t notice this change when upgrading to 10.1.5. If you can write a
simple program that demonstrates this bug that will help us fix it.

-DOn Friday, June 21, 2002, at 08:51 PM, Henry wrote:

Thanks for the offer. I’ll do some checking of my stuff first and then
get back to you.On Tuesday, June 25, 2002, at 02:56 AM, Darrell Walisser wrote:

On Friday, June 21, 2002, at 08:51 PM, Henry wrote:

I’ve recently noticed that the keyboard event behavior has changed. I
think it was after I upgraded to 10.1.5.

I didn’t notice this change when upgrading to 10.1.5. If you can write
a simple program that demonstrates this bug that will help us fix it.

-D


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Hello, SDL developers!

My name ist Martin Doering. I’m the maintainer of the EmuTOS project; we
write a clone of the Atari ST’s TOS operating system. This is meant for to
be run on emulators.

http://emutos.sourceforge.net

For that there is Aranym, an emulator of the Atari Falcon computer
hardware and more. EmuTOS can run on this. Aranym uses SDL for nearly all
it’s input and output functions.

http://aranym.atari.org

While thinking about, how I could make a small linux distribution for to
start Aranym, I got the idea: Why not port Aranym and SDL to the RTEMS
realtime OS?!?

http://www.oarcorp.com/RTEMS/rtems.html

It would be ideal for this purpose, if I would get it ported. You just
link RTEMS realtime executive to your application, like you would do it
with libc. You then get a bootable application (ok, it is a bit more to
do…). Running the emulation would then mean, just put in the boot disk
and go. No Linux around, just the running Aranym.

RTEMS has the following features:

  • Realtime OS
  • GPLed software
  • Posix API
  • Threading
  • Multiprocessor
  • Multiplatform (incl. Intel PC hardware)
  • Fast
  • Small

Ok. So, now how do I start to port SDL to it? I just plan to have it
running on the common Intel/PC hardware with RTEMS. Is there some
documentation about porting SDL to new platforms? I had a short look into
the different subdirectories of the current CVS. What would I need to add
at least and what do I need to change in the configure stuff?

At first this all is just an idea. And maybe, it will not be the preferred
platform for Aranym. But it could be an interesting thing. Also to have
SDL available on RTEMS maybe interesting for others too. An embedded
system with graphics capabilities maybe a good choice for many
applications.

What do you think, could this be done, and how hard would it be?–
Martin Doering

Did anyone ever answer this? I stuck some info farther down.

–joel

Martin Doering wrote:

Hello, SDL developers!

My name ist Martin Doering. I’m the maintainer of the EmuTOS project; we
write a clone of the Atari ST’s TOS operating system. This is meant for to
be run on emulators.

http://emutos.sourceforge.net

For that there is Aranym, an emulator of the Atari Falcon computer
hardware and more. EmuTOS can run on this. Aranym uses SDL for nearly all
it’s input and output functions.

http://aranym.atari.org

While thinking about, how I could make a small linux distribution for to
start Aranym, I got the idea: Why not port Aranym and SDL to the RTEMS
realtime OS?!?

http://www.oarcorp.com/RTEMS/rtems.html

It would be ideal for this purpose, if I would get it ported. You just
link RTEMS realtime executive to your application, like you would do it
with libc. You then get a bootable application (ok, it is a bit more to
do…). Running the emulation would then mean, just put in the boot disk
and go. No Linux around, just the running Aranym.

RTEMS has the following features:

  • Realtime OS
  • GPLed software
  • Posix API
  • Threading
  • Multiprocessor
  • Multiplatform (incl. Intel PC hardware)
  • Fast
  • Small

Ok. So, now how do I start to port SDL to it? I just plan to have it
running on the common Intel/PC hardware with RTEMS. Is there some
documentation about porting SDL to new platforms? I had a short look into
the different subdirectories of the current CVS. What would I need to add
at least and what do I need to change in the configure stuff?

With a PC, you should be able to use the i386-rtems target and one
of the pcXXX BSP variants. If you make extensive use of POSIX
services or just want to ease porting from Linux, then you
should add --enable-posix.

Not knowing the application, that’s about it.

At first this all is just an idea. And maybe, it will not be the preferred
platform for Aranym. But it could be an interesting thing. Also to have
SDL available on RTEMS maybe interesting for others too. An embedded
system with graphics capabilities maybe a good choice for many
applications.

It would be nice and light and could be a nice baseline anyway.

What do you think, could this be done, and how hard would it be?

If it doesn’t use UNIX processes or shared memory, it shouldn’t be
that difficult to port. The first step with any embedded environment
is getting hello world running though. :)> –

Martin Doering


Joel Sherrill, Ph.D. Director of Research & Development
joel at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985

Did anyone ever answer this? I stuck some info farther down.

Your best bet is to get the core SDL functions compiling for RTEMS,
and then look at the myriad drivers for SDL to see how to implement
new ones. The “disk” audio driver and the “dummy” video driver are
decent places to start.

You can disable most of the subsystems from the configure script, if
you want to get a bare-bones version of SDL building.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment