Created attachment 92597 [details]
journal of the crash
I'm reporting a bug I've already reported to the Linux Wacom driver project :
It may be a Xorg related bug, so I prefer to duplicate it here, and maybe you
will be able to help me track the issue.
Recently, I set up my Cintiq 21UX tablet (old model) with the new Gnome 3.10
expresskey interface, and I'm not sure if it's linked, but now each time I use
the left pad (not the strip), it causes an X.org crash (my session crash and
I'm back to GDM login).
For some button (bottom one) a single "click" is enough, for some other (top
ones) a "long click" cause the crash.
Using the right pad or the touch stripes, everything works just fine.
My distribution is Manjaro 8.8 stable with a 3.10 kernel, with latest xorg
server (1.14.5-1), latest open ati driver (xf86-video-ati 1:7.2.0-1), latest
wacom driver (libwacom 0.8-1 and xf86-input-wacom 0.23.0-1) and latest evdev driver (xf86-input-evdev 2.8.2-1)
I'm not sure wich log files I should join to this bug report, so here is my
Xorg log... Don't hesitate to ask me more.
I tried several mapping with 2 users sessions (one brand new for the occasion)
this morning, and I'm sorry to say crash occur in every case (whatever the
action), including with 'None' set on every touch strips and pads on both
Here are 2 logs from /var/log/gdm, and line 153 from journalctl.txt may be
Recents updates on the Manjaro distribution didn't change the behavior.
Maybe related to bug 33499
I need your Xorg.log please, the journal doesn't (yet) contain it.
Created attachment 92972 [details]
X.org log for the crash
I'm sorry I forgot that... I had it, simply didn't attach.. !
Created attachment 92973 [details]
GDM log for the crash
If it helps...
Created attachment 92974 [details]
Second GM log if useful
I can add you can easily reproduce the bug with latest Manjaro test build :
If you have troubles making it running, please boot in "text mode" instead of "video".
Tested on my computer (64 bits, ATI Radeon HD 4870 card).
If you need addtional history for this bug, please check on the Linux Wacom bug tracker.
Thanks for your great work anyway !
Comment on attachment 92972 [details]
X.org log for the crash
There's no backtrace in two of the logs - that usually signals an unresolved symbol. Try to start X from the console with startx, once it fails you should see it on the terminal.
One log has a backtrace, but is missing any debuginfo, maybe install the debuginfo packages to get a better backtrace
Created attachment 92981 [details]
Hopefully better log (startx as root)
Created attachment 92982 [details]
Hopefully better log (startx as user)
I'm sorry I'm not familiar with Xorg debugging...
I have no "debuginfo" package in my distrib, but I installed "xorg-server-devel" and "gdb". Hope this will work.
For some reason, if I disable GDM ("sudo systemctl disable gdm.service -f"), reboot, and try to connect to graphical interface using "startx", xorg fail to load and I'm back to console.
Here are 2 logs, one as root, one as user using "startx".
Should I follow this tutorial to report better logs : wiki.x.org/wiki/Development/Documentation/ServerDebugging/ ?
Thanks again !
(In reply to comment #8)
> For some reason, if I disable GDM ("sudo systemctl disable gdm.service -f"),
> reboot, and try to connect to graphical interface using "startx", xorg fail
> to load and I'm back to console.
and there is no error on the console? try "xinit -- " after installing xterm which starts the simplest session. exiting the xterm will get you back on the console. if it crashes before, you should have an error there. if it's really a symbol issue you won't see this in the log
Created attachment 93115 [details]
console result using "xinit --" as user
I'm sorry I'm so newbie... but I don't know how to save the console result in a text file... so I took pictures.
Created attachment 93117 [details]
console result using "xinit --" as root
Created attachment 93118 [details]
console result using "startx" as user
Created attachment 93119 [details]
console result using "xterm" as user
I spend the morning trying to understand this bug...
Behaviour changed a little on my session, and I don't know why (a package update ?) : Now crash do not occur every time, but randomly (most of the time not), on every button (1 to 8, left and right) whatever action is set on them (or at least I don't understand which mapping cause the crash). Sometimes I can use the button during a quarter an hour without triggering the crash.
I could not reproduce the bug with Manjaro KDE 8.8 or Manjaro Cinamon 8.8. But with Ubuntu 13.10 (Unity), crash occur 2 times with the same behaviour.
An interesting point is that Unity use gnome-control-center for Wacom settings too, and Cinamom is not (Wacom settings disappeared recently from their own control center).
I reported the bug to Gnome, but they considered it invalid...
Should I reopen it ?
Can it be a hardware issue (faulty contact) ?
I forgot to add I have a second monitor... but crash occur if its connected or not, whatever how I set it.
And finally... my system language is french... Probably not the right track, but maybe worth mentioning
Created attachment 93451 [details]
Backtrace obtained in Ubuntu Gnome edition
Eureka, I GOT IT !
the crash occur only if one or more pad buttons (not stripes) are pushed WHILE my mouse (Roccat kova plus) move, whatever action is set up with the pad buttons or with mouse buttons.
I made a short video : http://yagraph.org/images/bug/wacom-cintiq-21ux-and-mouse-crash.webm
I had the felling it happened only with left pad because when I use the right pad, I use my right hand... which isn't on the mouse at this particular moment.
With another mouse (Logitech RX250), nothing happen.
I tried again with several distributions, and I can only reproduce the bug with environments who use Gnome settings :
- Manjaro Gnome 8.9 rc1
- Ubuntu (Unity) 13.10
- Ubuntu Gnome Edition 13.10
nothing happen with :
- Manjaro Cinamon 8.8
- Manjaro KDE 8.8
- Manjaro XFCE 8.8
- Xubuntu 13.10
So, It look like an input conflict in the Gnome environment. I'm certainly the one guy in the world with such a configuration ;p
I upgraded to kernel 3.12 and installed alternatively "roccat-dkms" and "kmod-roccat", but the bug still occur.
Attached : an interesting backtrace obtained with Ubuntu Gnome edition.
I'm reporting this to Roccat linux driver (https://sourceforge.net/projects/roccat/) and X.org.... and I'm changing the title for this bug too.
Thanks for your patience !
Sorry, can't change the title...
link to my bug report at Roccat linux driver :
ok, here is what I need you to do so we can narrow this down. of the environments you can reproduce this with, please get the one with the most recent packages. Then install evemu and record the event sequence as you trigger the crash.
It'll be something like
sudo evemu-record /dev/input/event12 > cintiq-events.evemu
and do the same for the roccat mouse, at the same time.
Run that in screen so you don't lose it when X crashes. event12 is dependent on your setup, run evemu-record as root without any arguments to see the correct number for the wacom tablet.
Attach the .evemu file here (it's a plain text file). Also, right after the crash, collect the /var/log/Xorg.XXXX.log.old and attach it here. XXXX again represents a number (usually 0), search by timestamp to get it. Important: the .log.old file, since when the server restarts the .log file is the one from the currents session and won't have a backtrace. Make sure you do have a backtrace in the log.old file. Attach that here (obsoleting all older logs).
Also, install the debuginfo package (or whatever it's called on your distribution) for the server and for the wacom driver. In the backtrace you have a bunch of addresses. Pump those into eu-addrtoline and it will resolve the exact location of the crash in the source file. See:
Here is what I get, and so far I can go.
I'm on an up-to-date Manjaro distribution (Arch Linux based) with a 3.12 kernel. To obtain debug info, I compiled xorg-server-dev and xf86-input-wacom-git from AUR with the "debug" option set up in "makepkg.conf". See :
I couldn't obtain the input device list from "evemu-record", so I obtained it with "cat /proc/bus/input/devices".
I obtained a backtrace too, but not all symbols were understood by "eu-addrtoline". I hope what I get is enough !
Please help me continue if you need more infos after that, and many thanks !
Created attachment 93756 [details]
Input devices list
obtained with cat /proc/bus/input/devices
Created attachment 93757 [details]
Roccat input evemu result
Created attachment 93758 [details]
Roccat input evemu result (second one)
Created attachment 93759 [details]
Wacom cintiq 21UX evemu result
Created attachment 93760 [details]
X.org log for the crash
Created attachment 93761 [details]
Passing X.org backtrace to eu-addrtoline
Pretty sure this is fixed by b2d5ee2e3684951b611fd2068d57cc65fd8305a3 Xi: Ensure DeviceChanged is emitted after grabs are deactivated.
I haven't yet replicated the crash yet but if you could compile and test with that patch on your server that'd be great.
and thanks for the good news !
I try to build X server from git since 3 days with AUR (https://aur.archlinux.org/packages/xorg-server-git), but my computer fail to compile it :
/usr/include/X11/Xdefs.h:105:10: error: expected ')' before 'OSTimePtr'
OSTimePtr /* pTimeout */,
In file included from atom.c:57:0:
../include/dix.h:224:54: error: expected ')' before 'WakeupHandlerProcPtr'
../include/dix.h:230:52: error: expected ')' before 'WakeupHandlerProcPtr'
So I suppose I have to build my own custom package downloading the Xorg server version here :
I keep you updated...
This is something you need to bring up with your distribution, I'm not sure how to recompile a package on your distro. You could follow the distro-specific rebuild options and just apply that revision I listed as a local patch. Building from git means you may need some extra dependencies, but the start page for that is here: http://www.x.org/wiki/Building_the_X_Window_System/
THANK YOU !
I learned how to create a package for my distrib and how to patch it... And surprisingly its works...
And I confirmed this bug is FIXED with xorg-server 1.15 patched with the git commit you found.
So, all this mess for a bug already resolved in Git... but I suppose this is the game !