Bug 109750
Summary: | [rawhide] wacom tablets don't work without manual configuration | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | J. J. Ramsey <jjramsey> | ||||||
Component: | linuxwacom | Assignee: | Aristeu Rozanski <arozansk> | ||||||
Status: | CLOSED RAWHIDE | QA Contact: | |||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | rawhide | CC: | arnout.lok, cedric.laczny, dafydd, info, luya, mattdm, peter.hutterer | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2009-03-27 05:46:03 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 464826 | ||||||||
Attachments: |
|
Description
J. J. Ramsey
2003-11-11 16:22:21 UTC
Can you confirm this bug with Fedora Core 2 or better Fedora Core 3 test 1. What is the output of cat /proc/bus/input/devices "Can you confirm this bug with Fedora Core 2?" Yes. "What is the output of cat /proc/bus/input/devices?" Can't answer that. I'm running Slack right now (and I'm about to replace my PC with an eMac soon). Sorry. BTW, I don't remember the kernel or hotplug in Fedora Core having problems detecting the make and model of the Graphire, but rather that the Fedora-specific configuration tools don't do anything special for Wacom tablets. Created attachment 102869 [details]
output of cat /proc/bus/input/devices
This is the output of cat /proc/bus/input/devices of a machine with
2.6.7-1.478smp. It's the first time I connected the tablet to that machine, so
no special initializations in place.
Created attachment 102870 [details]
output of kudzu -p -b usb
Same machine, this time output of kudzu -p -b usb
rhpl.mouse.Mouse().probedList [..., Desc: WACOM CTE-430-UV3.1-4 Driver: genericwheelusb Device: input/mice ] Could the version of the bug be updated to fc6test1 ? Wacom tablets still aren't configured properly in (nowadays) xorg.conf. But I don't exactly know if its still being handled by redhat-config-mouse. Fedora Core 1 is maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thanks! NOTE: Fedora Core 1 is reaching the final end of support even by the Legacy project. After Fedora Core 6 Test 2 is released (currently scheduled for July 26th), there will be no more security updates for FC1. Please use these next two weeks to upgrade any remaining FC1 systems to a current release. Please try again with FC6t2 and let me know if you are still seeing problems. We have done a lot of work on X configuration for this release, and chances are this is being handled correctly now. I just tried it on FC6t2 with my Wacom Graphire 2 (usb) but it doesn't work as expected, it still just works as an mouse in relative mode instead of absolute mode. I manually had to enter the following to x.org: Section "ServerLayout" ... InputDevice "stylus" "SendCoreEvents" EndSection Section "InputDevice" Driver "wacom" Identifier "stylus" Option "Device" "/dev/input/wacom" Option "Type" "stylus" Option "USB" "on" EndSection taken from the documentation from linuxwacom (http://linuxwacom.sourceforge.net/index.php/howto/x11) Note, that this is quite an minimal configuration only to put the 'stylus' in absolute mode. The mouse and eraser configuration isn't added (yet). Also note that /dev/input/wacom isn't automatically generated due to bug 196923. The underlying problem here is that we need a concept of how the wacom driver fits in with X autoconfiguration. rhpxl can't just write out the block above in all configuration files because that's going in the opposite direction than we want, but not including that block means it doesn't work for people when they hot plug their device. We could add code to rhpxl to modify the config file when a tablet is attached, but that will require restarting X for the changes to take effect, the user to do something specific to have the tablet configured, and for it to be plugged in at that time. So driver guys, what direction should we take here to ensure a hotplug-like experience for these devices? What's the plan for having input devices configured without having to restart X when they are plugged in? there's a daemon called 'wdaemon' wrote to solve the hotplug issue until X.org supports hotplugging properly. I'll integrate it on Fedora. Nevermind, it won't solve the problem here This problem still exists more or less on F7. The only decent fix for this is x.org properly supporting input device hotplugging. I have no idea when this will happen. Tested Wacom Graphire 2 on Fedora 8. Fedora recognized the tablet but cannot enable other Wacom components. Manual configuration in xorg.conf to enable stylus, eraser, and tablet support is still required. Judging the date of the bug, it is a long overdue especially for artists and designers who use Wacom tablet. Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Luya, Daniel, J.J. Ramsey, now X.org has hotplugging capability and should detect and enable the tablet use without requiring manual configuration. Can you give it a try and tell how it goes? Thanks, Tested on both Fedora 9 and Rawhide. On Fedora 9, tablet acts as mouse (still requires manual configuration) and cursors move erratically. On rawhide, wacom tablet completely froze.. Apparently, Fedora version of linuxwacom (0.7.9-7) lags behind upsteam version 0.8.0-3 (production) and 0.8.1-4 (development) which support latest X.org 7.3. I've also tested it on an rawhide, and after plugging in my wacom-tablet while running X I can't use it. The Xorg.0.log speaks about configuring a type? Where should I do that? ==Xorg.0.log== T(II) config/hal: Adding input device Wacom Graphire2 4x5 (II) LoadModule: "wacom" (II) Loading /usr/lib/xorg/modules/input//wacom_drv.so (II) Module wacom: vendor="X.Org Foundation" compiled for 4.3.99.902, module version = 1.0.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 2.0 (II) Wacom driver level: 47-0.7.9-8 $ (EE) Wacom Graphire2 4x5: No type or invalid type specified. Must be one of stylus, cursor, eraser, or pad (EE) PreInit returned NULL for "Wacom Graphire2 4x5" (EE) config/hal: NewInputDeviceRequest failed ==/var/log/messages== Sep 4 17:28:35 csixten kernel: usb 1-1: new low speed USB device using uhci_hcd and address 2 Sep 4 17:28:35 csixten kernel: usb 1-1: configuration #1 chosen from 1 choice Sep 4 17:28:35 csixten kernel: usb 1-1: New USB device found, idVendor=056a, idProduct=0011 Sep 4 17:28:35 csixten kernel: usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Sep 4 17:28:35 csixten kernel: usb 1-1: Product: ET-0405A-UV2.0-3 Sep 4 17:28:35 csixten kernel: usb 1-1: Manufacturer: WACOM Sep 4 17:28:36 csixten kernel: input: Wacom Graphire2 4x5 as /devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1:1.0/input/input9 Sep 4 17:28:36 csixten kernel: usbcore: registered new interface driver wacom Sep 4 17:28:36 csixten kernel: wacom: v1.48:USB Wacom Graphire and Wacom Intuos tablet driver Tested Wacom Graphire2 on Fedora 10. The good news is the stylus works fine without xorg.conf, but the eraser does not. Should that be fixed, I think this bug can be closed. "Wacom isn't yet suited well for hotplugging, as we need three devices off one kernel device, but HAL only reports this device once. This needs fixing in the driver." This sentence comes from the HAL device description file (10-linuxwacom.fdi) that is distributed with Fedora 10. It describes to me in more or less human words what the problem is with the wacom autoconfiguration and where it should be fixed. I add this information here, because it took me a long time to figure out why things couldn't be automatically configured and this makes it more or less clear. The next question of course is: who will fix the driver ? Will this be done by a Fedora developer ? Or is this passed on to the linuxwacom project ? Or will it be coordinated between these two parties ? As I see it, as long as this "driver issue" isn't sorted out, it won't be possible to properly configure wacom tablets via evdev and HAL. As long as this is the case, wacom tablets will have to be manually excluded from evdev handling and manually configured in xorg.conf. I worked in a patch to fix this on xorg-server 1.5 but it's still not complete. for xorg-server 1.6, it'll be easier to do that. I just don't have time to work on the patch right now. Fixed with linuxwacom-0.8.2.2-8 *** Bug 465349 has been marked as a duplicate of this bug. *** Will that update be ported to Fedora 10 from #464826? Just confirming that this works in rawhide. I had to reconfigure my input devices in Gimp and Inkscape; I think it gave them a different name than I had manually configured. Not sure. In any case, works great after reconfiguration. (In reply to comment #23) > Fixed with linuxwacom-0.8.2.2-8 Could you please give an example how to specify the options in the fdi-file in order to use stylus, eraser and cursor at the same time? Thanks. You don't need any options, just take the stock fdi file that comes with linuxwacom. All devices are added separately, so they should all be useable at the same time. The problem is, that I have gentoo and the most recent linuxwacom-package doesn't seem to be yet available. I used the one from the linuxwacom-project homepage (v. 0.8.3.2) and took the relevant driver (wacom_drv.so) and copied it to the appropriate directory. Xorg0.log showed the correct loading of this driver, but again, only the stylus was usable. I know this here is not a gentoo-place, so I hoped for a general solution. Unfortunately, there is no fdi-file provided, neither with the original driver nor the gentoo-package. Could someone please post it here or send it to my email? Just like comment 26, I can confirm this works in rawhide (past FC11 Beta). For future reference by others, I just wish to add that with the new X11 evdev input model,wacdump will no longer work while X11 is running. This is expected behavior because the evdev driver grabs the wacom device and won't allow other programs to access it, including wacdump. I thought this to be a bug until I read Aristeu Rozanski's explanation in bug #475944 comment 14. I you wish to use wacdump to test the wacom kernel driver, you should make sure X11 is not running (eg boot in runlevel 3). In X11, you can use xidump to verify if your tablet is working. Use xidump --list to get a list of devices you can use with xidump. (In reply to comment #31) > Just like comment 26, I can confirm this works in rawhide (past FC11 Beta). > > For future reference by others, I just wish to add that with the new X11 evdev > input model,wacdump will no longer work while X11 is running. This is expected > behavior because the evdev driver grabs the wacom device and won't allow other > programs to access it, including wacdump. evdev stopped grabbing devices with version 2.1 - the one currently in F10. F11 ships version 2.2 and doesn't grab either. That's nice, I didn't know that. And indeed I can confirm that wacdump works on F10 when running it from a text console. However, it doesn't seem to work when running it from a console INSIDE the X11 session, like: Via the start menu, open a terminal window, become root and then run wacdump /dev/input/wacom Where is the difference ? If you're using the wacom driver (the default if linuxwacom is installed) the device is indeed grabbed. If you're using the evdev driver then the device is not grabbed. just check your Xorg.log to be sure. |