Bug 538036 - xf86-input-wacom doesn't work
Summary: xf86-input-wacom doesn't work
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-wacom
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Peter Hutterer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 532874
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-11-17 11:15 UTC by Thomas Spura
Modified: 2011-06-03 07:46 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-06-03 07:46:36 UTC


Attachments (Terms of Use)
lshal output (150.41 KB, text/plain)
2009-11-17 11:15 UTC, Thomas Spura
no flags Details
Xorg.log (57.48 KB, text/plain)
2009-11-17 11:16 UTC, Thomas Spura
no flags Details
new lshal output with installed fdi file (147.78 KB, text/plain)
2009-11-18 19:29 UTC, Thomas Spura
no flags Details
new xorg.log with installed fdi file (57.48 KB, text/plain)
2009-11-18 19:31 UTC, Thomas Spura
no flags Details
Xorg.log with wacom as no type (57.60 KB, text/plain)
2009-11-19 02:21 UTC, Thomas Spura
no flags Details
Xorg.log with wacom as type touch (29.86 KB, text/plain)
2009-11-19 02:25 UTC, Thomas Spura
no flags Details
lshal output with something.fdi (168.51 KB, text/plain)
2009-11-19 02:27 UTC, Thomas Spura
no flags Details
new lshal output (working) (150.39 KB, text/plain)
2009-11-23 09:30 UTC, Thomas Spura
no flags Details
Xorg.log recognising stylus/touch, but not working (58.30 KB, text/plain)
2009-11-23 09:32 UTC, Thomas Spura
no flags Details
evtest on /dev/input/event6 (1.08 KB, text/plain)
2009-11-24 15:49 UTC, Thomas Spura
no flags Details
evtest on /dev/input/event6 (20.00 KB, text/plain)
2009-11-25 12:32 UTC, Thomas Spura
no flags Details
evtest on /dev/input/event7 (56.00 KB, text/plain)
2009-12-01 20:47 UTC, Thomas Spura
no flags Details
evtest-capture on /dev/input/event6 (684.37 KB, text/plain)
2009-12-03 13:37 UTC, Thomas Spura
no flags Details

Description Thomas Spura 2009-11-17 11:15:07 UTC
Created attachment 369860 [details]
lshal output

Hi,
I'm justing the new driver xf86-input-wacom, but its packaging is in progress, so I'll attach this here.

Attached is 'lshal' and Xorg.log

Comment 1 Thomas Spura 2009-11-17 11:16:19 UTC
Created attachment 369861 [details]
Xorg.log

Comment 2 Peter Hutterer 2009-11-18 03:19:24 UTC
seems to be caused by the fdi file not being installed yet (0.10.0 is a developer release). simplest way to fix that is to copy the fdi file from linuxwacom and install it in the same place (/usr/share/hal/fdi/policy/20thirdparty/10-linuxwacom.fdi).

that'll be fixed as soon as the driver gets through the review process.

Comment 3 Thomas Spura 2009-11-18 19:29:33 UTC
Created attachment 370172 [details]
new lshal output with installed fdi file

No, with the fdi file it doesn't work too.

$ ls /usr/share/hal/fdi/policy/20thirdparty/
10-fpit.fdi        10-synaptics.fdi    20-libgpod-sysinfo-extended.fdi
10-linuxwacom.fdi  11-x11-vmmouse.fdi

Comment 4 Thomas Spura 2009-11-18 19:31:32 UTC
Created attachment 370175 [details]
new xorg.log with installed fdi file

Comment 5 Peter Hutterer 2009-11-18 23:22:44 UTC
the lshal output doesn't show input.x11_driver = wacom, without this the driver won't be started.
the key is simply finding the device and making sure that key is merged in.
if I read this correctly, just add a match section for the info.product "HID 1b96:0001". i think this is the device that matters, currently it's picked up by the synaptics driver.
then restart hal, make sure the wacom driver is set (lshal) and you should be good to go. 

if it doesnt work, the section in lshal matching the device also lists the /dev/input/eventX device, simply run evtest against it (you may need to VT switch away first) and make sure events leave the device when you touch the screen. if so, you've found the right device and something else is wrong :)

Comment 6 Thomas Spura 2009-11-19 00:14:45 UTC
The top of /dev/input/event6:
Input driver version is 1.0.0
Input device ID: bus 0x3 vendor 0x1b96 product 0x1 version 0x110
Input device name: "HID 1b96:0001"
Supported events:
  Event type 0 (Sync)
  Event type 1 (Key)
    Event code 320 (ToolPen)
    Event code 330 (Touch)
    Event code 333 (Tool Doubletap)
  Event type 3 (Absolute)

So "HID 1b96:0001" is the right one, but I don't know where to add ' a match section'.

I copied the 10-linuxwacom.fdi from linuxwacom and the wacom.fdi from your upstream repository into 20thirdpary and I guess, this should add this match section. (<merge key="input.x11_driver" type="string">wacom</merge>)
And restarted hal, tested again, restarted, tested again...

$ ls /usr/share/hal/fdi/policy/20thirdparty/
10-fpit.fdi        10-synaptics.fdi  11-x11-vmmouse.fdi
10-linuxwacom.fdi  10-wacom.fdi      20-libgpod-sysinfo-extended.fdi


It would probably the best to chat in irc to guide me or do you have another idea?
(For the next half an hour or so, I should be online, just in case ;) )

Comment 7 Peter Hutterer 2009-11-19 01:05:10 UTC
<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
  <device>
      <match key="info.product" contains="HID 1b96:0001">
          <merge key="input.x11_driver" type="string">wacom</merge>
    </match>
  </device>
</deviceinfo>

copy this as something.fdi into /etc/hal/fdi/policy (that way it won't get overwritten when you update) and restart hal.

Comment 8 Thomas Spura 2009-11-19 02:21:41 UTC
Created attachment 370251 [details]
Xorg.log with  wacom as no type

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
  <device>
      <match key="info.product" contains="HID 1b96:0001">
          <merge key="input.x11_driver" type="string">wacom</merge>
          <merge key="input.x11_options.SendCoreEvents" type="string">true</merge>
          <merge key="input.x11_options.Mode" type="string">absolute</merge>
    </match>
  </device>
</deviceinfo>

With this, xserver sees, but fails to add it:
 554 (II) config/hal: Adding input device HID 1b96:0001
 555 (II) LoadModule: "wacom"
 556 (II) Loading /usr/lib64/xorg/modules/input/wacom_drv.so
 557 (II) Module wacom: vendor="X.Org Foundation"
 558         compiled for 1.7.1, module version = 0.10.0
 559         Module class: X.Org XInput Driver
 560         ABI class: X.Org XInput driver, version 7.0
 561 (EE) HID 1b96:0001: No type or invalid type specified.
 562 Must be one of stylus, touch, cursor, eraser, or pad
 563 (EE) PreInit returned NULL for "HID 1b96:0001"
 564 (EE) config/hal: NewInputDeviceRequest failed (8)
 565 (II) config/hal: Adding input device CNF8038

Comment 9 Thomas Spura 2009-11-19 02:25:02 UTC
Created attachment 370253 [details]
Xorg.log with  wacom as type touch 

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
  <device>
      <match key="info.product" contains="HID 1b96:0001">
          <merge key="input.x11_driver" type="string">wacom</merge>
          <merge key="input.x11_options.SendCoreEvents"
type="string">true</merge>
          <merge key="input.x11_options.Mode" type="string">absolute</merge>
          <merge key="input.x11_options.Type" type="string">touch</merge>
    </match>
  </device>
</deviceinfo>


This should add touch support -> seqmenation fault in xorg.log

Comment 10 Thomas Spura 2009-11-19 02:27:34 UTC
Created attachment 370254 [details]
lshal output with something.fdi

Now wacom is in lshal.

Comment 11 Peter Hutterer 2009-11-20 04:57:31 UTC
Please try http://koji.fedoraproject.org/koji/taskinfo?taskID=1818772.

There were quite a lot of changes between 0.10.0 and 0.10.1, and while I'm not sure if your particular model will work, there's a much greater chance it will.
Also, this package installs the fdi file now, so no messing around.

I haven't submitted it as an update - xorg-x11-drv-wacom isn't quite ready yet, I want to avoid the confusion of those who get their mostly-working linuxwacom replaced.

Comment 12 Thomas Spura 2009-11-21 10:57:42 UTC
After installing and restarting hal:
'lshal | grep wacom' shows no output...

With the something.fdi:
<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
  <device>
      <match key="info.product" contains="HID 1b96:0001">
          <merge key="input.x11_driver" type="string">wacom</merge>
          <merge key="input.x11_options.SendCoreEvents" type="string">true</merge>
          <merge key="input.x11_options.Mode" type="string">absolute</merge>
    </match>
  </device>
</deviceinfo>

# lshal | grep wacom
  input.x11_driver = 'wacom'  (string)
  input.x11_driver = 'wacom'  (string)

Comment 13 Peter Hutterer 2009-11-23 07:07:43 UTC
I think I found it. the driver-supplied fdi file has this extra line:
<match key="info.parent" contains="if0">
and that's not true in your case. Please try the builds from koji again.

http://koji.fedoraproject.org/koji/taskinfo?taskID=1824160

Comment 14 Thomas Spura 2009-11-23 09:30:15 UTC
Created attachment 373047 [details]
new lshal output (working)

Yes, it's going into the right direction :)

# lshal | grep wacom
  input.x11_driver = 'wacom'  (string)
  input.x11_driver = 'wacom'  (string)

But touching and writing does not yet work, although Xorg.log says it should.

Comment 15 Thomas Spura 2009-11-23 09:32:15 UTC
Created attachment 373049 [details]
Xorg.log recognising stylus/touch, but not working

Comment 16 Peter Hutterer 2009-11-24 06:26:17 UTC
interesting - this device used to work with linuxwacom?
can you run evtest against it and attach the output here?

Comment 17 Thomas Spura 2009-11-24 15:49:19 UTC
Created attachment 373473 [details]
evtest on /dev/input/event6

I haven't tried yet with linuxwacom, directly started with this driver.

With the old driver version evtest used to work. Now 'testing' does not work anymore. It seems the tablet doesn't regognize anymore touching.

Was there a change in the driver?

The old something.fdi doesn't work anymore, too.

Comment 18 Peter Hutterer 2009-11-24 22:44:19 UTC
sorry, should have mentioned that. wacom and synaptics are the two drivers that require you to VT switch away before, otherwise you won't see any events (if you're interested in why, google for EVIOCGRAB). Shutting down X works of course too.

Comment 19 Thomas Spura 2009-11-25 12:32:46 UTC
Created attachment 373732 [details]
evtest on /dev/input/event6

Yes, it worked now, thanks.

At first, I touched with the finger on the tablet
(all Event: time 1259152036.*),
and later on a few times with the pen down and up
(all Event: time 1259152039.*).

Comment 20 Peter Hutterer 2009-12-01 04:04:33 UTC
New packages! loads of fixes though I dont yet know if they happen to fix your bug too - please let me know:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1839623

Comment 21 Thomas Spura 2009-12-01 20:47:44 UTC
Created attachment 375186 [details]
evtest on /dev/input/event7

The only difference is, that the device is now on /dev/input/event7.

Still nonworking under X.

Attaching the updated evtest, but the top is excactly the same...

Just as a side note:
When touching evtest works, when using the pen, it just recognizes 'above screen', 'not above screen', 'down' and 'up'

but *not* 'moving, when down' and 'moving, when above screen'.


Maybe this is related to this bug as a whole.

Comment 22 Peter Hutterer 2009-12-03 06:43:49 UTC
i need a software emulation device for this. Please install evtest 1.25 from koji [1] and run evtest-capture against all devices that the touchscreen exposes. then attach the xml files here (separately please).


[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=1845172

Comment 23 Thomas Spura 2009-12-03 13:37:20 UTC
Created attachment 375777 [details]
evtest-capture on /dev/input/event6

It's again on /dev/input/event6.

I don't find any other device, that comes from the touchscreen.

The file looks a bit big and messy, don't know, if I can do anything else.

Comment 24 Chris Bagwell 2010-01-05 03:50:49 UTC
Two items I'd like to add:  

1) As of xorg-x11-drv-wacom-0.10.3-1.rpm, this successfully detects and works with my Wacom Bamboo Touch and Pen that was recently added to driver (well, there are known issues in that 0.10.3 and linuxwacom-0.10.5-9 being discussed on linuxwacom-discuss and Ubuntu forums).  That means the include 10-wacom.fdi file is working good for this device... but my device is different then original reported that had fdi problems.  Thanks for making this package available for testing since using linuxwacom is hard to do without major patching in Fedora 12.

2) Since this is not a release package, I would like to hijack bug report somewhat.  Also, I've not yet figured were else to report this problem to.  0.10.3 driver has a couple of bugs in it related to Capacity setting on Bamboo P&T.  As a possible work around to bugs, I attempted to use "xsetwacom set xxx Capacity 3" but got an error message about mismatched formats.

The reason is for error is because xf86-input-wacom-0.10.3/tools/xsetwacom.c defines prop_format for "Capacity" as 8 where as src/wcmXCommands.c defines it as 32.  I verified changing xsetwacom.c to size 32 allows me to set Capacity although it is probably better change to make driver use 8.

I'm not sure were to report these upstream bugs.  linuxwacom-devel?

Comment 25 Thomas Spura 2010-03-01 00:21:28 UTC
A bit progress:

With a self made xfce livecd based on 2010-02-27 F-13 this is 'working':

- When touching with a finger, the display remembers where it was clicked and on the next click (or with any movement), the rectangle on the desktop (which picks files) changes, but never goes away.
Like left click and moving around or left click and remebering the click point and then suddendly changing the rectangle again.
There is no change to left click manual with the mouse anymore after that.

- The only possibility to get 'back to normal mode' is clicking with the pen:
  When doing that, the mouse is placed approximately at 2 cm from above and 2 cm from the left on the desktop. It's not possible to do anything else with the pen, except getting the cursor to that point.
(No right click with pen detected, no movement...)


Please tell me, how I can help you with this any further...

Comment 26 Chris Bagwell 2010-03-01 01:36:01 UTC
- Button Releases.

Can you add a new log of evtest/evtest-capture?  If this is a new install without evtest, then you can also use "xinput test <devnum>" and you can get <devnum> of your wacom from output of "xinput list".

This will help prove that the touch screen is sending a left-button-press but never a left-button release when you remove your finger.

The pen work around works because it sends a left-button-release eventually and X doesn't really care who sent it.

- pointer offset issues.

Your last Xorg.0.log attachment shows me something interesting.  You are running into a bug similar to one on Bamboo P&T's.  On your non-wacom device, it shares touch, stylus, and eraser all on the same /dev/input/event?.  The current code is getting confused and only reading some tablet size information related to the Touch part only.

Notice in log file that your stylus has bottomX=0 bottomY=0.  That probably explains some of your stylus offset issues.

Real Wacom devices will put stylus and touch on separate input devices and yours is combining them and greatly complicates things.  I'm not sure how to find the resolution of your touch screen versus stylus screen... or if they are considered the same on your device.  You may be able to help here by running evtest/xinput test and touching bottom right corner of screen with finger and stylus and see if they report similar X/Y values.

Now that you seem to have Fedora specific HAL/fdi issues resolved, we are mostly discussing xf86-input-wacom generic issues.  It may be better to move conversation over to linuxwacom.sourceforge.net mailing list.

Comment 27 Chris Bagwell 2010-03-01 02:55:05 UTC
I checked kernel driver for hid-ntrig.c (which appears what device HP tx2 have).  A future kernel will split the stylus and pen into separate input devices which will work with xf86-input-wacom much better.  Its not really worth debugging its interaction with xf86-input-wacom further until you get access to those kernel updates.

There is a mention in commit about also splitting single touch and multi touch into different input devices as well; which concerns me.  It could confuse current xf86-input-wacom gesture support.  But the kernel authors intent may be to use with xf86-input-evdev or similar.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=943ed464f3722de0569cf41ba6ec094768ac046d

It looks like its in active development so no telling what the interface will turn out as in the end or what xf86-input-* its meant to work with.

Comment 28 Thomas Spura 2010-03-01 13:19:31 UTC
Unfortunately, this seems to not be in the F-13 kernel.

But in the devel kernel is also another commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=dbf2b17de505d390b5ecf5b5944fc0c88f6d66fe

I'll do a new devel boot image and...

(In reply to comment #26)
> Now that you seem to have Fedora specific HAL/fdi issues resolved, we are
> mostly discussing xf86-input-wacom generic issues.  It may be better to move
> conversation over to linuxwacom.sourceforge.net mailing list.    

...ping on the mailinglist with the other infos requested, once I've done anything.

Comment 29 Bug Zapper 2010-03-15 13:03:30 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 30 Bug Zapper 2011-06-02 17:26:56 UTC
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 31 Thomas Spura 2011-06-03 07:46:36 UTC
This mostly worked last time I tried.

(Don't use that HP laptop anymore, because it overheats...)


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