On Wed, 20 Nov 2019, Ikjoon Jang wrote: > On Tue, Nov 19, 2019 at 11:14 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > > On Tue, 19 Nov 2019, Ikjoon Jang wrote: > > > > > On Sun, Nov 17, 2019 at 11:46 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > On Sun, 17 Nov 2019, Ikjoon Jang wrote: > > > > > > > > > This patchset enables hard wired hub device to use different bInterval > > > > > from its descriptor when the hub has a combined device node. > > > > > > > > > > When we know the specific hard wired hub supports changing its polling > > > > > interval, we can adjust hub's interval to reduce the time of waking up > > > > > from autosuspend or connect detection of HIDs. > > > > > > > > In fact, _all_ hubs support changing the polling interval. The value > > > > given in the USB spec is just an upper limit; any smaller value is > > > > equally acceptable. > > > > > > > > So why are you doing this only for hard-wired hubs? Why not for all > > > > hubs? > > > > > > Because we only want to apply it to a specific device instance under > > > our control. > > > > Why? What's so special about that device instance? > > > > For example, why not instead have a poll_interval sysfs attribute for > > all hubs that can be written from userspace? Then people could reduce > > the autoresume latency for any device they want. > > Changing its INT interval during runtime seems not so easy, there's no device > drivers doing this to my knowledge. At least xhci needs to restart > endpoint to change > the interval. So I think patching ep descriptor at enumeration stage > is more convincing. That's a good point. It would be necessary to send a Set-Interface request at the very least if you wanted to change the interval on-the-fly. > > > We apply autosuspend to built-in touchpad device for power savings, > > > > > > Users can attach external hub devices with same VID:PID that we don't want to > > > change the behavior. > > > > Why don't you want to change the behavior? Or allow the user to change > > the behavior? > > > > Yes, that's a difficult question here too, when the hub is external device, > it can't be fully controlled by here. Even though it's the same > VID:PID hub chip, > that's not the 100% same device. We don't know how much this will > impact to the other > external hub devices regarding power consumption and compatibility. > > > > Maybe disabling autosuspend for external HIDs > > > can be more reasonable for that case? > > > > If it makes sense to to save power for your built-in touchpad device, > > why doesn't it also make sense to save power for other external HIDs? > > > > > > And is 250 ms really too long to wait for remote wakeup or connect > > > > detection? What's the real motivation behind this change? > > > > > > When a user starts to move the cursor while touchpad is in autosuspend state, > > > It takes more than >250ms (worst case can be >500ms) to wake up and response. > > > That makes the cursor stuck for a while and warp to another location suddenly. > > > > All right, that's a good reason. But doesn't it apply just as well to > > other devices, not only your built-in touchpad? > > Actually the hub is the one to be applied, I don't care much about the > rare case that > a user connects an additional external hub with same PID and connect > external HID > under that hub. > > We could reduce autosuspend delay for built-in touchpad when we know > that's better > for power savings only if response time of wake up is good enough. but > we don't know > the optimal values for external HIDs. So we could use the default long > delay for external > devices, or just disable autosuspend for all external HIDs, > so user might experience much less cursor lags even with that rare case. All right. Can you resubmit the patch with this explanation added to the Changelog? Alan Stern
