On 02/20/2015 02:41 PM, Pali Rohár wrote:
On Friday 20 February 2015 20:56:23 Mario Limonciello wrote: I have BIOS version A05 on my E6440 machine. That version does not have problems with "repeating keys" and my workaround for ALPS touchpad (which is in mainline tree and -stable trees now) works fine. If I do not see other problems, I will not update BIOS (just because current version working -- with workarounds). But CCing Rob. He told me as first about existence of new BIOS version for E6440 and he is already testing new version of BIOS, so can share details. Mario, can you share some details about that new BIOS update? If it is not secret, how was problem with "repeating keys" fixed? Why linux had more problems as Windows? Cannot we implement some "workaround" in linux kernel to prevent that (or similar) problems in future?
It's a bit ironic really. The problem was introduced because a timer was added to the EC last year to fix a key repeating problem found on Windows. In doing so the EC was blocking "BREAK" from being sent to the OS. Windows OS didn't mind this, but Linux did. The fix doesn't block BREAK anymore.
resetafter=0 means to never reset (even if driver receive e.g thousand invalid packets). I think this is very dangerous if there will be other bugs either in linux driver or some other HW problems. For ALPS issue I added resetafter = pktsize * 2 (Allow 2 invalid packets without resetting device). Cannot you find something similar for synaptics touchpads on XPS? (pktsize for ALPS is 6, no idea how big are synaptics packets).
I'll take a look and see if there's an upper limit I can find for this that works well enough.
Older Dell HW (laptops, desktops, servers) supported BIOS update directly from Linux (ubuntu has needed tools in standard repositories). It is not supported/provided anymore? I see that dell_rbu driver is still in linux kernel. dell_rbu.ko: description: Driver for updating BIOS image on DELL systems
Servers can (and I believe still do) use this method. Latitude, Precision and XPS 13 (2015) do still support RBU for flashing but the BIOS executables no longer are distributed in a format that the payload can simply be extracted and flashed this way. The executable supports a variety of firmware targets and custom builds the payload for the machine it's being executed upon. Until we have a better method to do something similar to this in Linux, the best bet is to use the F12 BIOS boot menu to perform the flash if it's supported on the given machine.
There is problem with some synaptics touchpad on some laptops (probably not dell). Windows driver loads own firmware into synaptics touchpad which use different protocol (as original firmware in touchpad). And that loaded firmware is active until laptop is not shut down. When you reboot from Windows to Linux then linux kernel driver refuse to identify & use touchpad because it does not support that new firmware loaded by Windows... I do not know lot of about this problem, I just heard about it from other people. I did not see any laptop "in action".
Ah, so it's a special interface that's implemented in the Synaptics Windows driver. As described above this sounds like a stop gap type solution to resolve a field problem until the firmware can be implemented into manufactured parts. I'd suspect that people who purchased the same model of this computer later might run into problems without warm booting as the firmware got updated into the manufacturer's factory. -- 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
