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.
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?
Am I being crazy again?
Linus
--
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
