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