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>] [day] [month] [year] [list]
Date:	Tue, 3 Dec 2013 15:08:21 +0100 (CET)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Nestor Lopez Casado <nlopezcasad@...itech.com>
Cc:	Olivier Gay <ogay@...itech.com>,
	"open list:HID CORE LAYER" <linux-input@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Mathieu Meisser <mmeisser@...itech.com>
Subject: Re: [PATCH] HID: logitech-dj: add HIDRAW dependency in Kconfig

On Tue, 3 Dec 2013, Nestor Lopez Casado wrote:

> > > <3>[  210.131988] logitech-djreceiver 0003:046D:C52B.0005: claimed by
> > > neither input, hiddev nor hidraw
> > > <3>[  210.132202] logitech-djreceiver 0003:046D:C52B.0005:
> > > logi_dj_probe:hid_hw_start returned error
> > >
> > > In logi_dj_probe, we call hid_hw_start with HID_CONNECT_DEFAULT
> > > argument and if hidraw driver is not present, the call fails and we
> > > return an error in logi_dj_probe.
> > >
> > > > It's clear that without hidraw it's not possible to change the pairing
> > > > from userspace, but I fail to see why probing the receiver should be
> > > > affected?
> > >
> > > As of today, hid-logitech-dj.c depends on hidraw API to work. All HID
> > > reports sent to control / configure the receiver are sent using hidraw
> > > API. That's why we fail logi_dj_probe if we cannot connect to hidraw.
> >
> > Hmm, so unifying receiver is not claimed by hid-input at all?
> > (HID_CONNECT_DEFAULT also contains HID_CONNECT_HIDINPUT) How so?
> >
> > (again, I will not be able to test it with my receiver up until the day
> > after tomorrow).
> >
> The unifying receiver has 3 usb interfaces. When hid-logitech-dj driver is
> loaded, interfaces 0 and 1 are discarded.
> 
> Interface 2 consists of a hid class interface with 3 collections, each of
> which sports the 'vendor' usage, thus, there is no reason for hid_input to
> claim any of them. On the other hand, hidraw has no issue in claiming the
> collections, even if they are 'vendor'. As of today, hid-logitech-dj uses
> hidraw api to send configuration/control reports to interface 2 of the
> Unifying receiver.
> 
> Without the hid-logitech-dj driver, interfaces 0 and 1 are claimed by
> hid-input, as they correspond to a keyboard and a mouse. But that is not
> relevant to the discussion.

Ah, indeed, that's the part I forgot and will find out only when I have my 
receiver handy again.

Thanks for the explanation, now it all makes sense. I will be queuing the 
patch, with probably slightly more verbose changelog.

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ