Re: [DIGImend-users] Genius MousePen i608X Gimp 2.8RC1 issue
Brought to you by:
spb_nick
From: Nikolai K. <sp...@gm...> - 2012-04-18 20:54:41
|
Hi David, On 04/17/2012 05:48 PM, Favux ... wrote: > The Wacom X driver xf86-input-wacom gets around this issue by > appending the device type (stylus, eraser, cursor, touch, pad) to the > parent (descriptive) device name from the kernel. So in 'xinput list' > you see things like: > ⎜ ↳ Wacom Bamboo 2FG 4x5 Pen stylus id=8 [slave pointer (2)] > ⎜ ↳ Wacom Bamboo 2FG 4x5 Finger touch id=9 [slave pointer (2)] > > ⎜ ↳ Wacom Bamboo 2FG 4x5 Pen eraser id=13 [slave pointer (2)] > ⎜ ↳ Wacom Bamboo 2FG 4x5 Finger pad id=14 [slave pointer (2)] > > Notice for this BambooPT tablet there are two parent devices exported > from the kernel, the 'Wacom Bamboo 2FG 4x5 Pen' and the 'Wacom Bamboo > 2FG 4x5 Finger'. > > This permits identifying specific input tools with snippets in a > custom .conf file in /etc/X11/xorg.conf.d (with X Server 1.10) or in > the xsetwacom run-time commands. > The problem with using the device ID # is that the # can change with a hot > plug so it can't be relied on from session to session. So, this is the problem the GIMP developers are trying to solve. I should've thought about it. I think the only way this could be solved currently, at least to some extent is by matching device name and "type". I'm not sure, though, how much type information is really available to GIMP. It could actually be that the GIMP has started interpreting the absolute mouse of i608X as an extended input device and this leads to confusion when configuring it. > Unfortunately this does create a issue with parent device input tool, > usually the stylus. The X Server makes the MatchProduct match before the > input tools are appended so Options can not be applied to the stylus input > tool separately, instead they are tablet wide. Sure, because the driver is assigned as a result of matching only. > This was suppose to be solved by negative matches being > allowed in X Server 1.11, which should allow matching to the parent > device/stylus. Don't know if it was, because I haven't investigated > this yet. A quick look at 'man xorg.conf.d' doesn't seem to indicate > negative matching has been added in X Server 1.11.3. How is this matching supposed to work? > This was a problem for the WizardPen driver also. It could not handle > either a mouse or two devices and if the kernel said a mouse was > allegedly present the stylus didn't work. Sorry, I'm not sure I understand this. > That's why Martin Owen's > (DoctorMo) wizardpen.conf had a snippet matching to the mouse and > ignoring it. Originally: > Driver " " > Peter Hutterer thought that was quite "original" Apparently using a > null driver was an unanticipated usage. So later changed to the > "conventional": > Option "Ignore" "on" That was an interesting approach, for sure. > So from my perspective this may be a feature missing from evdev. But > not an evdev bug per se. I think I should look into the kernel code and see if I could assign names to input devices created from report IDs. Maybe I could assign the suffixes to them there. Sincerely, Nick |