Wacom graphire4 pad buttons: remap cause X-server restart

Bug #229694 reported by appultaart
16
Affects Status Importance Assigned to Milestone
xf86-input-wacom (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: wacom-tools

Hello,

This problem is identical to Creative2's report during the development of Hardy (http://ubuntuforums.org/showthread.php?t=742891). My xorg.conf is similar to his'.

I did a fresh Ubuntu Hardy 8.04 install, up-to-date, on i386 system (2.6.24-16-generic).
My Wacom Graphire 4 classic touchpad works well (pressure OK, stylus/eraser OK, touchpad scrollwheel OK) apart from the 2 buttons that are left and right of the scrollwheel.

In Gutsy (7.10/up-to-date), scroll wheel AND buttons worked fine (I had them re-assigned to browse fw/bw in Firefox), but after an internet upgrade to Hardy pressing either button forced X-server to crash. So, I did a fresh (cdrom-) install of Hardy. Pressing the buttons gives no apparent reaction, but remapping to anything makes the X-server to restart.

I run wacom-tools 1:0.7.9.8 from repositories. Installing 0.8.0 of wacom-tools (as suggested by http://ph.ubuntuforums.com/showthread.php?t=765915) did not work for me --> same results. So, I went back to repositories-package.

The problem can be reproduced on my system the following way:

#1: Test whether buttons are functional:
The command '>xidump pad' shows that button clicking IS noticed: xidump pad + buttonLeft --> "9-UP" and "9-DOWN", and +buttonRight --> "10-UP" and "10-DOWN". The scrollwheel is 4-UP and 5-UP for up and down, resp.

#2: Change button mapping is functional:
The command '>xsetwacom set pad Button1 "core key a" should remap Button1 to "a". This is confirmed by the command '>xsetwacom get pad Button1' which returns 'CORE KEY a'

#3: Press Button1 after change:
If the Button1 is pressed after the re-mapping, the X-server restarts (like CTRL+ALT+BackSpace).

I speculate the problem is in xsetwacom? Or, am I missing anything obvious here?
I have attached ~devices; ~dmesg; and /var/xorg.0.log as requested in the "DebuggingTouchpadDetection".

Thx,

Revision history for this message
appultaart (appultaart) wrote :
Revision history for this message
Michael Williamson (michaelw-cowtoolsmedia) wrote :

I'm using an intuos 3 and I get exactly the same result, xrestart whenever a remapped expresskey is pressed on both a 32 bit and a 64 bit system.

Both computers are running Hardy.

At the linux wacom site there was a mention that this is caused by the specific combination of driver version and linux kernel version.

I built the wacom driver 0.8.0-3 from source which fixed this problem, but then I had no pressure sensitivity in wine so have gone back to the driver in the repository.

Revision history for this message
Justin Dugger (jldugger) wrote :

If X crashes, there might be bugs in wacom, but there's also a bug in Xorg. The attached logs are not displaying the bug. There might be some other names for crash logs, like Xorg.0.log.old or Xorg.20.log etc. If you can't find the one with the crash report, just add them all and I'll see if I can find it.

Revision history for this message
Justin Dugger (jldugger) wrote :

Marked incomplete until requested Xorg log files are provided.

Changed in wacom-tools:
status: New → Incomplete
Revision history for this message
appultaart (appultaart) wrote :

Hi Justin, thanks for looking into this.

I have the two /var/log/Xorg.0.log files you requested for, see attach. The command 'diff Xorg.0.log Xorg.0.log.old' gives the following output:

$diff ...
23c23
< (==) Log file: "/var/log/Xorg.0.log", Time: Mon Jun 23 20:49:53 2008
---
> (==) Log file: "/var/log/Xorg.0.log", Time: Mon Jun 23 20:46:32 2008
488a489,491
>
> Fatal server error:
> Impossible keyboard event
$ ...

This 'impossible keyboard event' error message is reproducible and occurs after the "xsetwacom" pad button remapping (followed by, on button pressed, the X server restart).

Revision history for this message
Justin Dugger (jldugger) wrote :

Thank you. Can you also attach your /etc/X11/xorg.conf?

Revision history for this message
appultaart (appultaart) wrote :
Revision history for this message
Justin Dugger (jldugger) wrote : Re: [Bug 229694] Re: Wacom graphire4 pad buttons: remap cause X-server restart

Alrighty. I've narrowed it down to one of two places. If you're
familiar with this sort of thing,
https://wiki.ubuntu.com/X/Backtracing would be invaluable in finding
out which specific place is causing the error. If not, I can forward
this to upstream and see their opinion.

Justin Dugger

Revision history for this message
appultaart (appultaart) wrote :

OK. I just stopped playing with that gdb debugging program after some hours. Sorry, but it didn't work out:

I followed all instructions in the link; I do observe that Xorg is attached to gdb since I cannot mouse/type on the screen until I type 'cont' on my remote PC....However, the "backtrace full" command returns "No stack", after the X server was forced to crash by the button assignment. The screen message on the remote pc is: "(gdb) Program exited with code 01.".

Sorry I couldn't be of help, but you might give pointers to get me around this, if needed. BTW, I did not compile Xorg myself, it is from Ubuntu distro: this might be the reason for "no stack" answer from gdb?

Searching for 'xsetwacom backtrace' led me to this posting of some months ago: might be identical? Is this of help? http://www.nabble.com/Xorg-7.3-crashes-when-clicking-on-button-after-xsetwacom-td15566490.html.

Thanks, Appul

Revision history for this message
Justin Dugger (jldugger) wrote :

Did you install package "xserver-xorg-core-dbg"?

Revision history for this message
appultaart (appultaart) wrote :

yes, both "xserver-xorg-core-dbg", and "libgl1-mesa-dri-dbg" were installed.

Revision history for this message
Justin Dugger (jldugger) wrote :

Thank you very much for trying. I'll take a look myself and see who else can help.

Changed in wacom-tools:
status: Incomplete → Confirmed
Revision history for this message
FuocoTools (fuoco) wrote :

hello again , i am creative from ubuntu forum
and yes this silly problem is there....

Bryce Harrington (bryce)
tags: added: hardy
Revision history for this message
Bryce Harrington (bryce) wrote :

Thank you for reporting this issue with wacom-tools, we are migrating it to the new xf86-input-wacom package which has replaced it in the development version of Ubuntu.

This would be a good point for you to re-test this issue against the new package to see if is still occurring. If not, you can mark it as Fix Released in Launchpad. If it is still an issue in the current development release and you're the original reporter, please reply and attach a fresh Xorg.0.log.

affects: wacom-tools (Ubuntu) → xf86-input-wacom (Ubuntu)
Changed in xf86-input-wacom (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
appultaart (appultaart) wrote :

Hi Bryce,

I have re-tested this issue on Ubuntu Lucid 10.04. The bug is not occurring: button assigning seems to work. Superb! Thanks for looking into this, even with such an old reported bug.

Here is what I did to test:
(NB I have no access here to my old PC, I connected the Wacom Graphire4 pad to a laptop running Ubuntu 10.04, standard packages installed, standard settings)

1. The command "xsetwacom set pad Button1 "core key a"" did not work;
2. Command "xinput list" reported among other things a Virtual core pointer "Wacom Graphire4 4x5 pad, id=16 [slave pointer]"
3. I replaced that line with the 'pad' command of line 1:
    "xsetwacom set "Wacom Graphire4 4x5 pad" Button1 "core key a"
4. Pressing the pad's Button1 gives the output "a". No X-server restart.

(I noted that the "xsetwacom get "Wacom..." Button1" returns "1" instead of "CORE KEY a" as it used to do. But, I don't mind this as the assignment is working here....)

So I conclude that the X-server does not restart as initially reported in this bug. Hence, I will mark it as "Fix Released".

Changed in xf86-input-wacom (Ubuntu):
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.