Haptic joystick "hotpluging" bug (RFC for fix suggestions)

SDL Development
1

All,

Alternative Games (game porting company) has found a rather interesting
bug in the haptic code. I WOULD like to see it fixed for the 2.0.2
release, but the fix may be somewhat complicated. So I would like
suggestions as to how I should fix it…

Here is the bug. (which can be reproduced with the testhotplug.c I
recently added).

  1. Plug in a rumble-supported controller
  2. run the testhotplug test app in a terminal (terminal only app)
  3. It detects the controller and the haptic interface…
  4. Moving the axis,or pressing buttons triggers rumble (I had a little
    fun :smiley: ).
  5. disconnect the controller & the app sees the controller went away.
  6. reconnect the controller & the app sees the controller again and
    re-establishes the haptics

Now here’s one of the broken cases. press Ctrl-C in the terminal to
exit the test app.

  1. disconnect the controller
  2. start the testhotplug app
  3. note that it detects 0 controllers and 0 haptics.
  4. plug in your controller
  5. it detects the controller and sees that it supports haptic
    (JoystickIsHaptic) but fails to open it with an error that 0 haptic
    devices are available.

The bug…

So, in the platform generic haptic code there is an array SDL_haptics
and an in SDL_numhaptics that get sized and initialized on haptic
subsystem init. So in the second case it gets initialized to 0 haptic
devices. Later when a joystick is hotplugged that array is resized, nor
the # of devices updated thus the haptic open fails because there is no
place to store the data.

This is a fully cross-platform bug too!

This would also happen if you had one controller plugged and later
plugged a second controller… only one controller would be able to open
a haptic interface.

So, ideas I’ve had on fixing it.

  1. have the haptic generic bits resize the array / update the #. ( BAD
    as it could cause threading issues)
  2. pre-allocate a number of free slots. ( would limit the # of
    hotpluggable devices… Mixed feelings on this.)
  3. convert it to a linked list (less threading issues and it’s what is
    done in Joystick and GameController subsystems)… This just requires

I tried # 2 by doing a dirty fix of simply adding + 4 to the result of
SDL_SYS_HapticInit… this failed in horrible ways as the haptic system
tried opening non-existent devices… And #3 sounds the best approach to
solving the issue but requires a slight overhaul of the innards of the
haptic subsystem.–
Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
317-674-3296

2

So, ideas I’ve had on fixing it.

  1. have the haptic generic bits resize the array / update the #. ( BAD
    as it could cause threading issues)
  2. pre-allocate a number of free slots. ( would limit the # of
    hotpluggable devices… Mixed feelings on this.)
  3. convert it to a linked list (less threading issues and it’s what is
    done in Joystick and GameController subsystems)… This just requires

I think 3 is the way to go, which means it’s also time for yet another
linked list implementation…we really need to consolidate that stuff.–
Gabriel.

3

Are there other subsystems that have the same storage needs? What do they
do?

Jonny DOn Tue, Feb 4, 2014 at 10:20 AM, Gabriel Jacobo wrote:

So, ideas I’ve had on fixing it.

  1. have the haptic generic bits resize the array / update the #. ( BAD
    as it could cause threading issues)
  2. pre-allocate a number of free slots. ( would limit the # of
    hotpluggable devices… Mixed feelings on this.)
  3. convert it to a linked list (less threading issues and it’s what is
    done in Joystick and GameController subsystems)… This just requires

I think 3 is the way to go, which means it’s also time for yet another
linked list implementation…we really need to consolidate that stuff.

–
Gabriel.

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

4 
    So, ideas I've had on fixing it.

    1) have the haptic generic bits resize the array / update the
    #. ( BAD
    as it could cause threading issues)
    2) pre-allocate a number of free slots. ( would limit the # of
    hotpluggable devices.. Mixed feelings on this.)
    3) convert it to a linked list (less threading issues and it's
    what is
    done in Joystick and GameController subsystems).. This just
    requires


I think 3 is the way to go, which means it's also time for yet
another linked list implementation...we really need to consolidate
that stuff.

Are there other subsystems that have the same storage needs? What do
they do?

Jonny D
at least, Joystick and gamecontroller both use linked-list for this storage.

If this were C++ I’d be SO on writing a common generic template
implementation:)

I’ll work up a patch while I chase down game bugs :)On 02/04/2014 10:24 AM, Jonathan Dearborn wrote:

On Tue, Feb 4, 2014 at 10:20 AM, Gabriel Jacobo <gabomdq at gmail.com <mailto:gabomdq at gmail.com>> wrote:

–
Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
317-674-3296

5

2014-02-04 Edward Rudd :

So, ideas I’ve had on fixing it.

  1. have the haptic generic bits resize the array / update the #. ( BAD
    as it could cause threading issues)
  2. pre-allocate a number of free slots. ( would limit the # of
    hotpluggable devices… Mixed feelings on this.)
  3. convert it to a linked list (less threading issues and it’s what is
    done in Joystick and GameController subsystems)… This just requires

I think 3 is the way to go, which means it’s also time for yet another
linked list implementation…we really need to consolidate that stuff.

Are there other subsystems that have the same storage needs? What do they
do?

Jonny D

at least, Joystick and gamecontroller both use linked-list for this
storage.

udev, hints, asserts, logs, etc (if you grep for “->next” on SDL’s code
you’ll see an orgy of linked lists, each with its own implementation)

If this were C++ I’d be SO on writing a common generic template
implementation:)

Flamebait! :slight_smile:

I’ll work up a patch while I chase down game bugs :slight_smile:

Ryan suggested the Linux kernel’s implementation, which is of course GPL,
but might be a good inspiration source for a generalized solution. Other
than that, suggestions are most welcome!

Gabriel.> On 02/04/2014 10:24 AM, Jonathan Dearborn wrote:

On Tue, Feb 4, 2014 at 10:20 AM, Gabriel Jacobo <@Gabriel_Jacobo>wrote:

6

As far as combining the linked list implementations (while maintaining
binary compatibility) is to wrap their definitions in preprocessor. This
functions similarly to how C++ does it’s generic templating, processes at
compile time. The downside is this is quite ugly to code:

#define LINKED_LIST_PROTO( type, name )
struct name {
name *next;
type data;
};
void name##_push_tail( name *head, type *data );
// and other functions…

#define LINKED_LIST_IMPEMENTATION( type, name )
void name##_push_tail( name *head, type *data ) {
// code
}
// Other functions

It’s disgusting, but it does mean code once, use multiple times, but the
code is much less maintainable (so hopefully it would because something
that’s “set it and forget it”). I haven’t looked into the internals of
SDL’s linked list implementations, so this may not even be plausible.

Another solution would be to make the storage of the nodes to be void* and
hope that you know in every situation how to cast that properly.

Just my thoughts on it, though, and they may be quite off base (but I’ll
peek into SDL’s linked list stuff after work).

-AlexOn Tue, Feb 4, 2014 at 12:13 PM, Gabriel Jacobo wrote:

2014-02-04 Edward Rudd :

On 02/04/2014 10:24 AM, Jonathan Dearborn wrote:

On Tue, Feb 4, 2014 at 10:20 AM, Gabriel Jacobo wrote:

So, ideas I’ve had on fixing it.

  1. have the haptic generic bits resize the array / update the #. ( BAD
    as it could cause threading issues)
  2. pre-allocate a number of free slots. ( would limit the # of
    hotpluggable devices… Mixed feelings on this.)
  3. convert it to a linked list (less threading issues and it’s what is
    done in Joystick and GameController subsystems)… This just requires

I think 3 is the way to go, which means it’s also time for yet another
linked list implementation…we really need to consolidate that stuff.

Are there other subsystems that have the same storage needs? What do
they do?

Jonny D

at least, Joystick and gamecontroller both use linked-list for this
storage.

udev, hints, asserts, logs, etc (if you grep for “->next” on SDL’s code
you’ll see an orgy of linked lists, each with its own implementation)

If this were C++ I’d be SO on writing a common generic template
implementation:)

Flamebait! :slight_smile:

I’ll work up a patch while I chase down game bugs :slight_smile:

Ryan suggested the Linux kernel’s implementation, which is of course GPL,
but might be a good inspiration source for a generalized solution. Other
than that, suggestions are most welcome!

Gabriel.

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

7

There should be already several implementations for this kind of thing,
e.g. queue.h from the BSDs

Cheers,
DanielAm 04.02.2014 18:52, schrieb Alex Barry:

As far as combining the linked list implementations (while maintaining
binary compatibility) is to wrap their definitions in preprocessor.
This functions similarly to how C++ does it’s generic templating,
processes at compile time. The downside is this is quite ugly to code:

#define LINKED_LIST_PROTO( type, name )
struct name {
name *next;
type data;
};
void name##_push_tail( name *head, type *data );
// and other functions…

#define LINKED_LIST_IMPEMENTATION( type, name )
void name##_push_tail( name *head, type *data ) {
// code
}
// Other functions

It’s disgusting, but it does mean code once, use multiple times, but the
code is much less maintainable (so hopefully it would because something
that’s “set it and forget it”). I haven’t looked into the internals of
SDL’s linked list implementations, so this may not even be plausible.

Another solution would be to make the storage of the nodes to be void*
and hope that you know in every situation how to cast that properly.

Just my thoughts on it, though, and they may be quite off base (but I’ll
peek into SDL’s linked list stuff after work).

-Alex

On Tue, Feb 4, 2014 at 12:13 PM, Gabriel Jacobo <gabomdq at gmail.com <mailto:gabomdq at gmail.com>> wrote:

2014-02-04 Edward Rudd <urkle at outoforder.cc
<mailto:urkle at outoforder.cc>>:

    On 02/04/2014 10:24 AM, Jonathan Dearborn wrote:

    On Tue, Feb 4, 2014 at 10:20 AM, Gabriel Jacobo <gabomdq at gmail.com <mailto:gabomdq at gmail.com>> wrote:

            So, ideas I've had on fixing it.

            1) have the haptic generic bits resize the array /
            update the #. ( BAD
            as it could cause threading issues)
            2) pre-allocate a number of free slots. ( would limit
            the # of
            hotpluggable devices.. Mixed feelings on this.)
            3) convert it to a linked list (less threading issues
            and it's what is
            done in Joystick and GameController subsystems).. This
            just requires


        I think 3 is the way to go, which means it's also time for
        yet another linked list implementation...we really need to
        consolidate that stuff.


    Are there other subsystems that have the same storage needs?
     What do they do?

    Jonny D

    at least, Joystick and gamecontroller both use linked-list for
    this storage.


udev, hints, asserts, logs, etc (if you grep for "->next" on SDL's
code you'll see an orgy of linked lists, each with its own
implementation)


    If this were C++ I'd be SO on writing a common generic template
    implementation:)


Flamebait! :)


    I'll work up a patch while I chase down game bugs :)


Ryan suggested the Linux kernel's implementation, which is of course
GPL, but might be a good inspiration source for a generalized
solution. Other than that, suggestions are most welcome!

Gabriel.

_______________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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

8

2014-02-04 Edward Rudd <@Edward_Rudd mailto:Edward_Rudd>:

        So, ideas I've had on fixing it.

        1) have the haptic generic bits resize the array / update
        the #. ( BAD
        as it could cause threading issues)
        2) pre-allocate a number of free slots. ( would limit the
        # of
        hotpluggable devices.. Mixed feelings on this.)
        3) convert it to a linked list (less threading issues and
        it's what is
        done in Joystick and GameController subsystems).. This
        just requires


    I think 3 is the way to go, which means it's also time for
    yet another linked list implementation...we really need to
    consolidate that stuff.


Are there other subsystems that have the same storage needs?
 What do they do?

Jonny D

at least, Joystick and gamecontroller both use linked-list for
this storage.

udev, hints, asserts, logs, etc (if you grep for “->next” on SDL’s
code you’ll see an orgy of linked lists, each with its own implementation)

Yeah… the generalization of the linked lists will be for another
day… I don’t want to make TOO many changes right now:-D

And I’m 100% with the platform independent part, and about 60% done with
the linux platform of the patch… I’ll be throwing it at Ryan here
shortly for code review and will also post to the list. Anyone want to
volunteer to adjust the Windows platform? I can work on the mac side
(although my controller doesn’t seem to present haptics on mac, only
linux. odd)On 02/04/2014 12:13 PM, Gabriel Jacobo wrote:

On 02/04/2014 10:24 AM, Jonathan Dearborn wrote:

On Tue, Feb 4, 2014 at 10:20 AM, Gabriel Jacobo <gabomdq at gmail.com <mailto:gabomdq at gmail.com>> wrote:

–
Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
317-674-3296

9

All,

Alternative Games (game porting company) has found a rather interesting
bug in the haptic code. I WOULD like to see it fixed for the 2.0.2
release, but the fix may be somewhat complicated. So I would like
suggestions as to how I should fix it…

Here is the bug. (which can be reproduced with the testhotplug.c I
recently added).

  1. Plug in a rumble-supported controller
  2. run the testhotplug test app in a terminal (terminal only app)
  3. It detects the controller and the haptic interface…
  4. Moving the axis,or pressing buttons triggers rumble (I had a little
    fun :smiley: ).
  5. disconnect the controller & the app sees the controller went away.
  6. reconnect the controller & the app sees the controller again and
    re-establishes the haptics

Now here’s one of the broken cases. press Ctrl-C in the terminal to
exit the test app.

  1. disconnect the controller
  2. start the testhotplug app
  3. note that it detects 0 controllers and 0 haptics.
  4. plug in your controller
  5. it detects the controller and sees that it supports haptic
    (JoystickIsHaptic) but fails to open it with an error that 0 haptic
    devices are available.

The bug…

So, in the platform generic haptic code there is an array SDL_haptics
and an in SDL_numhaptics that get sized and initialized on haptic
subsystem init. So in the second case it gets initialized to 0 haptic
devices. Later when a joystick is hotplugged that array is resized, nor
the # of devices updated thus the haptic open fails because there is no
place to store the data.

This is a fully cross-platform bug too!

This would also happen if you had one controller plugged and later
plugged a second controller… only one controller would be able to open
a haptic interface.

So, ideas I’ve had on fixing it.
[snip] [snip]
3) convert it to a linked list (less threading issues and it’s what is
done in Joystick and GameController subsystems)… This just requires
I’ve attached the initial version of the patch that implements the
linked list way of solving things… ONLY the linux backend has been
updated currently. And it works 100% in my testing.On 02/04/2014 10:02 AM, Edward Rudd wrote:

–
Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
317-674-3296

-------------- next part --------------
A non-text attachment was scrubbed…
Name: haptic.patch
Type: text/x-patch
Size: 19338 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20140204/f3901183/attachment.bin

10

Sglib http://sglib.sourceforge.net/ may be a good option for having some
linked-list implementations in a standard way across SDL - it’s not limited
by any license, as long as the license stays attached - make it a dep, and
we’d be all set. It looks like it could be integrated into the current
source, too, but I think we’d need to contact the author to be sure this is
viable.
As Daniel Gibson also mentioned, BSD
queue.hhttp://www.openbsd.org/cgi-bin/cvsweb/src/sys/sys/queue.h?rev=1.38;content-type=text%2Fplainmay
be a good option, too.
It’s probably important that we do have a standard mechanism in SDL2 for
linked lists if they are being frequently used in the background (perhaps
for 2.0.3?). I’ll have some spare time in a week and a half, so perhaps I
can write a patch for one of these two options.

-AlexOn Tue, Feb 4, 2014 at 3:46 PM, Edward Rudd wrote:

On 02/04/2014 10:02 AM, Edward Rudd wrote:

All,

Alternative Games (game porting company) has found a rather interesting
bug in the haptic code. I WOULD like to see it fixed for the 2.0.2
release, but the fix may be somewhat complicated. So I would like
suggestions as to how I should fix it…

Here is the bug. (which can be reproduced with the testhotplug.c I
recently added).

  1. Plug in a rumble-supported controller
  2. run the testhotplug test app in a terminal (terminal only app)
  3. It detects the controller and the haptic interface…
  4. Moving the axis,or pressing buttons triggers rumble (I had a little
    fun :smiley: ).
  5. disconnect the controller & the app sees the controller went away.
  6. reconnect the controller & the app sees the controller again and
    re-establishes the haptics

Now here’s one of the broken cases. press Ctrl-C in the terminal to
exit the test app.

  1. disconnect the controller
  2. start the testhotplug app
  3. note that it detects 0 controllers and 0 haptics.
  4. plug in your controller
  5. it detects the controller and sees that it supports haptic
    (JoystickIsHaptic) but fails to open it with an error that 0 haptic
    devices are available.

The bug…

So, in the platform generic haptic code there is an array SDL_haptics
and an in SDL_numhaptics that get sized and initialized on haptic
subsystem init. So in the second case it gets initialized to 0 haptic
devices. Later when a joystick is hotplugged that array is resized, nor
the # of devices updated thus the haptic open fails because there is no
place to store the data.

This is a fully cross-platform bug too!

This would also happen if you had one controller plugged and later
plugged a second controller… only one controller would be able to open
a haptic interface.

So, ideas I’ve had on fixing it.
[snip] [snip]
3) convert it to a linked list (less threading issues and it’s what is
done in Joystick and GameController subsystems)… This just requires
I’ve attached the initial version of the patch that implements the
linked list way of solving things… ONLY the linux backend has been
updated currently. And it works 100% in my testing.

–
Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
317-674-3296

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

11

Probably sglib would be a better choice because its license is pretty
much like the zlib license (used by SDL2), while the BSD license used by
queue.h is a bit less liberal (requiring copyright notice in distributed
binaries).

Cheers,
DanielAm 04.02.2014 21:56, schrieb Alex Barry:

Sglib http://sglib.sourceforge.net/ may be a good option for having
some linked-list implementations in a standard way across SDL - it’s not
limited by any license, as long as the license stays attached - make it
a dep, and we’d be all set. It looks like it could be integrated into
the current source, too, but I think we’d need to contact the author to
be sure this is viable.
As Daniel Gibson also mentioned, BSD queue.h
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/sys/queue.h?rev=1.38;content-type=text%2Fplain
may be a good option, too.
It’s probably important that we do have a standard mechanism in SDL2 for
linked lists if they are being frequently used in the background
(perhaps for 2.0.3?). I’ll have some spare time in a week and a half,
so perhaps I can write a patch for one of these two options.

-Alex

On Tue, Feb 4, 2014 at 3:46 PM, Edward Rudd <urkle at outoforder.cc <mailto:urkle at outoforder.cc>> wrote:

On 02/04/2014 10:02 AM, Edward Rudd wrote:
 > All,
 >
 > Alternative Games (game porting company) has found a rather
interesting
 > bug in the haptic code.  I *WOULD* like to see it fixed for the 2.0.2
 > release, but the fix may be somewhat complicated.  So I would like
 > suggestions as to how I should fix it..
 >
 > Here is the bug. (which can be reproduced with the testhotplug.c I
 > recently added).
 >
 > 1) Plug in a rumble-supported controller
 > 2) run the testhotplug test app in a terminal (terminal only app)
 > 3) It detects the controller and the haptic interface..
 > 4) Moving the axis,or pressing buttons triggers rumble (I had a
little
 > fun :-D ).
 > 5) disconnect the controller & the app sees the controller went away.
 > 6) reconnect the controller & the app sees the controller again and
 > re-establishes the haptics
 >
 > Now here's one of the broken cases.  press Ctrl-C in the terminal to
 > exit the test app.
 >
 > 1) disconnect the controller
 > 2) start the testhotplug app
 > 3) note that it detects 0 controllers and 0 haptics.
 > 4) plug in your controller
 > 5) it detects the controller and sees that it supports haptic
 > (JoystickIsHaptic) but fails to open it with an error that 0 haptic
 > devices are available.
 >
 >
 > The bug...
 >
 > So, in the platform generic haptic code there is an array SDL_haptics
 > and an in SDL_numhaptics that get sized and initialized on haptic
 > subsystem init.  So in the second case it gets initialized to 0
haptic
 > devices.  Later when a joystick is hotplugged that array is
resized, nor
 > the # of devices updated thus the haptic open fails because there
is no
 > place to store the data.
 >
 > This is a fully cross-platform bug too!
 >
 > This would also happen if you had one controller plugged and later
 > plugged a second controller..  only one controller would be able
to open
 > a haptic interface.
 >
 > So, ideas I've had on fixing it.
[snip] [snip]
 > 3) convert it to a linked list (less threading issues and it's
what is
 > done in Joystick and GameController subsystems).. This just requires
I've attached the initial version of the patch that implements the
linked list way of solving things.. ONLY the linux backend has been
updated currently. And it works 100% in my testing.

--
Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
317-674-3296 <tel:317-674-3296>


_______________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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

12

I’m not sure if we really need an entire library to do linked lists…
we have very lightweight uses of them… Add, iterate, and remove. I
can very easily create 3 simple macros to encapsulate all of that logic
and require no data structure changes.

ITERATE_LINKED_LIST(list, iter)
{
// for loop body
}
LINKED_LIST_ADD(list, item);
LINKED_LIST_REMOVE(list, item, iter);

Where “list” is an pointer to the top list item (e.g. SDL_joysticks),
“iter” is pointer to the current item, and “item” is the item to add/remove

Expansion of these would be simply.

#define ITERATE_LINKED_LIST(list, iter) for(iter = list; iter; iter =
iter->next)
#define LINKED_LIST_ADD(list, item) { item->next = list; list = item; }
#define LINKED_LIST_REMOVE(list, item, iter) ITERATE_LINKED_LIST(list,
iter) {
if (iter == item && iter == list) {
list = iter->next;
break;
}
if (iter->next == item) {
iter->next = item->next;
break;
}
}

And I used one less variable for the remove logic than the code in
SDL_joystick.c:418-438!On 02/04/2014 04:03 PM, Daniel Gibson wrote:

Probably sglib would be a better choice because its license is pretty
much like the zlib license (used by SDL2), while the BSD license used
by queue.h is a bit less liberal (requiring copyright notice in
distributed binaries).

Cheers,
Daniel

Am 04.02.2014 21:56, schrieb Alex Barry:

Sglib http://sglib.sourceforge.net/ may be a good option for having
some linked-list implementations in a standard way across SDL - it’s not
limited by any license, as long as the license stays attached - make it
a dep, and we’d be all set. It looks like it could be integrated into
the current source, too, but I think we’d need to contact the author to
be sure this is viable.
As Daniel Gibson also mentioned, BSD queue.h
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/sys/queue.h?rev=1.38;content-type=text%2Fplain

may be a good option, too.
It’s probably important that we do have a standard mechanism in SDL2 for
linked lists if they are being frequently used in the background
(perhaps for 2.0.3?). I’ll have some spare time in a week and a half,
so perhaps I can write a patch for one of these two options.

-Alex

On Tue, Feb 4, 2014 at 3:46 PM, Edward Rudd <@Edward_Rudd mailto:Edward_Rudd> wrote:

On 02/04/2014 10:02 AM, Edward Rudd wrote:
 > All,
 >
 > Alternative Games (game porting company) has found a rather
interesting
 > bug in the haptic code.  I *WOULD* like to see it fixed for

the 2.0.2
> release, but the fix may be somewhat complicated. So I would
like
> suggestions as to how I should fix it…
>
> Here is the bug. (which can be reproduced with the
testhotplug.c I
> recently added).
>
> 1) Plug in a rumble-supported controller
> 2) run the testhotplug test app in a terminal (terminal only app)
> 3) It detects the controller and the haptic interface…
> 4) Moving the axis,or pressing buttons triggers rumble (I had a
little
> fun :smiley: ).
> 5) disconnect the controller & the app sees the controller
went away.
> 6) reconnect the controller & the app sees the controller
again and
> re-establishes the haptics
>
> Now here’s one of the broken cases. press Ctrl-C in the
terminal to
> exit the test app.
>
> 1) disconnect the controller
> 2) start the testhotplug app
> 3) note that it detects 0 controllers and 0 haptics.
> 4) plug in your controller
> 5) it detects the controller and sees that it supports haptic
> (JoystickIsHaptic) but fails to open it with an error that 0
haptic
> devices are available.
>
>
> The bug…
>
> So, in the platform generic haptic code there is an array
SDL_haptics
> and an in SDL_numhaptics that get sized and initialized on haptic
> subsystem init. So in the second case it gets initialized to 0
haptic
> devices. Later when a joystick is hotplugged that array is
resized, nor
> the # of devices updated thus the haptic open fails because there
is no
> place to store the data.
>
> This is a fully cross-platform bug too!
>
> This would also happen if you had one controller plugged and
later
> plugged a second controller… only one controller would be able
to open
> a haptic interface.
>
> So, ideas I’ve had on fixing it.
[snip] [snip]
> 3) convert it to a linked list (less threading issues and it’s
what is
> done in Joystick and GameController subsystems)… This just
requires
I’ve attached the initial version of the patch that implements the
linked list way of solving things… ONLY the linux backend has been
updated currently. And it works 100% in my testing.

--
Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
317-674-3296 <tel:317-674-3296>


_______________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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

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

–
Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
317-674-3296

13

(perhaps for 2.0.3?). I’ll have some spare time in a week and a half,
so perhaps I can write a patch for one of these two options.

I don’t think we need a third-party library for linked lists.

–ryan.

14

Yeah, I should have added the option of rolling our own - linked lists
aren’t hard, I was just thinking it may be quicker to use a 3rd party, but
now that I think about it, it’s probably roughly the same time to just use
what’s already in the code and just convert it to some sort of generic
macro.On Tue, Feb 4, 2014 at 4:49 PM, Ryan C. Gordon wrote:

(perhaps for 2.0.3?). I’ll have some spare time in a week and a half,

so perhaps I can write a patch for one of these two options.

I don’t think we need a third-party library for linked lists.

–ryan.

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

15

Ah, but binary compatibility isn’t needed here because SDL’s linked
lists are not exposed to the outside world. SDL keeps these things
opaque. That way any segfaults reported involving those structures
being mishandled are actually likely to be SDL’s fault.

And because it’s good practice to protect new C++ devs from
themselves so they can get back to making the most revolutionary
award-winning new game engine. Y’know as soon as they figure out
what matrices in OpenGL do. (Oooh, moar flamebait!) :wink:

JosephOn Tue, Feb 04, 2014 at 12:52:53PM -0500, Alex Barry wrote:

As far as combining the linked list implementations (while maintaining
binary compatibility) is to wrap their definitions in preprocessor. This
functions similarly to how C++ does it’s generic templating, processes at
compile time. The downside is this is quite ugly to code:

#define LINKED_LIST_PROTO( type, name )
struct name {
name *next;
type data;
};
void name##_push_tail( name *head, type *data );
// and other functions…

#define LINKED_LIST_IMPEMENTATION( type, name )
void name##_push_tail( name *head, type *data ) {
// code
}
// Other functions

It’s disgusting, but it does mean code once, use multiple times, but the
code is much less maintainable (so hopefully it would because something
that’s “set it and forget it”). I haven’t looked into the internals of
SDL’s linked list implementations, so this may not even be plausible.

Another solution would be to make the storage of the nodes to be void* and
hope that you know in every situation how to cast that properly.

Just my thoughts on it, though, and they may be quite off base (but I’ll
peek into SDL’s linked list stuff after work).

-Alex

On Tue, Feb 4, 2014 at 12:13 PM, Gabriel Jacobo wrote:

2014-02-04 Edward Rudd :

On 02/04/2014 10:24 AM, Jonathan Dearborn wrote:

On Tue, Feb 4, 2014 at 10:20 AM, Gabriel Jacobo wrote:

So, ideas I’ve had on fixing it.

  1. have the haptic generic bits resize the array / update the #. ( BAD
    as it could cause threading issues)
  2. pre-allocate a number of free slots. ( would limit the # of
    hotpluggable devices… Mixed feelings on this.)
  3. convert it to a linked list (less threading issues and it’s what is
    done in Joystick and GameController subsystems)… This just requires

I think 3 is the way to go, which means it’s also time for yet another
linked list implementation…we really need to consolidate that stuff.

Are there other subsystems that have the same storage needs? What do
they do?

Jonny D

at least, Joystick and gamecontroller both use linked-list for this
storage.

udev, hints, asserts, logs, etc (if you grep for “->next” on SDL’s code
you’ll see an orgy of linked lists, each with its own implementation)

If this were C++ I’d be SO on writing a common generic template
implementation:)

Flamebait! :slight_smile:

I’ll work up a patch while I chase down game bugs :slight_smile:

Ryan suggested the Linux kernel’s implementation, which is of course GPL,
but might be a good inspiration source for a generalized solution. Other
than that, suggestions are most welcome!

Gabriel.

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

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

16

NIH?

Cheers,
DanielAm 04.02.2014 22:49, schrieb Ryan C. Gordon:

(perhaps for 2.0.3?). I’ll have some spare time in a week and a half,
so perhaps I can write a patch for one of these two options.

I don’t think we need a third-party library for linked lists.

–ryan.

17

2014-02-05 Daniel Gibson :> Am 04.02.2014 22:49, schrieb Ryan C. Gordon:

(perhaps for 2.0.3?). I’ll have some spare time in a week and a half,

so perhaps I can write a patch for one of these two options.

I don’t think we need a third-party library for linked lists.

–ryan.

NIH?

Cheers,
Daniel

Dependency hell, actually. One of the main under advertised features of SDL
is that “it just builds” :slight_smile:

–
Gabriel.

18

2014-02-05 Daniel Gibson <@Daniel_Gibson
mailto:Daniel_Gibson>:

        (perhaps for 2.0.3?).  I'll have some spare time in a week
        and a half,
        so perhaps I can write a patch for one of these two options.


    I don't think we need a third-party library for linked lists.

    --ryan.


NIH?

Cheers,
Daniel

Dependency hell, actually. One of the main under advertised features of
SDL is that “it just builds” :slight_smile:

–
Gabriel.

sglib is just one header.
It could just be added to the SDL source => no additional external
dependency.

Cheers,
DanielAm 05.02.2014 13:29, schrieb Gabriel Jacobo:

Am 04.02.2014 22:49, schrieb Ryan C. Gordon:
19

I don’t think it makes much sense to try and rationalise the inclusion
of a whole library for something as straightforward as linked lists.
A “just one more header” approach doesn’t sound too clever to me.–
Melker

On Wed, Feb 5, 2014 at 2:34 PM, Daniel Gibson wrote:

Am 05.02.2014 13:29, schrieb Gabriel Jacobo:

2014-02-05 Daniel Gibson <metalcaedes at gmail.com
<mailto:metalcaedes at gmail.com>>:

Am 04.02.2014 22:49, schrieb Ryan C. Gordon:


        (perhaps for 2.0.3?).  I'll have some spare time in a week
        and a half,
        so perhaps I can write a patch for one of these two options.


    I don't think we need a third-party library for linked lists.

    --ryan.


NIH?

Cheers,
Daniel

Dependency hell, actually. One of the main under advertised features of
SDL is that “it just builds” :slight_smile:

–
Gabriel.

sglib is just one header.
It could just be added to the SDL source => no additional external dependency.

Cheers,
Daniel

20

“That’s easy, let’s just roll our own implementation instead of using
something existing that’s known to work” is pretty much the definition
of NIH.

But I don’t really care in the end, it’s not my time that’s being wasted
by reinventing the wheel :slight_smile:

Cheers,
DanielAm 05.02.2014 17:17, schrieb Melker Narikka:

I don’t think it makes much sense to try and rationalise the inclusion
of a whole library for something as straightforward as linked lists.
A “just one more header” approach doesn’t sound too clever to me.

–
Melker

On Wed, Feb 5, 2014 at 2:34 PM, Daniel Gibson <@Daniel_Gibson> wrote:

Am 05.02.2014 13:29, schrieb Gabriel Jacobo:

2014-02-05 Daniel Gibson <@Daniel_Gibson
mailto:Daniel_Gibson>:

 Am 04.02.2014 22:49, schrieb Ryan C. Gordon:


         (perhaps for 2.0.3?).  I'll have some spare time in a week
         and a half,
         so perhaps I can write a patch for one of these two options.


     I don't think we need a third-party library for linked lists.

     --ryan.


 NIH?

 Cheers,
 Daniel

Dependency hell, actually. One of the main under advertised features of
SDL is that “it just builds” :slight_smile:

–
Gabriel.

sglib is just one header.
It could just be added to the SDL source => no additional external dependency.

Cheers,
Daniel

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