Change component as it may required change by linuxwacom configuration.

This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

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

Please install evtest and run it as root against the device file.  The device
file is /dev/input/eventX, where X is a number. You can get the right device
file by looking into /proc/bus/input/devices. Then attach the output here.

Right now, the device is picked up by synaptics and it probably doesn't know
how to handle this properly. I've seen a bug float past on the hal list where
some touchscreens get marked as touchpads, if so, this is probably fixed by
hal 0.5.13-10. 
http://koji.fedoraproject.org/koji/buildinfo?buildID=141835

Same problem on my tx2520ew, touch is not working, i have newest hal 0.5.13-10.
I`ve seen many similiar posts on forums some problem may be wide ranged.

please attach the evtest output for this device (note that you have to VT switch away from X to get the touches to show up).

Created attachment 373709 [details]
Output of evtest event9 with touch, stylus and eraser events

Created attachment 373710 [details]
Output of evtest event10 with touch, stylus and eraser events

why evtest doesn`t report eraser events?

why evtest doesn`t report eraser events? they are reported as touch

The device is failing the PreInit

grep input /var/log/Xorg.0.log
(II) The server relies on HAL to provide the list of input devices.
(II) config/hal: Adding input device AT Translated Set 2 keyboard
(II) Loading /usr/lib64/xorg/modules/input/evdev_drv.so
(**) AT Translated Set 2 keyboard: Device: "/dev/input/event5"
(II) XINPUT: Adding extended input device "AT Translated Set 2 keyboard" (type: KEYBOARD)
(II) config/hal: Adding input device Macintosh mouse button emulation
(**) Macintosh mouse button emulation: Device: "/dev/input/event4"
(II) XINPUT: Adding extended input device "Macintosh mouse button emulation" (type: MOUSE)
(II) config/hal: Adding input device SynPS/2 Synaptics TouchPad
(II) Loading /usr/lib64/xorg/modules/input/synaptics_drv.so
(**) Option "Device" "/dev/input/event8"
(II) XINPUT: Adding extended input device "SynPS/2 Synaptics TouchPad" (type: TOUCHPAD)
(II) config/hal: Adding input device HID 1b96:0001
(**) Option "Device" "/dev/input/event7"
(EE) PreInit failed for input device "HID 1b96:0001"
(II) config/hal: Adding input device HID 1b96:0001
(**) Option "Device" "/dev/input/event6"
(EE) PreInit failed for input device "HID 1b96:0001"
(II) config/hal: Adding input device CNF8038
(**) CNF8038: Device: "/dev/input/event10"
(II) XINPUT: Adding extended input device "CNF8038" (type: KEYBOARD)
(II) config/hal: Adding input device Sleep Button
(**) Sleep Button: Device: "/dev/input/event2"
(II) XINPUT: Adding extended input device "Sleep Button" (type: KEYBOARD)
(II) config/hal: Adding input device Power Button
(**) Power Button: Device: "/dev/input/event1"
(II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD)
(II) config/hal: Adding input device Video Bus
(**) Video Bus: Device: "/dev/input/event9"
(II) XINPUT: Adding extended input device "Video Bus" (type: KEYBOARD)
(II) config/hal: Adding input device Power Button
(**) Power Button: Device: "/dev/input/event0"
(II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD)

Brennan - please attach the full Xorg.log, grep cut off a few vital pieces.

I`ve got solution provided by pooly8888 http://forums.fedoraforum.org/showthread.php?t=234468

Edit file:
/usr/share/hal/fdi/policy/20thirdparty/10-linuxwacom.fdi

Before </deviceinfo> section insert:
<device>
    <match key="input.originating_device" contains="if0">
	<match key="info.product" contains="Wacom">
		<merge key="input.x11_driver" type="string">wacom</merge>
		<merge key="input.x11_options.Type" type="string">stylus</merge>
		<merge key="info.product" type="string">stylus</merge>
		<append key="info.callouts.add" type="strlist">hal-setup-wacom</append>
          	<append key="wacom.types" type="strlist">eraser</append>
		<merge key="input.x11_options.BottomY" type="string">16466</merge>
		<merge key="input.x11_options.BottomX" type="string">26271</merge>
		<merge key="input.x11_options.TopY" type="string">183</merge>
		<merge key="input.x11_options.TopX" type="string">397</merge>
	</match>
    </match>
  </device>
  <device>
    <match key="input.originating_device" contains="if1">
	<match key="info.product" contains="Wacom">
		<merge key="input.x11_driver" type="string">wacom</merge>
		<merge key="input.x11_options.Type" type="string">touch</merge>
		<merge key="info.product" type="string">touch</merge>
		<merge key="input.x11_options.BottomY" type="string">3909</merge>
		<merge key="input.x11_options.BottomX" type="string">3947</merge>
		<merge key="input.x11_options.TopY" type="string">185</merge>
		<merge key="input.x11_options.TopX" type="string">186</merge>
	</match>
    </match>
  </device>

Created attachment 375627 [details]
Correct 10-linuxwacom.fdi which properly recognizes touch

Please try the xorg-x11-drv-wacom driver as well. It's seen a fair bit of autoconfiguration improvements, so this bug may already be fixed. Ping was testing against ISDV4 devices and claimed they worked.

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


Brennan, from what I can see you have a different device, please file a separate bugreport.

I updated with following with Ref of comment #3 and #14
hal-0.5.13-10.fc12.x86_64
xorg-x11-drv-wacom-0.10.2-1.fc12.x86_6

but still touch is not working.
Software: F12 Fresh installed, updated and then update these packages
Now trying to apply comment #12 and #13

comment #12 and comment 13 are not working for tx2z

reproducible on rawhide, with xorg-x11-drv-wacom
comment#13 helps to fix the issue.

possibly - http://sourceforge.net/tracker/index.php?func=detail&aid=2891575&group_id=69596&atid=525126

hmm, for some reason the above stopped working. evtest does report the event correctly. The patch from comment#18 does not help, either.

I tried with fresh install and it is _working_ with following packages:
xorg-x11-drv-wacom-0.10.4-1.fc13.x86_64
xorg-x11-drv-radeonhd-1.3.0-5.3.20100101git.fc13.x86_64

(basic xorg-x11-drv-ati was not working, so used radeonhd)

Moving to Rawhide (to get working with Fedora 13).

wacom 0.10.4 in rawhide and F12 are identical, so the theory goes that 0.10.4 in F12 should fix this issue too. unless there's a wacom kernel patch that's in rawhide that I missed.

Created attachment 388522 [details]
logs

log files, lshal, evtest and xorg logs .
Using 2.6.33-0.26.rc6.git1.fc13.i686, updated from F12 ( livecd install )

Created attachment 389984 [details]
evtest capture

kernel logs
usb 7-2: New USB device found, idVendor=1b96, idProduct=0001
usb 7-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
input: HID 1b96:0001 as /devices/pci0000:00/0000:00:14.5/usb7/7-2/7-2:1.0/input/input7
ntrig 0003:1B96:0001.0001: input,hiddev96,hidraw0: USB HID v1.10 Device [HID 1b96:0001] on usb-0000:00:14.5-2/input0
input: HID 1b96:0001 as /devices/pci0000:00/0000:00:14.5/usb7/7-2/7-2:1.1/input/input8
ntrig 0003:1B96:0001.0002: input,hiddev97,hidraw1: USB HID v1.10 Device [HID 1b96:0001] on usb-0000:00:14.5-2/input1


With the X.Org X Server 1.7.99.901 (1.8.0 RC 1)

xorg-x11-server-Xorg-1.7.99.901-6.20100215.fc13.i686
xorg-x11-drv-wacom-0.10.4-4.20100219.fc13.i686 ( rebuilt from rawhide )

(**) Option "Device" "/dev/input/event7"
(II) "HID 1b96:0001": type not specified, assuming 'stylus'.
(II) "HID 1b96:0001": other types will be automatically added.
(**) "HID 1b96:0001": always reports core events
(II) "HID 1b96:0001": hotplugging dependent devices.
(EE) No input driver/identifier specified (ignoring)
(EE) No input driver/identifier specified (ignoring)
(II) "HID 1b96:0001": hotplugging completed.
(II) XINPUT: Adding extended input device ""HID 1b96:0001"" (type: STYLUS)
(--) "HID 1b96:0001": using pressure threshold of 15 for button 1
(--) "HID 1b96:0001": Wacom Unknown USB tablet speed=38400 maxX=9600 maxY=7200 maxZ=256 resX=1016 resY=1016  tilt=enabled
(--) "HID 1b96:0001": top X=0 top Y=0 bottom X=9600 bottom Y=7200 resol X=1016 resol Y=1016
(II) config/udev: Adding input device "HID 1b96:0001" (/dev/input/mouse2)
(**) "HID 1b96:0001": Applying InputClass "Wacom serial class"
(**) Option "Device" "/dev/input/mouse2"
(EE) "HID 1b96:0001": wcmDeviceTypeKeys unable to ioctl USB key bits.
(II) UnloadModule: "wacom"
(EE) PreInit returned NULL for ""HID 1b96:0001""
(II) config/udev: Adding input device "HID 1b96:0001" (/dev/input/event8)
(**) "HID 1b96:0001": Applying InputClass "evdev tablet catchall"
(**) "HID 1b96:0001": Applying InputClass "Wacom serial class"
(**) Option "Device" "/dev/input/event8"
(II) "HID 1b96:0001": type not specified, assuming 'stylus'.
(II) "HID 1b96:0001": other types will be automatically added.
(**) "HID 1b96:0001": always reports core events
(II) "HID 1b96:0001": hotplugging dependent devices.
(EE) No input driver/identifier specified (ignoring)
(EE) No input driver/identifier specified (ignoring)
(II) "HID 1b96:0001": hotplugging completed.
(II) XINPUT: Adding extended input device ""HID 1b96:0001"" (type: STYLUS)
(--) "HID 1b96:0001": using pressure threshold of 15 for button 1
(--) "HID 1b96:0001": Wacom Unknown USB tablet speed=38400 maxX=9600 maxY=7200 maxZ=256 resX=1016 resY=1016  tilt=enabled
(--) "HID 1b96:0001": top X=0 top Y=0 bottom X=9600 bottom Y=7200 resol X=1016 resol Y=1016
(II) config/udev: Adding input device "HID 1b96:0001" (/dev/input/mouse3)
(**) "HID 1b96:0001": Applying InputClass "Wacom serial class"
(**) Option "Device" "/dev/input/mouse3"
(EE) "HID 1b96:0001": wcmDeviceTypeKeys unable to ioctl USB key bits.
(II) UnloadModule: "wacom"
(EE) PreInit returned NULL for ""HID 1b96:0001""

seems to have hit ubuntu also 
https://bugs.launchpad.net/ubuntu/+source/xf86-input-wacom/+bug/510311

I'm getting the same issue, same laptop, Fedora 12 amd64...  This is with updated firmware (Windows 7 firmware).

***As a note to anyone working on this/replying, they changed the way that the device reports to the OS when they changed the firmware from vista to win7, if I'm not mistaken...  I've been told/seen it work/had it work in Ubuntu 9.10 with vista firmware out of box, though not exactly well...***

# evtest /dev/input/event6
Input driver version is 1.0.0
Input device ID: bus 0x3 vendor 0x1b96 product 0x1 version 0x110
Input device name: "N-trig DuoSense"
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)
    Event code 0 (X)
      Value   1000
      Min        0
      Max     9600
    Event code 1 (Y)
      Value   1000
      Min        0
      Max     7200
    Event code 24 (Pressure)
      Value      0
      Min        0
      Max      256
    Event code 48 (Touch Major)
      Value      0
      Min        0
      Max     9600
    Event code 49 (Touch Minor)
      Value      0
      Min        0
      Max     7200
    Event code 52 (Orientation)
      Value      0
      Min        0
      Max        1
    Event code 53 (Position X)
      Value      0
      Min        0
      Max     9600
    Event code 54 (Position Y)
      Value      0
      Min        0
      Max     7200
  Event type 4 (Misc)
    Event code 4 (ScanCode)
Testing ... (interrupt to exit)
(I didn't add the below because I'm not particularly sure how to save tty output...)

(In reply to comment #26)

> Testing ... (interrupt to exit)
> (I didn't add the below because I'm not particularly sure how to save tty
> output...)    

Just use >> a.file or > a.file

>> will append > will rewrite

so
evtest /dev/input/event6 > evtest.out

Created attachment 397618 [details]
Output of evtest on HP tx2

xorg-x11-drv-wacom-0.10.4-5.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/xorg-x11-drv-wacom-0.10.4-5.fc13

The update above only matches the N-Trig section against /dev/input/event*, reducing the errors in the log file.

Can someone please state what the current status is? Is it working at all or only partially? I've got a lot of log files here but I lost track of whether the device even works at this point (Brennan, I need your Xorg.log please, your device is different)

I consider this as a duplicate of #538036, because I also have an tx2...


There is massive work on the kernel and at least the kernel from f14 is needed.

Status on f13 is descriped at:
https://bugzilla.redhat.com/show_bug.cgi?id=538036#c25

Status on f14:
- pen works with left click
- pen does not work with right click
- left click with finger does not work
- moving is wrong:
  When the mouse pointer is under the finger, and the finger is moved about 1 cm in any direction, the mouse pointer is moved 2 cm in the same direction.
  e.g. finger 1 cm up -> mouse 1 cm *above* finger and not under anymore

Unfortunately I have some problems generating an own livecd (when I boot into, I have an root pwd, which I'm not aware of) and therfore can't run any tests atm.
I hope to get this fixed and get more information, what exactly is going wrong and upload some evtest outputs...


Currently, I don't think it's a good idea to continue testing on f13, because some urgent parts from the kernel is missing, so you need to work around that.
(Also a bit descriped in: https://bugzilla.redhat.com/show_bug.cgi?id=538036#c26)
It would be the best to wait for a kernel 2.6.34.

yay ! works find with kernel-2.6.34-0.4.rc0.git2.fc14.i686, and xorg-x11-drv-wacom-0.10.4-5.20100219.fc13.i686.rpm


multitouch seems to drive the cursor crazy, and finger touch seems to act relative instead of absolute.

(In reply to comment #30)
> The update above only matches the N-Trig section against /dev/input/event*,
> reducing the errors in the log file.
> 
> Can someone please state what the current status is? Is it working at all or
> only partially? I've got a lot of log files here but I lost track of whether
> the device even works at this point (Brennan, I need your Xorg.log please, your
> device is different)    

Current state of Fedora 12 (from where I sit):
HP TouchSmart tx2-1025dx (as far as I know, same as tx2z)
N-Trig Duosense Touchscreen

Capabilities (None of which Currently are Working):
     Pen (Note:  HP TouchSmarts do NOT have eraser functionality)
     Pen Right Click Button
     Single Touch w/ Pressure Sensitivity
     Multi Touch (up to four fingers on Windows 7) w/ Pressure Sensitivity
     Operating System-Based Gestures (such as zooming in and out, rotate, etc)

Installed Software:
     Kernel: 2.6.31.12-174.2.22.fc12.x86_64
     HAL Daemon: hal-0.5.13-9.fc12.x86_64
     Wacom Driver: xorg-x11-drv-wacom-0.10.4-2.fc12.x86_64
*******************************************************************************

@Ritz:
With that Kernel/wacom combo, are you having any system stability issues?  I might try that myself if you aren't *too* bad off...

Hi @Michael Daum

  Using an F13 system, with kernel-2.6.34-0.4.rc0.git2.fc14.i686, and
xorg-x11-drv-wacom-0.10.4-5.20100219.fc13.i686.rpm ( rebuilt from source ) . system works fine, except for the quirks described by comment#31 . hal is deprecated ( atleast wrt xorg ) with latest build on F13 .

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

xorg-x11-drv-wacom-0.10.4-5.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

(In reply to comment #32)
> yay ! works find with kernel-2.6.34-0.4.rc0.git2.fc14.i686, and
> xorg-x11-drv-wacom-0.10.4-5.20100219.fc13.i686.rpm
> 
> 
> multitouch seems to drive the cursor crazy, and finger touch seems to act
> relative instead of absolute.

what's the xinput --list-props output for the touch device? I think only the cursor should be defined relative by default, the rest _should_ be absolute.

Hi @Peter

> multitouch seems to drive the cursor crazy, and finger touch seems to act
> relative instead of absolute.

fixed with kernel from f14, and evdev scratch build you has provided. multitouch now is ignored by apps ( probably due to lack of support ), will test this with F14, and update.

Desktop Live CD Fedora 13, worse experience.
Booted - Fine
Mouse Click - working
Touch Screen - Working (just once)
Now Mouse Click - Random behavior

Try to Install to Hard Drive - touch screen few time, try to use keyboard or mouse. mouse will not able to click anything, keyboard Randomly work.

(In reply to comment #39)
> Desktop Live CD Fedora 13, worse experience.
> Booted - Fine
> Mouse Click - working
> Touch Screen - Working (just once)
> Now Mouse Click - Random behavior
> 
> Try to Install to Hard Drive - touch screen few time, try to use keyboard or
> mouse. mouse will not able to click anything, keyboard Randomly work.    

That's funny...  When I installed it to the hard drive, the laptop worked fine...  Until I touched the screen.  After I touched the screen, the mouse would work, but the left click button would not.  To fix that problem, I would tap the screen with the pen, which would then fix the issue.  Please note, however, that the pen itself did NOT work at all, it just moved the pointer on the screen to a certain position about 100x100 pixels in from the top left.

Also, I was not able to click or drag using my finger on the screen.

After install and update machine with following packages:
xorg-x11-drv-wacom-0.10.6-1.fc13.x86_64
kernel-2.6.33.4-95.fc13.x86_64

Mouse/touchpad - Working till
you touch screen once.
Cursor work, but LMB/RMB is NOt working, only keyboard is working.

installing F14 kernel to check results....

with F14 kernel (kernel-2.6.34-11.fc14.x86_64), it is working perfect,
without any configuration
Touchpad - Left/Right Click works
Finger - Click works, Zoom/multi-touch Not
Pen -Click works, Right Click - Not

So, should I move this bug for Fedora 14 or any plan for Fedora 13?

Well if it's actually working in FC14, wouldn't that negate the necessity for a bug report against it there?

I vote to keep this within FC13, though I do think it's rather dependent on the newer kernel/wacom drivers being back-ported...  As FC13 was _just_ finally released, I could see it within the realm of possibility that those two packages be would upgraded before FC14, especially seeing at vanilla kernel 2.6.35 is already being worked on at this point...

(In reply to comment #43)
> Well if it's actually working in FC14, wouldn't that negate the necessity for a
> bug report against it there?
> 
> I vote to keep this within FC13, though I do think it's rather dependent on the
> newer kernel/wacom drivers being back-ported...  As FC13 was _just_ finally
> released, I could see it within the realm of possibility that those two
> packages be would upgraded before FC14, especially seeing at vanilla kernel
> 2.6.35 is already being worked on at this point...    

I don't think it is being worked now, but certainly we will leave this open for any future updates of the input driver.

following this article...
http://rkvsraman.blogspot.com/2008/10/gotcha-for-hp-touchsmart-pc.html
This is my evtest output 
###############
evtest /dev/input/event7
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 256 (Btn0)
    Event code 320 (ToolPen)
    Event code 321 (ToolRubber)
    Event code 330 (Touch)
    Event code 331 (Stylus)
    Event code 333 (Tool Doubletap)
  Event type 3 (Absolute)
    Event code 0 (X)
      Value      0
      Min        0
      Max     9600
    Event code 1 (Y)
      Value      0
      Min        0
      Max     7200
    Event code 24 (Pressure)
      Value      0
      Min        0
      Max      256
    Event code 48 (Touch Major)
      Value      0
      Min        0
      Max        1
    Event code 49 (Touch Minor)
      Value      0
      Min        0
      Max        1
    Event code 52 (Orientation)
      Value      0
      Min        0
      Max        1
    Event code 53 (Position X)
      Value      0
      Min        0
      Max     9600
    Event code 54 (Position Y)
      Value      0
      Min        0
      Max     7200
  Event type 4 (Misc)
    Event code 4 (ScanCode)
Testing ... (interrupt to exit)
#####################
what to enter in xorg.conf not sure... 
it says nextwindow.. but i guesss here the device is OEM : HID 1b96:0001
http://www.nextwindow.com/support/application_notes/app_working_under_linux_2.html

i guess we are near the solution..
after this is solved we can make a rpm so easy for future..

(In reply to comment #44)
> I don't think it is being worked now, but certainly we will leave this open for
> any future updates of the input driver.    

I can't work on this ATM for lack of time. If some-one wants to supply some backported patches that would be much appreciated. Essentially look for n-trig patches in the 2.6.33..2.6.34 cycle and try to apply them to the F-13 kernel rpm file. That should just be it, afaict.

but what about the xorg.conf file... if we made changes to kernel still this has to be added is'nt it.. the input device and the event

generally you don't need to edit xorg.conf options anymore. Once the kernel patches are in, I'll update the rules/xorg.conf.d snippets as needed for this device class.

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

Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.