Bug 115311

Summary: Patch to Input: xpad: handle "present" and "gone" correctly causes more issues and instability than it solves.
Product: Drivers Reporter: Malcolm Haak (insanemal)
Component: Input DevicesAssignee: drivers_input-devices
Status: NEW ---    
Severity: normal    
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 4.5.0 Tree: Mainline
Regression: No

Description Malcolm Haak 2016-03-27 06:47:48 UTC
Previously xpad precreated devices for all 4 wireless controller's supported by the wireless dongle. 

This meant if power was lost to a wireless control it would reconnect and continue to work 'like nothing had happened' 

Now that it handles 'present' and 'gone' correctly if power is lost the controller is assigned a new /dev entry and no longer works in the application that was using it without closing and relaunching the application. 

While I understand what was trying to be achieved with the change it feels more like a regression as previously wireless controllers 'just worked' in a way that was similar to the console they came from and also how they behave on windows. 

Now if you have any issues with a device you have to re-launch the application so it sees the new /dev object (also I'm guessing the links to /dev/input/jsX are also broken as the links are recreated each time the device disappears and reappears so I'm guessing the application is still holding the old file handle) 

Personally I want the old behavior back as this new one feels more broken, but possibly having it available via a module probe would also work.

I understand this is an attempt to bring wireless behaviour inline with wired, but I actually selected to use wireless controllers because of the 'ease of use' the previous behaviour allowed for. 


I can provide dmesg output, but I don't think that should be required.
Comment 1 Malcolm Haak 2016-03-29 02:46:37 UTC
Just for further clarification I think the git commit is 	09c8b00ae3e16c8d0fd4beb2ca064502a76c0f17

Also I think an even better answer than restoring old behaviour would be to add a configurable (proc or at modprobe) timeout before tearing down the device. 

This would allow for the controller to reconnect as per the old behavior, but also allow them to really disconnect and stay disconnected. 

If feasible this timeout behaviour would also be useful on supported wired devices as they have those 'quick disconnect' joins in the cable to prevent damage and having kids,cats or dogs disconnect cables forcing you to reload applications is also equally as 'jarring' to user experience.