| Message ID | 1424310180-2512-1-git-send-email-mario_limonciello@dell.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Mario, On Wed, Feb 18, 2015 at 07:43:00PM -0600, Mario Limonciello wrote: > When the touchpad for the Dell XPS 13 is running in PS/2 mode the > EC has a tendency to glitch causing the driver to receive bad data. > This doesn't affect the usage of the touchpad until enough bad data > is received that causes the driver to reset and "freeze". > What kind of glitch is this? Is there a certain pattern to it? Even if we do not reset the mouse the logs will be full of error messages. Thanks. > Signed-off-by: Mario Limonciello <mario_limonciello@dell.com> > --- > drivers/input/mouse/synaptics.c | 28 ++++++++++++++++++++++++++++ > 1 file changed, 28 insertions(+) > > diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c > index 7e705ee..4dc456c 100644 > --- a/drivers/input/mouse/synaptics.c > +++ b/drivers/input/mouse/synaptics.c > @@ -1244,6 +1244,21 @@ static int synaptics_reconnect(struct psmouse *psmouse) > return 0; > } > > +static bool dell_ec_glitch; > + > +static const struct dmi_system_id dell_dmi_table[] __initconst = { > +#if defined(CONFIG_DMI) && defined(CONFIG_X86) > + { > + /* XPS 13 (2015) */ > + .matches = { > + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), > + DMI_MATCH(DMI_PRODUCT_NAME, "XPS 13 9343"), > + }, > + }, > + { } > +#endif > +}; > + > static bool impaired_toshiba_kbc; > > static const struct dmi_system_id toshiba_dmi_table[] __initconst = { > @@ -1334,6 +1349,8 @@ void __init synaptics_module_init(void) > * so we have to resort to checking DMI. > */ > is_forcepad = dmi_check_system(forcepad_dmi_table); > + dell_ec_glitch = dmi_check_system(dell_dmi_table); > + > } > > static int __synaptics_init(struct psmouse *psmouse, bool absolute_mode) > @@ -1426,6 +1443,17 @@ static int __synaptics_init(struct psmouse *psmouse, bool absolute_mode) > psmouse->rate = 40; > } > > + /* > + * Some Dell touchpads have a problem where the EC will glitch causing > + * bad packets that are otherwise harmless unless they cause psmouse > + * to reset. > + */ > + if (psmouse->resetafter > 0 && dell_ec_glitch) { > + psmouse_info(psmouse, "Dell %s detected, disabling tpad reset.\n", > + dmi_get_system_info(DMI_PRODUCT_NAME)); > + psmouse->resetafter = 0; > + } > + > if (!priv->absolute_mode && SYN_ID_DISGEST_SUPPORTED(priv->identity)) { > err = device_create_file(&psmouse->ps2dev.serio->dev, > &psmouse_attr_disable_gesture.dattr); > -- > 1.9.1 >
Hi Dmitry, On 02/19/2015 11:16 AM, Dmitry Torokhov wrote: > > What kind of glitch is this? Is there a certain pattern to it? Even if we do > not reset the mouse the logs will be full of error messages. > > Thanks. > From waveform capture data leaving the touchpad is valid, but when it is resent through the EC it's getting corrupted. This isn't exclusive to Linux setting it up wrong or anything, it also happens on Windows. On Windows 7 the touchpad driver does not issue a reset from the bad data however. The glitch is more prevalent as the machine is turned on but seems to go away after it's been running a while. We currently don't believe it to be a problem with the EC firmware, but we are still exploring other firmware based solutions. Yes, the logs do fill up with error messages about the bad data within the first few minutes of usage. In my opinion not freezing but getting errors in the log is better than freezing and getting errors in the log, so we're at least trying to provide a workaround for the problem. If we come up with a firmware based solution I'd be happy to adjust or remove this later. Thanks, -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Mario, On Thu, Feb 19, 2015 at 12:16:51PM -0600, Mario Limonciello wrote: > Hi Dmitry, > > On 02/19/2015 11:16 AM, Dmitry Torokhov wrote: > > > >What kind of glitch is this? Is there a certain pattern to it? Even if we do > >not reset the mouse the logs will be full of error messages. > > > >Thanks. > > > From waveform capture data leaving the touchpad is valid, but when it is > resent through the EC it's getting corrupted. This isn't exclusive to Linux > setting it up wrong or anything, it also happens on Windows. On Windows 7 > the touchpad driver does not issue a reset from the bad data however. > > The glitch is more prevalent as the machine is turned on but seems to go away > after it's been running a while. We currently don't believe it to be a > problem with the EC firmware, but we are still exploring other firmware based > solutions. Can it be related to ther Dell models (Latitudes with ALPS touchpad) also sending junk data under certain conditions (adding Pali to teh CC as he was looking at this issue)? > > Yes, the logs do fill up with error messages about the bad data within the > first few minutes of usage. In my opinion not freezing but getting errors in > the log is better than freezing and getting errors in the log, so we're at > least trying to provide a workaround for the problem. If we come up with a > firmware based solution I'd be happy to adjust or remove this later. I am not saying we do not need the solution, I am wondering if we can suppress errors altogether. I am also curious why reset does not work as it should reinitialize the driver completely. And even if you do fix the firmware majority of users will still need the software solution as updating BIOS is not something that happens often. Thanks.
On Friday 20 February 2015 19:47:17 Dmitry Torokhov wrote: > Hi Mario, > > On Thu, Feb 19, 2015 at 12:16:51PM -0600, Mario Limonciello wrote: > > Hi Dmitry, > > > > On 02/19/2015 11:16 AM, Dmitry Torokhov wrote: > > >What kind of glitch is this? Is there a certain pattern to > > >it? Even if we do not reset the mouse the logs will be > > >full of error messages. > > > > > >Thanks. > > > > From waveform capture data leaving the touchpad is valid, > > but when it is resent through the EC it's getting > > corrupted. This isn't exclusive to Linux setting it up > > wrong or anything, it also happens on Windows. On Windows > > 7 the touchpad driver does not issue a reset from the bad > > data however. > > > > The glitch is more prevalent as the machine is turned on but > > seems to go away after it's been running a while. We > > currently don't believe it to be a problem with the EC > > firmware, but we are still exploring other firmware based > > solutions. > > Can it be related to ther Dell models (Latitudes with ALPS > touchpad) also sending junk data under certain conditions > (adding Pali to teh CC as he was looking at this issue)? > Dell Latitude Exx40 models (with ALPS touchpads) have similar problems. Linux psmouse.ko/alps.c driver receive invalid packets which cause lot of problems... ALPS people told me those packets which was found on i8042 bus are really invalid ALPS packets and do not come from ALPS touchpad. Unless there is invisible bug in ALPS touchpad firmware (which was not discovered yet), problem is either in Dell EmeddedController where is connected ALPS touchpad or in Dell BIOS/UEFI (which I believe can modify any such data). If Dell share EC firmware code in more models (Latitude and XPS) or share some BIOS parts, then problem can be really there. > > Yes, the logs do fill up with error messages about the bad > > data within the first few minutes of usage. In my opinion > > not freezing but getting errors in the log is better than > > freezing and getting errors in the log, so we're at least > > trying to provide a workaround for the problem. If we come > > up with a firmware based solution I'd be happy to adjust or > > remove this later. > > I am not saying we do not need the solution, I am wondering if > we can suppress errors altogether. I am also curious why > reset does not work as it should reinitialize the driver > completely. > > And even if you do fix the firmware majority of users will > still need the software solution as updating BIOS is not > something that happens often. > > Thanks. I do not know what can kernel do when it receive invalid PS/2 data from i8042 bus. If bogus packets are total random we can just try to ignore them and try be not out-of-sync. No idea how working solution it would be for new XPS model. Looks like for Latitude Exx40 models with their problems it is working... Of course correct way is to fix firmware or BIOS or which part of HW is buggy. Ideally distribute that firmware fix to users. I heard that synaptics touchpad supports something like on-the-fly firmware load (without flashing it) which will be active until notebook shutdown.
Hi Pali & Dmitry, On 02/20/2015 01:24 PM, Pali Rohár wrote: > On Friday 20 February 2015 19:47:17 Dmitry Torokhov wrote: >> Hi Mario, >> >> On Thu, Feb 19, 2015 at 12:16:51PM -0600, Mario Limonciello > wrote: >> >> Can it be related to ther Dell models (Latitudes with ALPS >> touchpad) also sending junk data under certain conditions >> (adding Pali to teh CC as he was looking at this issue)? >> We use the same embedded controller design and codebase on many of our laptops. Depending on the root cause, it's possible to be the same problem that's happening on Latitude 6x40. I'm leaning on it's likely not the same problem though because on Latitude 6x40 II understand the issue does not show up on the other side of the EC when the waveform was analyzed in Windows. > Dell Latitude Exx40 models (with ALPS touchpads) have similar > problems. Linux psmouse.ko/alps.c driver receive invalid packets > which cause lot of problems... ALPS people told me those packets > which was found on i8042 bus are really invalid ALPS packets and > do not come from ALPS touchpad. Unless there is invisible bug in > ALPS touchpad firmware (which was not discovered yet), problem is > either in Dell EmeddedController where is connected ALPS touchpad > or in Dell BIOS/UEFI (which I believe can modify any such data). A colleague has shared to me some information about the issue on 6x40 laptops as well. There was a recent EC change (released within last 2 weeks or so) that helps to fix problems with i8042 traffic. It was intended to fix keyboard repeating, but it may also fix the touchpad data. Can you please confirm if the new BIOS/EC update fixes the problem? > If Dell share EC firmware code in more models (Latitude and XPS) > or share some BIOS parts, then problem can be really there. > Yes, specifically with XPS 13 (2015) the code base for the EC has common components with Latitude and Precision. For the XPS problem, the EC code has been reviewed but not found any issues with it pointing to an EC problem. There are other aspects that are being explored such as the input to the EC being overamplified by a mis configured buffer in the touchpad. This would cause the data to saturate outside of spec in the EC. >>> Yes, the logs do fill up with error messages about the bad >>> data within the first few minutes of usage. In my opinion >>> not freezing but getting errors in the log is better than >>> freezing and getting errors in the log, so we're at least >>> trying to provide a workaround for the problem. If we come >>> up with a firmware based solution I'd be happy to adjust or >>> remove this later. >> I am not saying we do not need the solution, I am wondering if >> we can suppress errors altogether. I am also curious why >> reset does not work as it should reinitialize the driver >> completely. Thanks. I think it's fair to hide them when resetafter=0 is configured (such as the quirk turns on). If you agree, i'll adjust the patch to do this. To clarify the problem, the errors will show up and after 5 the touchpad is reset. The reset is what causes the freeze because the touchpad driver takes 1-3 seconds to reinitialize. The problem will happen continue to happen though as it's believed to be higher up the chain. If resetafter=0 is set, the errors will show up in the logs, but the touchpad recovers on it's own. >> >> And even if you do fix the firmware majority of users will >> still need the software solution as updating BIOS is not >> something that happens often. >> >> Thanks. Yes, thanks I agree on this. We are working on making firmware flash on Latitude/Precision/XPS easier for Linux users, but we're not there yet on everything. If you look on XPS 13 (2015) it's one of the first to support firmware flash from F12 boot menu. It will search any USB disks and partitions that firmware can mount such as EFI system partition. > I do not know what can kernel do when it receive invalid PS/2 > data from i8042 bus. If bogus packets are total random we can > just try to ignore them and try be not out-of-sync. No idea how > working solution it would be for new XPS model. Looks like for > Latitude Exx40 models with their problems it is working... > > Of course correct way is to fix firmware or BIOS or which part of > HW is buggy. Ideally distribute that firmware fix to users. I > heard that synaptics touchpad supports something like on-the-fly > firmware load (without flashing it) which will be active until > notebook shutdown. > Yes, if we can fix this in firmware, that's our goal too. If/when we get a firmware fix, the quirk can be configured to only activate on earlier versions of the firmware that are affected. I'm not aware of the on-the-fly firmware load for Synaptics. Do you know more about this? In dual mode touchpads is this only present on the I2C mode? -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 20 February 2015 20:56:23 Mario Limonciello wrote: > Hi Pali & Dmitry, > > On 02/20/2015 01:24 PM, Pali Rohár wrote: > > On Friday 20 February 2015 19:47:17 Dmitry Torokhov wrote: > >> Hi Mario, > >> > >> On Thu, Feb 19, 2015 at 12:16:51PM -0600, Mario Limonciello > > > > wrote: > >> Can it be related to ther Dell models (Latitudes with ALPS > >> touchpad) also sending junk data under certain conditions > >> (adding Pali to teh CC as he was looking at this issue)? > > We use the same embedded controller design and codebase on > many of our laptops. Depending on the root cause, it's > possible to be the same problem that's happening on Latitude > 6x40. I'm leaning on it's likely not the same problem though > because on Latitude 6x40 II understand the issue does not > show up on the other side of the EC when the waveform was > analyzed in Windows. > > > Dell Latitude Exx40 models (with ALPS touchpads) have > > similar problems. Linux psmouse.ko/alps.c driver receive > > invalid packets which cause lot of problems... ALPS people > > told me those packets which was found on i8042 bus are > > really invalid ALPS packets and do not come from ALPS > > touchpad. Unless there is invisible bug in ALPS touchpad > > firmware (which was not discovered yet), problem is either > > in Dell EmeddedController where is connected ALPS touchpad > > or in Dell BIOS/UEFI (which I believe can modify any such > > data). > > A colleague has shared to me some information about the issue > on 6x40 laptops as well. There was a recent EC change > (released within last 2 weeks or so) that helps to fix > problems with i8042 traffic. It was intended to fix keyboard > repeating, but it may also fix the touchpad data. Can you > please confirm if the new BIOS/EC update fixes the problem? > 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? > > If Dell share EC firmware code in more models (Latitude and > > XPS) or share some BIOS parts, then problem can be really > > there. > > Yes, specifically with XPS 13 (2015) the code base for the EC > has common components with Latitude and Precision. For the > XPS problem, the EC code has been reviewed but not found any > issues with it pointing to an EC problem. There are other > aspects that are being explored such as the input to the EC > being overamplified by a mis configured buffer in the > touchpad. This would cause the data to saturate outside of > spec in the EC. > > >>> Yes, the logs do fill up with error messages about the bad > >>> data within the first few minutes of usage. In my opinion > >>> not freezing but getting errors in the log is better than > >>> freezing and getting errors in the log, so we're at least > >>> trying to provide a workaround for the problem. If we > >>> come up with a firmware based solution I'd be happy to > >>> adjust or remove this later. > >> > >> I am not saying we do not need the solution, I am wondering > >> if we can suppress errors altogether. I am also curious > >> why reset does not work as it should reinitialize the > >> driver completely. > > Thanks. I think it's fair to hide them when resetafter=0 is > configured (such as the quirk turns on). If you agree, i'll > adjust the patch to do this. To clarify the problem, the > errors will show up and after 5 the touchpad is reset. The > reset is what causes the freeze because the touchpad driver > takes 1-3 seconds to reinitialize. The problem will happen > continue to happen though as it's believed to be higher up > the chain. If resetafter=0 is set, the errors will show up in > the logs, but the touchpad recovers on it's own. > 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). > >> And even if you do fix the firmware majority of users will > >> still need the software solution as updating BIOS is not > >> something that happens often. > >> > >> Thanks. > > Yes, thanks I agree on this. We are working on making > firmware flash on Latitude/Precision/XPS easier for Linux > users, but we're not there yet on everything. If you look on > XPS 13 (2015) it's one of the first to support firmware flash > from F12 boot menu. It will search any USB disks and > partitions that firmware can mount such as EFI system > partition. > 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 > > I do not know what can kernel do when it receive invalid > > PS/2 data from i8042 bus. If bogus packets are total random > > we can just try to ignore them and try be not out-of-sync. > > No idea how working solution it would be for new XPS model. > > Looks like for Latitude Exx40 models with their problems it > > is working... > > > > Of course correct way is to fix firmware or BIOS or which > > part of HW is buggy. Ideally distribute that firmware fix > > to users. I heard that synaptics touchpad supports > > something like on-the-fly firmware load (without flashing > > it) which will be active until notebook shutdown. > > Yes, if we can fix this in firmware, that's our goal too. > If/when we get a firmware fix, the quirk can be configured to > only activate on earlier versions of the firmware that are > affected. > > I'm not aware of the on-the-fly firmware load for Synaptics. > Do you know more about this? In dual mode touchpads is this > only present on the I2C mode? 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".
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Feb 20, 2015 at 4:21 PM, Mario Limonciello <mario_limonciello@dell.com> wrote: > > On 02/20/2015 02:41 PM, Pali Rohár wrote: >> [snipped] > >> 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. > > What is most likely happening is that the synaptics driver switches the touchpad into the i2c/hid protocol. And yes Synaptics told us that only a reset re-enables the touchpad in the PS/2 mode. Kernels 3.11 and later know how to deal with this mode (through hid-rmi), so we should not see these problems in the future unless hid-rmi is not compiled in the running kernel. Fortunately, we can deal with the Dell/Synaptics touchpads, the Lenovo ones are using SMBus, and we have never been able to talk to the devices with SMBus :( Cheers, Benjamin -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/20/2015 03:31 PM, Benjamin Tissoires wrote: > > What is most likely happening is that the synaptics driver switches > the touchpad into the i2c/hid protocol. And yes Synaptics told us that > only a reset re-enables the touchpad in the PS/2 mode. > Kernels 3.11 and later know how to deal with this mode (through > hid-rmi), so we should not see these problems in the future unless > hid-rmi is not compiled in the running kernel. > > Fortunately, we can deal with the Dell/Synaptics touchpads, the Lenovo > ones are using SMBus, and we have never been able to talk to the > devices with SMBus :( > > Cheers, > Benjamin Ah, yeah that makes more sense to me. And actually the newer touchpads like the one in the XPS 13 (2015) are microsoft precision touchpads. They don't even bother with hid-rmi. When in I2C mode the hid-multitouch and i2c-hid driver handle them sufficiently sans a patch that just hit linux-input to fix a problem introduced in 3.19 (and 3.18.3). For clarities sake: The touchpad in the XPS 13 (2015) will run in I2C or PS2 modes. When_OSI of Windows 2013 is recognized it will be put into I2C mode. I know that the current kernel does recognize Windows 2013 _OSI so by default the touchpad will be in I2C mode with a new kernel. Unfortunately this also puts the sound card into I2S mode which is not yet supported by Linux. This is being worked out separately, but currently we are recommending that customers use acpi_osi="!Windows 2013" to use the touchpad in PS2 and soundcard in HDA modes. Obviously this patch isn't applicable when running the touchpad is running in I2C mode. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 20 February 2015 22:40:38 Mario Limonciello wrote: > On 02/20/2015 03:31 PM, Benjamin Tissoires wrote: > > What is most likely happening is that the synaptics driver > > switches the touchpad into the i2c/hid protocol. And yes > > Synaptics told us that only a reset re-enables the touchpad > > in the PS/2 mode. Kernels 3.11 and later know how to deal > > with this mode (through hid-rmi), so we should not see > > these problems in the future unless hid-rmi is not compiled > > in the running kernel. > > > > Fortunately, we can deal with the Dell/Synaptics touchpads, > > the Lenovo ones are using SMBus, and we have never been > > able to talk to the devices with SMBus :( > > > > Cheers, > > Benjamin > > Ah, yeah that makes more sense to me. And actually the newer > touchpads like the one in the XPS 13 (2015) are microsoft > precision touchpads. They don't even bother with hid-rmi. > When in I2C mode the hid-multitouch and i2c-hid driver handle > them sufficiently sans a patch that just hit linux-input to > fix a problem introduced in 3.19 (and 3.18.3). > > For clarities sake: > The touchpad in the XPS 13 (2015) will run in I2C or PS2 > modes. When_OSI of Windows 2013 is recognized it will be put > into I2C mode. I know that the current kernel does recognize > Windows 2013 _OSI so by default the touchpad will be in I2C > mode with a new kernel. Unfortunately this also puts the > sound card into I2S mode which is not yet supported by Linux. > This is being worked out separately, but currently we are > recommending that customers use acpi_osi="!Windows 2013" to > use the touchpad in PS2 and soundcard in HDA modes. > > Obviously this patch isn't applicable when running the > touchpad is running in I2C mode. Maybe stupid question, but cannot you call that code which put sound card into HDA mode from kernel? It could fix problem when either sound or touchpad is not working...
On 02/20/2015 03:46 PM, Pali Rohár wrote: > On Friday 20 February 2015 22:40:38 Mario Limonciello wrote: > Maybe stupid question, but cannot you call that code which put > sound card into HDA mode from kernel? It could fix problem when > either sound or touchpad is not working... > As I understand with the HW and FW design this action needs to be done from the EC and it's only effective for "the next boot". The current boot will use the value cached from previous boot. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 20 February 2015 22:21:43 Mario Limonciello wrote: > 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. > Thank you for information! Mario, do you know if it is possible to "switch" keyboard into mode under which Fn key will send scancode (like Ctrl or Alt) when presses, so it could be possible to use any Fn+key combination for keyboard shortcuts? Because now Fn+F* send one scancode (e.g. suspend key) and other combination of Fn+something does not work... Dmitry, should not Linux follow this Windows input behaviour? For year we have seen people complaining about non working keyboard on Dell laptops under Linux (when user Windows it worked)... Now that BIOS/EC problem is fixed for some dell laptops (probably new versions of BIOSes for other modules will be released too), but it is really bad to see *new* laptop (with broken BIOS) that does not work under Linux (and work under Windows)...
On 02/22/2015 10:55 AM, Pali Rohár wrote: > Thank you for information! Sure, no problem. > Mario, do you know if it is possible to "switch" keyboard into > mode under which Fn key will send scancode (like Ctrl or Alt) > when presses, so it could be possible to use any Fn+key > combination for keyboard shortcuts? Because now Fn+F* send one > scancode (e.g. suspend key) and other combination of Fn+something > does not work... Sorry, this is not possible with today's BIOS and EC as I am aware. I'll inquire about this for the future though. > Dmitry, should not Linux follow this Windows input behaviour? For > year we have seen people complaining about non working keyboard > on Dell laptops under Linux (when user Windows it worked)... This is a bit surprising to me. Completely non-working? Or similar problem to what's getting fixed in the BIOS update we discussed above? > Now that BIOS/EC problem is fixed for some dell laptops (probably > new versions of BIOSes for other modules will be released too), > but it is really bad to see *new* laptop (with broken BIOS) that > does not work under Linux (and work under Windows)... > Yes, if you're aware of any models that are not fixed by the BIOS update this month, I would be interested to know. A majority of our hardware does undergo testing with Linux during development, so usually these types of things are caught. Once we declare a BIOS stable it's a much lengthier process to issue future fixes however. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 24 February 2015 00:31:52 Mario Limonciello wrote: > On 02/22/2015 10:55 AM, Pali Rohár wrote: > > Thank you for information! > > Sure, no problem. > > > Mario, do you know if it is possible to "switch" keyboard > > into mode under which Fn key will send scancode (like Ctrl > > or Alt) when presses, so it could be possible to use any > > Fn+key combination for keyboard shortcuts? Because now > > Fn+F* send one scancode (e.g. suspend key) and other > > combination of Fn+something does not work... > > Sorry, this is not possible with today's BIOS and EC as I am > aware. I'll inquire about this for the future though. > For older dell models (some old inspirions and maybe also latitude) it was possible to use undocumented DELLDIAG interface (which enter into SMM mode and call some functions) to enable that "RAW" mode. Now when you are discussing with us, do you have some information or can you comment (if it is not secret) that DELLDIAG SMM interface? In linux kernel we have for it driver (provides info about temperature, fan speed, power management, hotkeys, ...), but it use undocumented interface (and sometimes it has problems): https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/i8k.c > > Dmitry, should not Linux follow this Windows input > > behaviour? For year we have seen people complaining about > > non working keyboard on Dell laptops under Linux (when user > > Windows it worked)... > > This is a bit surprising to me. Completely non-working? Or > similar problem to what's getting fixed in the BIOS update we > discussed above? > Nothing new. It is that problem with repeating keys which is fixed by last version of BIOS. I saw one E6440 model with preinstalled Ubuntu 12.04.2 and distributed with A08 BIOS (which had that problem). And this was very very annoying! You could imagine it, you buy new Latitude (business class pro notebook), you started it and on preinstalled OS, keyboard is not usable. Updating to A10 fixed it. > > Now that BIOS/EC problem is fixed for some dell laptops > > (probably new versions of BIOSes for other modules will be > > released too), but it is really bad to see *new* laptop > > (with broken BIOS) that does not work under Linux (and work > > under Windows)... > > Yes, if you're aware of any models that are not fixed by the > BIOS update this month, I would be interested to know. A > majority of our hardware does undergo testing with Linux > during development, so usually these types of things are > caught. Once we declare a BIOS stable it's a much lengthier > process to issue future fixes however. In this forum thread people reported that "repeating keys" problem for more models: http://en.community.dell.com/support-forums/laptop/f/3518/t/19593360?pi239031352=19 And it looks like (from what I'm reading) last version A10 of E6440 BIOS broke USB3.0 support.
On Sun, Feb 22, 2015 at 05:55:05PM +0100, Pali Rohár wrote: > On Friday 20 February 2015 22:21:43 Mario Limonciello wrote: > > 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. > > > > Thank you for information! > > Mario, do you know if it is possible to "switch" keyboard into > mode under which Fn key will send scancode (like Ctrl or Alt) > when presses, so it could be possible to use any Fn+key > combination for keyboard shortcuts? Because now Fn+F* send one > scancode (e.g. suspend key) and other combination of Fn+something > does not work... > > Dmitry, should not Linux follow this Windows input behaviour? For > year we have seen people complaining about non working keyboard > on Dell laptops under Linux (when user Windows it worked)... I am not sure what exactly the issue is... We do need to have the break code to know when the key is released. We can't go and say that we will release old key when we detect another key press as that would mess up key combination handling (like control, meta, etc). What does Windows driver do? Thanks.
On 02/23/2015 06:01 PM, Pali Rohár wrote: > On Tuesday 24 February 2015 00:31:52 Mario Limonciello wrote: > For older dell models (some old inspirions and maybe also > latitude) it was possible to use undocumented DELLDIAG interface > (which enter into SMM mode and call some functions) to enable > that "RAW" mode. > > Now when you are discussing with us, do you have some information > or can you comment (if it is not secret) that DELLDIAG SMM > interface? > > In linux kernel we have for it driver (provides info about > temperature, fan speed, power management, hotkeys, ...), but it > use undocumented interface (and sometimes it has problems): > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/i8k.c I don't have any more information I can share on this interface other than I wouldn't recommend to rely on it. It's generally not supposed to be used by the OS but only for diagnostic purposes from BIOS level diagnostic tools. > Nothing new. It is that problem with repeating keys which is > fixed by last version of BIOS. > > I saw one E6440 model with preinstalled Ubuntu 12.04.2 and > distributed with A08 BIOS (which had that problem). And this was > very very annoying! You could imagine it, you buy new Latitude > (business class pro notebook), you started it and on preinstalled > OS, keyboard is not usable. Updating to A10 fixed it. > I'm sorry that this had actually made it out the door with a pre-installed machine, but I'm glad we were able to get it fixed in the field. > In this forum thread people reported that "repeating keys" > problem for more models: http://en.community.dell.com/support-forums/laptop/f/3518/t/19593360?pi239031352=19 Yes, there is a support agent in that thread relaying those models to the BIOS team. > And it looks like (from what I'm reading) last version A10 of > E6440 BIOS broke USB3.0 support. > -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/23/2015 06:51 PM, Dmitry Torokhov wrote: > On Sun, Feb 22, 2015 at 05:55:05PM +0100, Pali Rohár wrote: > I am not sure what exactly the issue is... We do need to have the break > code to know when the key is released. We can't go and say that we will > release old key when we detect another key press as that would mess up > key combination handling (like control, meta, etc). > > What does Windows driver do? > > Thanks. > To me it sounds like the Windows driver understands a situation that there are a bunch of key down events without a keyup event until you lift your finger rather than expecting a pair every time. https://msdn.microsoft.com/en-us/library/windows/desktop/ms646267(v=vs.85).aspx -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/20/2015 02:41 PM, Pali Rohár wrote: > On Friday 20 February 2015 20:56:23 Mario Limonciello wrote: > > 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). > Pali, I've done some experimentation with increasing the size to resetafter to up to pktsize * 4. It will decrease the number of occurrences of this problem, but the problem still occurs eventually. pktsize for synaptics is 6 as well. Would you recommend to continue to go higher than that? Since out_of_sync_cnt is reset when a full packet gets received, some arbitrarily high number should likely fix it to. That being said, if you try to more closely follow what Windows does for the mouse, it's not issuing a reconnect no matter how much bad data is received. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 25 February 2015 19:48:55 Mario Limonciello wrote: > On 02/20/2015 02:41 PM, Pali Rohár wrote: > > On Friday 20 February 2015 20:56:23 Mario Limonciello wrote: > > > > 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). > > Pali, > > I've done some experimentation with increasing the size to > resetafter to up to pktsize * 4. It will decrease the number > of occurrences of this problem, but the problem still occurs > eventually. pktsize for synaptics is 6 as well. Would you > recommend to continue to go higher than that? Since > out_of_sync_cnt is reset when a full packet gets received, > some arbitrarily high number should likely fix it to. > > That being said, if you try to more closely follow what > Windows does for the mouse, it's not issuing a reconnect no > matter how much bad data is received. I believe problem is similar to one as with ALPS devices. Driver always receive 6 bytes packet of data (no new byte is inserted and no byte is never lost), just one byte in packet is incorrect (does not match specification). Setting resetafter to > 0 prevent problems when driver enters into undefined state (either by bug in driver of other SW/HW problem). So I think setting resetafter to 0 is not good idea. But if we know that setting resetafter to 4*pktsize is not enough (e.g. with experimenting you saw that driver received more then 4 invalid packets consecutively), set it to higher value. I think it is still good idea to ignore maximally as many packets which can be received in time which is equal to resetting device. E.g. when period of time in which we are dropping all packets is higher then time needed to reset touchpad, we should stop dropping packets and immediately reset touchpad. In this case we could hit maybe problem in driver (there can be bugs) or touchpad is in some bad state and out-of-sync... So if your tests show that there are never invalid 10 packets consecutively, then set resetafter to 10 packets. Value 10 is still not high and if it fix problem with touchpad I think it is acceptable. But rather ask Dmitry what he thinks about it. This is just my opinion.
[top posting, sorry] Jason made some interesting progress today: with the patch in https://lkml.org/lkml/2015/3/12/149, the sound card is not switched in the I2S mode and works while the touchpad keeps using I2C. It looks like suspend/resume is also fixed by that :) I thought it was worth mentioning to the people in this thread. Cheers, Benjamin On Wed, Feb 25, 2015 at 3:45 PM, Pali Rohár <pali.rohar@gmail.com> wrote: > On Wednesday 25 February 2015 19:48:55 Mario Limonciello wrote: >> On 02/20/2015 02:41 PM, Pali Rohár wrote: >> > On Friday 20 February 2015 20:56:23 Mario Limonciello wrote: >> > >> > 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). >> >> Pali, >> >> I've done some experimentation with increasing the size to >> resetafter to up to pktsize * 4. It will decrease the number >> of occurrences of this problem, but the problem still occurs >> eventually. pktsize for synaptics is 6 as well. Would you >> recommend to continue to go higher than that? Since >> out_of_sync_cnt is reset when a full packet gets received, >> some arbitrarily high number should likely fix it to. >> >> That being said, if you try to more closely follow what >> Windows does for the mouse, it's not issuing a reconnect no >> matter how much bad data is received. > > I believe problem is similar to one as with ALPS devices. Driver > always receive 6 bytes packet of data (no new byte is inserted > and no byte is never lost), just one byte in packet is incorrect > (does not match specification). > > Setting resetafter to > 0 prevent problems when driver enters > into undefined state (either by bug in driver of other SW/HW > problem). So I think setting resetafter to 0 is not good idea. > > But if we know that setting resetafter to 4*pktsize is not enough > (e.g. with experimenting you saw that driver received more then 4 > invalid packets consecutively), set it to higher value. > > I think it is still good idea to ignore maximally as many packets > which can be received in time which is equal to resetting device. > > E.g. when period of time in which we are dropping all packets is > higher then time needed to reset touchpad, we should stop > dropping packets and immediately reset touchpad. In this case we > could hit maybe problem in driver (there can be bugs) or touchpad > is in some bad state and out-of-sync... > > So if your tests show that there are never invalid 10 packets > consecutively, then set resetafter to 10 packets. Value 10 is > still not high and if it fix problem with touchpad I think it is > acceptable. But rather ask Dmitry what he thinks about it. This > is just my opinion. > > -- > Pali Rohár > pali.rohar@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/14/2015 02:17 PM, Benjamin Tissoires wrote: > [top posting, sorry] > > Jason made some interesting progress today: > with the patch in https://lkml.org/lkml/2015/3/12/149, the sound card > is not switched in the I2S mode and works while the touchpad keeps > using I2C. > It looks like suspend/resume is also fixed by that :) > > I thought it was worth mentioning to the people in this thread. > > Cheers, > Benjamin Benjamin, Thanks for reporting the progress to me. Jason, Are you sure upon the particulars of what's happening here? That patch only modifies the behavior of how the EC is configured. I'm not aware of any suspend/resume issues, especially related to the EC, so that really surprises me. My initial suspicion is a suspend/resume issue you encountered was rare enough that you just haven't hit it yet even with that patch applied. Maybe something in the out of kernel Broadcom wireless driver if you are still using the Broadcom card with it. I believe you are incorrect in the audio being put in HDA mode. It's more likely that it's operating closer to properly in I2S mode. Here's some background around what that patch is doing. When this platform started development the Linux kernel didn't yet respond true to Windows 2013. All our validation for Linux happened on kernel 3.13. _OSI of Windows 2009 is supposed to set it for PS2 mouse, HDA device in ACPI and configure the EC to set up the Realtek codec for HDA mode. Linux was planned to mirror this behavior during development. _OSI of Windows 2013 is supposed to set it up for I2C mouse, I2S audio in ACPI and configure the EC to set up the Realtek codec for I2S mode. From when the platform was in development a _REV check was put in for Windows 2013 to make sure that in case the kernel started to respond to Windows 2013 we would still have it running in the intended modes for Linux. There was a mistake in this _REV check though that caused the I2S ACPI device but to misconfigure the EC. The reason _REV = 2 and _OSI = Windows 2013 you are getting working audio is the rt286 driver is starting to be used. You can validate this by looking at dmesg for lines about rt286. Realtek recently submitted some patches for this at Dell's request. There are still a variety of issues with the I2S driver including jack detection and some other microphone issues. Pulseaudio will possibly need some patches to work properly with this device too. Ideally we don't want customers to use I2S mode on Linux until it's solid. I don't believe this was in Linus' tree yet, so if you don't have it you can apply it and it should fix at least one microphone issue when in I2S mode. http://mailman.alsa-project.org/pipermail/alsa-devel/2015-March/088724.html Whether or not that _REV patch gets applied to the kernel we are fixing this incorrect behavior for Windows 2013 _OSI and Linux in upcoming BIOS A02. In BIOS A02 there will still be a _REV check but it will do this: Windows 2013 _OSI, _REV 5: I2C mouse, HDA device in ACPI, configure EC for HDA mode. Windows 2013 _OSI, _REV 2: I2C mouse, I2S device in ACPI, configure EC for I2S mode. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Mar 16, 2015 at 10:29 AM, Mario Limonciello <mario_limonciello@dell.com> wrote: > > On 03/14/2015 02:17 PM, Benjamin Tissoires wrote: >> >> [top posting, sorry] >> >> Jason made some interesting progress today: >> with the patch in https://lkml.org/lkml/2015/3/12/149, the sound card >> is not switched in the I2S mode and works while the touchpad keeps >> using I2C. >> It looks like suspend/resume is also fixed by that :) >> >> I thought it was worth mentioning to the people in this thread. >> >> Cheers, >> Benjamin > > Benjamin, > > Thanks for reporting the progress to me. > > Jason, > > Are you sure upon the particulars of what's happening here? That patch only > modifies the behavior of how the EC is configured. > I'm not aware of any suspend/resume issues, especially related to the EC, so > that really surprises me. My initial suspicion is a suspend/resume issue > you encountered was rare enough that you just haven't hit it yet even with > that patch applied. Maybe something in the out of kernel Broadcom wireless > driver if you are still using the Broadcom card with it. > > I believe you are incorrect in the audio being put in HDA mode. It's more > likely that it's operating closer to properly in I2S mode. Here's some > background around what that patch is doing. Regarding the I2S/HDA problem, I guess I must have interpreted too much what Jason said. All he said was that the patch made his sound card working. [Adding Matthew to the thread, I am sure he will find it interesting] Cheers, Benjamin > When this platform started development the Linux kernel didn't yet respond > true to Windows 2013. All our validation for Linux happened on kernel 3.13. > > _OSI of Windows 2009 is supposed to set it for PS2 mouse, HDA device in ACPI > and configure the EC to set up the Realtek codec for HDA mode. Linux was > planned to mirror this behavior during development. > _OSI of Windows 2013 is supposed to set it up for I2C mouse, I2S audio in > ACPI and configure the EC to set up the Realtek codec for I2S mode. > > From when the platform was in development a _REV check was put in for > Windows 2013 to make sure that in case the kernel started to respond to > Windows 2013 we would still have it running in the intended modes for Linux. > There was a mistake in this _REV check though that caused the I2S ACPI > device but to misconfigure the EC. The reason _REV = 2 and _OSI = Windows > 2013 you are getting working audio is the rt286 driver is starting to be > used. You can validate this by looking at dmesg for lines about rt286. > Realtek recently submitted some patches for this at Dell's request. There > are still a variety of issues with the I2S driver including jack detection > and some other microphone issues. Pulseaudio will possibly need some > patches to work properly with this device too. Ideally we don't want > customers to use I2S mode on Linux until it's solid. > > I don't believe this was in Linus' tree yet, so if you don't have it you can > apply it and it should fix at least one microphone issue when in I2S mode. > http://mailman.alsa-project.org/pipermail/alsa-devel/2015-March/088724.html > > Whether or not that _REV patch gets applied to the kernel we are fixing this > incorrect behavior for Windows 2013 _OSI and Linux in upcoming BIOS A02. > In BIOS A02 there will still be a _REV check but it will do this: > Windows 2013 _OSI, _REV 5: I2C mouse, HDA device in ACPI, configure EC for > HDA mode. > Windows 2013 _OSI, _REV 2: I2C mouse, I2S device in ACPI, configure EC for > I2S mode. > > > -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Mar 16, 2015 at 7:29 AM, Mario Limonciello <mario_limonciello@dell.com> wrote: > > On 03/14/2015 02:17 PM, Benjamin Tissoires wrote: >> >> [top posting, sorry] >> >> Jason made some interesting progress today: >> with the patch in https://lkml.org/lkml/2015/3/12/149, the sound card >> is not switched in the I2S mode and works while the touchpad keeps >> using I2C. >> It looks like suspend/resume is also fixed by that :) >> >> I thought it was worth mentioning to the people in this thread. >> >> Cheers, >> Benjamin > > Benjamin, > > Thanks for reporting the progress to me. > > Jason, > > Are you sure upon the particulars of what's happening here? That patch only > modifies the behavior of how the EC is configured. > I'm not aware of any suspend/resume issues, especially related to the EC, so > that really surprises me. My initial suspicion is a suspend/resume issue > you encountered was rare enough that you just haven't hit it yet even with > that patch applied. Maybe something in the out of kernel Broadcom wireless > driver if you are still using the Broadcom card with it. It's nothing about the wireless. I swapped it out for an intel card on day 3 or so. Yes, I am almost 100% sure that this affects suspend/resume. Prior to the _REV hack, my laptop *never* suspended correctly. Now it regularly suspends just fine. I also double-checked that rebasing on Linus' master didn't affect it. With the _REV hack it doesn't suspend. Without it, it's just fine. I don't know much about suspend/resume but is it possible that the problem is the kernel not being able to properly shut down the sound card? > I believe you are incorrect in the audio being put in HDA mode. It's more > likely that it's operating closer to properly in I2S mode. Here's some > background around what that patch is doing. > When this platform started development the Linux kernel didn't yet respond > true to Windows 2013. All our validation for Linux happened on kernel 3.13. That matches what I've seen. With the _REV hack, I see nothing about HDA in dmesg and I get different audio messages than with an _OSI of Windows 2009. > _OSI of Windows 2009 is supposed to set it for PS2 mouse, HDA device in ACPI > and configure the EC to set up the Realtek codec for HDA mode. Linux was > planned to mirror this behavior during development. > _OSI of Windows 2013 is supposed to set it up for I2C mouse, I2S audio in > ACPI and configure the EC to set up the Realtek codec for I2S mode. > > From when the platform was in development a _REV check was put in for > Windows 2013 to make sure that in case the kernel started to respond to > Windows 2013 we would still have it running in the intended modes for Linux. > There was a mistake in this _REV check though that caused the I2S ACPI > device but to misconfigure the EC. The reason _REV = 2 and _OSI = Windows > 2013 you are getting working audio is the rt286 driver is starting to be > used. You can validate this by looking at dmesg for lines about rt286. > Realtek recently submitted some patches for this at Dell's request. There > are still a variety of issues with the I2S driver including jack detection > and some other microphone issues. Pulseaudio will possibly need some > patches to work properly with this device too. Ideally we don't want > customers to use I2S mode on Linux until it's solid. > > I don't believe this was in Linus' tree yet, so if you don't have it you can > apply it and it should fix at least one microphone issue when in I2S mode. > http://mailman.alsa-project.org/pipermail/alsa-devel/2015-March/088724.html > > Whether or not that _REV patch gets applied to the kernel we are fixing this > incorrect behavior for Windows 2013 _OSI and Linux in upcoming BIOS A02. > In BIOS A02 there will still be a _REV check but it will do this: > Windows 2013 _OSI, _REV 5: I2C mouse, HDA device in ACPI, configure EC for > HDA mode. > Windows 2013 _OSI, _REV 2: I2C mouse, I2S device in ACPI, configure EC for > I2S mode. I look forward to seeing the update. Thanks for working on this! --Jason Ekstrand -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Mario, It's great to hear from someone with knowledge of the inner workings of Dell's firmware. Mario Limonciello <mario_limonciello@dell.com> writes: > Hi Pali & Dmitry, > > On 02/20/2015 01:24 PM, Pali Rohár wrote: >> On Friday 20 February 2015 19:47:17 Dmitry Torokhov wrote: snip >> Dell Latitude Exx40 models (with ALPS touchpads) have similar >> problems. Linux psmouse.ko/alps.c driver receive invalid packets >> which cause lot of problems... ALPS people told me those packets >> which was found on i8042 bus are really invalid ALPS packets and >> do not come from ALPS touchpad. Unless there is invisible bug in >> ALPS touchpad firmware (which was not discovered yet), problem is >> either in Dell EmeddedController where is connected ALPS touchpad >> or in Dell BIOS/UEFI (which I believe can modify any such data). > > A colleague has shared to me some information about the issue on 6x40 > laptops as well. There was a recent EC change (released within last 2 > weeks or so) that helps to fix problems with i8042 traffic. It was > intended to fix keyboard repeating, but it may also fix the touchpad > data. Can you please confirm if the new BIOS/EC update fixes the > problem? > As you likely know, the same issue is also known [1,2,3] to occur on the Latitude 7440. I own a Latitude 7440 which now runs the A14 BIOS. This revision indeed fixes the keyboard repeat issue although the touchpad issues remain. In particular the driver loses sync on resume from S3 and occassionally during normal operation (particularly during multitouch events it seems). I've also noticed it sometimes occurs when I start using an X session that has been idle for long enough that the panel is blanked. For reasons I've not yet had a chance to identify, switching away from my X session to a VT and back to X appears to reset the driver and stop the errant events. Cheers, - Ben [1] https://bugzilla.kernel.org/show_bug.cgi?id=8740 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1145954 [3] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1258837
On Wednesday 25 February 2015 21:45:22 Pali Rohár wrote: > On Wednesday 25 February 2015 19:48:55 Mario Limonciello wrote: > > On 02/20/2015 02:41 PM, Pali Rohár wrote: > > > On Friday 20 February 2015 20:56:23 Mario Limonciello > > > wrote: > > > > > > 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). > > > > Pali, > > > > I've done some experimentation with increasing the size to > > resetafter to up to pktsize * 4. It will decrease the > > number of occurrences of this problem, but the problem > > still occurs eventually. pktsize for synaptics is 6 as > > well. Would you recommend to continue to go higher than > > that? Since out_of_sync_cnt is reset when a full packet > > gets received, some arbitrarily high number should likely > > fix it to. > > > > That being said, if you try to more closely follow what > > Windows does for the mouse, it's not issuing a reconnect no > > matter how much bad data is received. > > I believe problem is similar to one as with ALPS devices. > Driver always receive 6 bytes packet of data (no new byte is > inserted and no byte is never lost), just one byte in packet > is incorrect (does not match specification). > > Setting resetafter to > 0 prevent problems when driver enters > into undefined state (either by bug in driver of other SW/HW > problem). So I think setting resetafter to 0 is not good idea. > > But if we know that setting resetafter to 4*pktsize is not > enough (e.g. with experimenting you saw that driver received > more then 4 invalid packets consecutively), set it to higher > value. > > I think it is still good idea to ignore maximally as many > packets which can be received in time which is equal to > resetting device. > > E.g. when period of time in which we are dropping all packets > is higher then time needed to reset touchpad, we should stop > dropping packets and immediately reset touchpad. In this case > we could hit maybe problem in driver (there can be bugs) or > touchpad is in some bad state and out-of-sync... > > So if your tests show that there are never invalid 10 packets > consecutively, then set resetafter to 10 packets. Value 10 is > still not high and if it fix problem with touchpad I think it > is acceptable. But rather ask Dmitry what he thinks about it. > This is just my opinion. Hello Mario, have you patched synaptics driver with some resetafter parameter? And have some team in dell found reason for invalid packets?
On 04/10/2015 05:39 PM, Pali Rohár wrote: > On Wednesday 25 February 2015 21:45:22 Pali Rohár wrote: > Hello Mario, > have you patched synaptics driver with some resetafter parameter? > And have some team in dell found reason for invalid packets? > Hi Pali, The reason was found for the invalid packets in PS2 mode, but I can't go into the details about it publicly. I think it's better to not bother including my proposed solution, however. The vector of users in PS2 mode should be very small now. Here's why: With no kernel command line options applied the touchpad will run in I2C mode with the current kernel. The only reason that users were being exposed to the PS2 mode was if they ran with the kernel command line option acpi_osi="!Windows 2013". This was required with BIOS A01 due to the problem with I2S audio. This I2S audio problem has been resolved for BIOS A02 and BIOS A03. With no options applied on the kernel command line the system will run in I2C touchpad and HDA audio. All new machines will be coming with A03 or later. Users with earlier versions have been advised to upgrade to fix this among other issues. The HDA audio will work correctly for output with 4.0. It will work properly for input when these two patches are applied (which will land in 4.1) https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/?h=for-next&id=e1e62b98ebddc3234f3259019d3236f66fc667f8 and https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/?h=for-next&id=f3b703326541d0c1ce85f5e570f6d2b6bd4296ec If the patch to disambiguate the value of _REV() lands in 4.1 the audio will begin to operate fully in I2S mode and the necessary support will be included in 4.1 as well. So with all those factors I feel that it's a very low risk that users will end up in PS2 mode with the current development focus kernels. Thanks, -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Saturday 11 April 2015 01:07:03 Mario Limonciello wrote: > On 04/10/2015 05:39 PM, Pali Rohár wrote: > > On Wednesday 25 February 2015 21:45:22 Pali Rohár wrote: > > Hello Mario, > > have you patched synaptics driver with some resetafter > > parameter? And have some team in dell found reason for > > invalid packets? > > Hi Pali, > > The reason was found for the invalid packets in PS2 mode, but > I can't go into the details about it publicly. > > I think it's better to not bother including my proposed > solution, however. The vector of users in PS2 mode should be > very small now. Here's why: > With no kernel command line options applied the touchpad will > run in I2C mode with the current kernel. The only reason > that users were being exposed to the PS2 mode was if they ran > with the kernel command line option acpi_osi="!Windows 2013". > This was required with BIOS A01 due to the problem with I2S > audio. This I2S audio problem has been resolved for BIOS A02 > and BIOS A03. With no options applied on the kernel command > line the system will run in I2C touchpad and HDA audio. All > new machines will be coming with A03 or later. Users with > earlier versions have been advised to upgrade to fix this > among other issues. > > The HDA audio will work correctly for output with 4.0. It > will work properly for input when these two patches are > applied (which will land in 4.1) > > https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/c > ommit/?h=for-next&id=e1e62b98ebddc3234f3259019d3236f66fc667f8 > > and > > https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/c > ommit/?h=for-next&id=f3b703326541d0c1ce85f5e570f6d2b6bd4296ec > > > If the patch to disambiguate the value of _REV() lands in 4.1 > the audio will begin to operate fully in I2S mode and the > necessary support will be included in 4.1 as well. > > So with all those factors I feel that it's a very low risk > that users will end up in PS2 mode with the current > development focus kernels. > > Thanks, I could see problem with using older kernels which are in more stable or LTS distribution versions... But it is nice that problems are fixes for future 4.0/4.1 versions. And if you located reason for invalid packets in PS/2 mode, will you fix it in some new bios versions? Can you comment if this is also same problem with invalid packets on E6440/E7440 machines?
On 04/10/2015 06:14 PM, Pali Rohár wrote: > On Saturday 11 April 2015 01:07:03 Mario Limonciello wrote: > I could see problem with using older kernels which are in more > stable or LTS distribution versions... > > But it is nice that problems are fixes for future 4.0/4.1 > versions. > > And if you located reason for invalid packets in PS/2 mode, will > you fix it in some new bios versions? > > Can you comment if this is also same problem with invalid packets > on E6440/E7440 machines? > Hi Pali, For the XPS 13, yes earlier kernel versions will be affected, but we are encouraging users to run with 3.16+. There are enough other issues with I2C touchpad, MST, HDA audio and other things that people will have a better experience on those kernels. People who will install Ubuntu 14.04 LTS we will encourage to install the HWE stack that provides 3.16 or 3.19 instead. Canonical is backporting fixes for I2C and HDA issues into these kernels already. The root cause for the invalid packets in PS/2 mode on the XPS 13 is not fixable via a BIOS update. The invalid packets on the Exx40 machines I believe is caused by some behavior that happens if the touchpad/trackstick receives data shortly after the internal keyboard was busy. An interrupt is fired on the EC that will cause it discard data. I think this is why it ends up on the other end looking like it does. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Mario Limonciello <mario_limonciello@dell.com> writes: > On 04/10/2015 06:14 PM, Pali Rohár wrote: snip >> Can you comment if this is also same problem with invalid packets >> on E6440/E7440 machines? >> > Hi Pali, > snip > > The invalid packets on the Exx40 machines I believe is caused by some > behavior that happens if the touchpad/trackstick receives data shortly > after the internal keyboard was busy. An interrupt is fired on the EC > that will cause it discard data. I think this is why it ends up on > the other end looking like it does. > Is this to say that the issue will be fixed with a BIOS update? Cheers, - Ben
On 04/10/2015 09:19 PM, Ben Gamari wrote: > Mario Limonciello <mario_limonciello@dell.com> writes: > > snip > > snip > Is this to say that the issue will be fixed with a BIOS update? > > Cheers, > > - Ben > From what I have gathered this is expected behavior that won't change. The EC will intentionally drop packets while processing keyboard input. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c index 7e705ee..4dc456c 100644 --- a/drivers/input/mouse/synaptics.c +++ b/drivers/input/mouse/synaptics.c @@ -1244,6 +1244,21 @@ static int synaptics_reconnect(struct psmouse *psmouse) return 0; } +static bool dell_ec_glitch; + +static const struct dmi_system_id dell_dmi_table[] __initconst = { +#if defined(CONFIG_DMI) && defined(CONFIG_X86) + { + /* XPS 13 (2015) */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), + DMI_MATCH(DMI_PRODUCT_NAME, "XPS 13 9343"), + }, + }, + { } +#endif +}; + static bool impaired_toshiba_kbc; static const struct dmi_system_id toshiba_dmi_table[] __initconst = { @@ -1334,6 +1349,8 @@ void __init synaptics_module_init(void) * so we have to resort to checking DMI. */ is_forcepad = dmi_check_system(forcepad_dmi_table); + dell_ec_glitch = dmi_check_system(dell_dmi_table); + } static int __synaptics_init(struct psmouse *psmouse, bool absolute_mode) @@ -1426,6 +1443,17 @@ static int __synaptics_init(struct psmouse *psmouse, bool absolute_mode) psmouse->rate = 40; } + /* + * Some Dell touchpads have a problem where the EC will glitch causing + * bad packets that are otherwise harmless unless they cause psmouse + * to reset. + */ + if (psmouse->resetafter > 0 && dell_ec_glitch) { + psmouse_info(psmouse, "Dell %s detected, disabling tpad reset.\n", + dmi_get_system_info(DMI_PRODUCT_NAME)); + psmouse->resetafter = 0; + } + if (!priv->absolute_mode && SYN_ID_DISGEST_SUPPORTED(priv->identity)) { err = device_create_file(&psmouse->ps2dev.serio->dev, &psmouse_attr_disable_gesture.dattr);
When the touchpad for the Dell XPS 13 is running in PS/2 mode the EC has a tendency to glitch causing the driver to receive bad data. This doesn't affect the usage of the touchpad until enough bad data is received that causes the driver to reset and "freeze". Signed-off-by: Mario Limonciello <mario_limonciello@dell.com> --- drivers/input/mouse/synaptics.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)