Created attachment 33781 [details] Xorg crash log Hi ! Here's a follow-up to my previous bugreport ( http://bugs.freedesktop.org/show_bug.cgi?id=26884 ). Using a Speedlink 360 style Gamepad, aka SL-6555-SBK, aka acrux-usb-gamepad-8116 Software : ArchLinux 64 bits, xf86-input-evdev 2.3.2-1, xf86-input-joystick 1.5.0-1, xorg-server 1.7.5-1, kernel26 2.6.32.9-1 ISSUE : with some fullscreen apps using the joystick (like xmoto, sdlmame), pressing a button, or moving an axis triggers an instant crash of the X server. (whether it uses the evdev or joystick driver ; had to add an HAL rule to /etc/hal/fdi/policy beforehand ; otherwise, even though the stick was seen as /dev/input/js0 AND detected by the games, it wouldn't initialize (LED unlit) and wouldn't work.) HOWEVER : in windowed games, no trash was triggered. (i.e. windowed sdlmame, rrootage) Attached : the relevant xorg log. I will also add my lshal, evtest output, and the fdi file. Cheers !
Created attachment 33782 [details] lshal output
Unfortunately, I cannot provide an evtest-capture output. Indeed : I need to unplug / replug the gamepad to get it initialized. If I switch to the TTY1 console, the gamepad needs to be initialized again. If I use evtest-capture in my X session, the crash is too sudden and the generated xml file is empty...
I forgot an important piece of information : the crash doesn't depend on the GPU driver used. (occurs with both VESA and NVIDIA drivers)
if it only crashes once you press the joystick, you can still get the evtest output from it this way: start a terminal, then start screen. inside screen, run evtest-capture. now crash the server, when it comes back reconnect to the screen session with "screen -r". This shouldn't kill the evtest-capture process and thus flush the xml file.
Thank you Peter, that's really good to know ! So here's the evtest-capture.xml file. I just launched sdlmame and moved the horizontal axis of the first stick to the left, then it brought down the whole X server. Cheers !
Created attachment 34033 [details] evtest-capture, with the fdi file, screen, sdlmame
reassigning to joystick driver, I can't reproduce this with evdev.
Did you set input.x11_options.SendCoreEvents to 'false'? Does it crash when you set it to true? If you have it to false you could as well just deactivate the joystick driver completely to be sure it's the joystick module that triggers the crash. I will try to reproduce it..
Hello Sascha, thanks for your reply ! I eventually decided to install both Archlinux and Ubuntu at the same time. I can confirm that : - with Archlinux (current), the crash occurs with input.x11_options.SendCoreEvents set to false. BUT INDEED, it doesn't crash when it is set to true ! Your assumption was right ! - with Ubuntu (Lucid Beta 1), it doesn't crash (strangely, it doesn't seem to respect the aforementioned option, which it did in Karmic - with no crash either). The other issues exist in both cases (custom FDI required, axis problems, unplug / replug required). Cheers !
I can not reproduce this bug with quake3. Generally joystick clients fight over the data so unless you are really using the xorg joystick driver, it's a good idea to generalle disable it completely. Setting SendCoreEvents to false is a workaround but will still keep the joystick module working in the background, possibly causing it to fight over the device with the game so you need to unplug it and replug it to make it work. If you do not use the joystick as a mouse device, I recommend to remove the joystick module. What distribution installs and enables the joystick driver by default? Usually that's not what people want. The crash seems to happen only when the joystick is in "floating" mode (not generating core events). Can you reproduce the bug with recent versions of xorg-server?
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.