-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
segfault when using Teensy 3.2/3.1 based USB devices #4981
Comments
What's the related output from running MAME with -verbose? |
with -verbose I get the following :
|
I suspect the problem is here: Input: Adding joystick #1: TeensyduinoKeyboard (device id: TeensyduinoKeyboard) MAME cannot handle a controller with 143 buttons (and I'm not too sure about 33 axes), but it shouldn't crash in that situation either. |
When I plug my device, here is what I get from dmesg :
Even if I use my device with Mame, it is supposed to be a keyboard, and Linux identifies it this way.
So the problem is likely that the Teensy keyboard mode is identified as a Joystick by Mame. By the way, by unplugging my other regular joystick (the one reported as DragonRiseInc.GenericUSBJoystick") I managed to run Mame, play my game and to only have the crash on exit, but it doesn't work every time.
I hopes it helps |
I did some more tests:
And when I test them with jstest-gtk, one of them reports an huge number of keys and axis (different from what Mame reports,if that matters). According to those results it seems that :
|
I tried to fix the problem on Mame side :
But it still segfaults when I plug my Teensy...
I didn't dive deep in the code but it seems that in the original code, the axis and buttons that in excess may still be added to the system
It's probably a feature, not just a bug. |
It would really be better if you could fix your peripheral so it doesn't erroneously present itself as a joystick with a huge number of buttons. |
I agree it is an unusual case, but the faulty code here is not mine, it's in the Teensy3 code base. Their basic "keyboard" example just provide this huge number of buttons, so other peripherals are likely to fail as well. |
This is not a teensy problem, I have the same issue with my Corsair k70 Gaming board. Detected by mame as a joystick. never would of thought that, been chasing this for some time now. Looks like it reports properly to me... |
output of lsusb Bus 004 Device 002: ID 8087:8002 Intel Corp. |
I dont have a lot of time to spend on this, but I will take a look around, seems like your joystick detection routine is a little broad ranged. Maybe it is an option for the SDL joystick query. |
Can you post the actual HID descriptor, in raw or parsed format? (You can get this with USB Prober on macOS, not sure how to get it on Linux or Windows. I know that's not directly helpful, but it may be a starting point for finding an equivalent tool.) |
lsusb --verbose should show the descriptors. |
I have come across a potential solution involving udev detecting the kb as a joystick. One potential solution here https://github.com/denilsonsa/udev-joystick-blacklist I will see if this is the case when I get home this evening. |
And there it is... my K70 has 3 input events and this one lists it as a joystick |
I'm going to rerun this with a debug build, according to Valgrind: ==17784== Memcheck, a memory error detector valgrind: m_mallocfree.c:307 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed. host stacktrace: sched status: Thread 1: status = VgTs_WaitSys syscall 257 (lwpid 17784) Thread 2: status = VgTs_WaitSys syscall 271 (lwpid 17786) Thread 3: status = VgTs_WaitSys syscall 1 (lwpid 17787) Thread 4: status = VgTs_Runnable (lwpid 17788) Note: see also the FAQ in the source distribution. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind |
gdb with full debug symbols: Starting program: /mnt/store/mame/mame/mame64d Thread 1 "mame64d" received signal SIGABRT, Aborted. |
trying to compile a fix now |
ok this is an unorthodox way of providing the fix... so what! |
Can you please stop sidestepping and actually post the HID descriptors? |
sure by all means... 005:007:001:DESCRIPTOR 1575690431.711363 005:007:000:DESCRIPTOR 1575690431.714341 |
tackling this on a device basis will be maddening as more and more KBs expose other functionality, like volume controls and media player interfaces which is what is going on with the K70. One event is the KB, the other is a volume control and the third is a media player control. The only real solution is to circumvent the excessive number of 'buttons' or deal with them correctly.
|
Consumer electronics controls (mostly media control keys).
Keyboard, maximum 256 keys.
Mouse with 16 buttons, X/Y axes, wheel, and a vendor-defined axis. I'm still confused about where the joystick with 174 buttons is coming from. There's the consumer electronics controls, the keyboard, and the mouse. I don't see the number 174 (0xAE) anywhere, either. MAME doesn't blow up on every keyboard with media control keys or see them as a joystick. What's actually causing this keyboard to be detected as a joystick? |
BTW, my apologies if I come across abrasive and condescending. I love the work you guys have done with all of this. I am just really busy with work and PhD studies, I just need to blow off some steam playing beasterizor (bloody roar) |
Its Udev as I post earlier |
So SDL reads the /dev/events(x) looking for the JOYSTICK flag. |
Udev may be detecting it as a joystick, but what is causing Udev to detect it as a joystick? That's the unanswered question. The descriptors you posted look no different to a regular composite keyboard/mouse device (like the Cherry and Sanwa Supply keyboards with integrated trackball/trackpad). There must be something special about it that causes the issue. |
I cant answer that, this goes back to kernel driver crap |
The K70 has programmable keys, that event id is listed as the joystick |
Well where's the descriptor for it? |
I gotta get my glasses checked, 1b1c:1b09 vs 1b1c:1b05 002:018:002:DESCRIPTOR 1575692877.783694 002:018:001:DESCRIPTOR 1575692877.784025 002:018:000:DESCRIPTOR 1575692877.784456 |
Keyboard, maximum 112 keys.
Consumer electronics controls.
Keyboard, maximum 256 keys, 3 LEDs. Weird, it looks like two keyboards in one? I still don't see where the number 174 comes from. @rb6502 given the current limitations of the MAME input module interface, and given that I'm planning to address pen/touch/IME edit before I even think about a serious rework of joysticks, what's your opinion on the best way to address this? |
@cuavas Given those things I'm inclined to go with his suggested change where we limit the buttons to INPUT_MAX_BUTTONS at the OSD level. It's bad that the keyboard is being detected that way though, the Microsoft keyboard on my Linux desktop has media controls and udev definitely does not report it as a joystick. |
I think it is a kernel 4.9 dependency |
The proposed fix isn't quite right - there's already code that's supposed to deal with excess buttons. Here's the fragment in question (starting at line 1072 in current master):
Note that it's already supposed to map excess buttons to switches. There's some other limit it's not checking. |
Oh duh, |
I hate that when it happens, and for me, it happens far too often :-) |
a660815 should work around crashes, both on start and if you actually press one of the excess buttons. |
Hi, |
Hello,
I am designing a custom controller based on a Teensy 3.1 board.
The board just reports as HID device (keyboard) but it probably does something uncommon since Mame crashes on startup when I launch Mame with my controller plugged.
I tried it with other games like FrozenBubble and I had no crash.
I don't think it comes from my code since I can reproduce the problem with the basic Teensy 3.1 keyboard example.
My guess is that the usb library of the Teensy 3 codebase must fill some fields in an unusual way that get parsed wrong by Mame.
Steps to reproduce the crash
Plugging the Teensy in after the game doesn't trigger the crash.
Starting Mame with the Teensy plugged in but without parameters doesn't trigger the crash either.
Stack trace
core.gz
My system
Debian stretch on core i7
Mame 209 compiled with a regular "make".
The behavior was identical with the official Debian Mame package (0.206)
lsusb
Here is the output of lusb -v for this device :
The text was updated successfully, but these errors were encountered: