On Thu, Jan 7, 2016 at 2:50 PM, Michal Malý <madcatxster@xxxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
