Bug 561835 - Latest update (linuxwacom => xorg-x11-drv-wacom) borks wacom Tablet PC setup
Summary: Latest update (linuxwacom => xorg-x11-drv-wacom) borks wacom Tablet PC setup
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-wacom
Version: 12
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Peter Hutterer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 556892 563298 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-02-04 13:42 UTC by Andrew Lofthouse
Modified: 2018-04-11 12:12 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-09-14 22:56:12 UTC
Type: ---


Attachments (Terms of Use)
fdi file that works with linuxwacom rpm (2.57 KB, text/plain)
2010-02-04 13:42 UTC, Andrew Lofthouse
no flags Details
Archive with requested info (lshal, Xorg.0.log and /proc/.../devices) (38.84 KB, application/x-gzip)
2010-02-05 01:14 UTC, Andrew Lofthouse
no flags Details
xorg log with new package and no custom fdi file (55.72 KB, text/plain)
2010-02-08 14:20 UTC, Andrew Lofthouse
no flags Details
lshal (new package, no custom fdi file) (154.03 KB, text/plain)
2010-02-08 14:20 UTC, Andrew Lofthouse
no flags Details
xorg log with new package and no custom fdi file (46.29 KB, text/plain)
2010-02-09 17:36 UTC, Andrew Lofthouse
no flags Details
lshal (new package, no custom fdi file) (153.71 KB, text/plain)
2010-02-09 17:37 UTC, Andrew Lofthouse
no flags Details
xorg.conf/Xorg.log for 0.10.1-2 attempts (5.42 KB, application/x-gzip)
2010-02-26 13:58 UTC, Andrew Lofthouse
no flags Details
suspend/resume script in /etc/pm/sleep.d (965 bytes, application/x-shellscript)
2010-03-16 15:05 UTC, Andrew Lofthouse
no flags Details

Description Andrew Lofthouse 2010-02-04 13:42:06 UTC
Created attachment 388783 [details]
fdi file that works with linuxwacom rpm

Description of problem:

The latest update included in the change from linuxwacom to xorg-x11-drv-wacom completely borks the wacom settings on my Tablet PC.  I have F12 installed, with a customized fdi file for the wacom drivers.  With this fdi file, my stylus works, with the eraser.  After the update, the stylus will only work once it is tapped once on the screen (before it is tapped on the screen, it won't move the cursor as it should).  In addition, the eraser is not detected or configures.  Finally, clicking the stylus button (equivalent to a right-click) registers a mouse event even when the stylus is not touching the screen.

I noticed that the fdi file was changed from 10-linuxwacom.fdi to 10-wacom.fdi.  I've also copied my working fdi file to the new filename (10-wacom.fdi) and it doesn't fix the problem.

Downgrading to linuxwacom-0.8.2.2-17.fc12 fixes the problems.


Version-Release number of selected component (if applicable):
xor-x11-drv-wacom-0.10.4-1.fc12

How reproducible:
Every time I reboot, or try to use stylus!

Steps to Reproduce:
1. F12 installed on Tablet PC with wacom settings working
2. yum update (on 3 Feb 2010)
3. Reboot -- stylus settings no longer work as expected
  
Actual results:
See above

Expected results:
No change in stylus behavior

Comment 1 Peter Hutterer 2010-02-04 22:10:33 UTC
Please attach your Xorg.log and the output from lshal (both working and non-working if possible). wacom uses a different type of hotplugging than linuxwacom, this may cause the difference.

/proc/bus/input/device may also be helpful, won't hurt to attach it at least :)

Comment 2 Andrew Lofthouse 2010-02-05 01:14:47 UTC
Created attachment 388938 [details]
Archive with requested info (lshal, Xorg.0.log and /proc/.../devices)

Comment 3 Peter Hutterer 2010-02-05 05:48:26 UTC
The main thing that changed for you here was that linuxwacom used an external hotplugging scheme, i.e. hal virtually duplicated the device.
xorg-x11-drv-wacom has an internal scheme, where the driver knows what devices are required and duplicates itself as required for the particular model.
This hotplugging only works if the type isn't set by the user; because you used the old fdi, the type is always set. So it's better to use the driver-provided fdi file, that should always hotplug the erasor.

Please also provide the xorg.log and lshal output with the vanilla fdi file from xorg-x11-drv-wacom.

(In reply to comment #0)
> After the update, the stylus will only work
> once it is tapped once on the screen (before it is tapped on the screen, it
> won't move the cursor as it should).

does this mean once you tapped it once it works, or you always have to tap it?

> Finally, clicking the stylus button (equivalent to a right-click) registers a 
> mouse event even when the stylus is not touching the screen.

this suggests that proximity isn't quite working right, which would go hand in hand with the tapping problem. I'll look into that, haven't found the cause yet.

Comment 4 Natalie 2010-02-05 23:49:59 UTC
Move to xorg-x11-drv-wacom-0.10.4-2

http://koji.fedoraproject.org/koji/buildinfo?buildID=154195

Worked for me on Fedora 12 x86_64

Comment 5 Andrew Lofthouse 2010-02-08 14:20:15 UTC
Created attachment 389522 [details]
xorg log with new package and no custom fdi file

Comment 6 Andrew Lofthouse 2010-02-08 14:20:53 UTC
Created attachment 389523 [details]
lshal (new package, no custom fdi file)

Comment 7 Andrew Lofthouse 2010-02-08 14:23:10 UTC
(In reply to comment #3)
> The main thing that changed for you here was that linuxwacom used an external
> hotplugging scheme, i.e. hal virtually duplicated the device.
> xorg-x11-drv-wacom has an internal scheme, where the driver knows what devices
> are required and duplicates itself as required for the particular model.
> This hotplugging only works if the type isn't set by the user; because you used
> the old fdi, the type is always set. So it's better to use the driver-provided
> fdi file, that should always hotplug the erasor.

I deleted the custom fdi file and tried again -- no change from behavior noted above (no eraser, proximity problems...)

> Please also provide the xorg.log and lshal output with the vanilla fdi file
> from xorg-x11-drv-wacom.

Done..

> (In reply to comment #0)
> > After the update, the stylus will only work
> > once it is tapped once on the screen (before it is tapped on the screen, it
> > won't move the cursor as it should).
> 
> does this mean once you tapped it once it works, or you always have to tap it?

It needs to be tapped once, then it works.

Comment 8 Peter Hutterer 2010-02-09 01:25:02 UTC
(In reply to comment #6)
> Created an attachment (id=389523) [details]
> lshal (new package, no custom fdi file)    

Are you sure you don't have any custom fdi files in /etc/hal or somewhere else? do you still have 10-linuxwacom.fdi somewhere? did you restart HAL?

The reason I ask is are these lines here:
  info.callouts.add = {'hal-setup-wacom', 'hal-setup-wacom', 'hal-setup-wacom'} (string list)
  ...
  input.x11_options.Type = 'stylus'  (string)

The latter is one problem - if the type is set the driver doesn't do auto-initialization of dependent devices (based on the premise that if the user configured it in a particular way, let's not mess that up ;). so we need to find out where this comes from. It used to be part of 10-linuxwacom.fdi but that should have been removed with linuxwacom. the hal-setup-wacom line shouldn't be there either and indicates some stale fdi file somewhere.

Comment 9 Andrew Lofthouse 2010-02-09 17:36:18 UTC
Okay, I've been rebooting (multiple times) with each new try to get a clean configuration.  I think the problem was that I moved my old fdi file to a subdirectory in /etc/hal/policy, thinking that it wouldn't be found.

I'm fairly certain now that the default fdi file is being used.  Now, the eraser is configured, but the stylus button is not (no right click).  And, the problem with having to tap the screen once to enable the stylus is still there.

I'll attach new lshal and Xorg.log files.

Comment 10 Andrew Lofthouse 2010-02-09 17:36:55 UTC
Created attachment 389812 [details]
xorg log with new package and no custom fdi file

Comment 11 Andrew Lofthouse 2010-02-09 17:37:23 UTC
Created attachment 389813 [details]
lshal (new package, no custom fdi file)

Comment 12 Matěj Cepl 2010-02-10 12:06:03 UTC
*** Bug 563298 has been marked as a duplicate of this bug. ***

Comment 13 Matěj Cepl 2010-02-10 12:07:02 UTC
*** Bug 556892 has been marked as a duplicate of this bug. ***

Comment 14 Peter Hutterer 2010-02-11 03:11:23 UTC
(In reply to comment #9)
> I'm fairly certain now that the default fdi file is being used.  Now, the
> eraser is configured, but the stylus button is not (no right click).

ok, my fault. I didn't see the button configuration in your custom fdi file. put the following into /etc/hal/fdi/policy/wacom.fdi

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
  <device>
      <match key="@info.parent:pnp.id" contains="FUJ02e5">
	<merge key="input.x11_options.Button2" type="string">3</merge>
      </match>
  </device>
</deviceinfo>

that just restores your button2 setting, but leaves the rest up to the driver.
note that this will affect the erasor button 2 as well (if there is one?), we don't have an fdi method to configure this separately :(

> And, the problem with having to tap the screen once to enable the stylus is still there.

I have not yet managed to figure out why this is the case.

Comment 15 Andrew Lofthouse 2010-02-18 15:13:52 UTC
That does indeed restore the the button2 setting, but the proximity issue still makes the stylus fairly unusable.  Not only do I have to tap the screen once to enable the stylus, but pushing the stylus button registers a right mouse click even when not tapping the screen (when the stylus is near enough to move the cursor).

Comment 16 Peter Hutterer 2010-02-23 04:51:52 UTC
I haven't given up on you Andrew but at this point I'm stuck. I don't know whether it was xorg-x11-drv-wacom that broke or linuxwacom that fixed the issue and diffing the two is an exercise in masochism.

To narrow down the issue, please grab any older version of xorg-x11-drv-wacom from koji and see if you can reproduce the bug. all builds are available at:
http://koji.fedoraproject.org/koji/packageinfo?packageID=9537

note that for builds before 0.10.2 you need to have an xorg.conf section for the wacom device, otherwise the hotplugging code will segfault (on serial devices anyway). Hopefully that should narrow down approximately when it broke.

Comment 17 Andrew Lofthouse 2010-02-26 13:58:12 UTC
Created attachment 396544 [details]
xorg.conf/Xorg.log for 0.10.1-2 attempts

I've tried the following with no change in behavior (reboots between each try):

xorg-x11-drv-wacom-0.10.2-1
xorg-x11-drv-wacom-0.10.2-2
xorg-x11-drv-wacom-0.10.3-1
xorg-x11-drv-wacom-0.10.4-1
xorg-x11-drv-wacom-0.10.4-2

I've been unable to get 0.10.1-2 to work (continuously segfaults).  I've tried using various versions of xorg.conf (see attached for two with the corresponding Xorg logs).  I've never used an xorg.conf on this particular machine, so I don't know if the one I have from another should work or not.

Comment 18 Peter Hutterer 2010-03-09 09:07:21 UTC
finally found something that could be the cause of your issue. in one of the patches in xf86-input-wacom, a check for different packet lengths was removed causing later events to be misparsed. 

can you try this scratch build here and let me know if that fixes anything for you?
http://koji.fedoraproject.org/scratch/whot/task_2040400/

Comment 19 Ike 2010-03-11 04:39:52 UTC
There is a similar regression on the Thinkpad X61T Tablet PC, fortunately the above scratch build appears to have fixed this regression.

The problem I was having was that while the stylus functioned when it was hovering above the screen, upon making contact with the screen (button 1 depressed) the cursor would jump between the point of contact and the bottom right corner while the click was underway and could release in either location.

I have no custom fdi files and it is a fresh install of F12 properly updated.

The only changes I have made to customize my tablet were to calibrate the finger touch (it has always been off with all wacom tablet drivers). My fix was to call several xsetwacom to calibrate the tablet at the end of /etc/gdm/Init/Default (just before the exit0). This allows me to use the touchscreen and fingerprint reader to conduct a keyboard-less login, and maintains the set calibration for all users.

I do wish the new driver included the wacomcpl graphical calibration utility despite its HAL foibles.

Anyway the gist of all of that is the scratch build fixes stylus regressions on the X61T. All set from here.

Comment 20 Fedora Update System 2010-03-11 05:00:29 UTC
xorg-x11-drv-wacom-0.10.4-3.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/xorg-x11-drv-wacom-0.10.4-3.fc12

Comment 21 Stephan Groß 2010-03-11 12:20:02 UTC
(In reply to comment #19)

> Anyway the gist of all of that is the scratch build fixes stylus regressions on
> the X61T. All set from here.    

Same here on my ThinkPad X200T. Installing 
xorg-x11-drv-wacom-0.10.4-3.fc12 fixed all stylus regressions.

Comment 22 Andrew Lofthouse 2010-03-11 15:19:17 UTC
(In reply to comment #18)
> finally found something that could be the cause of your issue. in one of the
> patches in xf86-input-wacom, a check for different packet lengths was removed
> causing later events to be misparsed. 
> 
> can you try this scratch build here and let me know if that fixes anything for
> you?
> http://koji.fedoraproject.org/scratch/whot/task_2040400/    

Yes, it does indeed fix the proximity issues.  Now, I just need to get my rotation script working again...

Comment 23 Peter Hutterer 2010-03-12 04:37:53 UTC
cool, thanks for testing. I think this bug is closed now?


Andrew:
the rotation script should work the same if you've been using xsetwacom. I think :)

Comment 24 Andrew Lofthouse 2010-03-12 14:55:01 UTC
Argh... I shouldn't have replied so soon...

The problem with having to tap the screen before the stylus would work is now fixed, but the problem with having a "right-click" register when the stylus is within sensing range (even when not tapping the screen) is not fixed.

As an aside, wrt the rotation script, shouldn't "xsetwacom list dev" list the devices available?  I've been trying to track down this issue yesterday and today, but it seems that sometimes it works and sometimes it doesn't.  When it doesn't, xsetwacom gives an error message about not being able to parse the config file.  I'll readily admit that it might be my ignorance with fdi files, etc.  This is affecting my rotation and calibration scripts because the names of the devices are changing...  Let me emphasize that the above issue about right-click is independent of fdi files (it is even there when only using the simple fdi entry discussed above to enable the stylus button).

Comment 25 Peter Hutterer 2010-03-15 04:02:24 UTC
(In reply to comment #24)
> The problem with having to tap the screen before the stylus would work is now
> fixed, but the problem with having a "right-click" register when the stylus is
> within sensing range (even when not tapping the screen) is not fixed.

Is this a new problem or was this present with linuxwacom already? If you run evtest against the device, do you get an event from the kernel?

 
> As an aside, wrt the rotation script, shouldn't "xsetwacom list dev" list the
> devices available?  I've been trying to track down this issue yesterday and
> today, but it seems that sometimes it works and sometimes it doesn't.  When it
> doesn't, xsetwacom gives an error message about not being able to parse the
> config file.

this is weird. the xsetwacom that comes with xorg-x11-drv-wacom doesn't check the config file at all anymore. Do you have a mix of linuxwacom and xorg-x11-drv-wacom installed?

Comment 26 Andrew Lofthouse 2010-03-15 16:05:51 UTC
(In reply to comment #25)
> (In reply to comment #24)
> > The problem with having to tap the screen before the stylus would work is now
> > fixed, but the problem with having a "right-click" register when the stylus is
> > within sensing range (even when not tapping the screen) is not fixed.
> 
> Is this a new problem or was this present with linuxwacom already? If you run
> evtest against the device, do you get an event from the kernel?

This is a new problem that showed up with the xorg-x11-drv-wacom update. I cannot get any event to register from this device.  I have /dev/input/event[0-13], but none of them are for the stylus...

> > As an aside, wrt the rotation script, shouldn't "xsetwacom list dev" list the
> > devices available?  I've been trying to track down this issue yesterday and
> > today, but it seems that sometimes it works and sometimes it doesn't.  When it
> > doesn't, xsetwacom gives an error message about not being able to parse the
> > config file.
> 
> this is weird. the xsetwacom that comes with xorg-x11-drv-wacom doesn't check
> the config file at all anymore. Do you have a mix of linuxwacom and
> xorg-x11-drv-wacom installed?    

Okay, "xsetwacom list dev" gives the following:

PnP Device (FUJ02e5) eraser ERASER
Pnp Device (FUJ02e5) STYLUS

And I can rotate the digitizer with:

$ xsetwacom set "PnP Device (FUJ02e5)" rotate ccw

It turns out that my "wacomrotate" utility was interfering with my earlier tests...

Now I have a further issue to report (it seems that as some things get resolved, my testing progresses further and I find more problems).  I have a script in /etc/pm/sleep.d to recalibrate the digitizer after a suspend/resume.  Essentially, on suspend I store the TopX, TopY, etc, values using this command:

su $USER -c "/usr/bin/xsetwacom --display :0.0 get $DEV TopX" etc

and then on resume restore the settings with

su $USER -c "/usr/bin/xsetwacom --display :0.0 set $DEV TopX $value" etc

The problem is that on suspend, the xsetwacom command fails with:

"Failed to open Display."

The same commands works fine from a terminal.  I'm not sure what is different now, besides that the device doesn't require "stylus" or "eraser" after the "PnP Device (FUJ02e5)" part.

I find it curious that it seems I'm the only one having these problems...

Comment 27 Peter Hutterer 2010-03-16 04:33:18 UTC
(In reply to comment #26)
> (In reply to comment #25)
> > (In reply to comment #24)
> > > The problem with having to tap the screen before the stylus would work is now
> > > fixed, but the problem with having a "right-click" register when the stylus is
> > > within sensing range (even when not tapping the screen) is not fixed.
> > 
> > Is this a new problem or was this present with linuxwacom already? If you run
> > evtest against the device, do you get an event from the kernel?
> 
> This is a new problem that showed up with the xorg-x11-drv-wacom update. I
> cannot get any event to register from this device.  I have
> /dev/input/event[0-13], but none of them are for the stylus...

oh right, you've got a serial device, I forgot.

> su $USER -c "/usr/bin/xsetwacom --display :0.0 set $DEV TopX $value" etc
> 
> The problem is that on suspend, the xsetwacom command fails with:
> 
> "Failed to open Display."

oops. you found a bug. xsetwacom didn't parse --display correctly, build is on its way.


> The same commands works fine from a terminal.  I'm not sure what is different
> now, besides that the device doesn't require "stylus" or "eraser" after the
> "PnP Device (FUJ02e5)" part.
> 
> I find it curious that it seems I'm the only one having these problems...    

you have a different device and you're actually using it. I have an Intuos3 and and Intuos4 for testing but I don't really use it for day-to-day work. I should have a serial device for the next couple of days, hopefully that makes it easier to reproduce and debug.

Comment 28 Fedora Update System 2010-03-16 04:38:29 UTC
xorg-x11-drv-wacom-0.10.4-4.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/xorg-x11-drv-wacom-0.10.4-4.fc12

Comment 29 Fedora Update System 2010-03-16 04:54:55 UTC
xorg-x11-drv-wacom-0.10.4-6.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/xorg-x11-drv-wacom-0.10.4-6.fc13

Comment 30 Andrew Lofthouse 2010-03-16 15:05:08 UTC
With xorg-x11-drv-wacom-0.10.4-4.fc12, the --display problem is now fixed.  My suspend/resume script now stores the TopX, etc, values in /tmp/calibration.tmp.  However, now the problem is that when I suspend with the display in portrait mode, the calibration values stored are for landscape, rather than portrait.  The script is in /etc/pm/sleep.d.  With linuxwacom, the same script stored portrait values when the display was in portrait mode.

Comment 31 Andrew Lofthouse 2010-03-16 15:05:45 UTC
Created attachment 400474 [details]
suspend/resume script in /etc/pm/sleep.d

Comment 32 Peter Hutterer 2010-03-17 05:52:18 UTC
Just found another option :)

Option "TPCButton" "on". Can you add this to your config file and see if that helps? or try xsetwacom set "device name" TPCButton 'on'

Comment 33 Andrew Lofthouse 2010-03-18 14:18:25 UTC
That did the trick for the button problem -- thanks!

Any ideas about the suspend-while-in-portrait-mode problem?  This is the final issue I'm having... Besides the problem with calibration settings not getting restored correctly, I've also noticed that suspending with the display in portrait mode is noticeably less reliable than it was before.  Sometimes the X-server crashes on resume when I attempt to use the pen to unlock the display.

Comment 34 Patrick 2010-08-13 21:52:46 UTC
I am having the same problem on F12, that being the cursor does not follow along via proximity only when the pen is actually making firm contact. 

Sorry to be so dumb, I tried as many things as I could from this thread but some of the links are dead now, it's several months later. Could someone point me to a work-around or an bug fixed RPM?

thanks for reading

Comment 35 Andrew Lofthouse 2010-08-23 20:22:53 UTC
I've finally upgraded to F13.

The latest xorg-x11-drv-wacom works fine with my machine.  I've been able to transfer my .fdi file settings to xorg.conf (only needed for TopX, etc).  I also got my suspend/resume script working -- I had to include commands to reset xyDefault; store/restore TopX, etc; and store/restore rotation setting.

As far as I'm concerned, you can close this bug.


Note You need to log in before you can comment on or make changes to this bug.