Fatal signal when initiaize with USB joystick on 2.6.2 kernel

Fred_Marmond · March 2, 2004, 5:03am

(Please reply in direct to @Fred_Marmond , as I’m NOT in the mailling
list.)

I’ve the following:
Fatal signal: Floating Point Exception (SDL Parachute Deployed)

when I initialize SDL with SDL_INIT_VIDEO | SDL_INIT_JOYSTICK, in the
SDL_Init() function.

If I unplug the joystick, it works just fine.
It worked fine in 2.4.22 kernel.
Tested with SDL-1.2.6 and the lastest SDL-1.2.7. On a Mandrake cooker (all
up-to-date).

Debugging it gives:
Program received signal SIGFPE, Arithmetic exception.
0x40086529 in SDL_SYS_JoystickName () from /usr/lib/libSDL-1.2.so.0
(gdb) info thread

2 Thread 1079095168 (LWP 18739) 0x40086529 in SDL_SYS_JoystickName ()
from /usr/lib/libSDL-1.2.so.0

My joystick is:
[fred at myHost]$ jstest /dev/js0
Joystick (Saitek Saitek X36) has 9 axes and 26 buttons. Driver version is
2.1.0.

It is really annoying!
If anybody has answers/work-around/bugfix, …
I’ll try to investigate this week-end, but if somebody else has already done
this…

thanks in advance!

Fred

PS: Please reply in direct to @Fred_Marmond, as I’m NOT in the mailling
list.

slouken · March 2, 2004, 10:46pm

I’ve the following:
Fatal signal: Floating Point Exception (SDL Parachute Deployed)

when I initialize SDL with SDL_INIT_VIDEO | SDL_INIT_JOYSTICK, in the
SDL_Init() function.

If I unplug the joystick, it works just fine.
It worked fine in 2.4.22 kernel.
Tested with SDL-1.2.6 and the lastest SDL-1.2.7. On a Mandrake cooker (all
up-to-date).

Debugging it gives:
Program received signal SIGFPE, Arithmetic exception.
0x40086529 in SDL_SYS_JoystickName () from /usr/lib/libSDL-1.2.so.0

That’s really wierd. The code for that function is:
const char *SDL_SYS_JoystickName(int index)
{
int fd;
static char namebuf[128];
char *name;

    name = NULL;
    fd = open(SDL_joylist[index], O_RDONLY, 0);
    if ( fd >= 0 ) {
            if (

#ifdef USE_INPUT_EVENTS
(ioctl(fd, EVIOCGNAME(sizeof(namebuf)), namebuf) <= 0) &&
#endif
(ioctl(fd, JSIOCGNAME(sizeof(namebuf)), namebuf) <= 0) ) {
name = SDL_joylist[index];
} else {
name = namebuf;
}
close(fd);
}
return name;
}

There’s not much that can trigger a floating point exception there.
Is it the ioctl itself that’s doing it inside the kernel?

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

Stephane_Marchesin · March 2, 2004, 11:55pm

There’s not much that can trigger a floating point exception there.

FPE can also be triggered by integer divisions, for example.
Fred, would you mind sending me your SDL12/src/joystick/linux/SDL_sysjoystick.lo file ?

Is it the ioctl itself that’s doing it inside the kernel?
Hmmm… maybe. Although there is no fp code in the kernel either, so we’re probably running after some div/idiv with invalid operands.

Stephane

Fred_Marmond · March 3, 2004, 12:25am

Le mercredi 3 Mars 2004 08:53, Stephane Marchesin a ?crit?:

There’s not much that can trigger a floating point exception there.

FPE can also be triggered by integer divisions, for example.
Fred, would you mind sending me your
SDL12/src/joystick/linux/SDL_sysjoystick.lo file ?

I use a binary rpm file, libSDL1.2-1.2.7-1mdk
I had the same problem with 1.2.6

Is it the ioctl itself that’s doing it inside the kernel?

Hmmm… maybe. Although there is no fp code in the kernel either, so we’re
probably running after some div/idiv with invalid operands.
Right for the div (see my last mail: 0x40086529 <SDL_SYS_JoystickName+1929>:
idiv %ecx )

I can’t compile source SDL without breaking my development configuration (need
other version of automake, autoheader, …) so I can’t debug it.
But you can debug it with the prog I sent few minutes ago.

It may be Mandrake related as the bin rpm came from them.
I posted a bug in the mandrake too…

Fred>

Stephane

Fred_Marmond · March 4, 2004, 12:08pm

I’ve sent a little code that shows the problem.
Can anybody test it with a libSDL compiled as DEBUG ?

I would really appreciate any validation of this behaviour.

Fred

Reminder: the code I sent:

In fact, I don’t think it i really in the SDL_SYS_JoystickName () function,
as dissassemble it (again with gdb) gives SDL_SYS_JoystickName () +a big
offset.
But when I disassemble it, it gives (at expetion offset):
0x40086529 <SDL_SYS_JoystickName+1929>: idiv %ecx
That’s to say that the problem may be outside the SDL_SYS_JoystickName
function.

I made a little prog to reproduce the problem:
#include <SDL/SDL.h>
int main(int argc,char** argv)
{
int i;
printf(“Debug1\n”);fflush(stdout);
int rc=SDL_Init(SDL_INIT_VIDEO | SDL_INIT_JOYSTICK);
printf(“Debug2\n”);fflush(stdout);
printf(“Nb Joystick:%i\n”,SDL_NumJoysticks());
printf(“Debug3\n”);fflush(stdout);
SDL_Joystick *joystick;
for(i=0; i < SDL_NumJoysticks(); i++ )
{
joystick = SDL_JoystickOpen(i);
}

    SDL_Quit(); 
    return 0;

}

the compil/exec line:
gcc testjoy.c -lSDL && ./a.out

result:
[fred at host shm]$ gcc testjoy.c -lSDL && ./a.out
Debug1
Debug2
Nb Joystick:1
Debug3
Fatal signal: Floating Point Exception (SDL Parachute Deployed)
[fred at host shm]$

My joystick is:
[fred at myHost]$ jstest /dev/js0
Joystick (Saitek Saitek X36) has 9 axes and 26 buttons. Driver version is
2.1.0.

Do you reproduce it?

Le mercredi 3 Mars 2004 08:53, Stephane Marchesin a ?crit?:> > There’s not much that can trigger a floating point exception there.

FPE can also be triggered by integer divisions, for example.
Fred, would you mind sending me your
SDL12/src/joystick/linux/SDL_sysjoystick.lo file ?

Is it the ioctl itself that’s doing it inside the kernel?

Hmmm… maybe. Although there is no fp code in the kernel either, so we’re
probably running after some div/idiv with invalid operands.

Stephane

Stephane_Marchesin · March 4, 2004, 12:33pm

Fred Marmond wrote:
[…]

My joystick is:
[fred at myHost]$ jstest /dev/js0
Joystick (Saitek Saitek X36) has 9 axes and 26 buttons. Driver version is
2.1.0.

Do you reproduce it?

Ahem… well, I have no joystick
But could you please again run it under gdb, and send us a disassembly
of the area around the place it crashes (say 20 lines before and 20
after), and send the ouput so that I can locate which idiv %ecx is
causing the crash inside the SDL binary ?

I’ll look at it when I have some time, probably this WE.

Stephane

Fred_Marmond · March 4, 2004, 1:34pm

I love assembly…

I think I’ve found the related code:
(decompiling the gdb given JoystickOpen give a call just before the error:
0x40086611 <SDL_SYS_JoystickOpen+161>: call 0x400862a0
<SDL_SYS_JoystickName+1280>
that, in the C code, refers to
if ( ! EV_ConfigJoystick(joystick, fd) )
So, I try to make the assembly match to the EV_Config C dode.
Then, I found this part:

0x400864a1 <SDL_SYS_JoystickName+1793>: cmp %eax,0x34(%esp,1)
0x400864a5 <SDL_SYS_JoystickName+1797>: je 0x40086541
<SDL_SYS_JoystickName+1953>
0x400864ab <SDL_SYS_JoystickName+1803>: mov 0x28(%edi),%edx
0x400864ae <SDL_SYS_JoystickName+1806>: mov %esi,%eax
0x400864b0 <SDL_SYS_JoystickName+1808>: mov $0x1,%ecx
0x400864b5 <SDL_SYS_JoystickName+1813>: shl $0x4,%eax
0x400864b8 <SDL_SYS_JoystickName+1816>: add %edx,%eax
0x400864ba <SDL_SYS_JoystickName+1818>: mov %ecx,0x150(%eax)
0x400864c0 <SDL_SYS_JoystickName+1824>: mov 0x38(%esp,1),%edx
0x400864c4 <SDL_SYS_JoystickName+1828>: mov %eax,0x2c(%esp,1)
0x400864c8 <SDL_SYS_JoystickName+1832>: mov 0x34(%esp,1),%eax
0x400864cc <SDL_SYS_JoystickName+1836>: mov 0x40(%esp,1),%ecx
0x400864d0 <SDL_SYS_JoystickName+1840>: add %edx,%eax
0x400864d2 <SDL_SYS_JoystickName+1842>: mov %eax,%edx
0x400864d4 <SDL_SYS_JoystickName+1844>: shr $0x1f,%edx
0x400864d7 <SDL_SYS_JoystickName+1847>: add %edx,%eax
0x400864d9 <SDL_SYS_JoystickName+1849>: sar %eax
0x400864db <SDL_SYS_JoystickName+1851>: sub %ecx,%eax
—Type to continue, or q to quit—
0x400864dd <SDL_SYS_JoystickName+1853>: mov 0x2c(%esp,1),%ecx
0x400864e1 <SDL_SYS_JoystickName+1857>: mov %eax,0x154(%ecx)
0x400864e7 <SDL_SYS_JoystickName+1863>: mov 0x38(%esp,1),%edx
0x400864eb <SDL_SYS_JoystickName+1867>: mov 0x34(%esp,1),%eax
0x400864ef <SDL_SYS_JoystickName+1871>: add %edx,%eax
0x400864f1 <SDL_SYS_JoystickName+1873>: mov %eax,%edx
0x400864f3 <SDL_SYS_JoystickName+1875>: shr $0x1f,%edx
0x400864f6 <SDL_SYS_JoystickName+1878>: add %edx,%eax
0x400864f8 <SDL_SYS_JoystickName+1880>: mov 0x40(%esp,1),%edx
0x400864fc <SDL_SYS_JoystickName+1884>: sar %eax
0x400864fe <SDL_SYS_JoystickName+1886>: add %edx,%eax
0x40086500 <SDL_SYS_JoystickName+1888>: mov %eax,0x158(%ecx)
0x40086506 <SDL_SYS_JoystickName+1894>: mov 0x34(%esp,1),%eax
0x4008650a <SDL_SYS_JoystickName+1898>: mov 0x38(%esp,1),%edx
0x4008650e <SDL_SYS_JoystickName+1902>: sub %eax,%edx
0x40086510 <SDL_SYS_JoystickName+1904>: mov %edx,%eax
0x40086512 <SDL_SYS_JoystickName+1906>: shr $0x1f,%eax
0x40086515 <SDL_SYS_JoystickName+1909>: add %eax,%edx
0x40086517 <SDL_SYS_JoystickName+1911>: mov 0x40(%esp,1),%eax
0x4008651b <SDL_SYS_JoystickName+1915>: sar %edx
0x4008651d <SDL_SYS_JoystickName+1917>: add %eax,%eax
0x4008651f <SDL_SYS_JoystickName+1919>: sub %eax,%edx
0x40086521 <SDL_SYS_JoystickName+1921>: mov $0x20000000,%eax
0x40086526 <SDL_SYS_JoystickName+1926>: mov %edx,%ecxam Lantinga
0x40086528 <SDL_SYS_JoystickName+1928>: cltd
0x40086529 <SDL_SYS_JoystickName+1929>: idiv %ecx
0x4008652b <SDL_SYS_JoystickName+1931>: mov 0x2c(%esp,1),%edx
0x4008652f <SDL_SYS_JoystickName+1935>: mov %eax,0x1c(%esp,1)
0x40086533 <SDL_SYS_JoystickName+1939>: mov %eax,0x15c(%edx)
0x40086539 <SDL_SYS_JoystickName+1945>: incl 0x8(%edi)
0x4008653c <SDL_SYS_JoystickName+1948>: jmp 0x400863d0
<SDL_SYS_JoystickName+1584>

to me, it refers to:
joystick->hwdata->abs_map[i] = joystick->naxes;
if ( values[1] == values[2] ) {
joystick->hwdata->abs_correct[i].used = 0;
} else {
joystick->hwdata->abs_correct[i].used = 1;
joystick->hwdata->abs_correct[i].coef[0] =
(values[2] + values[1]) / 2 - values[4];
joystick->hwdata->abs_correct[i].coef[1] =
(values[2] + values[1]) / 2 + values[4];
joystick->hwdata->abs_correct[i].coef[2] =
(1 << 29) / ((values[2] - values[1]) / 2 - 2 * values[4]);
}
++joystick->naxes;
in function
static SDL_bool EV_ConfigJoystick(SDL_Joystick *joystick, int fd)
of file
SDL-1.2.7/src/joystick/linux/SDL_sysjoystick.c

The idiv may refer to the main divizion in:
(1 << 29) / ((values[2] - values[1]) / 2 - 2 * values[4]);
so, the problem may come from… a lot of things.
As it is well documented, we understand at first eye look what it is supposed
to do, and where the data are coming from…

Now that I have pointed it out, may the writter of this code (Sam) help me?
Any suggestion?

Fred

Le jeudi 4 Mars 2004 21:44, Stephane Marchesin a ?crit?:> Fred Marmond wrote:

[…]

My joystick is:
[fred at myHost]$ jstest /dev/js0
Joystick (Saitek Saitek X36) has 9 axes and 26 buttons. Driver version is
2.1.0.

Do you reproduce it?

Ahem… well, I have no joystick
But could you please again run it under gdb, and send us a disassembly
of the area around the place it crashes (say 20 lines before and 20
after), and send the ouput so that I can locate which idiv %ecx is
causing the crash inside the SDL binary ?

I’ll look at it when I have some time, probably this WE.

Stephane

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

Fred_Marmond · March 4, 2004, 1:55pm

[…]
Ok, I found a way to cancel the problem…
Or more exactly, Alan found it for me!
Thanks to Alan!

The evdev module must set values used by the division to 0 (see my last mail
on the subject), which causes the division to generate the floating point
exception.

So, I have no problem since I unload the evdev…
But I think we can check data before dividing by it, in the previous mentioned
function…

Anyway, it works for me and I am happy.

Thanks for support and tips!

Fred

Stephane_Marchesin · March 4, 2004, 3:12pm

Fred Marmond wrote:

to me, it refers to:
joystick->hwdata->abs_map[i] = joystick->naxes;
if ( values[1] == values[2] ) {
joystick->hwdata->abs_correct[i].used = 0;
} else {
joystick->hwdata->abs_correct[i].used = 1;
joystick->hwdata->abs_correct[i].coef[0] =
(values[2] + values[1]) / 2 - values[4];
joystick->hwdata->abs_correct[i].coef[1] =
(values[2] + values[1]) / 2 + values[4];
joystick->hwdata->abs_correct[i].coef[2] =
(1 << 29) / ((values[2] - values[1]) / 2 - 2 * values[4]);
}
++joystick->naxes;
in function
static SDL_bool EV_ConfigJoystick(SDL_Joystick *joystick, int fd)
of file
SDL-1.2.7/src/joystick/linux/SDL_sysjoystick.c

The idiv may refer to the main divizion in:
(1 << 29) / ((values[2] - values[1]) / 2 - 2 * values[4]);

Yup, that’s the one I suspected too.

so, the problem may come from… a lot of things.
As it is well documented, we understand at first eye look what it is supposed
to do, and where the data are coming from…

Now that I have pointed it out, may the writter of this code (Sam) help me?
Any suggestion?

I think that values[*]==0, because it causes an FPE, which in our case
is probably a division by zero.
Some lines above your code snippet you’ll find this code in charge of
filling “values” :

ioctl(fd, EVIOCGABS(i), values);

The return value for that ioctl isn’t tested, maybe it would be a good
idea to check for an error.

Stephane

Alan_Swanson · March 5, 2004, 4:05am

Fred, how does the attached patch work for you? Do all your axes work?

I’ve made it to match the actual joydev kernel code which tests for
zero value (otherwise set coef[2] to 0, which joydev does by an earlier
memset).On Thu, 2004-03-04 at 23:27, Stephane Marchesin wrote:

Fred Marmond wrote:

Now that I have pointed it out, may the writter of this code (Sam) help me?
Any suggestion?

I think that values[*]==0, because it causes an FPE, which in our case
is probably a division by zero.
Some lines above your code snippet you’ll find this code in charge of
filling “values” :

ioctl(fd, EVIOCGABS(i), values);

The return value for that ioctl isn’t tested, maybe it would be a good
idea to check for an error.

–
Alan.

“One must never be purposelessnessnesslessness.”
-------------- next part --------------
A non-text attachment was scrubbed…
Name: SDL-joy-event-fpe.diff
Type: text/x-patch
Size: 907 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20040305/64db2b78/attachment.bin
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20040305/64db2b78/attachment.pgp

slouken · March 5, 2004, 7:12am

Fred, how does the attached patch work for you? Do all your axes work?

I think you meant the two lines to be reversed.
I checked a more robust version of this into CVS. Fred, can you see if it works?

Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment

Alan_Swanson · March 5, 2004, 8:09am

You’ve misread the code. :-/

For coef[0] and coef[1], it is (values[2]+values[1]) / 2 and then add
or subtract values[4] to the answer.

The checks are not required and anyone using an evdev joysick will now
get interesting results…On Fri, 2004-03-05 at 15:09, Sam Lantinga wrote:

Fred, how does the attached patch work for you? Do all your axes work?

I think you meant the two lines to be reversed.
I checked a more robust version of this into CVS. Fred, can you see if
it works?

–
Alan.

“One must never be purposelessnessnesslessness.”
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20040305/28e2d169/attachment.pgp

Alan_Swanson · March 5, 2004, 11:58am

Attached is a patch to correct your changes to CVS.

Also, as the coef values are not initialised, coef[2] needs to be set
to 0 when t=0 so I’ve added back the else statement. (Unless you would
prefer to memset abs_correct zero earlier on?)On Fri, 2004-03-05 at 15:09, Sam Lantinga wrote:

Fred, how does the attached patch work for you? Do all your axes work?

I think you meant the two lines to be reversed.
I checked a more robust version of this into CVS. Fred, can you see if
it works?

–
Alan.

“One must never be purposelessnessnesslessness.”
-------------- next part --------------
A non-text attachment was scrubbed…
Name: SDL-joy-event-fpe-2.diff
Type: text/x-patch
Size: 1093 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20040305/0fa2ec17/attachment.bin
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20040305/0fa2ec17/attachment.pgp

Fred_Marmond · March 5, 2004, 12:10pm

Well, Stephane proposed to send me the compiled lib (as I can’t do it here for
many reasons) to test…
I’ll test it as soon as i’ll recieve it!

But i think i’ll go to bed soon… (hard past week).

Fred

Le vendredi 5 Mars 2004 20:51, Alan Swanson a ?crit?:> On Fri, 2004-03-05 at 15:09, Sam Lantinga wrote:

Fred, how does the attached patch work for you? Do all your axes work?

I think you meant the two lines to be reversed.
I checked a more robust version of this into CVS. Fred, can you see if
it works?

Attached is a patch to correct your changes to CVS.

Also, as the coef values are not initialised, coef[2] needs to be set
to 0 when t=0 so I’ve added back the else statement. (Unless you would
prefer to memset abs_correct zero earlier on?)

Fred_Marmond · March 5, 2004, 12:41pm

Ok, it I haven’t the divide error anymore with the lib compiled by Stephane
(thanks) (evdev module loaded or not).
Tested on a 2.6.3 mandrake cooker kernel.

But when evdev is loaded, axis values are weird:
My (expensive) joystick has 9 axis and 26 buttons.
When evdev is loaded, a lot of SDL events are generated, with axis4 =32768
whatever I do on joystick.

Removing evdev module solve this: SDL event is genereted only when needed, and
all axis/buttons have right values.

I can continue testing what you want…
I’m sorry, but I work with kdevelop-3, and it requiers old
automake/autoconf/… that don’t work with SDL sources… And I don’t have
energy to play with managing versions of those tools…

Fred

Le vendredi 5 Mars 2004 20:51, Alan Swanson a ?crit?:> On Fri, 2004-03-05 at 15:09, Sam Lantinga wrote:

Fred, how does the attached patch work for you? Do all your axes work?

I think you meant the two lines to be reversed.
I checked a more robust version of this into CVS. Fred, can you see if
it works?

Attached is a patch to correct your changes to CVS.

Also, as the coef values are not initialised, coef[2] needs to be set
to 0 when t=0 so I’ve added back the else statement. (Unless you would
prefer to memset abs_correct zero earlier on?)

Alan_Swanson · March 5, 2004, 2:23pm

Le vendredi 5 Mars 2004 20:51, Alan Swanson a ?crit :

Attached is a patch to correct your changes to CVS.

Also, as the coef values are not initialised, coef[2] needs to be set
to 0 when t=0 so I’ve added back the else statement. (Unless you would
prefer to memset abs_correct zero earlier on?)

Ok, it I haven’t the divide error anymore with the lib compiled by
Stephane (thanks) (evdev module loaded or not).
Tested on a 2.6.3 mandrake cooker kernel.

Better.

But when evdev is loaded, axis values are weird:
My (expensive) joystick has 9 axis and 26 buttons.
When evdev is loaded, a lot of SDL events are generated, with axis4 =32768
whatever I do on joystick.

Worse. If this was the axis that was causing the divide by zero then
it should now be returning zero.

Just to confirm, was this using the CVS version after Sam’s commit only,
or with my (last) patch applied the CVS version?

Also, what is axis 4? A rudder or throttle? Is it possible to see if any
other axis values are affected?

Removing evdev module solve this: SDL event is genereted only when needed,
and all axis/buttons have right values.

Do you calibrate the joystick using jscal?On Fri, 2004-03-05 at 20:46, Fred Marmond wrote:

–
Alan.

“One must never be purposelessnessnesslessness.”
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20040305/8d57fa6a/attachment.pgp

Stephane_Marchesin · March 5, 2004, 4:26pm

Alan Swanson wrote:>On Fri, 2004-03-05 at 20:46, Fred Marmond wrote:

But when evdev is loaded, axis values are weird:
My (expensive) joystick has 9 axis and 26 buttons.
When evdev is loaded, a lot of SDL events are generated, with axis4 =32768
whatever I do on joystick.

Worse. If this was the axis that was causing the divide by zero then
it should now be returning zero.

Just to confirm, was this using the CVS version after Sam’s commit only,
or with my (last) patch applied the CVS version?

Yup, it’s the CVS version. I compiled it before recieving your patch.
Well, anyway don’t those patches just hide the problem ? That doesn’t
explain why the min/max values are zero in the first place (unless it’s
a calibration problem, or the init failed somehow).

I’ve taken a look at the kernel code and that ioctl shouldn’t fail in
"normal" conditions so there’s nothing to do there.

Stephane

slouken · March 5, 2004, 6:59pm

You’ve misread the code. :-/

For coef[0] and coef[1], it is (values[2]+values[1]) / 2 and then add
or subtract values[4] to the answer.

Whoops, thanks for the patch. I’ve applied it to CVS.

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

Fred_Marmond · March 6, 2004, 1:25am

In fact, not only the axis[4], but all axis.
Values vary from 27000 (instead of -32767) to 32768.
It seems something like: read=min(27000,real+32768) to be more precise.
real is the 'value it is supposed to read.

jscal doesn’t solve anything for me, as:

without any calibration, and without evdev SDL works fine
with/without calibration, and with evdev SDL gives bad values (those I
defined in the mail head)
without calibration, with/without evdev jstest works fine
-with calibration, with/without evdev, jstest has small ranged values (85-210)

by jscal, I mean “jscal -c /dev/js0”

I’m not aware in configuring joystick, maybe you want other operations…

Fred

Le samedi 6 Mars 2004 01:41, Stephane Marchesin a ?crit?:> Alan Swanson wrote:

On Fri, 2004-03-05 at 20:46, Fred Marmond wrote:

But when evdev is loaded, axis values are weird:
My (expensive) joystick has 9 axis and 26 buttons.
When evdev is loaded, a lot of SDL events are generated, with axis4
=32768 whatever I do on joystick.

Worse. If this was the axis that was causing the divide by zero then
it should now be returning zero.

Just to confirm, was this using the CVS version after Sam’s commit only,
or with my (last) patch applied the CVS version?

Yup, it’s the CVS version. I compiled it before recieving your patch.
Well, anyway don’t those patches just hide the problem ? That doesn’t
explain why the min/max values are zero in the first place (unless it’s
a calibration problem, or the init failed somehow).

I’ve taken a look at the kernel code and that ioctl shouldn’t fail in
"normal" conditions so there’s nothing to do there.

Stephane

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

Stephane_Marchesin · March 6, 2004, 7:44am

Sam Lantinga wrote:

You’ve misread the code. :-/

For coef[0] and coef[1], it is (values[2]+values[1]) / 2 and then add
or subtract values[4] to the answer.

Whoops, thanks for the patch. I’ve applied it to CVS.

Ok, I sent Fred the “latest-latest” CVS .so and here are the results :

As before, everything works fine without evdev
With evdev, the axis values are garbled (but there is no crash), while
the “jstest” program gives good axis values

Maybe we should look at the jstest source code to see where it differs
from SDL joystick code ?

Stephane