lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 21 Feb 2017 16:53:11 -0800
From:   Jason Gerecke <jason.gerecke@...om.com>
To:     Jiri Kosina <jikos@...nel.org>,
        Benjamin Tissoires <benjamin.tissoires@...hat.com>
CC:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andrew Duggan <aduggan@...aptics.com>,
        Ping Cheng <pinglinux@...il.com>,
        "linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
        Tobita Tatsunosuke <tobita.tatsunosuke@...om.co.jp>
Subject: Re: [PATCH] HID: rmi: fallback to generic/multitouch if hid-rmi is
 not built (was Re: [GIT PULL] HID for 4.11)

One of the main reasons Wacom devices have historically required a
special driver is that the HID descriptors on their branded devices are
useless. A generic driver would only know the length of a report; no
information about the contents or layout is actually provided by the
hardware. The latest generation of Wacom tablets somewhat improves the
situation, but its still not good enough for the devices to be at all
useful with an e.g. hid-generic fallback. The hardware now provides a
full descriptor, but every usage is in a Vendor Defined usage page. We
can use Wacom's usage table definitions to implement "generic Wacom"
support for these new devices (which is exactly what we did in 4.10),
but no vendor-agnostic generic driver will understand the usages.

Wacom's embedded tablet PC sensors are a different story. These devices
*do* provide generic HID descriptors and it should be possible to have
hid-generic power them as a fallback. That said, it seems that Wacom is
moving away from their 0x56A vendor ID for these embedded sensors to a
new 0x2D1F vendor ID. This VID isn't recognized by any of the existing
Wacom kernel drivers and is (as I understand) intended be a way to allow
new hardware to work with the hid-generic driver.

Jason Gerecke, Linux Software Engineer
Wacom Technology Corporation
tel: 360-896-9833 ext. 229 (direct) / fax: 360-896-9724
http://www.wacom.com

On 02/21/2017 01:03 PM, Jiri Kosina wrote:
> On Tue, 21 Feb 2017, Benjamin Tissoires wrote: > >> Well, Wacom devices use to need a special driver, but the latest
>> generation should somewhat be able to work without a driver (IIRC).
>> > > I vaguely recall this wasn't the case at all for the older >
generations I've had my hands on, and it wasn't just the matter of >
HID_QUIRK_NO_INIT_REPORTS quirk. > > But anyway ... that wasn't reported
as a regression for quite some > time, so let's defer to what Ping and
Jason have to say regarding > protocol/driver compatibility. > > I'll be
pushing the RMI fix to Linus soon. > > Thanks, >


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ