|
Bugzilla – Full Text Bug Listing |
| Summary: | wacom does not select correct event device automatically | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 10.3 | Reporter: | Martin Pley <martin> |
| Component: | X.Org | Assignee: | Matthias Hopf <mhopf> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <xorg-maintainer-bugs> |
| Severity: | Normal | ||
| Priority: | P4 - Low | CC: | eich, ms, sndirsch, urboss |
| Version: | Beta 1 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Beta-Customer | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
Matthias wanted to have a look at this to handle this similar to the synaptics driver. You're talking about the wacom driver, don't you? Yes, I wanted to look at wacom and evdev. Medium priority only, though. *** Bug 196456 has been marked as a duplicate of this bug. *** *** Bug 196456 has been marked as a duplicate of this bug. *** The evdev driver actually *can* match multiple devices, if configured by the "Name" or "Phys" option, not by "Device". I cited the according options in bug #220237 (com.9). Marcus, you complained that evdev uses "Name", which it shouldn't due to some policy. Where's this policy from? I couldn't find "Name" in *any* driver except evdev and vmware... I think we should start testing evdev more soon, bug reports on the list are getting fewer... Information required from Marcus, not reporter... Problem is that evdev doesn't allow Name to be a free format. Name must
match the string from /proc/bus/input/devices at least as a glob. As you
mentioned name is not used in any other driver this is because name is
a free and optional string and exactly like this it is used in sax2.
If I set Name to the correct string it will appear on the GUI as Name
and it is assumed you can select this name from some list. Even more worse
selecting a device from the list results in some nice name for "Name"
but of course will not match the input/devices information. If the Name for
example is something like "Logitech USB Receiver" one might set
Option Name "Logitech*"
and on the GUI you will see Mouse: Logitech* ... looks like a joke ;)
Anyway it is bad style to use Name here It is impossible to give the
device a free formatted name string using evdev. Additionally Name is
concerned to be the best method for setting up the device independent
of its location.
I would suggest to use another key here or provide a synonym.
It would at least make my life a lot easier
Thanks
(In reply to comment #7) > Problem is that evdev doesn't allow Name to be a free format. Name must Of course not. Name is just another option that influences the behavior of the driver. > match the string from /proc/bus/input/devices at least as a glob. As you > mentioned name is not used in any other driver this is because name is > a free and optional string and exactly like this it is used in sax2. What do you mean by "free and optional"? I've never read anything like that, and that as exactly what I was asking for. So as far as I understand you are using "Name" for internal representation inside sax, to distinguish different devices - just like the introduction of the "SaX*" options in the Device section for storing additional parameters needed by sax. In that case something like "SaXname" would probably be better, because the chance that a driver uses this option name in the future is *much* lower. > I would suggest to use another key here or provide a synonym. > It would at least make my life a lot easier "Name" is used upstream, and I *strongly* argue against changing upstream semantics. Except if it is documented somewhere that "Name" is an option without value to the drivers, in which case it would be an upstream bug. I don't use Name as a sax option otherwise I would have named it SaXName. Option "Name" and Option "Vendor" has been used in the same way for all sections since sax2 exists. The README.mouse was the basis for setting up the options of the InputDevice sections. I think this README doesn't exist anymore. The data behind Vendor and Name has never been used to influence the driver setup it always was used as information only. The evdev driver is the first one which changed that. - Anyway it doesn't work on 10.2 with my USB gaming mouse so we are talking about something broken - I was asking for an alternative option to Name not for a replacement shouldn't be that hard I think and wouldn't change upstream semantics. (In reply to comment #9) > Option "Name" and Option "Vendor" has been used in the same way for all > sections since sax2 exists. The README.mouse was the basis for setting up > the options of the InputDevice sections. I think this README doesn't exist > anymore. It's still in git. Too bad it isn't installed by default any longer :-(. I just check it, as well as the old version of XFree86 - the option "Name" isn't mentioned there at all. The string "vendor" isn't occuring anywhere either. You probably intermixed this with "Identifier"? > The data behind Vendor and Name has never been used to influence the driver > setup it always was used as information only. The evdev driver is the first > one which changed that. No, the data behind Vendor and Name never used to influence any driver because no driver had an option with this name. You could say this about option "XAFGXV" as well, but just because an option isn't used yet doesn't mean it can be used arbitrarily by an external tool. > - Anyway it doesn't work on 10.2 with my USB gaming mouse so we are talking > about something broken Definitely. We can very much agree here :) > - I was asking for an alternative option to Name not for a replacement > shouldn't be that hard I think and wouldn't change upstream semantics. IMHO very problematic, because that would - again - let others argue that we do something different from upstream. I could try discussing this with the edev developers (about including an option that overrides Name), but they would argue that we should rather fix the broken Name option. I wouldn't blame them, as I agree that an option that uses a standard name like "Name" shouldn't be used for storing configuration tool internal information. evdev can select the devices correctly, so changing summary to wacom only. JFYI. This is still present in 10.3 and makes it impossible to add remove a usb tablet without losing extended input events in X (like pressure) is there any timeline on this? Apparently, nobody works on that upstream. Unfortunately, I cannot give you a timeline for this, there are still more pressing issues. Fixed in stable (10.3 is out, so this won't show up there), I'll try to push this upstream. Wacom is now scanning the event devices on startup if "Device" is missing or set to "auto-dev" (similar to other drivers). This is not input hotplug support, still. BTW - the configuration sax2 creates is improved with 10.3, as it uses /dev/input/by-id/* devices, which should be the same after a reset. They won't live through a suspend/resume cycle, though, which the patched driver should be able to survive (tested and (finally) works). Also, the device configured by sax2 is wrong, it should be the *-event-mouse device, not the *-mouse device (-event missing). Also, of all configured devices only the wacom mouse will create mouse events. But as long as nobody understands the complete use case of wacom devices here, I don't have a better clue. So for now I would suggest changing the configuration of "Device" statically to "auto-dev" for STABLE. Let's see whether we can make input hotplug work in the next cycle. Do you agree, Marcus? I have no problem to set the device option as "auto-dev" wacom is configured by profile wacom and wacom.pl the dynamic part tries to find the real device the tablet is connected to. We can deactivate that and set a fixed value "auto-dev" As the autodetection seems to work well, I would very much appreciate this. Please leave the bug assigned to me, so I don't forget to push the changes upstream. I'd like to test this, too. Can I find src.rpm's or rpms for 10.3 somewhere? http://download.opensuse.org/repositories/home:/sndirsch:/xorg74/openSUSE_10.3/ Update - xorg-x11-server - xorg-x11-driver-video - xorg-x11-driver-input - x11-input-wacom When the tablet is not plugged in on X-server startup and the device is configured as "auto-dev" the screen becomes black, I can't switch back to console and the disk runs out of space because the xorg.log becomes huge. So for now, I will modify my copy of sax to use the persistent name of the tablet. Matthias, did you finally contact Ping Cheng <pingc@wacom.com>, so your patch can be included upstream? Small comment: I have changed my Sax2 package in [1] to use simply /dev/wacom for usb wacom device because of a report of a user, which reported, that this device is used by other distributions and seems to be more stable while suspend cycles than /dev/input devices. [1] https://build.opensuse.org/package/show?project=home%3Adkukawka&package=x11-input-wacom (In reply to comment #21 from Martin Pley) > When the tablet is not plugged in on X-server startup and the device is > configured as "auto-dev" the screen becomes black, I can't switch back to > console and the disk runs out of space because the xorg.log becomes huge. Can you attach a snippet of the xorg.log in that case? Martin, any news on this one? (In reply to comment #22 from Stefan Dirsch) > Matthias, did you finally contact Ping Cheng <pingc@wacom.com>, so your patch > can be included upstream? Tried again. Ping Cheng <pingc@wacom.com> (wacom driver author) confirmed, that Matthias' patch will be included in the next wacom driver release. Therefore closing as fixed. |
The event inerface of usb-tablets changes - depending on order of insertion of USB-devices. Because of that you have to change the xorg.conf everytime. My suggestion: Add something like BUS="usb", SYSFS{idPVendor}="056a", KERNEL="event*", NAME="input/%k", SYMLINK="input/tablet" to a /etc/udev/rules.d/46-tablet.rules And change the detection of interface in sax.