No html now ... Cheers, Nestor On Mon, Dec 3, 2012 at 5:17 AM, Jiri Kosina <jkosina@xxxxxxx> wrote: > On Mon, 26 Nov 2012, Benjamin Tissoires wrote: > >> It is clear that the goal is to make commit >> 4ea5454203d991ec85264f64f89ca8855fce69b0 less restrictive. >> The problem is that this commit stops any communication with the >> device, even configuration communication. >> >> Logitech devices use their own protocol on top of the HID standard >> protocol. For touch devices, this proprietary protocol requires to ask >> the device for axis ranges, etc... >> >> So here, the idea is not to open the can of worm for every hid devices >> through hw_start() / hw_stop() calls, I think the idea of Andrew is >> just to allow hid-logitech-dj to get rid of this restriction in some >> particular circumstances. >> Consider this as a controlled backdoor of the can of worms :) > > I have been thinking for this for a while, and I wasn't able to come up > with anything I'd personally consider substantially better aproach than > splitting the lock. So I don't have strong objections at the very moment. > > This will also allow us to get rid of what commit 596264082f introduced in > unifying driver, right? (adding Nestor to CC). That is correct. Moreover, we are planning additional changes to hid-logitech-dj that will somehow revert that commit. As Andrew mentioned earlier, the drivers for Unifying devices need to query several parameters during their probe() execution, and besides this lock issue, there is still another problem with the current hid-logitech-dj strategy. Unifying devices can only be queried when the radio link is active, and as such, we are planning to postpone calling hid_add_device() until we are sure that the device has an active radio link. With both issues resolved, the path will be clear to add native multitouch support for several Unifying devices like t650, t620 and t400. > -- > Jiri Kosina > SUSE Labs -- 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
