diff mbox

HID: logitech-dj: add HIDRAW dependency in Kconfig

Message ID 1386026244-21553-1-git-send-email-ogay@logitech.com (mailing list archive)
State New, archived
Delegated to: Jiri Kosina
Headers show

Commit Message

Olivier Gay Dec. 2, 2013, 11:17 p.m. UTC
hid-logitech-dj.c driver needs hidraw to work correctly. Without
hidraw, hid-logitech-dj.c fails during probe() and Logitech
Unifying devices HID reports aren't recognized.

Signed-off-by: Olivier Gay <ogay@logitech.com>
Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com>
Signed-off-by: Mathieu Meisser <mmeisser@logitech.com>
---

Hi everyone,

this adds a HIDRAW dependency in Kconfig for hid-logitech-dj.c
driver. The driver uses hidraw and needs it to work correctly.

Without hidraw if a Logitech Unifying device is plugged, the driver
fails during probe() and Logitech Unifying devices HID reports aren't
recognized. This has been the cause of some confusion. Some Linux and
Android distributions had HID_LOGITECH_DJ enabled without HIDRAW and
the Unifying mice and keyboards would simply not work (no cursor
tracking / no keyboard typing).

Best regards,

Olivier

 drivers/hid/Kconfig | 1 +
 1 file changed, 1 insertion(+)

Comments

Jiri Kosina Dec. 3, 2013, 7:53 a.m. UTC | #1
On Tue, 3 Dec 2013, Olivier Gay wrote:

> hid-logitech-dj.c driver needs hidraw to work correctly. Without
> hidraw, hid-logitech-dj.c fails during probe() and Logitech
> Unifying devices HID reports aren't recognized.
> 
> Signed-off-by: Olivier Gay <ogay@logitech.com>
> Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com>
> Signed-off-by: Mathieu Meisser <mmeisser@logitech.com>
> ---
> 
> Hi everyone,
> 
> this adds a HIDRAW dependency in Kconfig for hid-logitech-dj.c
> driver. The driver uses hidraw and needs it to work correctly.
> 
> Without hidraw if a Logitech Unifying device is plugged, the driver
> fails during probe() and Logitech Unifying devices HID reports aren't
> recognized. This has been the cause of some confusion. Some Linux and
> Android distributions had HID_LOGITECH_DJ enabled without HIDRAW and
> the Unifying mice and keyboards would simply not work (no cursor

Hi Oliver,

I don't have my receiver with me at the moment, so can't really verify -- 
how exactly does it fail during 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?

Thanks,
Olivier Gay Dec. 3, 2013, 10:30 a.m. UTC | #2
>On Tue, Dec 3, 2013 at 8:53 AM, Jiri Kosina <jkosina@suse.cz> wrote:
> I don't have my receiver with me at the moment, so can't really verify --
> how exactly does it fail during probe()?

Hi Jiri,

Without hidraw driver, we get this:

<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.

Best regards,

Olivier
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jiri Kosina Dec. 3, 2013, 12:51 p.m. UTC | #3
On Tue, 3 Dec 2013, Olivier Gay wrote:

> Without hidraw driver, we get this:
> 
> <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).

Thanks,
Nestor Lopez Casado Dec. 3, 2013, 2:03 p.m. UTC | #4
Sorry, no html now.


On Tue, Dec 3, 2013 at 3:01 PM, Nestor Lopez Casado
<nlopezcasad@logitech.com> wrote:
>
>
>
>
> On Tue, Dec 3, 2013 at 1:51 PM, Jiri Kosina <jkosina@suse.cz> wrote:
>>
>> On Tue, 3 Dec 2013, Olivier Gay wrote:
>>
>> > Without hidraw driver, we get this:
>> >
>> > <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.
>>
>>
>> Thanks,
>>
>> --
>> Jiri Kosina
>> SUSE Labs
>
> Cheers,
> -nestor
>
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jiri Kosina Dec. 3, 2013, 2:08 p.m. UTC | #5
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.
diff mbox

Patch

diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 329fbb9..c8a66b9 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -344,6 +344,7 @@  config HID_LOGITECH
 
 config HID_LOGITECH_DJ
 	tristate "Logitech Unifying receivers full support"
+	depends on HIDRAW
 	depends on HID_LOGITECH
 	---help---
 	Say Y if you want support for Logitech Unifying receivers and devices.