On Thu, Oct 30, 2014 at 12:06:03PM -0700, Linus Torvalds wrote: > On Thu, Oct 30, 2014 at 11:03 AM, Dmitry Torokhov > <dmitry.torokhov@xxxxxxxxx> wrote: > > > > Linus, any guidance here? Can we live with such regression? > > No. If people are already finding machines with problems, that means > that there will be a lot of them once distributions move to that > kernel. My only argument here is that failure is much less severe than with MUX case: when in legacy mode the worst that is happening is that advanced features (multi-touch, two-finger scroilling, etc) do not work so the experience is similar to Windows box with no venrod drivers installed. Whereas when active MUX does not work but we are tying to use it your device is completely hosed. > > And I'd much rather maintain an old blacklist of broken machines, than > start from scratch and have a whitelist for machines that want muxing. > > So I guess we'll need to revert and go back to the bad old days. > > That said, before we do that, maybe we can find a middle ground for > the default behavior. The old behavior is to always try to mux if the > hw seems to support it. The new behavior is to never try to mux by > default. How about "try to mux if the controller seems to support it, > but if you don't actually find any muxed devices behind the > controller, go back to no-mux mode"? > > Is there any way to do something like that? I don't actually know how > the heck people set up those touchpads, so maybe I'm just whistling in > the dark, and you can't even tell. > > IOW, can we just enumerate the muxed devices, and see if they actually > use anything else than just index zero? Make the default a bit more > dynamic than just "all on" or "all off"? > > Put another way: right now we do a lot of checking in > i8042_check_aux(), but we don't do *any* checking of the individual > muxed ports. Could we perhaps do some check per mux port? Do some > PSMOUSE_CMD_ENABLE thing and see if you get anything back? Very often (most often) with broken MUX we do see the device, it simply does not react properly (refuses to get enabled, fails to activate in advanced mode, spews garbage into data stream, etc), so I don't think that putting entire psmouse initialization sequence with all various protocols into i8042_check_aux() is good idea. And I have no idea whatsoever how they will behave if you try activating MUX mode, try using it, and then deactivate. I think that code path is even less travelled than active MUX one. -- 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
