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
Created attachment 369861 [details] Xorg.log
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.
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
Created attachment 370175 [details] new xorg.log with installed fdi file
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 :)
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 ;) )
<?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.
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
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
Created attachment 370254 [details] lshal output with something.fdi Now wacom is in lshal.
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.
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)
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
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.
Created attachment 373049 [details] Xorg.log recognising stylus/touch, but not working
interesting - this device used to work with linuxwacom? can you run evtest against it and attach the output here?
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.
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.
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.*).
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
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.
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
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.
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?
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...
- 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.
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.
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.
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
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
This mostly worked last time I tried. (Don't use that HP laptop anymore, because it overheats...)