Thread (7 messages) 7 messages, 4 authors, 2014-10-31

Re: Problems with Elantech touchpad in 3.18-rc2

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: 2014-10-30 19:25:10

On Thu, Oct 30, 2014 at 12:06:03PM -0700, Linus Torvalds wrote:
On Thu, Oct 30, 2014 at 11:03 AM, Dmitry Torokhov
[off-list ref] wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help