Bug 852385 - Cannot attach serial Spaceball 4000flx
Cannot attach serial Spaceball 4000flx
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: linuxconsoletools (Show other bugs)
19
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Jaromír Cápík
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-28 06:49 EDT by Alex Smirnoff
Modified: 2016-01-31 20:57 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-18 08:45:44 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
inputattach core dump (752.00 KB, application/octet-stream)
2013-03-11 09:56 EDT, Alex Smirnoff
no flags Details
inputattach.tar.gz (17.10 KB, application/x-gzip)
2013-03-11 12:31 EDT, Jaromír Cápík
no flags Details
Output of the inputattach diagnostic version (373 bytes, text/plain)
2013-03-11 12:33 EDT, Alex Smirnoff
no flags Details
3dxsrv proprietary driver straced (616.05 KB, text/plain)
2013-03-11 13:14 EDT, Alex Smirnoff
no flags Details
inputattach2.tar.gz (17.27 KB, application/x-gzip)
2013-03-11 13:49 EDT, Jaromír Cápík
no flags Details
new diagnostic output (853 bytes, text/plain)
2013-03-12 04:14 EDT, Alex Smirnoff
no flags Details
inputattach3.tar.gz (17.18 KB, application/x-gzip)
2013-03-12 08:09 EDT, Jaromír Cápík
no flags Details
new diagnostic output (714 bytes, text/plain)
2013-03-12 08:20 EDT, Alex Smirnoff
no flags Details
inputattach4.tar.gz (17.21 KB, application/x-gzip)
2013-03-12 12:38 EDT, Jaromír Cápík
no flags Details
inputattach5.tar.gz (17.19 KB, application/x-gzip)
2013-03-13 09:03 EDT, Jaromír Cápík
no flags Details
inputattach6.tar.gz (17.16 KB, application/x-gzip)
2013-03-13 09:32 EDT, Jaromír Cápík
no flags Details

  None (edit)
Description Alex Smirnoff 2012-08-28 06:49:18 EDT
Description of problem: neither jsattach nor inputattach work with Spaceball 4000flx


Version-Release number of selected component (if applicable):
joystick-1.2.15-27.fc17.x86_64


How reproducible:
Always


Steps to Reproduce:
1. Plugin Spaceball in
2. sudo jsattach --sball4 /dev/ttyUSB0
3. sudo inputattach --spaceball /dev/ttyUSB0

  
Actual results:
sudo jsattach --sball4 /dev/ttyS0
(spaceball beeps)
This doesn't look like a Spaceball 4000 FLX.
jsattach: device initialization failed

sudo inputattach --spaceball /dev/ttyUSB0
*** stack smashing detected ***: inputattach terminated
======= Backtrace: =========
/lib64/libc.so.6(__fortify_fail+0x37)[0x3ba39097c7]
/lib64/libc.so.6(__fortify_fail+0x0)[0x3ba3909790]
inputattach[0x4018c0]
inputattach[0x400bde]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x3ba3821735]
inputattach[0x400ead]
======= Memory map: ========
00400000-00403000 r-xp 00000000 fd:01 1051670                            /usr/sbin/inputattach
00602000-00604000 rw-p 00002000 fd:01 1051670                            /usr/sbin/inputattach
0081f000-00840000 rw-p 00000000 00:00 0                                  [heap]
3ba3400000-3ba3420000 r-xp 00000000 fd:01 1053535                        /usr/lib64/ld-2.15.so
3ba361f000-3ba3620000 r--p 0001f000 fd:01 1053535                        /usr/lib64/ld-2.15.so
3ba3620000-3ba3621000 rw-p 00020000 fd:01 1053535                        /usr/lib64/ld-2.15.so
3ba3621000-3ba3622000 rw-p 00000000 00:00 0 
3ba3800000-3ba39ac000 r-xp 00000000 fd:01 1055316                        /usr/lib64/libc-2.15.so
3ba39ac000-3ba3bac000 ---p 001ac000 fd:01 1055316                        /usr/lib64/libc-2.15.so
3ba3bac000-3ba3bb0000 r--p 001ac000 fd:01 1055316                        /usr/lib64/libc-2.15.so
3ba3bb0000-3ba3bb2000 rw-p 001b0000 fd:01 1055316                        /usr/lib64/libc-2.15.so
3ba3bb2000-3ba3bb7000 rw-p 00000000 00:00 0 
3ba5800000-3ba5815000 r-xp 00000000 fd:01 1055886                        /usr/lib64/libgcc_s-4.7.0-20120507.so.1
3ba5815000-3ba5a14000 ---p 00015000 fd:01 1055886                        /usr/lib64/libgcc_s-4.7.0-20120507.so.1
3ba5a14000-3ba5a15000 rw-p 00014000 fd:01 1055886                        /usr/lib64/libgcc_s-4.7.0-20120507.so.1
7fd8c12ba000-7fd8c12bd000 rw-p 00000000 00:00 0 
7fd8c12de000-7fd8c12e0000 rw-p 00000000 00:00 0 
7ffff2890000-7ffff28b1000 rw-p 00000000 00:00 0                          [stack]
7ffff29ff000-7ffff2a00000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

Expected results:
/dev/input/js0 device is created and accessible

Additional info:
I use Moschip 7840/7820 USB Serial Driver converter. It seems to work properly; at least proprietary Spaceball driver from 3Dconnexion site successfully attaches and controls are working.
Comment 1 Alex Smirnoff 2012-08-28 06:50:43 EDT
(ttyS0 on my system is a symbolic link to ttyUSB0 created to help proprietary driver to work out of the box, does not make any difference)
Comment 2 Alex Smirnoff 2013-03-11 05:37:20 EDT
any news on that? bug persists in fc18. also jsattach is deprecated now, so inputattach is the only option left.
Comment 3 Jaromír Cápík 2013-03-11 09:32:23 EDT
Hello Alex.

It's pity you don't have a useful backtrace. Did inputattach produce any core dump file? Please, let me know.

Regards,
Jaromir.
Comment 4 Alex Smirnoff 2013-03-11 09:56:02 EDT
Created attachment 708388 [details]
inputattach core dump

Coredump attached.
Comment 5 Alex Smirnoff 2013-03-11 09:58:39 EDT
What makes me suspicious is that it behaves similar way regardless if spaceball.ko is present in the system or not and if it was loaded or not. Same bug exists for CentOS/RHEL 6.3 current kernel.
Comment 6 Jaromír Cápík 2013-03-11 10:08:58 EDT
Hi Alex.

Is that the L version (left-hand) ?

Thx, J.
Comment 7 Alex Smirnoff 2013-03-11 10:18:44 EDT
I don't think so (it is IBM branded, which makes identification more difficult).
In its normal position buttons 1-9 are on the left side and A-C on the right side.
Text on the bottom says Spaceball 4000FLX manufactured for IBM, model 5000FLX-A.

this is what native driver says:
/etc/3DxWare/daemon/3dxsrv -d /dev/ttyUSB0 
3DxWareUNIX = V1.4.3
Device      = Spaceball 4000
Firmware    = V2.45
Comment 8 Jaromír Cápík 2013-03-11 10:30:07 EDT
Was the core file created by one of the official fedora releases of linuxconsoletools? Which version exactly?
Comment 9 Alex Smirnoff 2013-03-11 10:33:22 EDT
linuxconsoletools-1.4.4-7.fc18.x86_64
Comment 10 Jaromír Cápík 2013-03-11 11:05:02 EDT
It's crashing when leaving the spaceball_init function ... I'll try to dig in the code and search for the stack smashing issue ... will let you know.

J.
Comment 11 Jaromír Cápík 2013-03-11 11:07:47 EDT
The read buffer is defined as 64 bytes long and there's no check for overflow .... we could try to increase it and add some check there ... please, stay tuned.
Comment 12 Alex Smirnoff 2013-03-11 11:43:55 EDT
Thanks Jaromir!
Comment 13 Jaromír Cápík 2013-03-11 11:59:50 EDT
I'm going to send you a diagnostic binary. It seems your model returns unknown data (=is unsupported yet) and we need to find out if it is easily possible to make it working. I'll share the binary in a couple of minutes.
Comment 14 Jaromír Cápík 2013-03-11 12:29:56 EDT
Please, download the attached tarball ... it contains the mentioned diagnostic binary ...

test that again .... the binary should provide you with some debug info ...
Comment 15 Jaromír Cápík 2013-03-11 12:31:00 EDT
Created attachment 708491 [details]
inputattach.tar.gz
Comment 16 Jaromír Cápík 2013-03-11 12:32:55 EDT
Please collect the info and attach the result debug.txt here:

./inputattach --spaceball /dev/ttyUSB0 &> debug.txt
Comment 17 Alex Smirnoff 2013-03-11 12:33:47 EDT
Created attachment 708494 [details]
Output of the inputattach diagnostic version
Comment 18 Jaromír Cápík 2013-03-11 12:45:46 EDT
That doesn't look good. All the values returned are either 0x00 or 0x80. That looks more like a problem of the serial communication. As it affects only the highest bit, it looks like your model communicates on a higher bitrate. Let me modify the binary once again.
Comment 19 Alex Smirnoff 2013-03-11 12:56:21 EDT
I may try to strace 3dxware server if that helps..
Comment 20 Jaromír Cápík 2013-03-11 12:58:02 EDT
That would be great help!
Comment 21 Alex Smirnoff 2013-03-11 13:14:42 EDT
Created attachment 708520 [details]
3dxsrv proprietary driver straced
Comment 22 Jaromír Cápík 2013-03-11 13:19:19 EDT
Even more strange ... the strace says the baudrate is 9600 ... that's the correct one ... gonna dig deeper.
Comment 23 Jaromír Cápík 2013-03-11 13:31:11 EDT
This piece seems to require some init data ... we could try to do the same ...
Comment 24 Jaromír Cápík 2013-03-11 13:49:56 EDT
Created attachment 708555 [details]
inputattach2.tar.gz

A bit modified diagnostic binary ... please, repeat the test and provide me with the output ...
Comment 25 Alex Smirnoff 2013-03-12 04:14:26 EDT
Created attachment 708802 [details]
new diagnostic output
Comment 26 Jaromír Cápík 2013-03-12 05:59:39 EDT
This one looks much better.
Comment 27 Jaromír Cápík 2013-03-12 06:18:30 EDT
Here's what the device returned in ASCII after giving it the init sequence ...

-----
-�#76V&��Cdō"2 B:13 L PnP:1 Az:1 Sns:S 2710 14�#2c"�CR7&VFVB���?b#="4 Copyright(C) 2003 Spacetec IMC Corporation
-----

Let me analyze the result better and create a new diag binary.
Comment 28 Jaromír Cápík 2013-03-12 06:25:59 EDT
The HEX converter was missing leading zeros ... here's a better output:

-----------------
"1 Spaceball 4000 FLX
"2 B:13 L PnP:1 Az:1 Sns:S 2710 14
"3 V2.45 created on May 06 2003
"4 Copyright(C) 2003 Spacetec IMC Corporation
-----------------

I think it's perfectly readable now!

Anyway ... this output is unsupported by the current code and we'll have to exchange few more diag binaries in order to make this work.
Comment 29 Jaromír Cápík 2013-03-12 08:09:34 EDT
Created attachment 708926 [details]
inputattach3.tar.gz

Please .... repeat the test with this one ...
Comment 30 Alex Smirnoff 2013-03-12 08:20:20 EDT
Created attachment 708930 [details]
new diagnostic output
Comment 31 Jaromír Cápík 2013-03-12 12:38:55 EDT
Created attachment 709073 [details]
inputattach4.tar.gz

This diag binary could start working as you need ... your spaceball returns L, that means it's 4000FLX L (left-handed version).
Comment 32 Alex Smirnoff 2013-03-13 06:10:15 EDT
Thanks, it seems to work to certain extent, but axis values appear to be a bit weird (except zero is recognized properly while device is at rest).  Can you recommend a good diagnostic/calibration tool? Do you still need diagnostic values?
Comment 33 Jaromír Cápík 2013-03-13 07:34:02 EDT
Hi Alex. 

Could you please write more details? How do you mean weird?

According to some threads, there was a bug in the spaceball.c module, that affected the L version only and configuring it as right-handed helped. But unfortunately there are no more details written and I don't know if the information is still valid (it's 6 years old).

http://www.3dconnexion.com/forum/viewtopic.php?t=485

Have you tried jscal and jstest tools? They should be a part of the linuxconsoletools package.

Of course, we could try to collect some output data and fix that too, but first of all, try to do some calibration/testing and let me know about your findings.

Regards,
Jaromir.
Comment 34 Alex Smirnoff 2013-03-13 07:53:40 EDT
I mean if I move one of the axis, I see all values are changed and I do not see any logical axis to be corresponding to given physical one. That's what I found with jstest. Please tell me how to diagnose further.
Comment 35 Jaromír Cápík 2013-03-13 08:45:41 EDT
Oh I see ... in that case there are 2 possibilities ...

1.) The init sequence still needs to be finetuned

-OR-

2.) The device returns data unsupported by the kernel driver 


I'll try to create one more diag binary with improved init sequence ... if that doesn't help, then we need to dig in the kernel driver ...
Comment 36 Jaromír Cápík 2013-03-13 09:03:43 EDT
Created attachment 709562 [details]
inputattach5.tar.gz

Please, test ...
Comment 37 Alex Smirnoff 2013-03-13 09:17:42 EDT
This one does not initialize (inputattach: device initialization failed)
Comment 38 Jaromír Cápík 2013-03-13 09:32:36 EDT
Created attachment 709576 [details]
inputattach6.tar.gz

The previous one probably didn't get any answer to the "AD" command and failed ... Try this one ...
Comment 39 Alex Smirnoff 2013-03-13 09:42:18 EDT
This one works, but is no better :-)
Comment 40 Jaromír Cápík 2013-03-13 10:09:46 EDT
Ok .... so the axis are still mixed together, right?

In that case the problem lies in the spaceball module. 

Could you please document how the values exactly change? Are the values totally random or not?
Comment 41 Alex Smirnoff 2013-03-13 10:19:20 EDT
Ball to the left:

Axes:  0: -7117  1: -1134  2: -5586  3:  4013  4:     0  5: -5131 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off 11:off 12:off 

Ball to the right:

Axes:  0:  6321  1:   115  2: -6405  3:     0  4:     0  5:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off 11:off 12:off

Ball to the top:

Axes:  0:     0  1:  1034  2:  -894  3: -4779  4: -5048  5:  2565 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off 11:off 12:off

Ball to the bottom:

Axes:  0:  3144  1: -6124  2: -9206  3:  4778  4: -5131  5:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off 11:off 12:off

Ball clockwise:
Axes:  0:     0  1:     0  2:     0  3:     0  4: -4427  5: -8255 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off 11:off 12:off

Ball counterclockwise:

Axes:  0:     0  1:     0  2:  -733  3:  -187  4:     0  5:  8150 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off 11:off 12:off

Ball pushed in:

Axes:  0:     0  1:  -617  2: -6190  3:  1985  4:     0  5:  8150 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off 11:off 12:off

Ball pulled out:

Axes:  0:  -762  1:   889  2:  2325  3: -5131  4:     0  5:  5068 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off 11:off 12:off
Comment 42 Alex Smirnoff 2013-03-13 10:24:05 EDT
Ball moved left:

Axes:  0: -4998  1:  -315  2: -1142  3: -1821  4:     0  5:  5088 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off 11:off 12:off

Ball moved right:

Axes:  0:  4203  1:  -385  2: -1771  3:  4820  4: -4758  5:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off 11:off 12:off

Ball moved up:

Axes:  0:  -762  1:  2345  2:     0  3:  3640  4:     0  5:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off 11:off 12:off

Ball moved down:

Axes:  0:  1026  1: -3848  2: -1519  3:  1841  4:     0  5:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off 11:off 12:off
Comment 43 Alex Smirnoff 2013-03-13 10:25:56 EDT
I need to warn, however, that those values are hardly reproducable, one slight move and they change
Comment 44 Alex Smirnoff 2013-03-13 10:27:00 EDT
There is some correlation between how I move the ball and what I see, but it is very unreliable.
Comment 45 Jaromír Cápík 2013-03-13 11:10:53 EDT
Ok, thanks.

In that case we need to create a new tool for catching the joystick output. It would be 100x simplier and faster if I could have a physical access to the device. Such remote work can effectively cover only small issues. I'll come to you later (probably next week).

Regards,
Jaromir.
Comment 46 Fedora End Of Life 2013-12-21 10:05:11 EST
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 47 Fedora End Of Life 2014-02-05 17:47:09 EST
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 48 Fedora End Of Life 2015-01-09 17:00:31 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 49 Fedora End Of Life 2015-02-18 08:45:44 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.