Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1300588 > unrolled thread

Re: [Patch-V2 1/6] INPUT: xpad: Add minimal support for Logitech G920 Wheel

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [Patch-V2 1/6] INPUT: xpad: Add minimal support for Logitech  G920 Wheel Benjamin Tissoires <benjamin.tissoires@redhat.com> - 2016-01-04 11:00 +0100
    Re: [Patch-V2 1/6] INPUT: xpad: Add minimal support for Logitech  G920 Wheel madcatxster@devoid-pointer.net - 2016-01-04 13:50 +0100
    Re: [Patch-V2 1/6] INPUT: xpad: Add minimal support for Logitech  G920 Wheel Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2016-01-05 02:10 +0100
    Re: [Patch-V2 1/6] INPUT: xpad: Add minimal support for Logitech  G920 Wheel Jiri Kosina <jikos@kernel.org> - 2016-01-06 15:40 +0100
      Re: [Patch-V2 1/6] INPUT: xpad: Add minimal support for Logitech  G920 Wheel Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2016-01-07 02:50 +0100
        Re: [Patch-V2 1/6] INPUT: xpad: Add minimal support for Logitech  G920 Wheel "Simon Wood" <simon@mungewell.org> - 2016-01-07 05:30 +0100
        Re: [Patch-V2 1/6] INPUT: xpad: Add minimal support for Logitech  G920 Wheel Michal Malý <madcatxster@devoid-pointer.net> - 2016-01-08 00:00 +0100
          Re: [Patch-V2 1/6] INPUT: xpad: Add minimal support for Logitech G920 Wheel Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2016-01-08 00:00 +0100
            Re: [Patch-V2 1/6] INPUT: xpad: Add minimal support for Logitech  G920 Wheel Michal Malý <madcatxster@devoid-pointer.net> - 2016-01-08 00:10 +0100
        Re: [Patch-V2 1/6] INPUT: xpad: Add minimal support for Logitech  G920 Wheel Jiri Kosina <jikos@kernel.org> - 2016-01-08 10:20 +0100

#1300588 — Re: [Patch-V2 1/6] INPUT: xpad: Add minimal support for Logitech G920 Wheel

On Dec 10 2015 or thereabouts, Dmitry Torokhov wrote:
> On Thu, Dec 10, 2015 at 9:08 AM, Benjamin Tissoires
> <benjamin.tissoires@redhat.com> wrote:
> > On Dec 09 2015 or thereabouts, Dmitry Torokhov wrote:
> >> On Wed, Dec 9, 2015 at 5:23 PM, Dmitry Torokhov
> >> <dmitry.torokhov@gmail.com> wrote:
> >> > On Thu, Nov 19, 2015 at 10:31 AM, Dmitry Torokhov
> >> > <dmitry.torokhov@gmail.com> wrote:
> >> >> On Thu, Nov 19, 2015 at 02:50:51PM +0100, Jiri Kosina wrote:
> >> >>> On Thu, 12 Nov 2015, Simon Wood wrote:
> >> >>>
> >> >>> > When plugged in the Logitech G920 wheel starts with USBID 046d:c261
> >> >>> > and behaviors as a vendor specific class. If a 'magic' byte sequence
> >> >>> > is sent the wheel will detach and reconnect as a HID device with the
> >> >>> > USBID 046d:c262.
> >> >>> >
> >> >>> > Signed-off-by: Simon Wood <simon@mungewell.org>
> >> >>>
> >> >>> Adding Dmitry to CC.
> >> >>>
> >> >>> Dmitry, I am planning to take this through my tree together with the rest
> >> >>> of the actual HID support for that device if you Ack this.
> >> >>
> >> >> Hmm, I have an incoming series for xbox that night clash with this... If
> >> >> you'll put it in a clean branch off 4.3 I'd pull it and then get more
> >> >> changes on top.
> >> >>
> >> >> Can we also change the subject as it is not about adding a minimal
> >> >> support. Something like "Input: xpad - switch Logitech G920 Wheel into
> >> >> HID mode"
> >> >>
> >> >> Otherwise:
> >> >>
> >> >> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> >> >
> >> > Hmm, looking sat this some more why are we waiting to switch device
> >> > mode until after userspace opens input device instead of when we are
> >> > executing driver probe()?
> >> >
> >>
> >> Actually, thinking about it even more, why do we want to have this in
> >> xpad.c? Have HID module handle both IDs and switch to HID mode if we
> >> want HID to handle this device. I think we should revert/drop this
> >> patch.
> >>
> >
> > Hi Dmitry,
> 
> Hi Benjamin,
> 
> >
> > IIRC, last time I saw an XBox-like controller, it doesn't register as a
> > HID device at all. SO I think It will be hard to switch it into the HID
> > mode from HID directly.
> > Simon, can you confirm that the device does not contains any references
> > to HID while in the XBox mode (lsusb -v should give enough information).
> >
> > Switching the device during probe in xpad.c makes a lot of sense
> > however.
> 
> It makes as much sense doing it in xpad as doing it from a random USB
> network driver. I mean the only reason we are doing it from xpad is
> because of name and the fat that it has usb_driver structure. Nobody
> stops you from creating a tiny USB stub driver in hid portion that
> would probe the "non-hid" device and switch it over to hid.
> 

Jiri, I *think* this commit still is in your next pull request for
Linus. We might want to drop it before it hits Linus' tree.

We can still keep the HID work in place even if the device is not
switched into the HID protocol at plug.

Simon, do you mind looking into Dmitry's suggestion of having a clean,
small usb device which loads itself when the G920 is plugged in and
switches it immediately into the HID mode?

Cheers,
Benjamin



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

[toc] | [next] | [standalone]

#1300731

DQoNCk9uIE1vbiBKYW4gNCAxMDo1NToyNCAyMDE2IEdNVCswMTAwLCBCZW5qYW1pbiBUaXNzb2ly
ZXMgd3JvdGU6DQo+IE9uIERlYyAxMCAyMDE1IG9yIHRoZXJlYWJvdXRzLCBEbWl0cnkgVG9yb2to
b3Ygd3JvdGU6DQo+ID4gT24gVGh1LCBEZWMgMTAsIDIwMTUgYXQgOTowOCBBTSwgQmVuamFtaW4g
VGlzc29pcmVzDQo+ID4gPGJlbmphbWluLnRpc3NvaXJlc0ByZWRoYXQuY29tPiB3cm90ZToNCj4g
PiA+IE9uIERlYyAwOSAyMDE1IG9yIHRoZXJlYWJvdXRzLCBEbWl0cnkgVG9yb2tob3Ygd3JvdGU6
DQo+ID4gPj4gT24gV2VkLCBEZWMgOSwgMjAxNSBhdCA1OjIzIFBNLCBEbWl0cnkgVG9yb2tob3YN
Cj4gPiA+PiA8ZG1pdHJ5LnRvcm9raG92QGdtYWlsLmNvbT4gd3JvdGU6DQo+ID4gPj4gPiBPbiBU
aHUsIE5vdiAxOSwgMjAxNSBhdCAxMDozMSBBTSwgRG1pdHJ5IFRvcm9raG92DQo+ID4gPj4gPiA8
ZG1pdHJ5LnRvcm9raG92QGdtYWlsLmNvbT4gd3JvdGU6DQo+ID4gPj4gPj4gT24gVGh1LCBOb3Yg
MTksIDIwMTUgYXQgMDI6NTA6NTFQTSArMDEwMCwgSmlyaSBLb3NpbmEgd3JvdGU6DQo+ID4gPj4g
Pj4+IE9uIFRodSwgMTIgTm92IDIwMTUsIFNpbW9uIFdvb2Qgd3JvdGU6DQo+ID4gPj4gPj4+DQo+
ID4gPj4gPj4+ID4gV2hlbiBwbHVnZ2VkIGluIHRoZSBMb2dpdGVjaCBHOTIwIHdoZWVsIHN0YXJ0
cyB3aXRoIFVTQklEIDA0NmQ6YzI2MQ0KPiA+ID4+ID4+PiA+IGFuZCBiZWhhdmlvcnMgYXMgYSB2
ZW5kb3Igc3BlY2lmaWMgY2xhc3MuIElmIGEgJ21hZ2ljJyBieXRlIHNlcXVlbmNlDQo+ID4gPj4g
Pj4+ID4gaXMgc2VudCB0aGUgd2hlZWwgd2lsbCBkZXRhY2ggYW5kIHJlY29ubmVjdCBhcyBhIEhJ
RCBkZXZpY2Ugd2l0aCB0aGUNCj4gPiA+PiA+Pj4gPiBVU0JJRCAwNDZkOmMyNjIuDQo+ID4gPj4g
Pj4+ID4NCj4gPiA+PiA+Pj4gPiBTaWduZWQtb2ZmLWJ5OiBTaW1vbiBXb29kIDxzaW1vbkBtdW5n
ZXdlbGwub3JnPg0KPiA+ID4+ID4+Pg0KPiA+ID4+ID4+PiBBZGRpbmcgRG1pdHJ5IHRvIENDLg0K
PiA+ID4+ID4+Pg0KPiA+ID4+ID4+PiBEbWl0cnksIEkgYW0gcGxhbm5pbmcgdG8gdGFrZSB0aGlz
IHRocm91Z2ggbXkgdHJlZSB0b2dldGhlciB3aXRoIHRoZSByZXN0DQo+ID4gPj4gPj4+IG9mIHRo
ZSBhY3R1YWwgSElEIHN1cHBvcnQgZm9yIHRoYXQgZGV2aWNlIGlmIHlvdSBBY2sgdGhpcy4NCj4g
PiA+PiA+Pg0KPiA+ID4+ID4+IEhtbSwgSSBoYXZlIGFuIGluY29taW5nIHNlcmllcyBmb3IgeGJv
eCB0aGF0IG5pZ2h0IGNsYXNoIHdpdGggdGhpcy4uLiBJZg0KPiA+ID4+ID4+IHlvdSdsbCBwdXQg
aXQgaW4gYSBjbGVhbiBicmFuY2ggb2ZmIDQuMyBJJ2QgcHVsbCBpdCBhbmQgdGhlbiBnZXQgbW9y
ZQ0KPiA+ID4+ID4+IGNoYW5nZXMgb24gdG9wLg0KPiA+ID4+ID4+DQo+ID4gPj4gPj4gQ2FuIHdl
IGFsc28gY2hhbmdlIHRoZSBzdWJqZWN0IGFzIGl0IGlzIG5vdCBhYm91dCBhZGRpbmcgYSBtaW5p
bWFsDQo+ID4gPj4gPj4gc3VwcG9ydC4gU29tZXRoaW5nIGxpa2UgIklucHV0OiB4cGFkIC0gc3dp
dGNoIExvZ2l0ZWNoIEc5MjAgV2hlZWwgaW50bw0KPiA+ID4+ID4+IEhJRCBtb2RlIg0KPiA+ID4+
ID4+DQo+ID4gPj4gPj4gT3RoZXJ3aXNlOg0KPiA+ID4+ID4+DQo+ID4gPj4gPj4gQWNrZWQtYnk6
IERtaXRyeSBUb3Jva2hvdiA8ZG1pdHJ5LnRvcm9raG92QGdtYWlsLmNvbT4NCj4gPiA+PiA+DQo+
ID4gPj4gPiBIbW0sIGxvb2tpbmcgc2F0IHRoaXMgc29tZSBtb3JlIHdoeSBhcmUgd2Ugd2FpdGlu
ZyB0byBzd2l0Y2ggZGV2aWNlDQo+ID4gPj4gPiBtb2RlIHVudGlsIGFmdGVyIHVzZXJzcGFjZSBv
cGVucyBpbnB1dCBkZXZpY2UgaW5zdGVhZCBvZiB3aGVuIHdlIGFyZQ0KPiA+ID4+ID4gZXhlY3V0
aW5nIGRyaXZlciBwcm9iZSgpPw0KPiA+ID4+ID4NCj4gPiA+Pg0KPiA+ID4+IEFjdHVhbGx5LCB0
aGlua2luZyBhYm91dCBpdCBldmVuIG1vcmUsIHdoeSBkbyB3ZSB3YW50IHRvIGhhdmUgdGhpcyBp
bg0KPiA+ID4+IHhwYWQuYz8gSGF2ZSBISUQgbW9kdWxlIGhhbmRsZSBib3RoIElEcyBhbmQgc3dp
dGNoIHRvIEhJRCBtb2RlIGlmIHdlDQo+ID4gPj4gd2FudCBISUQgdG8gaGFuZGxlIHRoaXMgZGV2
aWNlLiBJIHRoaW5rIHdlIHNob3VsZCByZXZlcnQvZHJvcCB0aGlzDQo+ID4gPj4gcGF0Y2guDQo+
ID4gPj4NCj4gPiA+DQo+ID4gPiBIaSBEbWl0cnksDQo+ID4gDQo+ID4gSGkgQmVuamFtaW4sDQo+
ID4gDQo+ID4gPg0KPiA+ID4gSUlSQywgbGFzdCB0aW1lIEkgc2F3IGFuIFhCb3gtbGlrZSBjb250
cm9sbGVyLCBpdCBkb2Vzbid0IHJlZ2lzdGVyIGFzIGENCj4gPiA+IEhJRCBkZXZpY2UgYXQgYWxs
LiBTTyBJIHRoaW5rIEl0IHdpbGwgYmUgaGFyZCB0byBzd2l0Y2ggaXQgaW50byB0aGUgSElEDQo+
ID4gPiBtb2RlIGZyb20gSElEIGRpcmVjdGx5Lg0KPiA+ID4gU2ltb24sIGNhbiB5b3UgY29uZmly
bSB0aGF0IHRoZSBkZXZpY2UgZG9lcyBub3QgY29udGFpbnMgYW55IHJlZmVyZW5jZXMNCj4gPiA+
IHRvIEhJRCB3aGlsZSBpbiB0aGUgWEJveCBtb2RlIChsc3VzYiAtdiBzaG91bGQgZ2l2ZSBlbm91
Z2ggaW5mb3JtYXRpb24pLg0KPiA+ID4NCj4gPiA+IFN3aXRjaGluZyB0aGUgZGV2aWNlIGR1cmlu
ZyBwcm9iZSBpbiB4cGFkLmMgbWFrZXMgYSBsb3Qgb2Ygc2Vuc2UNCj4gPiA+IGhvd2V2ZXIuDQo+
ID4gDQo+ID4gSXQgbWFrZXMgYXMgbXVjaCBzZW5zZSBkb2luZyBpdCBpbiB4cGFkIGFzIGRvaW5n
IGl0IGZyb20gYSByYW5kb20gVVNCDQo+ID4gbmV0d29yayBkcml2ZXIuIEkgbWVhbiB0aGUgb25s
eSByZWFzb24gd2UgYXJlIGRvaW5nIGl0IGZyb20geHBhZCBpcw0KPiA+IGJlY2F1c2Ugb2YgbmFt
ZSBhbmQgdGhlIGZhdCB0aGF0IGl0IGhhcyB1c2JfZHJpdmVyIHN0cnVjdHVyZS4gTm9ib2R5DQo+
ID4gc3RvcHMgeW91IGZyb20gY3JlYXRpbmcgYSB0aW55IFVTQiBzdHViIGRyaXZlciBpbiBoaWQg
cG9ydGlvbiB0aGF0DQo+ID4gd291bGQgcHJvYmUgdGhlICJub24taGlkIiBkZXZpY2UgYW5kIHN3
aXRjaCBpdCBvdmVyIHRvIGhpZC4NCj4gPiANCj4gDQo+IEppcmksIEkgKnRoaW5rKiB0aGlzIGNv
bW1pdCBzdGlsbCBpcyBpbiB5b3VyIG5leHQgcHVsbCByZXF1ZXN0IGZvcg0KPiBMaW51cy4gV2Ug
bWlnaHQgd2FudCB0byBkcm9wIGl0IGJlZm9yZSBpdCBoaXRzIExpbnVzJyB0cmVlLg0KPiANCj4g
V2UgY2FuIHN0aWxsIGtlZXAgdGhlIEhJRCB3b3JrIGluIHBsYWNlIGV2ZW4gaWYgdGhlIGRldmlj
ZSBpcyBub3QNCj4gc3dpdGNoZWQgaW50byB0aGUgSElEIHByb3RvY29sIGF0IHBsdWcuDQo+IA0K
PiBTaW1vbiwgZG8geW91IG1pbmQgbG9va2luZyBpbnRvIERtaXRyeSdzIHN1Z2dlc3Rpb24gb2Yg
aGF2aW5nIGEgY2xlYW4sDQo+IHNtYWxsIHVzYiBkZXZpY2Ugd2hpY2ggbG9hZHMgaXRzZWxmIHdo
ZW4gdGhlIEc5MjAgaXMgcGx1Z2dlZCBpbiBhbmQNCj4gc3dpdGNoZXMgaXQgaW1tZWRpYXRlbHkg
aW50byB0aGUgSElEIG1vZGU/DQo+IA0KPiBDaGVlcnMsDQo+IEJlbmphbWluDQo+IA0KDQpIaSBn
dXlzLA0KDQpzaW5jZSBJIGZlZWwgcHJldHR5IGJhZCBmb3Igbm90IGNvbnRyaWJ1dGluZyB0byB0
aGUgcHJvamVjdCAodG9vIG11Y2ggUGhEIHN0dWZmKSBJJ2QgZ2xhZGx5IGxvb2sgaW50byB0aGUg
VVNCIHN0dWIgZHJpdmVyIGlzIFNpbW9uIGlzIHRvbyBidXlzIG9yIG90aGVyd2lzZSB1bmFibGUg
dG8gZG8gaXQgaGltc2VsZi4gSWYgSSB1bmRlcnN0YW5kIHRoZSBpc3N1ZSB0aGUgaWRlYSBpcyB0
byBoYXZlIGEgc2ltcGxlIG1vZHVsZSB0aGF0IHdvdWxkIHBpY2sgdXAgYSBkZXZpY2UgdGhhdCBh
dCBmaXJzdCBhcHBlYXJzIGFzIGEgZ2VuZXJpYyBVU0IgZGV2aWNlLCBkbyB0aGUgbmVjZXNzYXJ5
IGluaXRpYWxpemF0aW9uIGFuZCBsZXQgdGhlIGRldmljZS1zcGVjaWZpYyBkcml2ZXIgdGFrZSBv
dmVyIGZyb20gdGhlcmU/DQoNCk1pY2hhbA==
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1301215

Hi Simon,

On Mon, Jan 04, 2016 at 01:05:35PM -0700, Simon Wood wrote:
> 
> On Mon, 4 Jan 2016 02:55:24 -0700, Benjamin Tissoires wrote:
> your next pull request for
> > Linus. We might want to drop it before it hits Linus' tree.
> > 
> > We can still keep the HID work in place even if the device is not
> > switched into the HID protocol at plug.
> > 
> > Simon, do you mind looking into Dmitry's suggestion of having a clean,
> > small usb device which loads itself when the G920 is plugged in and
> > switches it immediately into the HID mode?
> 

> Hi,
>
> As noted 'xpad.c' sends the magic bytes to switch the G920 wheel into
> HID mode, the wheel then detaches and reconnects as a HID+ device
> handled by 'logitech-hidpp.c'.
> 
> I'd like to point that up to this point the wheel _is_ a Xbox One
> control device, that speaks some undocumented protocol from Microsoft.
> To my mind xpad is the correct place to send the magic bytes.

OTOH one can argue if it does not speak protocol that xpad understands
then it does not belong in xpad.

Currently xpad.ko "weighs" at 44K (in my configuration), this is steep
price for sending 1 packet to the device. I am certain that adding a
skeleton usb driver into hid module will be much cheaper.

> 
> It is possible that at some future time that the Xpad devs will
> understand the protocol enough sufficiently to do useful stuff with
> the wheel. In an earlier version of the patch I had a param to disable
> the 'switch to HID', and that might be resurrected.

This is way down the road. We may even end up with a brand new driver
for it, not xpad. And if/when that happens we'll be able to drop hid
potion.

Thanks.

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

[toc] | [prev] | [next] | [standalone]

#1302814

On Mon, 4 Jan 2016, Benjamin Tissoires wrote:

> Jiri, I *think* this commit still is in your next pull request for
> Linus. We might want to drop it before it hits Linus' tree.

What exactly would be the reasoning for dropping it?

I am all for implementing the skeleton HID driver to take over the xpad.c 
heavylifting, but before that work gets done, this can stay, can't it?

Thanks,

-- 
Jiri Kosina
SUSE Labs

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

[toc] | [prev] | [next] | [standalone]

#1303234

On Wed, Jan 06, 2016 at 03:36:57PM +0100, Jiri Kosina wrote:
> On Mon, 4 Jan 2016, Benjamin Tissoires wrote:
> 
> > Jiri, I *think* this commit still is in your next pull request for
> > Linus. We might want to drop it before it hits Linus' tree.
> 
> What exactly would be the reasoning for dropping it?

It is wrong. Aside form the fact that IMO xpad.c is the wrong place for
this code to be in, why are we waiting for the input device to be
opened by userspace before we do the switch instead of doing it
immediately?

Thanks.

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

[toc] | [prev] | [next] | [standalone]

#1303284

On Wed, January 6, 2016 6:47 pm, Dmitry Torokhov wrote:

> It is wrong. Aside form the fact that IMO xpad.c is the wrong place for
> this code to be in, why are we waiting for the input device to be opened by
> userspace before we do the switch instead of doing it immediately?

The 'send magic' might be better in a probe() call, but I don't believe
that it requires userspace interaction as it stands. The wheel will
disconnect almost immediately without me doing anything other than plug it
in.
--
Jan  6 21:18:50 speedster kernel: [  439.604037] usb 5-1: new full-speed
USB device number 2 using uhci_hcd
Jan  6 21:18:50 speedster kernel: [  439.791153] usb 5-1: New USB device
found, idVendor=046d, idProduct=c261
Jan  6 21:18:50 speedster kernel: [  439.791160] usb 5-1: New USB device
strings: Mfr=1, Product=2, SerialNumber=3
Jan  6 21:18:50 speedster kernel: [  439.791164] usb 5-1: Product: G920
Driving Force Racing Wheel for Xbox One
Jan  6 21:18:50 speedster kernel: [  439.791167] usb 5-1: Manufacturer:
Logitech
Jan  6 21:18:50 speedster kernel: [  439.791170] usb 5-1: SerialNumber:
00005d1d5129cebe
Jan  6 21:18:50 speedster mtp-probe: checking bus 5, device 2:
"/sys/devices/pci0000:00/0000:00:1d.3/usb5/5-1"
Jan  6 21:18:50 speedster mtp-probe: bus: 5, device: 2 was not an MTP device
Jan  6 21:18:51 speedster kernel: [  440.815191] input: Logitech G920
Driving Force Racing Wheel as
/devices/pci0000:00/0000:00:1d.3/usb5/5-1/5-1:1.0/input/input4
Jan  6 21:18:51 speedster kernel: [  440.815310] usbcore: registered new
interface driver xpad
Jan  6 21:18:52 speedster kernel: [  441.340093] usb 5-1: USB disconnect,
device number 2
Jan  6 21:18:52 speedster kernel: [  442.052037] usb 5-1: new full-speed
USB device number 3 using uhci_hcd
Jan  6 21:18:52 speedster kernel: [  442.239129] usb 5-1: New USB device
found, idVendor=046d, idProduct=c262
Jan  6 21:18:52 speedster kernel: [  442.239136] usb 5-1: New USB device
strings: Mfr=1, Product=2, SerialNumber=3
Jan  6 21:18:52 speedster kernel: [  442.239139] usb 5-1: Product: G920
Driving Force Racing Wheel for Xbox One
Jan  6 21:18:52 speedster kernel: [  442.239142] usb 5-1: Manufacturer:
Logitech
Jan  6 21:18:52 speedster kernel: [  442.239145] usb 5-1: SerialNumber:
00005d1d5129cebe
Jan  6 21:18:52 speedster mtp-probe: checking bus 5, device 3:
"/sys/devices/pci0000:00/0000:00:1d.3/usb5/5-1"
Jan  6 21:18:52 speedster mtp-probe: bus: 5, device: 3 was not an MTP device
Jan  6 21:18:52 speedster kernel: [  442.267248] input: Logitech G920
Driving Force Racing Wheel for Xbox One as
/devices/pci0000:00/0000:00:1d.3/usb5/5-1/5-1:1.0/0003:046D:C262.0002/input/input5
Jan  6 21:18:52 speedster kernel: [  442.267510] logitech-hidpp-device
0003:046D:C262.0002: input,hiddev0,hidraw1: USB HID v1.11 Joystick
[Logitech G920 Driving Force Racing Wheel for Xbox One] on
usb-0000:00:1d.3-1/input0
Jan  6 21:18:53 speedster kernel: [  442.322160] logitech-hidpp-device
0003:046D:C262.0002: HID++ 4.2 device connected.
--

I also did a quick check with the 'send magic' disabled. Xpad creates the
js0 and populates buttons, but pressing buttons/turning wheel does not
result in any change in js0.

I don't disagree to it being a seperate module, but don't have the time to
implement/test at the moment. If some else does that would be good, can we
make sure that the kconfig/makefile stuff uses same/sensible HID_CONFIGs?
Simon


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

[toc] | [prev] | [next] | [standalone]

#1303976

On Wed, 2016-01-06 at 17:47 -0800, Dmitry Torokhov wrote:
> On Wed, Jan 06, 2016 at 03:36:57PM +0100, Jiri Kosina wrote:
> > On Mon, 4 Jan 2016, Benjamin Tissoires wrote:
> > 
> > > Jiri, I *think* this commit still is in your next pull request
> > > for
> > > Linus. We might want to drop it before it hits Linus' tree.
> > 
> > What exactly would be the reasoning for dropping it?
> 
> It is wrong. Aside form the fact that IMO xpad.c is the wrong place
> for
> this code to be in, why are we waiting for the input device to be
> opened by userspace before we do the switch instead of doing it
> immediately?
> 

Hi all,

I have to disagree with the xpad driver being the wrong place to handle
this. The xpad driver matches devices it should handle by interface
class, subclass and protocol. When G920 first appears on the USB bus,
it for all intents and purposes looks like a Xbox One controller so the
xpad driver picks it up even if there is no G920-specific code in the
driver. Unless there is a way how to blacklist certain idProduct
values, the switch from XBone mode to HID mode will have to be done in
the xpad driver.

I'm pretty much done with the simple switching module but it will be of
no use if we cannot make the xpad module ignore G920 first.

Michal

[toc] | [prev] | [next] | [standalone]

#1303984 — Re: [Patch-V2 1/6] INPUT: xpad: Add minimal support for Logitech G920 Wheel

On Thu, Jan 7, 2016 at 2:50 PM, Michal Malý
<madcatxster@devoid-pointer.net> wrote:
> On Wed, 2016-01-06 at 17:47 -0800, Dmitry Torokhov wrote:
>> On Wed, Jan 06, 2016 at 03:36:57PM +0100, Jiri Kosina wrote:
>> > On Mon, 4 Jan 2016, Benjamin Tissoires wrote:
>> >
>> > > Jiri, I *think* this commit still is in your next pull request
>> > > for
>> > > Linus. We might want to drop it before it hits Linus' tree.
>> >
>> > What exactly would be the reasoning for dropping it?
>>
>> It is wrong. Aside form the fact that IMO xpad.c is the wrong place
>> for
>> this code to be in, why are we waiting for the input device to be
>> opened by userspace before we do the switch instead of doing it
>> immediately?
>>
>
> Hi all,
>
> I have to disagree with the xpad driver being the wrong place to handle
> this. The xpad driver matches devices it should handle by interface
> class, subclass and protocol. When G920 first appears on the USB bus,
> it for all intents and purposes looks like a Xbox One controller so the
> xpad driver picks it up even if there is no G920-specific code in the
> driver. Unless there is a way how to blacklist certain idProduct
> values, the switch from XBone mode to HID mode will have to be done in
> the xpad driver.
>
> I'm pretty much done with the simple switching module but it will be of
> no use if we cannot make the xpad module ignore G920 first.

I see that Simon's patch added:

XPAD_XBOXONE_VENDOR(0x046d),

to the xpad driver. Are you saying that we latch onto the controller
even without this addition?

Thanks.

-- 
Dmitry

[toc] | [prev] | [next] | [standalone]

#1303989

On Thu, 2016-01-07 at 14:53 -0800, Dmitry Torokhov wrote:
> On Thu, Jan 7, 2016 at 2:50 PM, Michal Malý
> <madcatxster@devoid-pointer.net> wrote:
> > On Wed, 2016-01-06 at 17:47 -0800, Dmitry Torokhov wrote:
> > > On Wed, Jan 06, 2016 at 03:36:57PM +0100, Jiri Kosina wrote:
> > > > On Mon, 4 Jan 2016, Benjamin Tissoires wrote:
> > > > 
> > > > > Jiri, I *think* this commit still is in your next pull
> > > > > request
> > > > > for
> > > > > Linus. We might want to drop it before it hits Linus' tree.
> > > > 
> > > > What exactly would be the reasoning for dropping it?
> > > 
> > > It is wrong. Aside form the fact that IMO xpad.c is the wrong
> > > place
> > > for
> > > this code to be in, why are we waiting for the input device to be
> > > opened by userspace before we do the switch instead of doing it
> > > immediately?
> > > 
> > 
> > Hi all,
> > 
> > I have to disagree with the xpad driver being the wrong place to
> > handle
> > this. The xpad driver matches devices it should handle by interface
> > class, subclass and protocol. When G920 first appears on the USB
> > bus,
> > it for all intents and purposes looks like a Xbox One controller so
> > the
> > xpad driver picks it up even if there is no G920-specific code in
> > the
> > driver. Unless there is a way how to blacklist certain idProduct
> > values, the switch from XBone mode to HID mode will have to be done
> > in
> > the xpad driver.
> > 
> > I'm pretty much done with the simple switching module but it will
> > be of
> > no use if we cannot make the xpad module ignore G920 first.
> 
> I see that Simon's patch added:
> 
> XPAD_XBOXONE_VENDOR(0x046d),
> 
> to the xpad driver. Are you saying that we latch onto the controller
> even without this addition?
> 
> Thanks.

Sorry, my bad, I missed that change in the patch. Handling the switch
elsewhere should be no problem then.

Michal

[toc] | [prev] | [next] | [standalone]

#1304303

Alright, so what I am planning to do is to drop 27b9d5a254d ("INPUT: xpad: 
switch Logitech G920 Wheel into HID mode") from the for-4.5/logitech 
branch, while keeping the rest of the G920 support in, so that it 
immediately starts working once proper HID-mode switching is implemented.

If anyone has objections to this aproach, please speak up.

Thanks,

-- 
Jiri Kosina
SUSE Labs

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web