Rewrite input system for hot-plugging

I haven’t checked the keyboard code yet, but the mouse stuff has a lot
of sloppy coding, like using mouse IDs and indices interchangeably,
maintaining several separate lists for the same set of devices and
various memory leaks. It all works fine, for the most part, until you
try to delete a mouse, then falls apart completely.

I’ve gone through the input system tracking this stuff down, and it’s
not going to be a nice little 10 line patch. It really should be
rewritten from scratch. I can work on Windows and Linux, but while I
may be able to stumble my way through on other platforms, I have no
way to test them. This may need a branch in SVN to avoid breaking
trunk.

Also, Joysticks use a completely different API than the mouse and
keyboard. It would be nice to have it consistent between all three.

Device notifications and raw input can work without a visible window.
It would make sense to split input off to a separate subsystem instead
of grouping it with video.

We’re running out of space for new events. There’s still a little
room left, but it might be a good idea to switch to 64 bits instead of
32 for event masks, or group keyboard, mouse and joystick events the
same way window events are grouped.

This may be a good time to work in some C++ code as well. Not as a
wrapper, but as a separate library built on SDL internals and compiled
alongside SDL proper.

Device notifications and raw input can work without a visible window.
It would make sense to split input off to a separate subsystem instead
of grouping it with video.

I thought that was the exact reason it was grouped with video to begin
with? I mean, sure on most platforms you can access most HIDs without
a window, but I think we should definitely be prepared to hear from
people who disagree with the assertion that you can easily separate
video from input.

This may be a good time to work in some C++ code as well. ?Not as a
wrapper, but as a separate library built on SDL internals and compiled
alongside SDL proper.

It does seem like 1.3 SDL is moving away from old, esoteric platforms
where it would have been nice to not need the C++ runtime dependency.
Maybe consider something like what happened to Mozilla Spidermonkey
where they still maintain their C API but a lot of the underlying
implementation is now written in C++.

If I were going to vote for any big move forward, I’d recommend moving
to Git or even better Mercurial. Subversion just doesn’t cut it
anymore guys!On Tue, Sep 8, 2009 at 7:29 AM, Kenneth Bull wrote:


http://codebad.com/

Device notifications and raw input can work without a visible window.
It would make sense to split input off to a separate subsystem instead
of grouping it with video.

I thought that was the exact reason it was grouped with video to begin
with? I mean, sure on most platforms you can access most HIDs without
a window, but I think we should definitely be prepared to hear from
people who disagree with the assertion that you can easily separate
video from input.

Whether or not it’s easy, it needs to be done. Forcibly coupling video and
input feels very artificial makes some simple tasks (most notably using
SDL input without SDL video) require ugly workarounds.>----- Original Message ----

From: Donny Viszneki <donny.viszneki at gmail.com>
Subject: Re: [SDL] Rewrite input system for hot-plugging
On Tue, Sep 8, 2009 at 7:29 AM, Kenneth Bull wrote:

Compared to the alternative of requiring ugly workarounds for more
common use cases (ie. both video and input) seems undesirable to the
SDL community.On Tue, Sep 8, 2009 at 9:45 AM, Mason Wheeler wrote:

Whether or not it’s easy, it needs to be done. ?Forcibly coupling video and
input feels very artificial makes some simple tasks (most notably using
SDL input without SDL video) require ugly workarounds.


http://codebad.com/

Whether or not it’s easy, it needs to be done. Forcibly coupling video and
input feels very artificial makes some simple tasks (most notably using
SDL input without SDL video) require ugly workarounds.

Compared to the alternative of requiring ugly workarounds for more
common use cases (ie. both video and input) seems undesirable to the
SDL community.

What ugly workarounds?

SDL_Init(SDL_INIT_VIDEO | SDL_INIT_INPUT);

Done.>----- Original Message ----

From: Donny Viszneki <donny.viszneki at gmail.com>
Subject: Re: [SDL] Rewrite input system for hot-plugging
On Tue, Sep 8, 2009 at 9:45 AM, Mason Wheeler<@Mason_Wheeler> wrote:

Whether or not it’s easy, it needs to be done. ?Forcibly coupling video and
input feels very artificial makes some simple tasks (most notably using
SDL input without SDL video) require ugly workarounds.

Compared to the alternative of requiring ugly workarounds for more
common use cases (ie. both video and input) seems undesirable to the
SDL community.

What ugly workarounds?

SDL_Init(SDL_INIT_VIDEO | SDL_INIT_INPUT);

Done.

sigh

Yes, that is the way things are now. I wasn’t advising against making
core changes to the input and video subsystems that would make things
the way they are already.

Right now it can be a little hairy if you want input without video. My
understanding which I explained already was that this was because some
platforms require a window before you can listen to certain input
devices.

My advice was that we shouldn’t resolve input-sans-video hairiness if
it means incurring input-and-video hairiness.On Tue, Sep 8, 2009 at 10:10 AM, Mason Wheeler wrote:

----- Original Message ----
From: Donny Viszneki <@Donny_Viszneki>
Subject: Re: [SDL] Rewrite input system for hot-plugging
On Tue, Sep 8, 2009 at 9:45 AM, Mason Wheeler wrote:


http://codebad.com/

Hi.

Sounds good.

I don’t know about introducing C++. I like C++ as a language (RAII is
great), but it has drawbacks. C++ tends to produce much larger
binaries, and if you are going to be using C as the API anyway then
you aren’t gaining all that much. Can you see any benefits (to the API
users primarly, but also to the library maintainers) of writing some
areas in C++?

At the risk of being called a heretic, but if you want a SDL-like API
in C++ there is always SFML.

I like the idea of moving grouping the various types of input events
though. Dealing with windowless input is less of a priority, I don’t
know how reliably it could be done cross platform.

Forcibly coupling video and input feels very artificial makes some simple tasks

I don’t think that SDL is the one forcing that coupling. It tends to
be the way window managers expect you to work - which is reasonable
for 99% of applications I guess.

– BrianOn Tue, Sep 8, 2009 at 2:23 PM, Donny Viszneki<donny.viszneki at gmail.com> wrote:

On Tue, Sep 8, 2009 at 7:29 AM, Kenneth Bull wrote:

Device notifications and raw input can work without a visible window.
It would make sense to split input off to a separate subsystem instead
of grouping it with video.

I thought that was the exact reason it was grouped with video to begin
with? I mean, sure on most platforms you can access most HIDs without
a window, but I think we should definitely be prepared to hear from
people who disagree with the assertion that you can easily separate
video from input.

This may be a good time to work in some C++ code as well. ?Not as a
wrapper, but as a separate library built on SDL internals and compiled
alongside SDL proper.

It does seem like 1.3 SDL is moving away from old, esoteric platforms
where it would have been nice to not need the C++ runtime dependency.
Maybe consider something like what happened to Mozilla Spidermonkey
where they still maintain their C API but a lot of the underlying
implementation is now written in C++.

SDL is an abstraction layer. There are a lot of C structs packed with
pointers to functions which have been selected by SDL as being the
appropriate implementations of what is symbolically referred to by the
corresponding struct member. These are a lot like Java interfaces, or
C++ pure virtual base classes (or nearly pure, anyhow.)

“C++ tends to produce much larger binaries” is a myth. If you write
something using a bunch of STL or other template-heavy code, then
sure, you get big binaries. But attributing this to C++ is a mistake.On Tue, Sep 8, 2009 at 10:32 AM, Brian<brian.ripoff at gmail.com> wrote:

I don’t know about introducing C++. I like C++ as a language (RAII is
great), but it has drawbacks. C++ tends to produce much larger
binaries, and if you are going to be using C as the API anyway then
you aren’t gaining all that much. Can you see any benefits (to the API
users primarly, but also to the library maintainers) of writing some
areas in C++?


http://codebad.com/

I like C++ as a language (RAII is great), but it has drawbacks.

blink

Umm… what C++ are you using? In the one I learned in college,
RAII isn’t “great”, it’s an annoying, hackish idom requiring the
coder to do a lot of extra work to compensate for two stupid
mistakes in the language design: that object construction
doesn’t zero out the memory space first and that you’re allowed
to allocate objects on the stack.>----- Original Message ----

From: Brian <brian.ripoff at gmail.com>
Subject: Re: [SDL] Rewrite input system for hot-plugging

I understand that, but if you are not using the SC++L, it makes using
C++ not nearly as attractive. And yes, the function pointers are a
little ugly, but is it a big enough burden to justify such a move (at
least IMHO)? At the end of the day its a small amount of boilerplate
code. The current setup is a little ugly and hackish - I agree. I
would be worried that we might be making it hard for future ports to
obscure platforms where the C++ compiler support isn’t as good.

Umm… what C++ are you using? …

Stepping away from the potential language war, I will just say:

  1. Memory isn’t the only resource that needs managing, RAII can handle
    all kinds of resources.
  2. I love objects on the stack =)
  3. Zero isn’t always a great default value for complex objects members

– BrianOn Tue, Sep 8, 2009 at 3:39 PM, Donny Viszneki<donny.viszneki at gmail.com> wrote:

On Tue, Sep 8, 2009 at 10:32 AM, Brian<@Brian_Barrett> wrote:

I don’t know about introducing C++. I like C++ as a language (RAII is
great), but it has drawbacks. C++ tends to produce much larger
binaries, and if you are going to be using C as the API anyway then
you aren’t gaining all that much. Can you see any benefits (to the API
users primarly, but also to the library maintainers) of writing some
areas in C++?

SDL is an abstraction layer. There are a lot of C structs packed with
pointers to functions which have been selected by SDL as being the
appropriate implementations of what is symbolically referred to by the
corresponding struct member. These are a lot like Java interfaces, or
C++ pure virtual base classes (or nearly pure, anyhow.)

“C++ tends to produce much larger binaries” is a myth. If you write
something using a bunch of STL or other template-heavy code, then
sure, you get big binaries. But attributing this to C++ is a mistake.


http://codebad.com/


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I hate to spam the list with this, but I’ve done it in the past…On Tue, Sep 8, 2009 at 10:46 AM, Mason Wheeler wrote:

Umm… what C++ are you using? ?In the one I learned in college,
RAII isn’t “great”, it’s an annoying, hackish idom requiring the
coder to do a lot of extra work to compensate for two stupid
mistakes in the language design: that object construction
doesn’t zero out the memory space first and that you’re allowed
to allocate objects on the stack.

rofl, wtf mason? can you really not realize how tiny a minority you
are in to express such feelings about the raii pattern?


http://codebad.com/

I hate to spam the list with this, but I’ve done it in the past…

Umm… what C++ are you using? In the one I learned in college,
RAII isn’t “great”, it’s an annoying, hackish idom requiring the
coder to do a lot of extra work to compensate for two stupid
mistakes in the language design: that object construction
doesn’t zero out the memory space first and that you’re allowed
to allocate objects on the stack.

rofl, wtf mason? can you really not realize how tiny a minority you
are in to express such feelings about the raii pattern?

It’s only a minority if you define “the whole” as only including those
coders who actually enjoy using C++. (And even then I’m not so sure.)>----- Original Message ----

From: Donny Viszneki <donny.viszneki at gmail.com>
Subject: Re: [SDL] Rewrite input system for hot-plugging
On Tue, Sep 8, 2009 at 10:46 AM, Mason Wheeler<@Mason_Wheeler> wrote:

I understand that, but if you are not using the SC++L, it makes using
C++ not nearly as attractive. And yes, the function pointers are a
little ugly, but is it a big enough burden to justify such a move (at
least IMHO)? At the end of the day its a small amount of boilerplate
code. The current setup is a little ugly and hackish - I agree.

I don’t think it’s ugly at all. This used to be the right way to do
this sort of thing. I just think people get more done in C++ when this
is the kind of code they have to work with.

I
would be worried that we might be making it hard for future ports to
obscure platforms where the C++ compiler support isn’t as good.

As I said earlier, I think those days have pretty much concluded with
SDL 1.2.7. SDL 1.3 is brave new territory.On Tue, Sep 8, 2009 at 10:56 AM, Brian<brian.ripoff at gmail.com> wrote:


http://codebad.com/

err… that 7 is entirely habitual from my days on a specific system
where 1.2.7 was the package that was availableOn Tue, Sep 8, 2009 at 11:03 AM, Donny Viszneki<@Donny_Viszneki> wrote:

As I said earlier, I think those days have pretty much concluded with
SDL 1.2.7. SDL 1.3 is brave new territory.


http://codebad.com/

Umm… what C++ are you using? …

Stepping away from the potential language war, I will just say:

  1. Memory isn’t the only resource that needs managing, RAII can handle
    all kinds of resources.

Yes, but so can plenty of other, less hackish patterns.

  1. I love objects on the stack =)

OK, can’t help you there. You can have value types, or you can have
objects, but trying to mix the two leads to all sorts of problems, not
the least of which is requiring ugly hacks like RAII to manage them
properly.

  1. Zero isn’t always a great default value for complex objects members

It is when you consider the alternative. How often do you write a
constructor and initialize any member to any constant value other than
zero/NULL? I’ve seen it a very few times, and those usually have to
do with enumerated types. But most of the time you either initialize
things to zero or to the result of some function or constructor.

The reason you need RAII when you don’t zero out the memory is because
if something goes wrong during object construction and you throw an
exception, the destructor has no way of telling how far along the
construction process got before bailing out, so it doesn’t know which
sub-objects are safe to destroy and which aren’t. If the memory had been
zeroed out first, you could call Free on everything safely.>----- Original Message ----

From: Brian <brian.ripoff at gmail.com>
Subject: Re: [SDL] Rewrite input system for hot-plugging

Damage control time…

if you’re under the age of 13 please stop reading what mason writes :stuck_out_tongue:

It is when you consider the alternative. ?How often do you write a
constructor and initialize any member to any constant value other than
zero/NULL? ?I’ve seen it a very few times, and those usually have to
do with enumerated types. ?But most of the time you either initialize
things to zero or to the result of some function or constructor.

If you were only talking about references/pointers, I’m behind you
100% on the initialization value argument.

In fact, C++ is also behind you 100%. That’s why references were added
to C++ so that you don’t have to use pointers which might have
arbitrary garbage values. (Personally I feel they’re a little too
restrictive, but it sounds like you care more about having your values
initialized to something useful.)

Your assertion that most initialization values should be zero or NULL
is completely f’n retarded. It is critical to initialize values
yourself.

The reason you need RAII when you don’t zero out the memory is because
if something goes wrong during object construction and you throw an
exception, the destructor has no way of telling how far along the
construction process got before bailing out, so it doesn’t know which
sub-objects are safe to destroy and which aren’t. ?If the memory had been
zeroed out first, you could call Free on everything safely.

Sure, in Imagination Land where most of the Resources you’re Acquiring
only exist inside in-process memory, and aren’t things that exist in
other processes, in the kernel, on other systems, or in meatspace (try
telling the engineers that write systems at a nuclear power facility
they can’t use RAII because all their plutonium should have been
initialized to zeros.)

Take this off list.On Tue, Sep 8, 2009 at 11:13 AM, Mason Wheeler wrote:


http://codebad.com/

Your assertion that most initialization values should be zero or NULL
is completely f’n retarded. It is critical to initialize values
yourself.

If that’s what I was asserting, yes, it would be. But that’s not what I
meant, and I can’t help but wonder what sort of mental gymnastics it
takes to arrive at that conclusion from what I wrote.

To make it extra clear for those who don’t get it: Zero is often not the
right ultimate value to initialize your references to when you create an
object. But it’s the only starting point that makes sense, because
things can go wrong while creating an object, and C++'s object model
not zeroing object memory before the constructor runs is a serious
defect.

On the other hand, there’s often a fair amount of the object that you want
to initialize to 0, especially non-object members. In this case, zeroing
the memory beforehand saves you a lot of work.

The reason you need RAII when you don’t zero out the memory is because
if something goes wrong during object construction and you throw an
exception, the destructor has no way of telling how far along the
construction process got before bailing out, so it doesn’t know which
sub-objects are safe to destroy and which aren’t. If the memory had been
zeroed out first, you could call Free on everything safely.

Sure, in Imagination Land where most of the Resources you’re Acquiring
only exist inside in-process memory, and aren’t things that exist in
other processes, in the kernel, on other systems, or in meatspace (try
telling the engineers that write systems at a nuclear power facility
they can’t use RAII because all their plutonium should have been
initialized to zeros.)

Umm… most of the resources you acquire do exist only inside process
memory! Show me even one program where external resources account
for more than 1% of resource acquisitions. And there are plenty of
better ways to handle external resources. (And if you know of a nuclear
power plant whose control system runs on C++, please let me know
where it is so I can make sure I don’t live nearby.)

Bottom line: You can say “I like feature X” or “most of the people using
this language like feature X”, but, as you pointed out, that’s a real
subjective measurement. A much better way to measure the quality of
a language feature is to see what else uses it. Truly good features get
copied around and integrated elsewhere. AFAIK the only other
programming language that implements RAII is D. No surprise there,
since its object model is heavily based on C++'s, and it allows you to
allocate objects on the stack.

2009/9/8 Mason Wheeler :

Your assertion that most initialization values should be zero or NULL
is completely f’n retarded. It is critical to initialize values
yourself.

This is true, you should be initializing variables yourself, but
having a sensible default assigned by the constructors of the various
types you’re working with helps. Not zeroing everything through some
backend compiler magic, but using well designed type classes that do
it for you. Even int and double have constructors, which do assign a
zero value by default. The compiler just doesn’t always call these
constructors on basic types when you might expect it to.

To make it extra clear for those who don’t get it: ?Zero is often not the
right ultimate value to initialize your references to when you create an
object. ?But it’s the only starting point that makes sense, because
things can go wrong while creating an object, and C++'s object model
not zeroing object memory before the constructor runs is a serious
defect.

On the other hand, there’s often a fair amount of the object that you want
to initialize to 0, especially non-object members. ?In this case, zeroing
the memory beforehand saves you a lot of work.

“Zeroing memory beforehand” would also be time consuming for large
types and arrays. So would calling constructors. Also, if you’re
using pointers, the compiler can’t really initialize the pointer’s
target, only the pointer itself.

The reason you need RAII when you don’t zero out the memory is because
if something goes wrong during object construction and you throw an
exception, the destructor has no way of telling how far along the
construction process got before bailing out, so it doesn’t know which
sub-objects are safe to destroy and which aren’t. ?If the memory had been
zeroed out first, you could call Free on everything safely.

You’re not likely to get an exception when assigning values to basic
types. You could initialize the simple stuff at the beginning of the
constructor and the more complex stuff near the end. Also, don’t
forget that most exceptions can be caught. You can put a try/catch
block in a constructor. You can also set a flag at the beginning of
the constructor and clear it at the end to indicate whether it
finished or not.

Sure, in Imagination Land where most of the Resources you’re Acquiring
only exist inside in-process memory, and aren’t things that exist in
other processes, in the kernel, on other systems, or in meatspace (try
telling the engineers that write systems at a nuclear power facility
they can’t use RAII because all their plutonium should have been
initialized to zeros.)

If a value exists “in meatspace” then you need some sort of user input
function to get it into the computer. I would rather avoid calling
such a function from a constructor, and rather pass the value as a
constructor argument or fetch it after the object is created.

Umm… most of the resources you acquire do exist only inside process
memory! ?Show me even one program where external resources account
for more than 1% of resource acquisitions. ?And there are plenty of
better ways to handle external resources. (And if you know of a nuclear
power plant whose control system runs on C++, please let me know
where it is so I can make sure I don’t live nearby.)

Anything which uses files, input devices or system calls.

I’d be more worried about nuclear power plant software that tries to
use an uninitialized value, no matter what the language. I kinda
expect at least a few would run on Fortran and Cobol; is that an
improvement?

Bottom line: You can say “I like feature X” or “most of the people using
this language like feature X”, but, as you pointed out, that’s a real
subjective measurement. ?A much better way to measure the quality of
a language feature is to see what else uses it. ?Truly good features get
copied around and integrated elsewhere. ?AFAIK the only other
programming language that implements RAII is D. ?No surprise there,
since its object model is heavily based on C++'s, and it allows you to
allocate objects on the stack.

If you don’t like a particular programming language, use a different
one. Most compilers / interpreters allow you to call code written in
other languages, so “but library x is written in y” isn’t really an
excuse.

Donny Viszneki <donny.viszneki at gmail.com> writes:

Device notifications and raw input can work without a visible window.
It would make sense to split input off to a separate subsystem instead
of grouping it with video.

I thought that was the exact reason it was grouped with video to begin
with? I mean, sure on most platforms you can access most HIDs without
a window, but I think we should definitely be prepared to hear from
people who disagree with the assertion that you can easily separate
video from input.

First: yes input device hot-plugging would be a nice to have. Regarding
API issues or perhaps the more general perspective: yes, ideally input
and output would be completely seperate issues, but to some degree the
proliferation of pointing devices introduced a dependency of input on
output :wink:

This may be a good time to work in some C++ code as well. Not as a
wrapper, but as a separate library built on SDL internals and
compiled alongside SDL proper.

You probably would have better used a different thread for this one or
maybe search the archive. Anyway here is my point of view: i prefer c++
over c but anyway I would not introduce C++ to SDL. Why? Because
providing language bindings and a stable API for C libraries is so much
easier. (+ portability is still easier with C).

Greets
karme> On Tue, Sep 8, 2009 at 7:29 AM, Kenneth Bull wrote:

Mason Wheeler wrote:

Umm… what C++ are you using? In the one I learned in college,
RAII isn’t “great”, it’s an annoying, hackish idom requiring the
coder to do a lot of extra work to compensate for two stupid
mistakes in the language design: that object construction
doesn’t zero out the memory space first and that you’re allowed
to allocate objects on the stack.

RAII and the ability to put objects in the stack are the reasons I use
C++. Other designs are possible, but it is supremely ignorant to call
these aspects of C++ “design mistakes”.–
Rainer Deyke - rainerd at eldwood.com