On Tue, Mar 15, 2016 at 02:51:57PM -0700, Jason Gerecke wrote: > On 03/09/2016 05:41 PM, Peter Hutterer wrote: > > On Fri, Mar 04, 2016 at 09:30:03AM -0800, Jason Gerecke wrote: > >> The Wacom Bluetooth Keyboard matches the "Wacom class" and so is bound to > >> the > >> xf86-input-wacom driver. This driver is not designed to work with > >> keyboards, > >> so we add a new configuration snippet which rebinds it to the "evdev" > >> driver. > >> This driver is likely present on most systems and will handle keyboards > >> just > >> fine. > >> > >> Note that simply adding 'MatchIsKeyboard "false"' to our existing snippets > >> would cause devices like the Cintiq 24HDT Pad and Cintiq 27QHDT Pad from > >> binding to our driver since both are recognized as (partial) keyboards due > >> to the presence of KEY_* kernel events. > >> > >> Fixes: https://sourceforge.net/p/linuxwacom/bugs/294/ > >> Fixes: https://github.com/linuxwacom/xf86-input-wacom/issues/1 > >> > >> Signed-off-by: Jason Gerecke <jason.gere...@wacom.com> > >> --- > >> conf/50-wacom.conf | 15 +++++++++++++++ > >> 1 file changed, 15 insertions(+) > >> > >> diff --git a/conf/50-wacom.conf b/conf/50-wacom.conf > >> index fc0eed2..019fd95 100644 > >> --- a/conf/50-wacom.conf > >> +++ b/conf/50-wacom.conf > >> @@ -57,3 +57,18 @@ Section "InputClass" > >> Option "Button2" "3" > >> EndSection > >> > >> +# https://sourceforge.net/p/linuxwacom/bugs/294/ > >> +# "Wacom Bluetooth Keyboard mistakenly bound to xf86-input-wacom driver" > >> +# > >> +# - Force keyboard-only devices like the Wacom Bluetooth Keyboard > >> +# to re-bind to the "evdev" driver. Some systems may need to use > >> +# the "libinput" driver (or maybe even the ancient "kbd") instead. > >> +Section "InputClass" > >> + Identifier "Wacom Keyboard class" > >> + MatchDriver "wacom" > >> + MatchIsKeyboard "true" > >> + MatchIsTablet "false" > >> + MatchIsTouchscreen "false" > >> + MatchIsTouchpad "false" > >> + Driver "evdev" > >> +EndSection > > > > Can we make this a bit more specific to this device (through a MatchProduct > > or vid/pid matching). Also, i notice we don't use MatchIsTablet in our > > We could, but I don't much like the idea of having to keep making > one-off edits for an entire class of device.
how often do you release those though? :) newer X servers will have a NoMatch directive which we may be able to use for this, though I guess we'll have to maintain some backwards compat for quite a while. > > current configuration snippets, maybe we should start using those? Except > > for touch screens I believe this will be set on all devices we care about > > but shouldn't be set on the keyboard? > > > > Cheers, > > Peter > > > > Using MatchIsTablet in our snippets should be fine (bypasssing this > whole keyboard issue in the process), but we'd also have to duplicate > the rules for MatchIsTouchscreen and MatchIsTouchpad variations. The > resulting set of rules would be a bit fragile, but might be fine given > how little we touch them. I wonder: can we use MatchTag somehow? we can assign tags via udev and then match on those, maybe this is a way to get around it? Cheers, Peter ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140 _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
