Problems with Elantech touchpad in 3.18-rc2

Problems with Elantech touchpad in 3.18-rc2

[Roel Aaij]

[-- Attachment #1.1: Type: text/plain, Size: 2372 bytes --]

Dear kernel input developers,

While trying out 3.18-rc2, I noticed that the Elantech touchpad on my
laptop didn't work as intended anymore. Mouse movement and tapping one
finger worked, but scrolling and two finger tapping did not. X.org also
didn't recognise the touchpad as a synaptics touchpad anymore.

After googling around I found that i8042.nomux=0 brought it back to normal.

My laptop is a Clevo model W650SH with a keyboard and a touchpad attached,
and no touchschreen. Some output of dmesg is listed at the bottom, and the
result of dmidecode is attached.

Best regards,

Roel Aaij

Some dmesg output without i8042.nomux=0 (not fully functional touchpad)

[    1.221297] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:ELNM] at 0x60,0x64 irq 1,12
[    1.226412] serio: i8042 KBD port at 0x60,0x64 irq 1
[    1.226414] serio: i8042 AUX port at 0x60,0x64 irq 12
[    1.229415] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input6
[    5.017142] psmouse serio1: elantech: assuming hardware version 3 (with firmware version 0x450f02)
[    5.018055] psmouse serio1: elantech: elantech_send_cmd query 0x02 failed.
[    5.018057] psmouse serio1: elantech: failed to query capabilities.
[    5.930158] input: PS/2 Elantech Touchpad as /devices/platform/i8042/serio1/input/input8


Some dmesg output with i8042.nomux=0 (fully functional touchpad)

[    1.361320] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:ELNM] at 0x60,0x64 irq 1,12
[    1.366134] i8042: Detected active multiplexing controller, rev 1.1
[    1.367757] serio: i8042 KBD port at 0x60,0x64 irq 1
[    1.367759] serio: i8042 AUX0 port at 0x60,0x64 irq 12
[    1.367764] serio: i8042 AUX1 port at 0x60,0x64 irq 12
[    1.367765] serio: i8042 AUX2 port at 0x60,0x64 irq 12
[    1.367766] serio: i8042 AUX3 port at 0x60,0x64 irq 12
[    1.371243] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input6
[   99.389964] psmouse serio2: elantech: assuming hardware version 3 (with firmware version 0x450f02)
[   99.489797] psmouse serio2: elantech: Synaptics capabilities query result 0x79, 0x17, 0x0c.
[   99.819119] input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio2/input/input22

P.S. The late timestamps in the last few lines are due to a "modprobe -r psmouse && modprobe psmouse"

[-- Attachment #1.2: dmi --]
[-- Type: text/plain, Size: 11352 bytes --]

# dmidecode 2.12
SMBIOS 2.7 present.
34 structures occupying 1874 bytes.
Table at 0x000EB500.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
	Vendor: American Megatrends Inc.
	Version: 1.00.05
	Release Date: 08/07/2013
	Address: 0xF0000
	Runtime Size: 64 kB
	ROM Size: 4096 kB
	Characteristics:
		PCI is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		Boot from CD is supported
		Selectable boot is supported
		EDD is supported
		Print screen service is supported (int 5h)
		8042 keyboard services are supported (int 9h)
		Printer services are supported (int 17h)
		ACPI is supported
		USB legacy is supported
		BIOS boot specification is supported
		Targeted content distribution is supported
		UEFI is supported
	BIOS Revision: 4.6

Handle 0x0001, DMI type 1, 27 bytes
System Information
	Manufacturer: Notebook                        
	Product Name: W65_W670SH                      
	Version: Not Applicable                  
	Serial Number: Not Applicable                  
	UUID: ECF59000-47ED-0000-0000-000000000000
	Wake-up Type: Power Switch
	SKU Number: Not Applicable                  
	Family: Not Applicable                  

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
	Manufacturer: Notebook                        
	Product Name: W65_W670SH                      
	Version: Not Applicable                  
	Serial Number: Not Applicable                  
	Asset Tag: Tag 12345
	Features:
		Board is a hosting board
		Board is replaceable
	Location In Chassis: Not Applicable
	Chassis Handle: 0x0003
	Type: Motherboard
	Contained Object Handles: 0

Handle 0x0003, DMI type 3, 22 bytes
Chassis Information
	Manufacturer: Notebook                        
	Type: Laptop
	Lock: Not Present
	Version: N/A                             
	Serial Number: None                            
	Asset Tag: No Asset Tag
	Boot-up State: Safe
	Power Supply State: Safe
	Thermal State: Safe
	Security Status: None
	OEM Information: 0x00000000
	Height: Unspecified
	Number Of Power Cords: 1
	Contained Elements: 0
	SKU Number: To be filled by O.E.M.

Handle 0x0004, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1A1
	Internal Connector Type: None
	External Reference Designator: PS2Mouse
	External Connector Type: PS/2
	Port Type: Mouse Port

Handle 0x0005, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1A1
	Internal Connector Type: None
	External Reference Designator: Keyboard
	External Connector Type: PS/2
	Port Type: Keyboard Port

Handle 0x0006, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J2A1
	Internal Connector Type: None
	External Reference Designator: TV Out
	External Connector Type: Mini Centronics Type-14
	Port Type: Other

Handle 0x0007, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J2A2A
	Internal Connector Type: None
	External Reference Designator: COM A
	External Connector Type: DB-9 male
	Port Type: Serial Port 16550A Compatible

Handle 0x0008, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J2A2B
	Internal Connector Type: None
	External Reference Designator: Video
	External Connector Type: DB-15 female
	Port Type: Video Port

Handle 0x0009, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J3A1
	Internal Connector Type: None
	External Reference Designator: USB1
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x000A, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J3A1
	Internal Connector Type: None
	External Reference Designator: USB2
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x000B, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J3A1
	Internal Connector Type: None
	External Reference Designator: USB3
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x000C, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J5A1
	Internal Connector Type: None
	External Reference Designator: LAN
	External Connector Type: RJ-45
	Port Type: Network Port

Handle 0x000D, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J5A1
	Internal Connector Type: None
	External Reference Designator: USB4
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x000E, DMI type 9, 17 bytes
System Slot Information
	Designation: J6B2
	Type: x16 PCI Express
	Current Usage: In Use
	Length: Long
	ID: 0
	Characteristics:
		3.3 V is provided
		Opening is shared
		PME signal is supported
	Bus Address: 0000:00:01.0

Handle 0x000F, DMI type 10, 8 bytes
On Board Device 1 Information
	Type: Video
	Status: Enabled
	Description:    To Be Filled By O.E.M.
On Board Device 2 Information
	Type: Ethernet
	Status: Enabled
	Description: To Be Filled By O.E.M.

Handle 0x0010, DMI type 11, 5 bytes
OEM Strings
	String 1: 1558
	String 2: OEM String
	String 3: To Be Filled By O.E.M.
	String 4: To Be Filled By O.E.M.
	String 5: BIOS:1.00.05

Handle 0x0011, DMI type 12, 5 bytes
System Configuration Options
	Option 1: To Be Filled By O.E.M.

Handle 0x0012, DMI type 24, 5 bytes
Hardware Security
	Power-On Password Status: Disabled
	Keyboard Password Status: Disabled
	Administrator Password Status: Disabled
	Front Panel Reset Status: Disabled

Handle 0x0013, DMI type 32, 20 bytes
System Boot Information
	Status: No errors detected

Handle 0x0014, DMI type 4, 42 bytes
Processor Information
	Socket Designation: SOCKET 0
	Type: Central Processor
	Family: Core i7
	Manufacturer: Intel
	ID: C3 06 03 00 FF FB EB BF
	Signature: Type 0, Family 6, Model 60, Stepping 3
	Flags:
		FPU (Floating-point unit on-chip)
		VME (Virtual mode extension)
		DE (Debugging extension)
		PSE (Page size extension)
		TSC (Time stamp counter)
		MSR (Model specific registers)
		PAE (Physical address extension)
		MCE (Machine check exception)
		CX8 (CMPXCHG8 instruction supported)
		APIC (On-chip APIC hardware supported)
		SEP (Fast system call)
		MTRR (Memory type range registers)
		PGE (Page global enable)
		MCA (Machine check architecture)
		CMOV (Conditional move instruction supported)
		PAT (Page attribute table)
		PSE-36 (36-bit page size extension)
		CLFSH (CLFLUSH instruction supported)
		DS (Debug store)
		ACPI (ACPI supported)
		MMX (MMX technology supported)
		FXSR (FXSAVE and FXSTOR instructions supported)
		SSE (Streaming SIMD extensions)
		SSE2 (Streaming SIMD extensions 2)
		SS (Self-snoop)
		HTT (Multi-threading)
		TM (Thermal monitor supported)
		PBE (Pending break enabled)
	Version: Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz
	Voltage: 1.2 V
	External Clock: 100 MHz
	Max Speed: 3800 MHz
	Current Speed: 2400 MHz
	Status: Populated, Enabled
	Upgrade: Socket rPGA988B
	L1 Cache Handle: 0x0016
	L2 Cache Handle: 0x0015
	L3 Cache Handle: 0x0017
	Serial Number: Not Specified
	Asset Tag: Fill By OEM
	Part Number: Fill By OEM
	Core Count: 4
	Core Enabled: 4
	Thread Count: 8
	Characteristics:
		64-bit capable

Handle 0x0015, DMI type 7, 19 bytes
Cache Information
	Socket Designation: CPU Internal L2
	Configuration: Enabled, Not Socketed, Level 2
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 1024 kB
	Maximum Size: 1024 kB
	Supported SRAM Types:
		Unknown
	Installed SRAM Type: Unknown
	Speed: Unknown
	Error Correction Type: Single-bit ECC
	System Type: Unified
	Associativity: 8-way Set-associative

Handle 0x0016, DMI type 7, 19 bytes
Cache Information
	Socket Designation: CPU Internal L1
	Configuration: Enabled, Not Socketed, Level 1
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 256 kB
	Maximum Size: 256 kB
	Supported SRAM Types:
		Unknown
	Installed SRAM Type: Unknown
	Speed: Unknown
	Error Correction Type: Single-bit ECC
	System Type: Other
	Associativity: 8-way Set-associative

Handle 0x0017, DMI type 7, 19 bytes
Cache Information
	Socket Designation: CPU Internal L3
	Configuration: Enabled, Not Socketed, Level 3
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 6144 kB
	Maximum Size: 6144 kB
	Supported SRAM Types:
		Unknown
	Installed SRAM Type: Unknown
	Speed: Unknown
	Error Correction Type: Single-bit ECC
	System Type: Unified
	Associativity: 12-way Set-associative

Handle 0x0018, DMI type 16, 23 bytes
Physical Memory Array
	Location: System Board Or Motherboard
	Use: System Memory
	Error Correction Type: None
	Maximum Capacity: 32 GB
	Error Information Handle: Not Provided
	Number Of Devices: 4

Handle 0x0019, DMI type 17, 34 bytes
Memory Device
	Array Handle: 0x0018
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 8192 MB
	Form Factor: SODIMM
	Set: None
	Locator: ChannelA-DIMM0
	Bank Locator: BANK 0
	Type: DDR3
	Type Detail: Synchronous
	Speed: 1600 MHz
	Manufacturer: 1315
	Serial Number: 12230000
	Asset Tag: 9876543210
	Part Number: CT102464BF160B.C16
	Rank: 2
	Configured Clock Speed: 1600 MHz

Handle 0x001A, DMI type 20, 35 bytes
Memory Device Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x001FFFFFFFF
	Range Size: 8 GB
	Physical Device Handle: 0x0019
	Memory Array Mapped Address Handle: 0x001E
	Partition Row Position: Unknown
	Interleave Position: Unknown
	Interleaved Data Depth: Unknown

Handle 0x001B, DMI type 17, 34 bytes
Memory Device
	Array Handle: 0x0018
	Error Information Handle: Not Provided
	Total Width: Unknown
	Data Width: Unknown
	Size: No Module Installed
	Form Factor: DIMM
	Set: None
	Locator: ChannelA-DIMM1
	Bank Locator: BANK 1
	Type: Unknown
	Type Detail: None
	Speed: Unknown
	Manufacturer: [Empty]
	Serial Number: [Empty]
	Asset Tag: 9876543210
	Part Number: [Empty]
	Rank: Unknown
	Configured Clock Speed: Unknown

Handle 0x001C, DMI type 17, 34 bytes
Memory Device
	Array Handle: 0x0018
	Error Information Handle: Not Provided
	Total Width: Unknown
	Data Width: Unknown
	Size: No Module Installed
	Form Factor: DIMM
	Set: None
	Locator: ChannelB-DIMM0
	Bank Locator: BANK 2
	Type: Unknown
	Type Detail: None
	Speed: Unknown
	Manufacturer: [Empty]
	Serial Number: [Empty]
	Asset Tag: 9876543210
	Part Number: [Empty]
	Rank: Unknown
	Configured Clock Speed: Unknown

Handle 0x001D, DMI type 17, 34 bytes
Memory Device
	Array Handle: 0x0018
	Error Information Handle: Not Provided
	Total Width: Unknown
	Data Width: Unknown
	Size: No Module Installed
	Form Factor: DIMM
	Set: None
	Locator: ChannelB-DIMM1
	Bank Locator: BANK 3
	Type: Unknown
	Type Detail: None
	Speed: Unknown
	Manufacturer: [Empty]
	Serial Number: [Empty]
	Asset Tag: 9876543210
	Part Number: [Empty]
	Rank: Unknown
	Configured Clock Speed: Unknown

Handle 0x001E, DMI type 19, 31 bytes
Memory Array Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x001FFFFFFFF
	Range Size: 8 GB
	Physical Array Handle: 0x0018
	Partition Width: 4

Handle 0x0022, DMI type 131, 64 bytes
OEM-specific Type
	Header and Data:
		83 40 22 00 31 00 00 00 00 00 00 00 00 00 00 00
		F8 00 49 8C 00 00 00 00 01 20 00 00 00 00 09 00
		7A 05 0D 00 00 00 00 00 C8 00 FF FF 00 00 00 00
		00 00 00 00 66 00 00 00 76 50 72 6F 00 00 00 00

Handle 0x0023, DMI type 13, 22 bytes
BIOS Language Information
	Language Description Format: Long
	Installable Languages: 1
		en|US|iso8859-1
	Currently Installed Language: en|US|iso8859-1

Handle 0x0025, DMI type 127, 4 bytes
End Of Table


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: Problems with Elantech touchpad in 3.18-rc2

[Dmitry Torokhov]

Hi Roel,

On Thu, Oct 30, 2014 at 06:14:09PM +0100, Roel Aaij wrote:
> Dear kernel input developers,
> 
> While trying out 3.18-rc2, I noticed that the Elantech touchpad on my
> laptop didn't work as intended anymore. Mouse movement and tapping one
> finger worked, but scrolling and two finger tapping did not. X.org also
> didn't recognise the touchpad as a synaptics touchpad anymore.
> 
> After googling around I found that i8042.nomux=0 brought it back to normal.
> 
> My laptop is a Clevo model W650SH with a keyboard and a touchpad attached,
> and no touchschreen. Some output of dmesg is listed at the bottom, and the
> result of dmidecode is attached.

Argh, so quick search shows that there might be quite a few clones of
W650SH floating around, and I wonder if any of W650SF/W650SJ/W670SJQ/
W650SR/W650SZ exhibit the same behavior.

We might need to revert the nomux back to the original setting, although
I really do not want to do this: in my opinion it is better to have
touchpad revert to basic mode on affected laptops and work on
re-enabling MUX on them instead of having touchpad/keyboard completely
hosed from the get-go.

Linus, any guidance here? Can we live with such regression?

Thanks.

-- 
Dmitry

Re: Problems with Elantech touchpad in 3.18-rc2

[Linus Torvalds]

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

Re: Problems with Elantech touchpad in 3.18-rc2

[Dmitry Torokhov]

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@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.

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

Re: Problems with Elantech touchpad in 3.18-rc2

[Dmitry Torokhov]

On Thu, Oct 30, 2014 at 12:25:06PM -0700, Dmitry Torokhov wrote:
> 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@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.
> 
> 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.

So I slept on it and I decided that we should indeed revert the patch,
since it causes more grief to people with good hardware than I
expected. We should not punish owners of good hardware because some
vendors can't write their firmware.

Thanks.

-- 
Dmitry

Re: Problems with Elantech touchpad in 3.18-rc2

[Pavel Machek]

On Fri 2014-10-31 09:24:36, Dmitry Torokhov wrote:
> On Thu, Oct 30, 2014 at 12:25:06PM -0700, Dmitry Torokhov wrote:
> > 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@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.
> > 
> > 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.
> 
> So I slept on it and I decided that we should indeed revert the patch,
> since it causes more grief to people with good hardware than I
> expected. We should not punish owners of good hardware because some
> vendors can't write their firmware.

You can still add "for anything manufactured in 2015+, assume it does
not need MUX" and add a whitelist entry for any machine with external
ps/2 ports that still needs it... I guess there would be very little
of them made in 2015+.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Problems with Elantech touchpad in 3.18-rc2

[Dmitry Torokhov]

On Fri, Oct 31, 2014 at 06:30:40PM +0100, Pavel Machek wrote:
> On Fri 2014-10-31 09:24:36, Dmitry Torokhov wrote:
> > On Thu, Oct 30, 2014 at 12:25:06PM -0700, Dmitry Torokhov wrote:
> > > 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@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.
> > > 
> > > 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.
> > 
> > So I slept on it and I decided that we should indeed revert the patch,
> > since it causes more grief to people with good hardware than I
> > expected. We should not punish owners of good hardware because some
> > vendors can't write their firmware.
> 
> You can still add "for anything manufactured in 2015+, assume it does
> not need MUX" and add a whitelist entry for any machine with external
> ps/2 ports that still needs it... I guess there would be very little
> of them made in 2015+.

No, that Clevo W650SH that Roel has is a Haswell and is fairly recent
and has no external PS/2 ports and still wants to be in active MUX mode.
So we'll have to continue with the blacklist I'm afraid.

-- 
Dmitry