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 <[email protected]>
---
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 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 <[email protected]>
> ---
> 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
>
--
Dmitry
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,
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.
--
Dmitry
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.
--
Pali Rohár
[email protected]
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?
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".
--
Pali Rohár
[email protected]
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.
On Fri, Feb 20, 2015 at 4:21 PM, Mario Limonciello
<[email protected]> 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
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.
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...
--
Pali Rohár
[email protected]
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.
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)...
--
Pali Rohár
[email protected]
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.
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.
--
Pali Rohár
[email protected]
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.
--
Dmitry
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.
>
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
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.
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
[email protected]
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?
--
Pali Rohár
[email protected]
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,
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?
--
Pali Rohár
[email protected]
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.
Mario Limonciello <[email protected]> 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 <[email protected]> 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.