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.
(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)
any news on that? bug persists in fc18. also jsattach is deprecated now, so inputattach is the only option left.
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.
Created attachment 708388 [details] inputattach core dump Coredump attached.
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.
Hi Alex. Is that the L version (left-hand) ? Thx, J.
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
Was the core file created by one of the official fedora releases of linuxconsoletools? Which version exactly?
linuxconsoletools-1.4.4-7.fc18.x86_64
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.
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.
Thanks Jaromir!
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.
Please, download the attached tarball ... it contains the mentioned diagnostic binary ... test that again .... the binary should provide you with some debug info ...
Created attachment 708491 [details] inputattach.tar.gz
Please collect the info and attach the result debug.txt here: ./inputattach --spaceball /dev/ttyUSB0 &> debug.txt
Created attachment 708494 [details] Output of the inputattach diagnostic version
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.
I may try to strace 3dxware server if that helps..
That would be great help!
Created attachment 708520 [details] 3dxsrv proprietary driver straced
Even more strange ... the strace says the baudrate is 9600 ... that's the correct one ... gonna dig deeper.
This piece seems to require some init data ... we could try to do the same ...
Created attachment 708555 [details] inputattach2.tar.gz A bit modified diagnostic binary ... please, repeat the test and provide me with the output ...
Created attachment 708802 [details] new diagnostic output
This one looks much better.
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.
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.
Created attachment 708926 [details] inputattach3.tar.gz Please .... repeat the test with this one ...
Created attachment 708930 [details] new diagnostic output
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).
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?
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.
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.
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 ...
Created attachment 709562 [details] inputattach5.tar.gz Please, test ...
This one does not initialize (inputattach: device initialization failed)
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 ...
This one works, but is no better :-)
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?
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
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
I need to warn, however, that those values are hardly reproducable, one slight move and they change
There is some correlation between how I move the ball and what I see, but it is very unreliable.
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.
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.
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.
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.
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.