From: Linus Torvalds <torvalds@linux-foundation.org>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Roel Aaij <roel.aaij@gmail.com>,
"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>
Subject: Re: Problems with Elantech touchpad in 3.18-rc2
Date: Thu, 30 Oct 2014 12:06:03 -0700 [thread overview]
Message-ID: <CA+55aFzkh8NMSPSe7D=sYHPqU3_v3PBUEQrjH7PvFPwkp=ytuA@mail.gmail.com> (raw)
In-Reply-To: <20141030180331.GF36444@dtor-ws>
On Thu, Oct 30, 2014 at 11:03 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> 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
next prev parent reply other threads:[~2014-10-30 19:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-30 17:14 Problems with Elantech touchpad in 3.18-rc2 Roel Aaij
2014-10-30 18:03 ` Dmitry Torokhov
2014-10-30 19:06 ` Linus Torvalds [this message]
2014-10-30 19:25 ` Dmitry Torokhov
2014-10-31 16:24 ` Dmitry Torokhov
2014-10-31 17:30 ` Pavel Machek
2014-10-31 17:35 ` Dmitry Torokhov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+55aFzkh8NMSPSe7D=sYHPqU3_v3PBUEQrjH7PvFPwkp=ytuA@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=roel.aaij@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).