lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 11 Sep 2009 15:25:30 +0200
From:	Arjan Opmeer <arjan@...eer.net>
To:	dtor@...l.ru, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: How to handle laptop with Elantech touchpad that chokes on current
 driver configuration values?


Recently I debugged a problem for a user where the Elantech touchpad of his
laptop chokes on the configuration values that the current kernel driver is
using. After sending a conflicting value the PS/2 controller freezes and
doesn't accept any subsequent bytes.

The current configuration values for hardware version 2 (EeePC style) come
from the touchpad driver in the original Xandros Linux distribution for the
EeePC. And until now I haven't heard of problems with them. They look like
this:

   etd->reg_10 = 0x54;
   etd->reg_11 = 0x88;
   etd->reg_21 = 0x60;

Some time ago I received the updated touchpad driver that is used in the
Dell mini Ubuntu distribution. Here the values are changed to be the same as
most of the Windows driver are using. Notice the difference in register 0x11
and how they dropped configuring register 0x21:

   etd->reg_10 = 0x54;
   etd->reg_11 = 0x8a;

However for the laptop of the user mentioned above the values of his Windows
driver are like this:

   etd->reg_10 = 0x64;
   etd->reg_11 = 0x8a;

Notice the different values for registers 0x10 and 0x11 in comparison with
the current kernel driver. Also the registers _must_ be configured like
this. Using the current kernel driver values for either one of the registers
makes the touchpad freeze up.

Remember that there isn't any publicly available documentation for the
hardware, so these configuration values are "black magic numbers" and the
only source of them is snooping what Windows drivers do or the source of
drivers in dedicated Linux distributions that happen to come my way.

In all cases this is about touchpads with a firmware version reply of 0x02,
0x00, 0x30. So even though the touchpad in this users laptops seems to be
the same as in the EeePC it really requires different values to be
configured.

My question now is what is a prudent way to go forward?

Is it OK that add a DMI check to the kernel driver that matches this users
laptop and dynamically adjust the configuration values?

And how about the common case? Do we keep the values in the driver as they
are, or do we update them to the revised numbers as learned from the Ubuntu
driver?

What are your thoughts on this?


Arjan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ