Dell docking station & Dell Embedded Controller & PS/2 devices

Dell docking station & Dell Embedded Controller & PS/2 devices

[Pali Rohár]

Hi Dmitry!

I'm observing a problem with internal touchpad (handled by psmouse.ko)
on Dell laptops connected to Dell E docking station. When I connect
external PS/2 keyboard to docking station then internal laptop touchpad
switch from multitouch absolute mode to relative bare PS/2 mode.

And because ALPS driver in psmouse.ko is capable to process interleaved
bare 3-byte PS/2 packets with 6-byte ALPS packets (which handles
trackstick data on some ALPS models), ALPS driver does not show any
message about this "downgrade" from multitouch to bare mode. And
continue working in bare mode.

When I rmmod psmouse and modprobe it again, then touchpad switch back to
multitouch mode.

Mario told me that Dell Embedded Controller, which handle internal
keyboard, internal touchpad and external PS/2 keyboard, automatically
send RESET command to *all* those devices when external PS/2 keyboard is
connected. Therefore this is reason why touchpad downgrade to to bare
mode. And according to Mario, host system should issue vendor specific
PS/2 commands to re-initialize all PS/2 devices when this situation
happen. Mario also told me that Windows is doing this action.

Every time when I connect external PS/2 keyboard to dock I see this
message in dmesg:

Spurious ACK... Some program might be trying to access hardware directly.

I see it also every time when I dock laptop into docking station (to
which is keyboard already connected). And it happens also when I connect
external PS/2 mouse to dock.

Dmitry, how to handle this situation to re-initialize psmouse.ko when
external PS/2 device is connected to Dell E docking station? According
to Mario, this is how Dell Embedded Controller is designed and suppose
how OS should work with it.

Manually rmmoding and modprobing for every docking/undocking laptop is
not ideal solution.

Could it be possible to use that Spurious ATKBD_RET_ACK from atkbd.c be
handled on Dell systems (probably via DMI) as an event to reset and
reinitialize all PS/2 devices?

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Dell docking station & Dell Embedded Controller & PS/2 devices

[Dmitry Torokhov]

Hi Pali,

On Wed, Jan 24, 2018 at 11:41:21AM +0100, Pali Rohár wrote:
> Hi Dmitry!
> 
> I'm observing a problem with internal touchpad (handled by psmouse.ko)
> on Dell laptops connected to Dell E docking station. When I connect
> external PS/2 keyboard to docking station then internal laptop touchpad
> switch from multitouch absolute mode to relative bare PS/2 mode.
> 
> And because ALPS driver in psmouse.ko is capable to process interleaved
> bare 3-byte PS/2 packets with 6-byte ALPS packets (which handles
> trackstick data on some ALPS models), ALPS driver does not show any
> message about this "downgrade" from multitouch to bare mode. And
> continue working in bare mode.
> 
> When I rmmod psmouse and modprobe it again, then touchpad switch back to
> multitouch mode.
> 
> Mario told me that Dell Embedded Controller, which handle internal
> keyboard, internal touchpad and external PS/2 keyboard, automatically
> send RESET command to *all* those devices when external PS/2 keyboard is
> connected. Therefore this is reason why touchpad downgrade to to bare
> mode. And according to Mario, host system should issue vendor specific
> PS/2 commands to re-initialize all PS/2 devices when this situation
> happen. Mario also told me that Windows is doing this action.

Yeah, I remember fun with Inspiron 8100 - when you dock it it woudl
silently switch Synaptics touchpad into standard mode and it would not
come back as Synaptics until you disconnect. And there was no
notification to the kernel as far as I could tell.

It could be that we need to monitor dock events and then kick reconnect
of serio port, either from userspace via udev (I think that would be
preferred), or in kernel.

> 
> Every time when I connect external PS/2 keyboard to dock I see this
> message in dmesg:
> 
> Spurious ACK... Some program might be trying to access hardware directly.
> 
> I see it also every time when I dock laptop into docking station (to
> which is keyboard already connected). And it happens also when I connect
> external PS/2 mouse to dock.
> 
> Dmitry, how to handle this situation to re-initialize psmouse.ko when
> external PS/2 device is connected to Dell E docking station? According
> to Mario, this is how Dell Embedded Controller is designed and suppose
> how OS should work with it.
> 
> Manually rmmoding and modprobing for every docking/undocking laptop is
> not ideal solution.
> 
> Could it be possible to use that Spurious ATKBD_RET_ACK from atkbd.c be
> handled on Dell systems (probably via DMI) as an event to reset and
> reinitialize all PS/2 devices?

So we need to figure out what exactly we are getting from the docking
station in this case. We do try to handle the new device 0xaa 0x00
announcements:

	/* Check if this is a new device announcement (0xAA 0x00) */
	if (unlikely(psmouse->packet[0] == PSMOUSE_RET_BAT && psmouse->pktcnt <= 2)) {
		if (psmouse->pktcnt == 1) {
			psmouse->last = jiffies;
			goto out;
		}

		if (psmouse->packet[1] == PSMOUSE_RET_ID ||
		    (psmouse->protocol->type == PSMOUSE_HGPK &&
		     psmouse->packet[1] == PSMOUSE_RET_BAT)) {
			__psmouse_set_state(psmouse, PSMOUSE_IGNORE);
			serio_reconnect(serio);
			goto out;
		}

...

I am not sure where the "spurious ACK comes from". Can you enable i8042
debug before trying to dock and capture the data stream from the mouse?

Thanks.

-- 
Dmitry

RE: Dell docking station & Dell Embedded Controller & PS/2 devices

[Mario.Limonciello]

> -----Original Message-----
> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> Sent: Thursday, February 1, 2018 1:30 PM
> To: Pali Rohár <pali.rohar@gmail.com>
> Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; linux-
> input@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: Dell docking station & Dell Embedded Controller & PS/2 devices
> 
> Hi Pali,
> 
> On Wed, Jan 24, 2018 at 11:41:21AM +0100, Pali Rohár wrote:
> > Hi Dmitry!
> >
> > I'm observing a problem with internal touchpad (handled by psmouse.ko)
> > on Dell laptops connected to Dell E docking station. When I connect
> > external PS/2 keyboard to docking station then internal laptop touchpad
> > switch from multitouch absolute mode to relative bare PS/2 mode.
> >
> > And because ALPS driver in psmouse.ko is capable to process interleaved
> > bare 3-byte PS/2 packets with 6-byte ALPS packets (which handles
> > trackstick data on some ALPS models), ALPS driver does not show any
> > message about this "downgrade" from multitouch to bare mode. And
> > continue working in bare mode.
> >
> > When I rmmod psmouse and modprobe it again, then touchpad switch back to
> > multitouch mode.
> >
> > Mario told me that Dell Embedded Controller, which handle internal
> > keyboard, internal touchpad and external PS/2 keyboard, automatically
> > send RESET command to *all* those devices when external PS/2 keyboard is
> > connected. Therefore this is reason why touchpad downgrade to to bare
> > mode. And according to Mario, host system should issue vendor specific
> > PS/2 commands to re-initialize all PS/2 devices when this situation
> > happen. Mario also told me that Windows is doing this action.
> 
> Yeah, I remember fun with Inspiron 8100 - when you dock it it woudl
> silently switch Synaptics touchpad into standard mode and it would not
> come back as Synaptics until you disconnect. And there was no
> notification to the kernel as far as I could tell.
> 
> It could be that we need to monitor dock events and then kick reconnect
> of serio port, either from userspace via udev (I think that would be
> preferred), or in kernel.
> 
> >
> > Every time when I connect external PS/2 keyboard to dock I see this
> > message in dmesg:
> >
> > Spurious ACK... Some program might be trying to access hardware directly.
> >
> > I see it also every time when I dock laptop into docking station (to
> > which is keyboard already connected). And it happens also when I connect
> > external PS/2 mouse to dock.
> >
> > Dmitry, how to handle this situation to re-initialize psmouse.ko when
> > external PS/2 device is connected to Dell E docking station? According
> > to Mario, this is how Dell Embedded Controller is designed and suppose
> > how OS should work with it.
> >
> > Manually rmmoding and modprobing for every docking/undocking laptop is
> > not ideal solution.
> >
> > Could it be possible to use that Spurious ATKBD_RET_ACK from atkbd.c be
> > handled on Dell systems (probably via DMI) as an event to reset and
> > reinitialize all PS/2 devices?
> 
> So we need to figure out what exactly we are getting from the docking
> station in this case. We do try to handle the new device 0xaa 0x00
> announcements:

Docking station itself won't have sent any events.  The PS2 ports in it
are electrically wired to the external PS2 pins in the docking adapter on
the system.

System EC is what will be sending any PS2 events.

> 
> 	/* Check if this is a new device announcement (0xAA 0x00) */
> 	if (unlikely(psmouse->packet[0] == PSMOUSE_RET_BAT && psmouse-
> >pktcnt <= 2)) {
> 		if (psmouse->pktcnt == 1) {
> 			psmouse->last = jiffies;
> 			goto out;
> 		}
> 
> 		if (psmouse->packet[1] == PSMOUSE_RET_ID ||
> 		    (psmouse->protocol->type == PSMOUSE_HGPK &&
> 		     psmouse->packet[1] == PSMOUSE_RET_BAT)) {
> 			__psmouse_set_state(psmouse, PSMOUSE_IGNORE);
> 			serio_reconnect(serio);
> 			goto out;
> 		}
> 
> ...
> 
> I am not sure where the "spurious ACK comes from". Can you enable i8042
> debug before trying to dock and capture the data stream from the mouse?
> 

The system EC has reset PS2 devices (but AFAIK kernel won't have seen this
communication).

RE: Dell docking station & Dell Embedded Controller & PS/2 devices

[Mario.Limonciello]

> -----Original Message-----
> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> Sent: Thursday, February 1, 2018 1:30 PM
> To: Pali Rohár <pali.rohar@gmail.com>
> Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; linux-
> input@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: Dell docking station & Dell Embedded Controller & PS/2 devices
> 
> Hi Pali,
> 
> On Wed, Jan 24, 2018 at 11:41:21AM +0100, Pali Rohár wrote:
> > Hi Dmitry!
> >
> > I'm observing a problem with internal touchpad (handled by psmouse.ko)
> > on Dell laptops connected to Dell E docking station. When I connect
> > external PS/2 keyboard to docking station then internal laptop touchpad
> > switch from multitouch absolute mode to relative bare PS/2 mode.
> >
> > And because ALPS driver in psmouse.ko is capable to process interleaved
> > bare 3-byte PS/2 packets with 6-byte ALPS packets (which handles
> > trackstick data on some ALPS models), ALPS driver does not show any
> > message about this "downgrade" from multitouch to bare mode. And
> > continue working in bare mode.
> >
> > When I rmmod psmouse and modprobe it again, then touchpad switch back to
> > multitouch mode.
> >
> > Mario told me that Dell Embedded Controller, which handle internal
> > keyboard, internal touchpad and external PS/2 keyboard, automatically
> > send RESET command to *all* those devices when external PS/2 keyboard is
> > connected. Therefore this is reason why touchpad downgrade to to bare
> > mode. And according to Mario, host system should issue vendor specific
> > PS/2 commands to re-initialize all PS/2 devices when this situation
> > happen. Mario also told me that Windows is doing this action.
> 
> Yeah, I remember fun with Inspiron 8100 - when you dock it it woudl
> silently switch Synaptics touchpad into standard mode and it would not
> come back as Synaptics until you disconnect. And there was no
> notification to the kernel as far as I could tell.
> 
> It could be that we need to monitor dock events and then kick reconnect
> of serio port, either from userspace via udev (I think that would be
> preferred), or in kernel.
> 
> >
> > Every time when I connect external PS/2 keyboard to dock I see this
> > message in dmesg:
> >
> > Spurious ACK... Some program might be trying to access hardware directly.
> >
> > I see it also every time when I dock laptop into docking station (to
> > which is keyboard already connected). And it happens also when I connect
> > external PS/2 mouse to dock.
> >
> > Dmitry, how to handle this situation to re-initialize psmouse.ko when
> > external PS/2 device is connected to Dell E docking station? According
> > to Mario, this is how Dell Embedded Controller is designed and suppose
> > how OS should work with it.
> >
> > Manually rmmoding and modprobing for every docking/undocking laptop is
> > not ideal solution.
> >
> > Could it be possible to use that Spurious ATKBD_RET_ACK from atkbd.c be
> > handled on Dell systems (probably via DMI) as an event to reset and
> > reinitialize all PS/2 devices?
> 
> So we need to figure out what exactly we are getting from the docking
> station in this case. We do try to handle the new device 0xaa 0x00
> announcements:

Docking station itself won't have sent any events.  The PS2 ports in it
are electrically wired to the external PS2 pins in the docking adapter on
the system.

System EC is what will be sending any PS2 events.

> 
> 	/* Check if this is a new device announcement (0xAA 0x00) */
> 	if (unlikely(psmouse->packet[0] == PSMOUSE_RET_BAT && psmouse-
> >pktcnt <= 2)) {
> 		if (psmouse->pktcnt == 1) {
> 			psmouse->last = jiffies;
> 			goto out;
> 		}
> 
> 		if (psmouse->packet[1] == PSMOUSE_RET_ID ||
> 		    (psmouse->protocol->type == PSMOUSE_HGPK &&
> 		     psmouse->packet[1] == PSMOUSE_RET_BAT)) {
> 			__psmouse_set_state(psmouse, PSMOUSE_IGNORE);
> 			serio_reconnect(serio);
> 			goto out;
> 		}
> 
> ...
> 
> I am not sure where the "spurious ACK comes from". Can you enable i8042
> debug before trying to dock and capture the data stream from the mouse?
> 

The system EC has reset PS2 devices (but AFAIK kernel won't have seen this
communication).

Re: Dell docking station & Dell Embedded Controller & PS/2 devices

[Dmitry Torokhov]

On Thu, Feb 1, 2018 at 11:35 AM,  <Mario.Limonciello@dell.com> wrote:
>
>
>> -----Original Message-----
>> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
>> Sent: Thursday, February 1, 2018 1:30 PM
>> To: Pali Rohár <pali.rohar@gmail.com>
>> Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; linux-
>> input@vger.kernel.org; linux-kernel@vger.kernel.org
>> Subject: Re: Dell docking station & Dell Embedded Controller & PS/2 devices
>>
>> Hi Pali,
>>
>> On Wed, Jan 24, 2018 at 11:41:21AM +0100, Pali Rohár wrote:
>> > Hi Dmitry!
>> >
>> > I'm observing a problem with internal touchpad (handled by psmouse.ko)
>> > on Dell laptops connected to Dell E docking station. When I connect
>> > external PS/2 keyboard to docking station then internal laptop touchpad
>> > switch from multitouch absolute mode to relative bare PS/2 mode.
>> >
>> > And because ALPS driver in psmouse.ko is capable to process interleaved
>> > bare 3-byte PS/2 packets with 6-byte ALPS packets (which handles
>> > trackstick data on some ALPS models), ALPS driver does not show any
>> > message about this "downgrade" from multitouch to bare mode. And
>> > continue working in bare mode.
>> >
>> > When I rmmod psmouse and modprobe it again, then touchpad switch back to
>> > multitouch mode.
>> >
>> > Mario told me that Dell Embedded Controller, which handle internal
>> > keyboard, internal touchpad and external PS/2 keyboard, automatically
>> > send RESET command to *all* those devices when external PS/2 keyboard is
>> > connected. Therefore this is reason why touchpad downgrade to to bare
>> > mode. And according to Mario, host system should issue vendor specific
>> > PS/2 commands to re-initialize all PS/2 devices when this situation
>> > happen. Mario also told me that Windows is doing this action.
>>
>> Yeah, I remember fun with Inspiron 8100 - when you dock it it woudl
>> silently switch Synaptics touchpad into standard mode and it would not
>> come back as Synaptics until you disconnect. And there was no
>> notification to the kernel as far as I could tell.
>>
>> It could be that we need to monitor dock events and then kick reconnect
>> of serio port, either from userspace via udev (I think that would be
>> preferred), or in kernel.
>>
>> >
>> > Every time when I connect external PS/2 keyboard to dock I see this
>> > message in dmesg:
>> >
>> > Spurious ACK... Some program might be trying to access hardware directly.
>> >
>> > I see it also every time when I dock laptop into docking station (to
>> > which is keyboard already connected). And it happens also when I connect
>> > external PS/2 mouse to dock.
>> >
>> > Dmitry, how to handle this situation to re-initialize psmouse.ko when
>> > external PS/2 device is connected to Dell E docking station? According
>> > to Mario, this is how Dell Embedded Controller is designed and suppose
>> > how OS should work with it.
>> >
>> > Manually rmmoding and modprobing for every docking/undocking laptop is
>> > not ideal solution.
>> >
>> > Could it be possible to use that Spurious ATKBD_RET_ACK from atkbd.c be
>> > handled on Dell systems (probably via DMI) as an event to reset and
>> > reinitialize all PS/2 devices?
>>
>> So we need to figure out what exactly we are getting from the docking
>> station in this case. We do try to handle the new device 0xaa 0x00
>> announcements:
>
> Docking station itself won't have sent any events.  The PS2 ports in it
> are electrically wired to the external PS2 pins in the docking adapter on
> the system.
>
> System EC is what will be sending any PS2 events.

OK, it does not matter from the input layer POW, if they are PS/2
events they should be coming from i8042.

>
>>
>>       /* Check if this is a new device announcement (0xAA 0x00) */
>>       if (unlikely(psmouse->packet[0] == PSMOUSE_RET_BAT && psmouse-
>> >pktcnt <= 2)) {
>>               if (psmouse->pktcnt == 1) {
>>                       psmouse->last = jiffies;
>>                       goto out;
>>               }
>>
>>               if (psmouse->packet[1] == PSMOUSE_RET_ID ||
>>                   (psmouse->protocol->type == PSMOUSE_HGPK &&
>>                    psmouse->packet[1] == PSMOUSE_RET_BAT)) {
>>                       __psmouse_set_state(psmouse, PSMOUSE_IGNORE);
>>                       serio_reconnect(serio);
>>                       goto out;
>>               }
>>
>> ...
>>
>> I am not sure where the "spurious ACK comes from". Can you enable i8042
>> debug before trying to dock and capture the data stream from the mouse?
>>
>
> The system EC has reset PS2 devices (but AFAIK kernel won't have seen this
> communication).

So what kind of communication does EC send when docking? It sounds it
is completely out of band from PS/2 connection.

Thanks.

-- 
Dmitry

RE: Dell docking station & Dell Embedded Controller & PS/2 devices

[Mario.Limonciello]

> -----Original Message-----
> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> Sent: Thursday, February 1, 2018 3:14 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: Pali Rohár <pali.rohar@gmail.com>; linux-input@vger.kernel.org; lkml <linux-
> kernel@vger.kernel.org>
> Subject: Re: Dell docking station & Dell Embedded Controller & PS/2 devices
> 
> On Thu, Feb 1, 2018 at 11:35 AM,  <Mario.Limonciello@dell.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> >> Sent: Thursday, February 1, 2018 1:30 PM
> >> To: Pali Rohár <pali.rohar@gmail.com>
> >> Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; linux-
> >> input@vger.kernel.org; linux-kernel@vger.kernel.org
> >> Subject: Re: Dell docking station & Dell Embedded Controller & PS/2 devices
> >>
> >> Hi Pali,
> >>
> >> On Wed, Jan 24, 2018 at 11:41:21AM +0100, Pali Rohár wrote:
> >> > Hi Dmitry!
> >> >
> >> > I'm observing a problem with internal touchpad (handled by psmouse.ko)
> >> > on Dell laptops connected to Dell E docking station. When I connect
> >> > external PS/2 keyboard to docking station then internal laptop touchpad
> >> > switch from multitouch absolute mode to relative bare PS/2 mode.
> >> >
> >> > And because ALPS driver in psmouse.ko is capable to process interleaved
> >> > bare 3-byte PS/2 packets with 6-byte ALPS packets (which handles
> >> > trackstick data on some ALPS models), ALPS driver does not show any
> >> > message about this "downgrade" from multitouch to bare mode. And
> >> > continue working in bare mode.
> >> >
> >> > When I rmmod psmouse and modprobe it again, then touchpad switch back to
> >> > multitouch mode.
> >> >
> >> > Mario told me that Dell Embedded Controller, which handle internal
> >> > keyboard, internal touchpad and external PS/2 keyboard, automatically
> >> > send RESET command to *all* those devices when external PS/2 keyboard is
> >> > connected. Therefore this is reason why touchpad downgrade to to bare
> >> > mode. And according to Mario, host system should issue vendor specific
> >> > PS/2 commands to re-initialize all PS/2 devices when this situation
> >> > happen. Mario also told me that Windows is doing this action.
> >>
> >> Yeah, I remember fun with Inspiron 8100 - when you dock it it woudl
> >> silently switch Synaptics touchpad into standard mode and it would not
> >> come back as Synaptics until you disconnect. And there was no
> >> notification to the kernel as far as I could tell.
> >>
> >> It could be that we need to monitor dock events and then kick reconnect
> >> of serio port, either from userspace via udev (I think that would be
> >> preferred), or in kernel.
> >>
> >> >
> >> > Every time when I connect external PS/2 keyboard to dock I see this
> >> > message in dmesg:
> >> >
> >> > Spurious ACK... Some program might be trying to access hardware directly.
> >> >
> >> > I see it also every time when I dock laptop into docking station (to
> >> > which is keyboard already connected). And it happens also when I connect
> >> > external PS/2 mouse to dock.
> >> >
> >> > Dmitry, how to handle this situation to re-initialize psmouse.ko when
> >> > external PS/2 device is connected to Dell E docking station? According
> >> > to Mario, this is how Dell Embedded Controller is designed and suppose
> >> > how OS should work with it.
> >> >
> >> > Manually rmmoding and modprobing for every docking/undocking laptop is
> >> > not ideal solution.
> >> >
> >> > Could it be possible to use that Spurious ATKBD_RET_ACK from atkbd.c be
> >> > handled on Dell systems (probably via DMI) as an event to reset and
> >> > reinitialize all PS/2 devices?
> >>
> >> So we need to figure out what exactly we are getting from the docking
> >> station in this case. We do try to handle the new device 0xaa 0x00
> >> announcements:
> >
> > Docking station itself won't have sent any events.  The PS2 ports in it
> > are electrically wired to the external PS2 pins in the docking adapter on
> > the system.
> >
> > System EC is what will be sending any PS2 events.
> 
> OK, it does not matter from the input layer POW, if they are PS/2
> events they should be coming from i8042.
> 
> >
> >>
> >>       /* Check if this is a new device announcement (0xAA 0x00) */
> >>       if (unlikely(psmouse->packet[0] == PSMOUSE_RET_BAT && psmouse-
> >> >pktcnt <= 2)) {
> >>               if (psmouse->pktcnt == 1) {
> >>                       psmouse->last = jiffies;
> >>                       goto out;
> >>               }
> >>
> >>               if (psmouse->packet[1] == PSMOUSE_RET_ID ||
> >>                   (psmouse->protocol->type == PSMOUSE_HGPK &&
> >>                    psmouse->packet[1] == PSMOUSE_RET_BAT)) {
> >>                       __psmouse_set_state(psmouse, PSMOUSE_IGNORE);
> >>                       serio_reconnect(serio);
> >>                       goto out;
> >>               }
> >>
> >> ...
> >>
> >> I am not sure where the "spurious ACK comes from". Can you enable i8042
> >> debug before trying to dock and capture the data stream from the mouse?
> >>
> >
> > The system EC has reset PS2 devices (but AFAIK kernel won't have seen this
> > communication).
> 
> So what kind of communication does EC send when docking? It sounds it
> is completely out of band from PS/2 connection.

Yes it's out of band from PS/2 connection OS sees.  However as Pali has 
mentioned this issue will happen even if already docked but you plug in
PS/2 keyboard.

It will probably be clearer to you what OS has seen from this when Pali
shares the captured data stream.

RE: Dell docking station & Dell Embedded Controller & PS/2 devices

[Mario.Limonciello]

> -----Original Message-----
> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> Sent: Thursday, February 1, 2018 3:14 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: Pali Rohár <pali.rohar@gmail.com>; linux-input@vger.kernel.org; lkml <linux-
> kernel@vger.kernel.org>
> Subject: Re: Dell docking station & Dell Embedded Controller & PS/2 devices
> 
> On Thu, Feb 1, 2018 at 11:35 AM,  <Mario.Limonciello@dell.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> >> Sent: Thursday, February 1, 2018 1:30 PM
> >> To: Pali Rohár <pali.rohar@gmail.com>
> >> Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; linux-
> >> input@vger.kernel.org; linux-kernel@vger.kernel.org
> >> Subject: Re: Dell docking station & Dell Embedded Controller & PS/2 devices
> >>
> >> Hi Pali,
> >>
> >> On Wed, Jan 24, 2018 at 11:41:21AM +0100, Pali Rohár wrote:
> >> > Hi Dmitry!
> >> >
> >> > I'm observing a problem with internal touchpad (handled by psmouse.ko)
> >> > on Dell laptops connected to Dell E docking station. When I connect
> >> > external PS/2 keyboard to docking station then internal laptop touchpad
> >> > switch from multitouch absolute mode to relative bare PS/2 mode.
> >> >
> >> > And because ALPS driver in psmouse.ko is capable to process interleaved
> >> > bare 3-byte PS/2 packets with 6-byte ALPS packets (which handles
> >> > trackstick data on some ALPS models), ALPS driver does not show any
> >> > message about this "downgrade" from multitouch to bare mode. And
> >> > continue working in bare mode.
> >> >
> >> > When I rmmod psmouse and modprobe it again, then touchpad switch back to
> >> > multitouch mode.
> >> >
> >> > Mario told me that Dell Embedded Controller, which handle internal
> >> > keyboard, internal touchpad and external PS/2 keyboard, automatically
> >> > send RESET command to *all* those devices when external PS/2 keyboard is
> >> > connected. Therefore this is reason why touchpad downgrade to to bare
> >> > mode. And according to Mario, host system should issue vendor specific
> >> > PS/2 commands to re-initialize all PS/2 devices when this situation
> >> > happen. Mario also told me that Windows is doing this action.
> >>
> >> Yeah, I remember fun with Inspiron 8100 - when you dock it it woudl
> >> silently switch Synaptics touchpad into standard mode and it would not
> >> come back as Synaptics until you disconnect. And there was no
> >> notification to the kernel as far as I could tell.
> >>
> >> It could be that we need to monitor dock events and then kick reconnect
> >> of serio port, either from userspace via udev (I think that would be
> >> preferred), or in kernel.
> >>
> >> >
> >> > Every time when I connect external PS/2 keyboard to dock I see this
> >> > message in dmesg:
> >> >
> >> > Spurious ACK... Some program might be trying to access hardware directly.
> >> >
> >> > I see it also every time when I dock laptop into docking station (to
> >> > which is keyboard already connected). And it happens also when I connect
> >> > external PS/2 mouse to dock.
> >> >
> >> > Dmitry, how to handle this situation to re-initialize psmouse.ko when
> >> > external PS/2 device is connected to Dell E docking station? According
> >> > to Mario, this is how Dell Embedded Controller is designed and suppose
> >> > how OS should work with it.
> >> >
> >> > Manually rmmoding and modprobing for every docking/undocking laptop is
> >> > not ideal solution.
> >> >
> >> > Could it be possible to use that Spurious ATKBD_RET_ACK from atkbd.c be
> >> > handled on Dell systems (probably via DMI) as an event to reset and
> >> > reinitialize all PS/2 devices?
> >>
> >> So we need to figure out what exactly we are getting from the docking
> >> station in this case. We do try to handle the new device 0xaa 0x00
> >> announcements:
> >
> > Docking station itself won't have sent any events.  The PS2 ports in it
> > are electrically wired to the external PS2 pins in the docking adapter on
> > the system.
> >
> > System EC is what will be sending any PS2 events.
> 
> OK, it does not matter from the input layer POW, if they are PS/2
> events they should be coming from i8042.
> 
> >
> >>
> >>       /* Check if this is a new device announcement (0xAA 0x00) */
> >>       if (unlikely(psmouse->packet[0] == PSMOUSE_RET_BAT && psmouse-
> >> >pktcnt <= 2)) {
> >>               if (psmouse->pktcnt == 1) {
> >>                       psmouse->last = jiffies;
> >>                       goto out;
> >>               }
> >>
> >>               if (psmouse->packet[1] == PSMOUSE_RET_ID ||
> >>                   (psmouse->protocol->type == PSMOUSE_HGPK &&
> >>                    psmouse->packet[1] == PSMOUSE_RET_BAT)) {
> >>                       __psmouse_set_state(psmouse, PSMOUSE_IGNORE);
> >>                       serio_reconnect(serio);
> >>                       goto out;
> >>               }
> >>
> >> ...
> >>
> >> I am not sure where the "spurious ACK comes from". Can you enable i8042
> >> debug before trying to dock and capture the data stream from the mouse?
> >>
> >
> > The system EC has reset PS2 devices (but AFAIK kernel won't have seen this
> > communication).
> 
> So what kind of communication does EC send when docking? It sounds it
> is completely out of band from PS/2 connection.

Yes it's out of band from PS/2 connection OS sees.  However as Pali has 
mentioned this issue will happen even if already docked but you plug in
PS/2 keyboard.

It will probably be clearer to you what OS has seen from this when Pali
shares the captured data stream.

Re: Dell docking station & Dell Embedded Controller & PS/2 devices

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 6893 bytes --]

On Thursday 01 February 2018 21:23:40 Mario.Limonciello@dell.com wrote:
> > -----Original Message-----
> > From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> > Sent: Thursday, February 1, 2018 3:14 PM
> > To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > Cc: Pali Rohár <pali.rohar@gmail.com>; linux-input@vger.kernel.org; lkml <linux-
> > kernel@vger.kernel.org>
> > Subject: Re: Dell docking station & Dell Embedded Controller & PS/2 devices
> > 
> > On Thu, Feb 1, 2018 at 11:35 AM,  <Mario.Limonciello@dell.com> wrote:
> > >
> > >
> > >> -----Original Message-----
> > >> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> > >> Sent: Thursday, February 1, 2018 1:30 PM
> > >> To: Pali Rohár <pali.rohar@gmail.com>
> > >> Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; linux-
> > >> input@vger.kernel.org; linux-kernel@vger.kernel.org
> > >> Subject: Re: Dell docking station & Dell Embedded Controller & PS/2 devices
> > >>
> > >> Hi Pali,
> > >>
> > >> On Wed, Jan 24, 2018 at 11:41:21AM +0100, Pali Rohár wrote:
> > >> > Hi Dmitry!
> > >> >
> > >> > I'm observing a problem with internal touchpad (handled by psmouse.ko)
> > >> > on Dell laptops connected to Dell E docking station. When I connect
> > >> > external PS/2 keyboard to docking station then internal laptop touchpad
> > >> > switch from multitouch absolute mode to relative bare PS/2 mode.
> > >> >
> > >> > And because ALPS driver in psmouse.ko is capable to process interleaved
> > >> > bare 3-byte PS/2 packets with 6-byte ALPS packets (which handles
> > >> > trackstick data on some ALPS models), ALPS driver does not show any
> > >> > message about this "downgrade" from multitouch to bare mode. And
> > >> > continue working in bare mode.
> > >> >
> > >> > When I rmmod psmouse and modprobe it again, then touchpad switch back to
> > >> > multitouch mode.
> > >> >
> > >> > Mario told me that Dell Embedded Controller, which handle internal
> > >> > keyboard, internal touchpad and external PS/2 keyboard, automatically
> > >> > send RESET command to *all* those devices when external PS/2 keyboard is
> > >> > connected. Therefore this is reason why touchpad downgrade to to bare
> > >> > mode. And according to Mario, host system should issue vendor specific
> > >> > PS/2 commands to re-initialize all PS/2 devices when this situation
> > >> > happen. Mario also told me that Windows is doing this action.
> > >>
> > >> Yeah, I remember fun with Inspiron 8100 - when you dock it it woudl
> > >> silently switch Synaptics touchpad into standard mode and it would not
> > >> come back as Synaptics until you disconnect. And there was no
> > >> notification to the kernel as far as I could tell.
> > >>
> > >> It could be that we need to monitor dock events and then kick reconnect
> > >> of serio port, either from userspace via udev (I think that would be
> > >> preferred), or in kernel.
> > >>
> > >> >
> > >> > Every time when I connect external PS/2 keyboard to dock I see this
> > >> > message in dmesg:
> > >> >
> > >> > Spurious ACK... Some program might be trying to access hardware directly.
> > >> >
> > >> > I see it also every time when I dock laptop into docking station (to
> > >> > which is keyboard already connected). And it happens also when I connect
> > >> > external PS/2 mouse to dock.
> > >> >
> > >> > Dmitry, how to handle this situation to re-initialize psmouse.ko when
> > >> > external PS/2 device is connected to Dell E docking station? According
> > >> > to Mario, this is how Dell Embedded Controller is designed and suppose
> > >> > how OS should work with it.
> > >> >
> > >> > Manually rmmoding and modprobing for every docking/undocking laptop is
> > >> > not ideal solution.
> > >> >
> > >> > Could it be possible to use that Spurious ATKBD_RET_ACK from atkbd.c be
> > >> > handled on Dell systems (probably via DMI) as an event to reset and
> > >> > reinitialize all PS/2 devices?
> > >>
> > >> So we need to figure out what exactly we are getting from the docking
> > >> station in this case. We do try to handle the new device 0xaa 0x00
> > >> announcements:
> > >
> > > Docking station itself won't have sent any events.  The PS2 ports in it
> > > are electrically wired to the external PS2 pins in the docking adapter on
> > > the system.
> > >
> > > System EC is what will be sending any PS2 events.
> > 
> > OK, it does not matter from the input layer POW, if they are PS/2
> > events they should be coming from i8042.

Dell EC sends reset to touchpad, not to kernel.

> > >
> > >>
> > >>       /* Check if this is a new device announcement (0xAA 0x00) */
> > >>       if (unlikely(psmouse->packet[0] == PSMOUSE_RET_BAT && psmouse-
> > >> >pktcnt <= 2)) {
> > >>               if (psmouse->pktcnt == 1) {
> > >>                       psmouse->last = jiffies;
> > >>                       goto out;
> > >>               }
> > >>
> > >>               if (psmouse->packet[1] == PSMOUSE_RET_ID ||
> > >>                   (psmouse->protocol->type == PSMOUSE_HGPK &&
> > >>                    psmouse->packet[1] == PSMOUSE_RET_BAT)) {
> > >>                       __psmouse_set_state(psmouse, PSMOUSE_IGNORE);
> > >>                       serio_reconnect(serio);
> > >>                       goto out;
> > >>               }
> > >>
> > >> ...
> > >>
> > >> I am not sure where the "spurious ACK comes from". Can you enable i8042
> > >> debug before trying to dock and capture the data stream from the mouse?
> > >>
> > >
> > > The system EC has reset PS2 devices (but AFAIK kernel won't have seen this
> > > communication).
> > 
> > So what kind of communication does EC send when docking? It sounds it
> > is completely out of band from PS/2 connection.
> 
> Yes it's out of band from PS/2 connection OS sees.  However as Pali has 
> mentioned this issue will happen even if already docked but you plug in
> PS/2 keyboard.
> 
> It will probably be clearer to you what OS has seen from this when Pali
> shares the captured data stream.

Currently I'm not near my docking station, so cannot do testing.

But in logs I can dig these lines which appeared every time after
putting notebook into dock (which has PS/2 keyboard connected):

kernel: [20127.033965] atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.
kernel: [20127.076030] acpi PNP0401:00: Already enumerated
kernel: [20127.083088] acpi PNP0501:00: Still not present
kernel: [20127.087042] acpi device:41: Cannot transition to power state D3hot for parent in (unknown)

And sometimes after 1-5s I see Spurious event again:

kernel: [20128.325569] atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Dell docking station & Dell Embedded Controller & PS/2 devices

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 5344 bytes --]

On Thursday 01 February 2018 11:29:45 Dmitry Torokhov wrote:
> Hi Pali,
> 
> On Wed, Jan 24, 2018 at 11:41:21AM +0100, Pali Rohár wrote:
> > Hi Dmitry!
> > 
> > I'm observing a problem with internal touchpad (handled by psmouse.ko)
> > on Dell laptops connected to Dell E docking station. When I connect
> > external PS/2 keyboard to docking station then internal laptop touchpad
> > switch from multitouch absolute mode to relative bare PS/2 mode.
> > 
> > And because ALPS driver in psmouse.ko is capable to process interleaved
> > bare 3-byte PS/2 packets with 6-byte ALPS packets (which handles
> > trackstick data on some ALPS models), ALPS driver does not show any
> > message about this "downgrade" from multitouch to bare mode. And
> > continue working in bare mode.
> > 
> > When I rmmod psmouse and modprobe it again, then touchpad switch back to
> > multitouch mode.
> > 
> > Mario told me that Dell Embedded Controller, which handle internal
> > keyboard, internal touchpad and external PS/2 keyboard, automatically
> > send RESET command to *all* those devices when external PS/2 keyboard is
> > connected. Therefore this is reason why touchpad downgrade to to bare
> > mode. And according to Mario, host system should issue vendor specific
> > PS/2 commands to re-initialize all PS/2 devices when this situation
> > happen. Mario also told me that Windows is doing this action.
> 
> Yeah, I remember fun with Inspiron 8100 - when you dock it it woudl
> silently switch Synaptics touchpad into standard mode and it would not
> come back as Synaptics until you disconnect. And there was no
> notification to the kernel as far as I could tell.
> 
> It could be that we need to monitor dock events and then kick reconnect
> of serio port, either from userspace via udev (I think that would be
> preferred), or in kernel.
> 
> > 
> > Every time when I connect external PS/2 keyboard to dock I see this
> > message in dmesg:
> > 
> > Spurious ACK... Some program might be trying to access hardware directly.
> > 
> > I see it also every time when I dock laptop into docking station (to
> > which is keyboard already connected). And it happens also when I connect
> > external PS/2 mouse to dock.
> > 
> > Dmitry, how to handle this situation to re-initialize psmouse.ko when
> > external PS/2 device is connected to Dell E docking station? According
> > to Mario, this is how Dell Embedded Controller is designed and suppose
> > how OS should work with it.
> > 
> > Manually rmmoding and modprobing for every docking/undocking laptop is
> > not ideal solution.
> > 
> > Could it be possible to use that Spurious ATKBD_RET_ACK from atkbd.c be
> > handled on Dell systems (probably via DMI) as an event to reset and
> > reinitialize all PS/2 devices?
> 
> So we need to figure out what exactly we are getting from the docking
> station in this case. We do try to handle the new device 0xaa 0x00
> announcements:
> 
> 	/* Check if this is a new device announcement (0xAA 0x00) */
> 	if (unlikely(psmouse->packet[0] == PSMOUSE_RET_BAT && psmouse->pktcnt <= 2)) {
> 		if (psmouse->pktcnt == 1) {
> 			psmouse->last = jiffies;
> 			goto out;
> 		}
> 
> 		if (psmouse->packet[1] == PSMOUSE_RET_ID ||
> 		    (psmouse->protocol->type == PSMOUSE_HGPK &&
> 		     psmouse->packet[1] == PSMOUSE_RET_BAT)) {
> 			__psmouse_set_state(psmouse, PSMOUSE_IGNORE);
> 			serio_reconnect(serio);
> 			goto out;
> 		}
> 
> ...
> 
> I am not sure where the "spurious ACK comes from". Can you enable i8042
> debug before trying to dock and capture the data stream from the mouse?
> 
> Thanks.
> 

Hi Dmitry!

I enabled unmask_kbd_data and debug and here is output from dmesg.

echo Y > /sys/module/i8042/parameters/debug
echo Y > /sys/module/i8042/parameters/unmask_kbd_data

PS/2 keyboard is already connected in dock and laptop was just docked:

[25461.552314] i8042: [6365474] fa <- i8042 (interrupt, 0, 1)
[25461.552319] atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.
[25462.707296] i8042: [6365763] ed -> i8042 (kbd-data)
[25462.851289] i8042: [6365799] fa <- i8042 (interrupt, 0, 1)
[25462.851303] i8042: [6365799] 00 -> i8042 (kbd-data)
[25462.858437] i8042: [6365801] fa <- i8042 (interrupt, 0, 1)
[25462.869512] i8042: [6365804] fa <- i8042 (interrupt, 0, 1)
[25462.869517] atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.
[25463.670515] i8042: [6366004] ed -> i8042 (kbd-data)
[25463.670647] i8042: [6366004] fa <- i8042 (interrupt, 0, 1)
[25463.670655] i8042: [6366004] 02 -> i8042 (kbd-data)
[25463.676769] i8042: [6366005] fa <- i8042 (interrupt, 0, 1)


Laptop is docked and PS/2 keyboard was just connected:

[26571.014368] i8042: [6642848] fa <- i8042 (interrupt, 0, 1)
[26571.014380] atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.


In both cases there is no events from touchpad, only from keyboard. So
Dell EC silently reset PS/2 touchpad when PS/2 keyboard is attached.

So I think we should capture 0xFA and on Dell machines we should
reinitialize PS/2 drivers. As there is really nothing more then 0xFA.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Dell docking station & Dell Embedded Controller & PS/2 devices

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 7197 bytes --]

On Sunday 06 May 2018 15:47:33 Pali Rohár wrote:
> On Thursday 01 February 2018 11:29:45 Dmitry Torokhov wrote:
> > Hi Pali,
> > 
> > On Wed, Jan 24, 2018 at 11:41:21AM +0100, Pali Rohár wrote:
> > > Hi Dmitry!
> > > 
> > > I'm observing a problem with internal touchpad (handled by psmouse.ko)
> > > on Dell laptops connected to Dell E docking station. When I connect
> > > external PS/2 keyboard to docking station then internal laptop touchpad
> > > switch from multitouch absolute mode to relative bare PS/2 mode.
> > > 
> > > And because ALPS driver in psmouse.ko is capable to process interleaved
> > > bare 3-byte PS/2 packets with 6-byte ALPS packets (which handles
> > > trackstick data on some ALPS models), ALPS driver does not show any
> > > message about this "downgrade" from multitouch to bare mode. And
> > > continue working in bare mode.
> > > 
> > > When I rmmod psmouse and modprobe it again, then touchpad switch back to
> > > multitouch mode.
> > > 
> > > Mario told me that Dell Embedded Controller, which handle internal
> > > keyboard, internal touchpad and external PS/2 keyboard, automatically
> > > send RESET command to *all* those devices when external PS/2 keyboard is
> > > connected. Therefore this is reason why touchpad downgrade to to bare
> > > mode. And according to Mario, host system should issue vendor specific
> > > PS/2 commands to re-initialize all PS/2 devices when this situation
> > > happen. Mario also told me that Windows is doing this action.
> > 
> > Yeah, I remember fun with Inspiron 8100 - when you dock it it woudl
> > silently switch Synaptics touchpad into standard mode and it would not
> > come back as Synaptics until you disconnect. And there was no
> > notification to the kernel as far as I could tell.
> > 
> > It could be that we need to monitor dock events and then kick reconnect
> > of serio port, either from userspace via udev (I think that would be
> > preferred), or in kernel.
> > 
> > > 
> > > Every time when I connect external PS/2 keyboard to dock I see this
> > > message in dmesg:
> > > 
> > > Spurious ACK... Some program might be trying to access hardware directly.
> > > 
> > > I see it also every time when I dock laptop into docking station (to
> > > which is keyboard already connected). And it happens also when I connect
> > > external PS/2 mouse to dock.
> > > 
> > > Dmitry, how to handle this situation to re-initialize psmouse.ko when
> > > external PS/2 device is connected to Dell E docking station? According
> > > to Mario, this is how Dell Embedded Controller is designed and suppose
> > > how OS should work with it.
> > > 
> > > Manually rmmoding and modprobing for every docking/undocking laptop is
> > > not ideal solution.
> > > 
> > > Could it be possible to use that Spurious ATKBD_RET_ACK from atkbd.c be
> > > handled on Dell systems (probably via DMI) as an event to reset and
> > > reinitialize all PS/2 devices?
> > 
> > So we need to figure out what exactly we are getting from the docking
> > station in this case. We do try to handle the new device 0xaa 0x00
> > announcements:
> > 
> > 	/* Check if this is a new device announcement (0xAA 0x00) */
> > 	if (unlikely(psmouse->packet[0] == PSMOUSE_RET_BAT && psmouse->pktcnt <= 2)) {
> > 		if (psmouse->pktcnt == 1) {
> > 			psmouse->last = jiffies;
> > 			goto out;
> > 		}
> > 
> > 		if (psmouse->packet[1] == PSMOUSE_RET_ID ||
> > 		    (psmouse->protocol->type == PSMOUSE_HGPK &&
> > 		     psmouse->packet[1] == PSMOUSE_RET_BAT)) {
> > 			__psmouse_set_state(psmouse, PSMOUSE_IGNORE);
> > 			serio_reconnect(serio);
> > 			goto out;
> > 		}
> > 
> > ...
> > 
> > I am not sure where the "spurious ACK comes from". Can you enable i8042
> > debug before trying to dock and capture the data stream from the mouse?
> > 
> > Thanks.
> > 
> 
> Hi Dmitry!
> 
> I enabled unmask_kbd_data and debug and here is output from dmesg.
> 
> echo Y > /sys/module/i8042/parameters/debug
> echo Y > /sys/module/i8042/parameters/unmask_kbd_data
> 
> PS/2 keyboard is already connected in dock and laptop was just docked:
> 
> [25461.552314] i8042: [6365474] fa <- i8042 (interrupt, 0, 1)
> [25461.552319] atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.
> [25462.707296] i8042: [6365763] ed -> i8042 (kbd-data)
> [25462.851289] i8042: [6365799] fa <- i8042 (interrupt, 0, 1)
> [25462.851303] i8042: [6365799] 00 -> i8042 (kbd-data)
> [25462.858437] i8042: [6365801] fa <- i8042 (interrupt, 0, 1)
> [25462.869512] i8042: [6365804] fa <- i8042 (interrupt, 0, 1)
> [25462.869517] atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.
> [25463.670515] i8042: [6366004] ed -> i8042 (kbd-data)
> [25463.670647] i8042: [6366004] fa <- i8042 (interrupt, 0, 1)
> [25463.670655] i8042: [6366004] 02 -> i8042 (kbd-data)
> [25463.676769] i8042: [6366005] fa <- i8042 (interrupt, 0, 1)
> 
> 
> Laptop is docked and PS/2 keyboard was just connected:
> 
> [26571.014368] i8042: [6642848] fa <- i8042 (interrupt, 0, 1)
> [26571.014380] atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.
> 
> 
> In both cases there is no events from touchpad, only from keyboard. So
> Dell EC silently reset PS/2 touchpad when PS/2 keyboard is attached.
> 
> So I think we should capture 0xFA and on Dell machines we should
> reinitialize PS/2 drivers. As there is really nothing more then 0xFA.

Info about PS/2 mouse:

In case I have laptop already docked and just connect PS/2 mouse there
is absolutely no i8042 event.

To check that mouse is worked I clicked button and then in dmesg
appeared:

[ 3945.481403] i8042: [986322] 09 <- i8042 (interrupt, 1, 12)
[ 3945.482486] i8042: [986323] 00 <- i8042 (interrupt, 1, 12)
[ 3945.483667] i8042: [986323] 00 <- i8042 (interrupt, 1, 12)
[ 3945.483917] input: PS/2 ALPS Mouse as /devices/platform/i8042/serio1/input/input36
[ 3945.594926] i8042: [986351] 08 <- i8042 (interrupt, 1, 12)
[ 3945.596062] i8042: [986351] 00 <- i8042 (interrupt, 1, 12)
[ 3945.597203] i8042: [986351] 00 <- i8042 (interrupt, 1, 12)

So we have no way to detect when external PS/2 mouse was connected to
dock. But ALPS driver can deal with it and process these mouse events.

And when I have already connected PS/2 mouse to the dock and I'm just
putting laptop into dock, then I get following events:

[ 4336.481381] i8042: [1084079] fa <- i8042 (interrupt, 0, 1)
[ 4336.481388] atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.
[ 4337.653275] i8042: [1084372] ed -> i8042 (kbd-data)
[ 4337.949198] i8042: [1084446] fa <- i8042 (interrupt, 0, 1)
[ 4337.949202] atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.
[ 4338.623167] i8042: [1084615] ed -> i8042 (kbd-data)

So again, no event from mouse, just from keyboard.

Note that in these tests I have disconnected my PS/2 keyboard from
dock.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Dell docking station & Dell Embedded Controller & PS/2 devices

[Dmitry Torokhov]

On Mon, May 07, 2018 at 10:44:31AM +0200, Pali Rohár wrote:
> On Sunday 06 May 2018 15:47:33 Pali Rohár wrote:
> > On Thursday 01 February 2018 11:29:45 Dmitry Torokhov wrote:
> > > Hi Pali,
> > > 
> > > On Wed, Jan 24, 2018 at 11:41:21AM +0100, Pali Rohár wrote:
> > > > Hi Dmitry!
> > > > 
> > > > I'm observing a problem with internal touchpad (handled by psmouse.ko)
> > > > on Dell laptops connected to Dell E docking station. When I connect
> > > > external PS/2 keyboard to docking station then internal laptop touchpad
> > > > switch from multitouch absolute mode to relative bare PS/2 mode.
> > > > 
> > > > And because ALPS driver in psmouse.ko is capable to process interleaved
> > > > bare 3-byte PS/2 packets with 6-byte ALPS packets (which handles
> > > > trackstick data on some ALPS models), ALPS driver does not show any
> > > > message about this "downgrade" from multitouch to bare mode. And
> > > > continue working in bare mode.
> > > > 
> > > > When I rmmod psmouse and modprobe it again, then touchpad switch back to
> > > > multitouch mode.
> > > > 
> > > > Mario told me that Dell Embedded Controller, which handle internal
> > > > keyboard, internal touchpad and external PS/2 keyboard, automatically
> > > > send RESET command to *all* those devices when external PS/2 keyboard is
> > > > connected. Therefore this is reason why touchpad downgrade to to bare
> > > > mode. And according to Mario, host system should issue vendor specific
> > > > PS/2 commands to re-initialize all PS/2 devices when this situation
> > > > happen. Mario also told me that Windows is doing this action.
> > > 
> > > Yeah, I remember fun with Inspiron 8100 - when you dock it it woudl
> > > silently switch Synaptics touchpad into standard mode and it would not
> > > come back as Synaptics until you disconnect. And there was no
> > > notification to the kernel as far as I could tell.
> > > 
> > > It could be that we need to monitor dock events and then kick reconnect
> > > of serio port, either from userspace via udev (I think that would be
> > > preferred), or in kernel.
> > > 
> > > > 
> > > > Every time when I connect external PS/2 keyboard to dock I see this
> > > > message in dmesg:
> > > > 
> > > > Spurious ACK... Some program might be trying to access hardware directly.
> > > > 
> > > > I see it also every time when I dock laptop into docking station (to
> > > > which is keyboard already connected). And it happens also when I connect
> > > > external PS/2 mouse to dock.
> > > > 
> > > > Dmitry, how to handle this situation to re-initialize psmouse.ko when
> > > > external PS/2 device is connected to Dell E docking station? According
> > > > to Mario, this is how Dell Embedded Controller is designed and suppose
> > > > how OS should work with it.
> > > > 
> > > > Manually rmmoding and modprobing for every docking/undocking laptop is
> > > > not ideal solution.
> > > > 
> > > > Could it be possible to use that Spurious ATKBD_RET_ACK from atkbd.c be
> > > > handled on Dell systems (probably via DMI) as an event to reset and
> > > > reinitialize all PS/2 devices?
> > > 
> > > So we need to figure out what exactly we are getting from the docking
> > > station in this case. We do try to handle the new device 0xaa 0x00
> > > announcements:
> > > 
> > > 	/* Check if this is a new device announcement (0xAA 0x00) */
> > > 	if (unlikely(psmouse->packet[0] == PSMOUSE_RET_BAT && psmouse->pktcnt <= 2)) {
> > > 		if (psmouse->pktcnt == 1) {
> > > 			psmouse->last = jiffies;
> > > 			goto out;
> > > 		}
> > > 
> > > 		if (psmouse->packet[1] == PSMOUSE_RET_ID ||
> > > 		    (psmouse->protocol->type == PSMOUSE_HGPK &&
> > > 		     psmouse->packet[1] == PSMOUSE_RET_BAT)) {
> > > 			__psmouse_set_state(psmouse, PSMOUSE_IGNORE);
> > > 			serio_reconnect(serio);
> > > 			goto out;
> > > 		}
> > > 
> > > ...
> > > 
> > > I am not sure where the "spurious ACK comes from". Can you enable i8042
> > > debug before trying to dock and capture the data stream from the mouse?
> > > 
> > > Thanks.
> > > 
> > 
> > Hi Dmitry!
> > 
> > I enabled unmask_kbd_data and debug and here is output from dmesg.
> > 
> > echo Y > /sys/module/i8042/parameters/debug
> > echo Y > /sys/module/i8042/parameters/unmask_kbd_data
> > 
> > PS/2 keyboard is already connected in dock and laptop was just docked:
> > 
> > [25461.552314] i8042: [6365474] fa <- i8042 (interrupt, 0, 1)
> > [25461.552319] atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.
> > [25462.707296] i8042: [6365763] ed -> i8042 (kbd-data)
> > [25462.851289] i8042: [6365799] fa <- i8042 (interrupt, 0, 1)
> > [25462.851303] i8042: [6365799] 00 -> i8042 (kbd-data)
> > [25462.858437] i8042: [6365801] fa <- i8042 (interrupt, 0, 1)
> > [25462.869512] i8042: [6365804] fa <- i8042 (interrupt, 0, 1)
> > [25462.869517] atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.
> > [25463.670515] i8042: [6366004] ed -> i8042 (kbd-data)
> > [25463.670647] i8042: [6366004] fa <- i8042 (interrupt, 0, 1)
> > [25463.670655] i8042: [6366004] 02 -> i8042 (kbd-data)
> > [25463.676769] i8042: [6366005] fa <- i8042 (interrupt, 0, 1)
> > 
> > 
> > Laptop is docked and PS/2 keyboard was just connected:
> > 
> > [26571.014368] i8042: [6642848] fa <- i8042 (interrupt, 0, 1)
> > [26571.014380] atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.
> > 
> > 
> > In both cases there is no events from touchpad, only from keyboard. So
> > Dell EC silently reset PS/2 touchpad when PS/2 keyboard is attached.
> > 
> > So I think we should capture 0xFA and on Dell machines we should
> > reinitialize PS/2 drivers. As there is really nothing more then 0xFA.
> 
> Info about PS/2 mouse:
> 
> In case I have laptop already docked and just connect PS/2 mouse there
> is absolutely no i8042 event.
> 
> To check that mouse is worked I clicked button and then in dmesg
> appeared:
> 
> [ 3945.481403] i8042: [986322] 09 <- i8042 (interrupt, 1, 12)
> [ 3945.482486] i8042: [986323] 00 <- i8042 (interrupt, 1, 12)
> [ 3945.483667] i8042: [986323] 00 <- i8042 (interrupt, 1, 12)
> [ 3945.483917] input: PS/2 ALPS Mouse as /devices/platform/i8042/serio1/input/input36
> [ 3945.594926] i8042: [986351] 08 <- i8042 (interrupt, 1, 12)
> [ 3945.596062] i8042: [986351] 00 <- i8042 (interrupt, 1, 12)
> [ 3945.597203] i8042: [986351] 00 <- i8042 (interrupt, 1, 12)
> 
> So we have no way to detect when external PS/2 mouse was connected to
> dock. But ALPS driver can deal with it and process these mouse events.
> 
> And when I have already connected PS/2 mouse to the dock and I'm just
> putting laptop into dock, then I get following events:
> 
> [ 4336.481381] i8042: [1084079] fa <- i8042 (interrupt, 0, 1)
> [ 4336.481388] atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.
> [ 4337.653275] i8042: [1084372] ed -> i8042 (kbd-data)

I wonder where this "set leds" command is coming from and where is the
parameter... Can you add some more tracing? And maybe boot with
libps2.dyndbg=+pf

> [ 4337.949198] i8042: [1084446] fa <- i8042 (interrupt, 0, 1)
> [ 4337.949202] atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.
> [ 4338.623167] i8042: [1084615] ed -> i8042 (kbd-data)
> 
> So again, no event from mouse, just from keyboard.
> 
> Note that in these tests I have disconnected my PS/2 keyboard from
> dock.

So I guess you could write a platform driver that would install i8042
filter on Dell laptops/portables, monitor keyboard data stream and kick
of rescans on serio ports. The problem is filter gets "serio" so you do
not really know whether ACK is spurious or not. And I would really
prefer keeping this crap out of atkbd proper... And all of this is racy
as hell. What happens if we get keyboard reconnected as we reinitialize
it?

Mario, how does Windows driver know when it should send "vendor"
commands to reinitialize peripherals?

Thanks.

-- 
Dmitry

Re: Dell docking station & Dell Embedded Controller & PS/2 devices

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 9432 bytes --]

On Monday 07 May 2018 12:33:06 Dmitry Torokhov wrote:
> On Mon, May 07, 2018 at 10:44:31AM +0200, Pali Rohár wrote:
> > On Sunday 06 May 2018 15:47:33 Pali Rohár wrote:
> > > On Thursday 01 February 2018 11:29:45 Dmitry Torokhov wrote:
> > > > Hi Pali,
> > > > 
> > > > On Wed, Jan 24, 2018 at 11:41:21AM +0100, Pali Rohár wrote:
> > > > > Hi Dmitry!
> > > > > 
> > > > > I'm observing a problem with internal touchpad (handled by psmouse.ko)
> > > > > on Dell laptops connected to Dell E docking station. When I connect
> > > > > external PS/2 keyboard to docking station then internal laptop touchpad
> > > > > switch from multitouch absolute mode to relative bare PS/2 mode.
> > > > > 
> > > > > And because ALPS driver in psmouse.ko is capable to process interleaved
> > > > > bare 3-byte PS/2 packets with 6-byte ALPS packets (which handles
> > > > > trackstick data on some ALPS models), ALPS driver does not show any
> > > > > message about this "downgrade" from multitouch to bare mode. And
> > > > > continue working in bare mode.
> > > > > 
> > > > > When I rmmod psmouse and modprobe it again, then touchpad switch back to
> > > > > multitouch mode.
> > > > > 
> > > > > Mario told me that Dell Embedded Controller, which handle internal
> > > > > keyboard, internal touchpad and external PS/2 keyboard, automatically
> > > > > send RESET command to *all* those devices when external PS/2 keyboard is
> > > > > connected. Therefore this is reason why touchpad downgrade to to bare
> > > > > mode. And according to Mario, host system should issue vendor specific
> > > > > PS/2 commands to re-initialize all PS/2 devices when this situation
> > > > > happen. Mario also told me that Windows is doing this action.
> > > > 
> > > > Yeah, I remember fun with Inspiron 8100 - when you dock it it woudl
> > > > silently switch Synaptics touchpad into standard mode and it would not
> > > > come back as Synaptics until you disconnect. And there was no
> > > > notification to the kernel as far as I could tell.
> > > > 
> > > > It could be that we need to monitor dock events and then kick reconnect
> > > > of serio port, either from userspace via udev (I think that would be
> > > > preferred), or in kernel.
> > > > 
> > > > > 
> > > > > Every time when I connect external PS/2 keyboard to dock I see this
> > > > > message in dmesg:
> > > > > 
> > > > > Spurious ACK... Some program might be trying to access hardware directly.
> > > > > 
> > > > > I see it also every time when I dock laptop into docking station (to
> > > > > which is keyboard already connected). And it happens also when I connect
> > > > > external PS/2 mouse to dock.
> > > > > 
> > > > > Dmitry, how to handle this situation to re-initialize psmouse.ko when
> > > > > external PS/2 device is connected to Dell E docking station? According
> > > > > to Mario, this is how Dell Embedded Controller is designed and suppose
> > > > > how OS should work with it.
> > > > > 
> > > > > Manually rmmoding and modprobing for every docking/undocking laptop is
> > > > > not ideal solution.
> > > > > 
> > > > > Could it be possible to use that Spurious ATKBD_RET_ACK from atkbd.c be
> > > > > handled on Dell systems (probably via DMI) as an event to reset and
> > > > > reinitialize all PS/2 devices?
> > > > 
> > > > So we need to figure out what exactly we are getting from the docking
> > > > station in this case. We do try to handle the new device 0xaa 0x00
> > > > announcements:
> > > > 
> > > > 	/* Check if this is a new device announcement (0xAA 0x00) */
> > > > 	if (unlikely(psmouse->packet[0] == PSMOUSE_RET_BAT && psmouse->pktcnt <= 2)) {
> > > > 		if (psmouse->pktcnt == 1) {
> > > > 			psmouse->last = jiffies;
> > > > 			goto out;
> > > > 		}
> > > > 
> > > > 		if (psmouse->packet[1] == PSMOUSE_RET_ID ||
> > > > 		    (psmouse->protocol->type == PSMOUSE_HGPK &&
> > > > 		     psmouse->packet[1] == PSMOUSE_RET_BAT)) {
> > > > 			__psmouse_set_state(psmouse, PSMOUSE_IGNORE);
> > > > 			serio_reconnect(serio);
> > > > 			goto out;
> > > > 		}
> > > > 
> > > > ...
> > > > 
> > > > I am not sure where the "spurious ACK comes from". Can you enable i8042
> > > > debug before trying to dock and capture the data stream from the mouse?
> > > > 
> > > > Thanks.
> > > > 
> > > 
> > > Hi Dmitry!
> > > 
> > > I enabled unmask_kbd_data and debug and here is output from dmesg.
> > > 
> > > echo Y > /sys/module/i8042/parameters/debug
> > > echo Y > /sys/module/i8042/parameters/unmask_kbd_data
> > > 
> > > PS/2 keyboard is already connected in dock and laptop was just docked:
> > > 
> > > [25461.552314] i8042: [6365474] fa <- i8042 (interrupt, 0, 1)
> > > [25461.552319] atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.
> > > [25462.707296] i8042: [6365763] ed -> i8042 (kbd-data)
> > > [25462.851289] i8042: [6365799] fa <- i8042 (interrupt, 0, 1)
> > > [25462.851303] i8042: [6365799] 00 -> i8042 (kbd-data)
> > > [25462.858437] i8042: [6365801] fa <- i8042 (interrupt, 0, 1)
> > > [25462.869512] i8042: [6365804] fa <- i8042 (interrupt, 0, 1)
> > > [25462.869517] atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.
> > > [25463.670515] i8042: [6366004] ed -> i8042 (kbd-data)
> > > [25463.670647] i8042: [6366004] fa <- i8042 (interrupt, 0, 1)
> > > [25463.670655] i8042: [6366004] 02 -> i8042 (kbd-data)
> > > [25463.676769] i8042: [6366005] fa <- i8042 (interrupt, 0, 1)
> > > 
> > > 
> > > Laptop is docked and PS/2 keyboard was just connected:
> > > 
> > > [26571.014368] i8042: [6642848] fa <- i8042 (interrupt, 0, 1)
> > > [26571.014380] atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.
> > > 
> > > 
> > > In both cases there is no events from touchpad, only from keyboard. So
> > > Dell EC silently reset PS/2 touchpad when PS/2 keyboard is attached.
> > > 
> > > So I think we should capture 0xFA and on Dell machines we should
> > > reinitialize PS/2 drivers. As there is really nothing more then 0xFA.
> > 
> > Info about PS/2 mouse:
> > 
> > In case I have laptop already docked and just connect PS/2 mouse there
> > is absolutely no i8042 event.
> > 
> > To check that mouse is worked I clicked button and then in dmesg
> > appeared:
> > 
> > [ 3945.481403] i8042: [986322] 09 <- i8042 (interrupt, 1, 12)
> > [ 3945.482486] i8042: [986323] 00 <- i8042 (interrupt, 1, 12)
> > [ 3945.483667] i8042: [986323] 00 <- i8042 (interrupt, 1, 12)
> > [ 3945.483917] input: PS/2 ALPS Mouse as /devices/platform/i8042/serio1/input/input36
> > [ 3945.594926] i8042: [986351] 08 <- i8042 (interrupt, 1, 12)
> > [ 3945.596062] i8042: [986351] 00 <- i8042 (interrupt, 1, 12)
> > [ 3945.597203] i8042: [986351] 00 <- i8042 (interrupt, 1, 12)
> > 
> > So we have no way to detect when external PS/2 mouse was connected to
> > dock. But ALPS driver can deal with it and process these mouse events.
> > 
> > And when I have already connected PS/2 mouse to the dock and I'm just
> > putting laptop into dock, then I get following events:
> > 
> > [ 4336.481381] i8042: [1084079] fa <- i8042 (interrupt, 0, 1)
> > [ 4336.481388] atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.
> > [ 4337.653275] i8042: [1084372] ed -> i8042 (kbd-data)
> 
> I wonder where this "set leds" command is coming from and where is the
> parameter... Can you add some more tracing? And maybe boot with
> libps2.dyndbg=+pf
> 
> > [ 4337.949198] i8042: [1084446] fa <- i8042 (interrupt, 0, 1)
> > [ 4337.949202] atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.
> > [ 4338.623167] i8042: [1084615] ed -> i8042 (kbd-data)
> > 
> > So again, no event from mouse, just from keyboard.
> > 
> > Note that in these tests I have disconnected my PS/2 keyboard from
> > dock.
> 
> So I guess you could write a platform driver that would install i8042
> filter on Dell laptops/portables, monitor keyboard data stream and kick
> of rescans on serio ports.

Ok. dell-laptop.ko already installs i8042 filter, so it could be
extended.

How can such dell-laptop.ko driver instruct serio0/1 devices to
reinitialize bound drivers (atk and psmouse, probably other)?

> The problem is filter gets "serio" so you do
> not really know whether ACK is spurious or not.

It is possible to extend i8042/serio driver to provide information via
i8042 filter callback if ACK is spurious or not?

> And I would really
> prefer keeping this crap out of atkbd proper... And all of this is racy
> as hell. What happens if we get keyboard reconnected as we reinitialize
> it?

Do not know, such race conditions are hard to test as you need correct
timing. And doing connecting/disconnecting PS/2 cable from dock together
with laptop docking/undocking cannot be done reliable for less then 5s
(need to press two buttons, take/unplug laptop + reconnecting PS/2 slot)
so hard to simulate race condition.

Plus we do not know what is that Dell EC doing with PS/2 data...

> Mario, how does Windows driver know when it should send "vendor"
> commands to reinitialize peripherals?
> 
> Thanks.
> 

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

RE: Dell docking station & Dell Embedded Controller & PS/2 devices

[Mario.Limonciello]

> -----Original Message-----
> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> Sent: Monday, May 7, 2018 2:33 PM
> To: Pali Rohár
> Cc: Limonciello, Mario; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: Dell docking station & Dell Embedded Controller & PS/2 devices
> 
> On Mon, May 07, 2018 at 10:44:31AM +0200, Pali Rohár wrote:
> > On Sunday 06 May 2018 15:47:33 Pali Rohár wrote:
> > > On Thursday 01 February 2018 11:29:45 Dmitry Torokhov wrote:
> > > > Hi Pali,
> > > >
> > > > On Wed, Jan 24, 2018 at 11:41:21AM +0100, Pali Rohár wrote:
> > > > > Hi Dmitry!
> > > > >
> > > > > I'm observing a problem with internal touchpad (handled by psmouse.ko)
> > > > > on Dell laptops connected to Dell E docking station. When I connect
> > > > > external PS/2 keyboard to docking station then internal laptop touchpad
> > > > > switch from multitouch absolute mode to relative bare PS/2 mode.
> > > > >
> > > > > And because ALPS driver in psmouse.ko is capable to process interleaved
> > > > > bare 3-byte PS/2 packets with 6-byte ALPS packets (which handles
> > > > > trackstick data on some ALPS models), ALPS driver does not show any
> > > > > message about this "downgrade" from multitouch to bare mode. And
> > > > > continue working in bare mode.
> > > > >
> > > > > When I rmmod psmouse and modprobe it again, then touchpad switch back
> to
> > > > > multitouch mode.
> > > > >
> > > > > Mario told me that Dell Embedded Controller, which handle internal
> > > > > keyboard, internal touchpad and external PS/2 keyboard, automatically
> > > > > send RESET command to *all* those devices when external PS/2 keyboard is
> > > > > connected. Therefore this is reason why touchpad downgrade to to bare
> > > > > mode. And according to Mario, host system should issue vendor specific
> > > > > PS/2 commands to re-initialize all PS/2 devices when this situation
> > > > > happen. Mario also told me that Windows is doing this action.
> > > >
> > > > Yeah, I remember fun with Inspiron 8100 - when you dock it it woudl
> > > > silently switch Synaptics touchpad into standard mode and it would not
> > > > come back as Synaptics until you disconnect. And there was no
> > > > notification to the kernel as far as I could tell.
> > > >
> > > > It could be that we need to monitor dock events and then kick reconnect
> > > > of serio port, either from userspace via udev (I think that would be
> > > > preferred), or in kernel.
> > > >
> > > > >
> > > > > Every time when I connect external PS/2 keyboard to dock I see this
> > > > > message in dmesg:
> > > > >
> > > > > Spurious ACK... Some program might be trying to access hardware directly.
> > > > >
> > > > > I see it also every time when I dock laptop into docking station (to
> > > > > which is keyboard already connected). And it happens also when I connect
> > > > > external PS/2 mouse to dock.
> > > > >
> > > > > Dmitry, how to handle this situation to re-initialize psmouse.ko when
> > > > > external PS/2 device is connected to Dell E docking station? According
> > > > > to Mario, this is how Dell Embedded Controller is designed and suppose
> > > > > how OS should work with it.
> > > > >
> > > > > Manually rmmoding and modprobing for every docking/undocking laptop is
> > > > > not ideal solution.
> > > > >
> > > > > Could it be possible to use that Spurious ATKBD_RET_ACK from atkbd.c be
> > > > > handled on Dell systems (probably via DMI) as an event to reset and
> > > > > reinitialize all PS/2 devices?
> > > >
> > > > So we need to figure out what exactly we are getting from the docking
> > > > station in this case. We do try to handle the new device 0xaa 0x00
> > > > announcements:
> > > >
> > > > 	/* Check if this is a new device announcement (0xAA 0x00) */
> > > > 	if (unlikely(psmouse->packet[0] == PSMOUSE_RET_BAT && psmouse-
> >pktcnt <= 2)) {
> > > > 		if (psmouse->pktcnt == 1) {
> > > > 			psmouse->last = jiffies;
> > > > 			goto out;
> > > > 		}
> > > >
> > > > 		if (psmouse->packet[1] == PSMOUSE_RET_ID ||
> > > > 		    (psmouse->protocol->type == PSMOUSE_HGPK &&
> > > > 		     psmouse->packet[1] == PSMOUSE_RET_BAT)) {
> > > > 			__psmouse_set_state(psmouse, PSMOUSE_IGNORE);
> > > > 			serio_reconnect(serio);
> > > > 			goto out;
> > > > 		}
> > > >
> > > > ...
> > > >
> > > > I am not sure where the "spurious ACK comes from". Can you enable i8042
> > > > debug before trying to dock and capture the data stream from the mouse?
> > > >
> > > > Thanks.
> > > >
> > >
> > > Hi Dmitry!
> > >
> > > I enabled unmask_kbd_data and debug and here is output from dmesg.
> > >
> > > echo Y > /sys/module/i8042/parameters/debug
> > > echo Y > /sys/module/i8042/parameters/unmask_kbd_data
> > >
> > > PS/2 keyboard is already connected in dock and laptop was just docked:
> > >
> > > [25461.552314] i8042: [6365474] fa <- i8042 (interrupt, 0, 1)
> > > [25461.552319] atkbd serio0: Spurious ACK on isa0060/serio0. Some program
> might be trying to access hardware directly.
> > > [25462.707296] i8042: [6365763] ed -> i8042 (kbd-data)
> > > [25462.851289] i8042: [6365799] fa <- i8042 (interrupt, 0, 1)
> > > [25462.851303] i8042: [6365799] 00 -> i8042 (kbd-data)
> > > [25462.858437] i8042: [6365801] fa <- i8042 (interrupt, 0, 1)
> > > [25462.869512] i8042: [6365804] fa <- i8042 (interrupt, 0, 1)
> > > [25462.869517] atkbd serio0: Spurious ACK on isa0060/serio0. Some program
> might be trying to access hardware directly.
> > > [25463.670515] i8042: [6366004] ed -> i8042 (kbd-data)
> > > [25463.670647] i8042: [6366004] fa <- i8042 (interrupt, 0, 1)
> > > [25463.670655] i8042: [6366004] 02 -> i8042 (kbd-data)
> > > [25463.676769] i8042: [6366005] fa <- i8042 (interrupt, 0, 1)
> > >
> > >
> > > Laptop is docked and PS/2 keyboard was just connected:
> > >
> > > [26571.014368] i8042: [6642848] fa <- i8042 (interrupt, 0, 1)
> > > [26571.014380] atkbd serio0: Spurious ACK on isa0060/serio0. Some program
> might be trying to access hardware directly.
> > >
> > >
> > > In both cases there is no events from touchpad, only from keyboard. So
> > > Dell EC silently reset PS/2 touchpad when PS/2 keyboard is attached.
> > >
> > > So I think we should capture 0xFA and on Dell machines we should
> > > reinitialize PS/2 drivers. As there is really nothing more then 0xFA.
> >
> > Info about PS/2 mouse:
> >
> > In case I have laptop already docked and just connect PS/2 mouse there
> > is absolutely no i8042 event.
> >
> > To check that mouse is worked I clicked button and then in dmesg
> > appeared:
> >
> > [ 3945.481403] i8042: [986322] 09 <- i8042 (interrupt, 1, 12)
> > [ 3945.482486] i8042: [986323] 00 <- i8042 (interrupt, 1, 12)
> > [ 3945.483667] i8042: [986323] 00 <- i8042 (interrupt, 1, 12)
> > [ 3945.483917] input: PS/2 ALPS Mouse as
> /devices/platform/i8042/serio1/input/input36
> > [ 3945.594926] i8042: [986351] 08 <- i8042 (interrupt, 1, 12)
> > [ 3945.596062] i8042: [986351] 00 <- i8042 (interrupt, 1, 12)
> > [ 3945.597203] i8042: [986351] 00 <- i8042 (interrupt, 1, 12)
> >
> > So we have no way to detect when external PS/2 mouse was connected to
> > dock. But ALPS driver can deal with it and process these mouse events.
> >
> > And when I have already connected PS/2 mouse to the dock and I'm just
> > putting laptop into dock, then I get following events:
> >
> > [ 4336.481381] i8042: [1084079] fa <- i8042 (interrupt, 0, 1)
> > [ 4336.481388] atkbd serio0: Spurious ACK on isa0060/serio0. Some program
> might be trying to access hardware directly.
> > [ 4337.653275] i8042: [1084372] ed -> i8042 (kbd-data)
> 
> I wonder where this "set leds" command is coming from and where is the
> parameter... Can you add some more tracing? And maybe boot with
> libps2.dyndbg=+pf
> 
> > [ 4337.949198] i8042: [1084446] fa <- i8042 (interrupt, 0, 1)
> > [ 4337.949202] atkbd serio0: Spurious ACK on isa0060/serio0. Some program
> might be trying to access hardware directly.
> > [ 4338.623167] i8042: [1084615] ed -> i8042 (kbd-data)
> >
> > So again, no event from mouse, just from keyboard.
> >
> > Note that in these tests I have disconnected my PS/2 keyboard from
> > dock.
> 
> So I guess you could write a platform driver that would install i8042
> filter on Dell laptops/portables, monitor keyboard data stream and kick
> of rescans on serio ports. The problem is filter gets "serio" so you do
> not really know whether ACK is spurious or not. And I would really
> prefer keeping this crap out of atkbd proper... And all of this is racy
> as hell. What happens if we get keyboard reconnected as we reinitialize
> it?

If it's done as a platform driver I would suspect it's possible to tell whether
a dock is connected to at least give you some heuristic here to have a better
guess whether it's spurious.

Pali on your system that supports this dock, check and see how many
System Enclosure SMBIOS tables (structure type 03) are present.
There should be a separate one for the dock as far as I can tell with values
that will vary based on whether it's attached.

Assuming that's true I think making a platform filter driver that only attaches
to systems that actually support this type of dock should be possible too.

> 
> Mario, how does Windows driver know when it should send "vendor"
> commands to reinitialize peripherals?
> 

Sorry , I don't know.  It's "inbox" Windows drivers that are used here so
it's a "black box" to me how they work.

RE: Dell docking station & Dell Embedded Controller & PS/2 devices

[Mario.Limonciello]

> -----Original Message-----
> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> Sent: Monday, May 7, 2018 2:33 PM
> To: Pali Rohár
> Cc: Limonciello, Mario; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: Dell docking station & Dell Embedded Controller & PS/2 devices
> 
> On Mon, May 07, 2018 at 10:44:31AM +0200, Pali Rohár wrote:
> > On Sunday 06 May 2018 15:47:33 Pali Rohár wrote:
> > > On Thursday 01 February 2018 11:29:45 Dmitry Torokhov wrote:
> > > > Hi Pali,
> > > >
> > > > On Wed, Jan 24, 2018 at 11:41:21AM +0100, Pali Rohár wrote:
> > > > > Hi Dmitry!
> > > > >
> > > > > I'm observing a problem with internal touchpad (handled by psmouse.ko)
> > > > > on Dell laptops connected to Dell E docking station. When I connect
> > > > > external PS/2 keyboard to docking station then internal laptop touchpad
> > > > > switch from multitouch absolute mode to relative bare PS/2 mode.
> > > > >
> > > > > And because ALPS driver in psmouse.ko is capable to process interleaved
> > > > > bare 3-byte PS/2 packets with 6-byte ALPS packets (which handles
> > > > > trackstick data on some ALPS models), ALPS driver does not show any
> > > > > message about this "downgrade" from multitouch to bare mode. And
> > > > > continue working in bare mode.
> > > > >
> > > > > When I rmmod psmouse and modprobe it again, then touchpad switch back
> to
> > > > > multitouch mode.
> > > > >
> > > > > Mario told me that Dell Embedded Controller, which handle internal
> > > > > keyboard, internal touchpad and external PS/2 keyboard, automatically
> > > > > send RESET command to *all* those devices when external PS/2 keyboard is
> > > > > connected. Therefore this is reason why touchpad downgrade to to bare
> > > > > mode. And according to Mario, host system should issue vendor specific
> > > > > PS/2 commands to re-initialize all PS/2 devices when this situation
> > > > > happen. Mario also told me that Windows is doing this action.
> > > >
> > > > Yeah, I remember fun with Inspiron 8100 - when you dock it it woudl
> > > > silently switch Synaptics touchpad into standard mode and it would not
> > > > come back as Synaptics until you disconnect. And there was no
> > > > notification to the kernel as far as I could tell.
> > > >
> > > > It could be that we need to monitor dock events and then kick reconnect
> > > > of serio port, either from userspace via udev (I think that would be
> > > > preferred), or in kernel.
> > > >
> > > > >
> > > > > Every time when I connect external PS/2 keyboard to dock I see this
> > > > > message in dmesg:
> > > > >
> > > > > Spurious ACK... Some program might be trying to access hardware directly.
> > > > >
> > > > > I see it also every time when I dock laptop into docking station (to
> > > > > which is keyboard already connected). And it happens also when I connect
> > > > > external PS/2 mouse to dock.
> > > > >
> > > > > Dmitry, how to handle this situation to re-initialize psmouse.ko when
> > > > > external PS/2 device is connected to Dell E docking station? According
> > > > > to Mario, this is how Dell Embedded Controller is designed and suppose
> > > > > how OS should work with it.
> > > > >
> > > > > Manually rmmoding and modprobing for every docking/undocking laptop is
> > > > > not ideal solution.
> > > > >
> > > > > Could it be possible to use that Spurious ATKBD_RET_ACK from atkbd.c be
> > > > > handled on Dell systems (probably via DMI) as an event to reset and
> > > > > reinitialize all PS/2 devices?
> > > >
> > > > So we need to figure out what exactly we are getting from the docking
> > > > station in this case. We do try to handle the new device 0xaa 0x00
> > > > announcements:
> > > >
> > > > 	/* Check if this is a new device announcement (0xAA 0x00) */
> > > > 	if (unlikely(psmouse->packet[0] == PSMOUSE_RET_BAT && psmouse-
> >pktcnt <= 2)) {
> > > > 		if (psmouse->pktcnt == 1) {
> > > > 			psmouse->last = jiffies;
> > > > 			goto out;
> > > > 		}
> > > >
> > > > 		if (psmouse->packet[1] == PSMOUSE_RET_ID ||
> > > > 		    (psmouse->protocol->type == PSMOUSE_HGPK &&
> > > > 		     psmouse->packet[1] == PSMOUSE_RET_BAT)) {
> > > > 			__psmouse_set_state(psmouse, PSMOUSE_IGNORE);
> > > > 			serio_reconnect(serio);
> > > > 			goto out;
> > > > 		}
> > > >
> > > > ...
> > > >
> > > > I am not sure where the "spurious ACK comes from". Can you enable i8042
> > > > debug before trying to dock and capture the data stream from the mouse?
> > > >
> > > > Thanks.
> > > >
> > >
> > > Hi Dmitry!
> > >
> > > I enabled unmask_kbd_data and debug and here is output from dmesg.
> > >
> > > echo Y > /sys/module/i8042/parameters/debug
> > > echo Y > /sys/module/i8042/parameters/unmask_kbd_data
> > >
> > > PS/2 keyboard is already connected in dock and laptop was just docked:
> > >
> > > [25461.552314] i8042: [6365474] fa <- i8042 (interrupt, 0, 1)
> > > [25461.552319] atkbd serio0: Spurious ACK on isa0060/serio0. Some program
> might be trying to access hardware directly.
> > > [25462.707296] i8042: [6365763] ed -> i8042 (kbd-data)
> > > [25462.851289] i8042: [6365799] fa <- i8042 (interrupt, 0, 1)
> > > [25462.851303] i8042: [6365799] 00 -> i8042 (kbd-data)
> > > [25462.858437] i8042: [6365801] fa <- i8042 (interrupt, 0, 1)
> > > [25462.869512] i8042: [6365804] fa <- i8042 (interrupt, 0, 1)
> > > [25462.869517] atkbd serio0: Spurious ACK on isa0060/serio0. Some program
> might be trying to access hardware directly.
> > > [25463.670515] i8042: [6366004] ed -> i8042 (kbd-data)
> > > [25463.670647] i8042: [6366004] fa <- i8042 (interrupt, 0, 1)
> > > [25463.670655] i8042: [6366004] 02 -> i8042 (kbd-data)
> > > [25463.676769] i8042: [6366005] fa <- i8042 (interrupt, 0, 1)
> > >
> > >
> > > Laptop is docked and PS/2 keyboard was just connected:
> > >
> > > [26571.014368] i8042: [6642848] fa <- i8042 (interrupt, 0, 1)
> > > [26571.014380] atkbd serio0: Spurious ACK on isa0060/serio0. Some program
> might be trying to access hardware directly.
> > >
> > >
> > > In both cases there is no events from touchpad, only from keyboard. So
> > > Dell EC silently reset PS/2 touchpad when PS/2 keyboard is attached.
> > >
> > > So I think we should capture 0xFA and on Dell machines we should
> > > reinitialize PS/2 drivers. As there is really nothing more then 0xFA.
> >
> > Info about PS/2 mouse:
> >
> > In case I have laptop already docked and just connect PS/2 mouse there
> > is absolutely no i8042 event.
> >
> > To check that mouse is worked I clicked button and then in dmesg
> > appeared:
> >
> > [ 3945.481403] i8042: [986322] 09 <- i8042 (interrupt, 1, 12)
> > [ 3945.482486] i8042: [986323] 00 <- i8042 (interrupt, 1, 12)
> > [ 3945.483667] i8042: [986323] 00 <- i8042 (interrupt, 1, 12)
> > [ 3945.483917] input: PS/2 ALPS Mouse as
> /devices/platform/i8042/serio1/input/input36
> > [ 3945.594926] i8042: [986351] 08 <- i8042 (interrupt, 1, 12)
> > [ 3945.596062] i8042: [986351] 00 <- i8042 (interrupt, 1, 12)
> > [ 3945.597203] i8042: [986351] 00 <- i8042 (interrupt, 1, 12)
> >
> > So we have no way to detect when external PS/2 mouse was connected to
> > dock. But ALPS driver can deal with it and process these mouse events.
> >
> > And when I have already connected PS/2 mouse to the dock and I'm just
> > putting laptop into dock, then I get following events:
> >
> > [ 4336.481381] i8042: [1084079] fa <- i8042 (interrupt, 0, 1)
> > [ 4336.481388] atkbd serio0: Spurious ACK on isa0060/serio0. Some program
> might be trying to access hardware directly.
> > [ 4337.653275] i8042: [1084372] ed -> i8042 (kbd-data)
> 
> I wonder where this "set leds" command is coming from and where is the
> parameter... Can you add some more tracing? And maybe boot with
> libps2.dyndbg=+pf
> 
> > [ 4337.949198] i8042: [1084446] fa <- i8042 (interrupt, 0, 1)
> > [ 4337.949202] atkbd serio0: Spurious ACK on isa0060/serio0. Some program
> might be trying to access hardware directly.
> > [ 4338.623167] i8042: [1084615] ed -> i8042 (kbd-data)
> >
> > So again, no event from mouse, just from keyboard.
> >
> > Note that in these tests I have disconnected my PS/2 keyboard from
> > dock.
> 
> So I guess you could write a platform driver that would install i8042
> filter on Dell laptops/portables, monitor keyboard data stream and kick
> of rescans on serio ports. The problem is filter gets "serio" so you do
> not really know whether ACK is spurious or not. And I would really
> prefer keeping this crap out of atkbd proper... And all of this is racy
> as hell. What happens if we get keyboard reconnected as we reinitialize
> it?

If it's done as a platform driver I would suspect it's possible to tell whether
a dock is connected to at least give you some heuristic here to have a better
guess whether it's spurious.

Pali on your system that supports this dock, check and see how many
System Enclosure SMBIOS tables (structure type 03) are present.
There should be a separate one for the dock as far as I can tell with values
that will vary based on whether it's attached.

Assuming that's true I think making a platform filter driver that only attaches
to systems that actually support this type of dock should be possible too.

> 
> Mario, how does Windows driver know when it should send "vendor"
> commands to reinitialize peripherals?
> 

Sorry , I don't know.  It's "inbox" Windows drivers that are used here so
it's a "black box" to me how they work.

Re: Dell docking station & Dell Embedded Controller & PS/2 devices

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 11055 bytes --]

On Monday 07 May 2018 19:59:14 Mario.Limonciello@dell.com wrote:
> > -----Original Message-----
> > From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> > Sent: Monday, May 7, 2018 2:33 PM
> > To: Pali Rohár
> > Cc: Limonciello, Mario; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org
> > Subject: Re: Dell docking station & Dell Embedded Controller & PS/2 devices
> > 
> > On Mon, May 07, 2018 at 10:44:31AM +0200, Pali Rohár wrote:
> > > On Sunday 06 May 2018 15:47:33 Pali Rohár wrote:
> > > > On Thursday 01 February 2018 11:29:45 Dmitry Torokhov wrote:
> > > > > Hi Pali,
> > > > >
> > > > > On Wed, Jan 24, 2018 at 11:41:21AM +0100, Pali Rohár wrote:
> > > > > > Hi Dmitry!
> > > > > >
> > > > > > I'm observing a problem with internal touchpad (handled by psmouse.ko)
> > > > > > on Dell laptops connected to Dell E docking station. When I connect
> > > > > > external PS/2 keyboard to docking station then internal laptop touchpad
> > > > > > switch from multitouch absolute mode to relative bare PS/2 mode.
> > > > > >
> > > > > > And because ALPS driver in psmouse.ko is capable to process interleaved
> > > > > > bare 3-byte PS/2 packets with 6-byte ALPS packets (which handles
> > > > > > trackstick data on some ALPS models), ALPS driver does not show any
> > > > > > message about this "downgrade" from multitouch to bare mode. And
> > > > > > continue working in bare mode.
> > > > > >
> > > > > > When I rmmod psmouse and modprobe it again, then touchpad switch back
> > to
> > > > > > multitouch mode.
> > > > > >
> > > > > > Mario told me that Dell Embedded Controller, which handle internal
> > > > > > keyboard, internal touchpad and external PS/2 keyboard, automatically
> > > > > > send RESET command to *all* those devices when external PS/2 keyboard is
> > > > > > connected. Therefore this is reason why touchpad downgrade to to bare
> > > > > > mode. And according to Mario, host system should issue vendor specific
> > > > > > PS/2 commands to re-initialize all PS/2 devices when this situation
> > > > > > happen. Mario also told me that Windows is doing this action.
> > > > >
> > > > > Yeah, I remember fun with Inspiron 8100 - when you dock it it woudl
> > > > > silently switch Synaptics touchpad into standard mode and it would not
> > > > > come back as Synaptics until you disconnect. And there was no
> > > > > notification to the kernel as far as I could tell.
> > > > >
> > > > > It could be that we need to monitor dock events and then kick reconnect
> > > > > of serio port, either from userspace via udev (I think that would be
> > > > > preferred), or in kernel.
> > > > >
> > > > > >
> > > > > > Every time when I connect external PS/2 keyboard to dock I see this
> > > > > > message in dmesg:
> > > > > >
> > > > > > Spurious ACK... Some program might be trying to access hardware directly.
> > > > > >
> > > > > > I see it also every time when I dock laptop into docking station (to
> > > > > > which is keyboard already connected). And it happens also when I connect
> > > > > > external PS/2 mouse to dock.
> > > > > >
> > > > > > Dmitry, how to handle this situation to re-initialize psmouse.ko when
> > > > > > external PS/2 device is connected to Dell E docking station? According
> > > > > > to Mario, this is how Dell Embedded Controller is designed and suppose
> > > > > > how OS should work with it.
> > > > > >
> > > > > > Manually rmmoding and modprobing for every docking/undocking laptop is
> > > > > > not ideal solution.
> > > > > >
> > > > > > Could it be possible to use that Spurious ATKBD_RET_ACK from atkbd.c be
> > > > > > handled on Dell systems (probably via DMI) as an event to reset and
> > > > > > reinitialize all PS/2 devices?
> > > > >
> > > > > So we need to figure out what exactly we are getting from the docking
> > > > > station in this case. We do try to handle the new device 0xaa 0x00
> > > > > announcements:
> > > > >
> > > > > 	/* Check if this is a new device announcement (0xAA 0x00) */
> > > > > 	if (unlikely(psmouse->packet[0] == PSMOUSE_RET_BAT && psmouse-
> > >pktcnt <= 2)) {
> > > > > 		if (psmouse->pktcnt == 1) {
> > > > > 			psmouse->last = jiffies;
> > > > > 			goto out;
> > > > > 		}
> > > > >
> > > > > 		if (psmouse->packet[1] == PSMOUSE_RET_ID ||
> > > > > 		    (psmouse->protocol->type == PSMOUSE_HGPK &&
> > > > > 		     psmouse->packet[1] == PSMOUSE_RET_BAT)) {
> > > > > 			__psmouse_set_state(psmouse, PSMOUSE_IGNORE);
> > > > > 			serio_reconnect(serio);
> > > > > 			goto out;
> > > > > 		}
> > > > >
> > > > > ...
> > > > >
> > > > > I am not sure where the "spurious ACK comes from". Can you enable i8042
> > > > > debug before trying to dock and capture the data stream from the mouse?
> > > > >
> > > > > Thanks.
> > > > >
> > > >
> > > > Hi Dmitry!
> > > >
> > > > I enabled unmask_kbd_data and debug and here is output from dmesg.
> > > >
> > > > echo Y > /sys/module/i8042/parameters/debug
> > > > echo Y > /sys/module/i8042/parameters/unmask_kbd_data
> > > >
> > > > PS/2 keyboard is already connected in dock and laptop was just docked:
> > > >
> > > > [25461.552314] i8042: [6365474] fa <- i8042 (interrupt, 0, 1)
> > > > [25461.552319] atkbd serio0: Spurious ACK on isa0060/serio0. Some program
> > might be trying to access hardware directly.
> > > > [25462.707296] i8042: [6365763] ed -> i8042 (kbd-data)
> > > > [25462.851289] i8042: [6365799] fa <- i8042 (interrupt, 0, 1)
> > > > [25462.851303] i8042: [6365799] 00 -> i8042 (kbd-data)
> > > > [25462.858437] i8042: [6365801] fa <- i8042 (interrupt, 0, 1)
> > > > [25462.869512] i8042: [6365804] fa <- i8042 (interrupt, 0, 1)
> > > > [25462.869517] atkbd serio0: Spurious ACK on isa0060/serio0. Some program
> > might be trying to access hardware directly.
> > > > [25463.670515] i8042: [6366004] ed -> i8042 (kbd-data)
> > > > [25463.670647] i8042: [6366004] fa <- i8042 (interrupt, 0, 1)
> > > > [25463.670655] i8042: [6366004] 02 -> i8042 (kbd-data)
> > > > [25463.676769] i8042: [6366005] fa <- i8042 (interrupt, 0, 1)
> > > >
> > > >
> > > > Laptop is docked and PS/2 keyboard was just connected:
> > > >
> > > > [26571.014368] i8042: [6642848] fa <- i8042 (interrupt, 0, 1)
> > > > [26571.014380] atkbd serio0: Spurious ACK on isa0060/serio0. Some program
> > might be trying to access hardware directly.
> > > >
> > > >
> > > > In both cases there is no events from touchpad, only from keyboard. So
> > > > Dell EC silently reset PS/2 touchpad when PS/2 keyboard is attached.
> > > >
> > > > So I think we should capture 0xFA and on Dell machines we should
> > > > reinitialize PS/2 drivers. As there is really nothing more then 0xFA.
> > >
> > > Info about PS/2 mouse:
> > >
> > > In case I have laptop already docked and just connect PS/2 mouse there
> > > is absolutely no i8042 event.
> > >
> > > To check that mouse is worked I clicked button and then in dmesg
> > > appeared:
> > >
> > > [ 3945.481403] i8042: [986322] 09 <- i8042 (interrupt, 1, 12)
> > > [ 3945.482486] i8042: [986323] 00 <- i8042 (interrupt, 1, 12)
> > > [ 3945.483667] i8042: [986323] 00 <- i8042 (interrupt, 1, 12)
> > > [ 3945.483917] input: PS/2 ALPS Mouse as
> > /devices/platform/i8042/serio1/input/input36
> > > [ 3945.594926] i8042: [986351] 08 <- i8042 (interrupt, 1, 12)
> > > [ 3945.596062] i8042: [986351] 00 <- i8042 (interrupt, 1, 12)
> > > [ 3945.597203] i8042: [986351] 00 <- i8042 (interrupt, 1, 12)
> > >
> > > So we have no way to detect when external PS/2 mouse was connected to
> > > dock. But ALPS driver can deal with it and process these mouse events.
> > >
> > > And when I have already connected PS/2 mouse to the dock and I'm just
> > > putting laptop into dock, then I get following events:
> > >
> > > [ 4336.481381] i8042: [1084079] fa <- i8042 (interrupt, 0, 1)
> > > [ 4336.481388] atkbd serio0: Spurious ACK on isa0060/serio0. Some program
> > might be trying to access hardware directly.
> > > [ 4337.653275] i8042: [1084372] ed -> i8042 (kbd-data)
> > 
> > I wonder where this "set leds" command is coming from and where is the
> > parameter... Can you add some more tracing? And maybe boot with
> > libps2.dyndbg=+pf
> > 
> > > [ 4337.949198] i8042: [1084446] fa <- i8042 (interrupt, 0, 1)
> > > [ 4337.949202] atkbd serio0: Spurious ACK on isa0060/serio0. Some program
> > might be trying to access hardware directly.
> > > [ 4338.623167] i8042: [1084615] ed -> i8042 (kbd-data)
> > >
> > > So again, no event from mouse, just from keyboard.
> > >
> > > Note that in these tests I have disconnected my PS/2 keyboard from
> > > dock.
> > 
> > So I guess you could write a platform driver that would install i8042
> > filter on Dell laptops/portables, monitor keyboard data stream and kick
> > of rescans on serio ports. The problem is filter gets "serio" so you do
> > not really know whether ACK is spurious or not. And I would really
> > prefer keeping this crap out of atkbd proper... And all of this is racy
> > as hell. What happens if we get keyboard reconnected as we reinitialize
> > it?
> 
> If it's done as a platform driver I would suspect it's possible to tell whether
> a dock is connected to at least give you some heuristic here to have a better
> guess whether it's spurious.

Apparently checking for docking station is not enough. There are also
Dell Legacy Extenders (or how it is called) which exports internal PS/2,
Parallel and Serial Ports. It is also connecting to bottom of laptop.
But currently I do not have them for testing.

> Pali on your system that supports this dock, check and see how many
> System Enclosure SMBIOS tables (structure type 03) are present.

Do you mean DMI type 3 structure? Here is something from dmidecode:

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

But probably you mean something different?

> There should be a separate one for the dock as far as I can tell with values
> that will vary based on whether it's attached.
> 
> Assuming that's true I think making a platform filter driver that only attaches
> to systems that actually support this type of dock should be possible too.
> 
> > 
> > Mario, how does Windows driver know when it should send "vendor"
> > commands to reinitialize peripherals?
> > 
> 
> Sorry , I don't know.  It's "inbox" Windows drivers that are used here so
> it's a "black box" to me how they work.
> 

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

RE: Dell docking station & Dell Embedded Controller & PS/2 devices

[Mario.Limonciello]

> > > So I guess you could write a platform driver that would install i8042
> > > filter on Dell laptops/portables, monitor keyboard data stream and kick
> > > of rescans on serio ports. The problem is filter gets "serio" so you do
> > > not really know whether ACK is spurious or not. And I would really
> > > prefer keeping this crap out of atkbd proper... And all of this is racy
> > > as hell. What happens if we get keyboard reconnected as we reinitialize
> > > it?
> >
> > If it's done as a platform driver I would suspect it's possible to tell whether
> > a dock is connected to at least give you some heuristic here to have a better
> > guess whether it's spurious.
> 
> Apparently checking for docking station is not enough. There are also
> Dell Legacy Extenders (or how it is called) which exports internal PS/2,
> Parallel and Serial Ports. It is also connecting to bottom of laptop.
> But currently I do not have them for testing.
> 
> > Pali on your system that supports this dock, check and see how many
> > System Enclosure SMBIOS tables (structure type 03) are present.
> 
> Do you mean DMI type 3 structure? Here is something from dmidecode:
> 
> Handle 0x0003, DMI type 3, 22 bytes
> Chassis Information
>         Manufacturer: Dell Inc.
>         Type: Laptop
>         Lock: Not Present
>         Version: Not Specified
>         Serial Number: --REMOVED--
>         Asset Tag: Not Specified
>         Boot-up State: Safe
>         Power Supply State: Safe
>         Thermal State: Safe
>         Security Status: None
>         OEM Information: 0x00000000
>         Height: Unspecified
>         Number Of Power Cords: 1
>         Contained Elements: 0
>         SKU Number: To be filled by O.E.M.
> 
> But probably you mean something different?

Plug in your dock before you boot up and see if you have a second structure like
that type produced.

If not, then I guess this isn't a reliable way to find the dock
on that system and I'll have to see if there is another.

RE: Dell docking station & Dell Embedded Controller & PS/2 devices

[Mario.Limonciello]

> > > So I guess you could write a platform driver that would install i8042
> > > filter on Dell laptops/portables, monitor keyboard data stream and kick
> > > of rescans on serio ports. The problem is filter gets "serio" so you do
> > > not really know whether ACK is spurious or not. And I would really
> > > prefer keeping this crap out of atkbd proper... And all of this is racy
> > > as hell. What happens if we get keyboard reconnected as we reinitialize
> > > it?
> >
> > If it's done as a platform driver I would suspect it's possible to tell whether
> > a dock is connected to at least give you some heuristic here to have a better
> > guess whether it's spurious.
> 
> Apparently checking for docking station is not enough. There are also
> Dell Legacy Extenders (or how it is called) which exports internal PS/2,
> Parallel and Serial Ports. It is also connecting to bottom of laptop.
> But currently I do not have them for testing.
> 
> > Pali on your system that supports this dock, check and see how many
> > System Enclosure SMBIOS tables (structure type 03) are present.
> 
> Do you mean DMI type 3 structure? Here is something from dmidecode:
> 
> Handle 0x0003, DMI type 3, 22 bytes
> Chassis Information
>         Manufacturer: Dell Inc.
>         Type: Laptop
>         Lock: Not Present
>         Version: Not Specified
>         Serial Number: --REMOVED--
>         Asset Tag: Not Specified
>         Boot-up State: Safe
>         Power Supply State: Safe
>         Thermal State: Safe
>         Security Status: None
>         OEM Information: 0x00000000
>         Height: Unspecified
>         Number Of Power Cords: 1
>         Contained Elements: 0
>         SKU Number: To be filled by O.E.M.
> 
> But probably you mean something different?

Plug in your dock before you boot up and see if you have a second structure like
that type produced.

If not, then I guess this isn't a reliable way to find the dock
on that system and I'll have to see if there is another.

Re: Dell docking station & Dell Embedded Controller & PS/2 devices

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 2492 bytes --]

On Monday 07 May 2018 20:18:30 Mario.Limonciello@dell.com wrote:
> > > > So I guess you could write a platform driver that would install i8042
> > > > filter on Dell laptops/portables, monitor keyboard data stream and kick
> > > > of rescans on serio ports. The problem is filter gets "serio" so you do
> > > > not really know whether ACK is spurious or not. And I would really
> > > > prefer keeping this crap out of atkbd proper... And all of this is racy
> > > > as hell. What happens if we get keyboard reconnected as we reinitialize
> > > > it?
> > >
> > > If it's done as a platform driver I would suspect it's possible to tell whether
> > > a dock is connected to at least give you some heuristic here to have a better
> > > guess whether it's spurious.
> > 
> > Apparently checking for docking station is not enough. There are also
> > Dell Legacy Extenders (or how it is called) which exports internal PS/2,
> > Parallel and Serial Ports. It is also connecting to bottom of laptop.
> > But currently I do not have them for testing.
> > 
> > > Pali on your system that supports this dock, check and see how many
> > > System Enclosure SMBIOS tables (structure type 03) are present.
> > 
> > Do you mean DMI type 3 structure? Here is something from dmidecode:
> > 
> > Handle 0x0003, DMI type 3, 22 bytes
> > Chassis Information
> >         Manufacturer: Dell Inc.
> >         Type: Laptop
> >         Lock: Not Present
> >         Version: Not Specified
> >         Serial Number: --REMOVED--
> >         Asset Tag: Not Specified
> >         Boot-up State: Safe
> >         Power Supply State: Safe
> >         Thermal State: Safe
> >         Security Status: None
> >         OEM Information: 0x00000000
> >         Height: Unspecified
> >         Number Of Power Cords: 1
> >         Contained Elements: 0
> >         SKU Number: To be filled by O.E.M.
> > 
> > But probably you mean something different?
> 
> Plug in your dock before you boot up and see if you have a second structure like
> that type produced.

I already started docked laptop via dock power button. And in dmidecode
output is only one DMI type 3 block.

> If not, then I guess this isn't a reliable way to find the dock
> on that system and I'll have to see if there is another.

Seems not. Also detection of dock should work also when you connect
laptop at system runtime, not only when connected prior to booting.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

RE: Dell docking station & Dell Embedded Controller & PS/2 devices

[Mario.Limonciello]

> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@gmail.com]
> Sent: Monday, May 7, 2018 3:28 PM
> To: Limonciello, Mario
> Cc: dmitry.torokhov@gmail.com; linux-input@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: Re: Dell docking station & Dell Embedded Controller & PS/2 devices
> 
> On Monday 07 May 2018 20:18:30 Mario.Limonciello@dell.com wrote:
> > > > > So I guess you could write a platform driver that would install i8042
> > > > > filter on Dell laptops/portables, monitor keyboard data stream and kick
> > > > > of rescans on serio ports. The problem is filter gets "serio" so you do
> > > > > not really know whether ACK is spurious or not. And I would really
> > > > > prefer keeping this crap out of atkbd proper... And all of this is racy
> > > > > as hell. What happens if we get keyboard reconnected as we reinitialize
> > > > > it?
> > > >
> > > > If it's done as a platform driver I would suspect it's possible to tell whether
> > > > a dock is connected to at least give you some heuristic here to have a better
> > > > guess whether it's spurious.
> > >
> > > Apparently checking for docking station is not enough. There are also
> > > Dell Legacy Extenders (or how it is called) which exports internal PS/2,
> > > Parallel and Serial Ports. It is also connecting to bottom of laptop.
> > > But currently I do not have them for testing.
> > >
> > > > Pali on your system that supports this dock, check and see how many
> > > > System Enclosure SMBIOS tables (structure type 03) are present.
> > >
> > > Do you mean DMI type 3 structure? Here is something from dmidecode:
> > >
> > > Handle 0x0003, DMI type 3, 22 bytes
> > > Chassis Information
> > >         Manufacturer: Dell Inc.
> > >         Type: Laptop
> > >         Lock: Not Present
> > >         Version: Not Specified
> > >         Serial Number: --REMOVED--
> > >         Asset Tag: Not Specified
> > >         Boot-up State: Safe
> > >         Power Supply State: Safe
> > >         Thermal State: Safe
> > >         Security Status: None
> > >         OEM Information: 0x00000000
> > >         Height: Unspecified
> > >         Number Of Power Cords: 1
> > >         Contained Elements: 0
> > >         SKU Number: To be filled by O.E.M.
> > >
> > > But probably you mean something different?
> >
> > Plug in your dock before you boot up and see if you have a second structure like
> > that type produced.
> 
> I already started docked laptop via dock power button. And in dmidecode
> output is only one DMI type 3 block.
> 
> > If not, then I guess this isn't a reliable way to find the dock
> > on that system and I'll have to see if there is another.
> 
> Seems not. Also detection of dock should work also when you connect
> laptop at system runtime, not only when connected prior to booting.
> 

The items that show up in this structure are supposed to be dynamic
values but static addresses.  I was asking to check before bootup in 
case this was a problem of Linux caching SMBIOS table information once.
The values I was referring to might be for older generation dock though,
I'll see if I can find anything else you can check.

RE: Dell docking station & Dell Embedded Controller & PS/2 devices

[Mario.Limonciello]

> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@gmail.com]
> Sent: Monday, May 7, 2018 3:28 PM
> To: Limonciello, Mario
> Cc: dmitry.torokhov@gmail.com; linux-input@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: Re: Dell docking station & Dell Embedded Controller & PS/2 devices
> 
> On Monday 07 May 2018 20:18:30 Mario.Limonciello@dell.com wrote:
> > > > > So I guess you could write a platform driver that would install i8042
> > > > > filter on Dell laptops/portables, monitor keyboard data stream and kick
> > > > > of rescans on serio ports. The problem is filter gets "serio" so you do
> > > > > not really know whether ACK is spurious or not. And I would really
> > > > > prefer keeping this crap out of atkbd proper... And all of this is racy
> > > > > as hell. What happens if we get keyboard reconnected as we reinitialize
> > > > > it?
> > > >
> > > > If it's done as a platform driver I would suspect it's possible to tell whether
> > > > a dock is connected to at least give you some heuristic here to have a better
> > > > guess whether it's spurious.
> > >
> > > Apparently checking for docking station is not enough. There are also
> > > Dell Legacy Extenders (or how it is called) which exports internal PS/2,
> > > Parallel and Serial Ports. It is also connecting to bottom of laptop.
> > > But currently I do not have them for testing.
> > >
> > > > Pali on your system that supports this dock, check and see how many
> > > > System Enclosure SMBIOS tables (structure type 03) are present.
> > >
> > > Do you mean DMI type 3 structure? Here is something from dmidecode:
> > >
> > > Handle 0x0003, DMI type 3, 22 bytes
> > > Chassis Information
> > >         Manufacturer: Dell Inc.
> > >         Type: Laptop
> > >         Lock: Not Present
> > >         Version: Not Specified
> > >         Serial Number: --REMOVED--
> > >         Asset Tag: Not Specified
> > >         Boot-up State: Safe
> > >         Power Supply State: Safe
> > >         Thermal State: Safe
> > >         Security Status: None
> > >         OEM Information: 0x00000000
> > >         Height: Unspecified
> > >         Number Of Power Cords: 1
> > >         Contained Elements: 0
> > >         SKU Number: To be filled by O.E.M.
> > >
> > > But probably you mean something different?
> >
> > Plug in your dock before you boot up and see if you have a second structure like
> > that type produced.
> 
> I already started docked laptop via dock power button. And in dmidecode
> output is only one DMI type 3 block.
> 
> > If not, then I guess this isn't a reliable way to find the dock
> > on that system and I'll have to see if there is another.
> 
> Seems not. Also detection of dock should work also when you connect
> laptop at system runtime, not only when connected prior to booting.
> 

The items that show up in this structure are supposed to be dynamic
values but static addresses.  I was asking to check before bootup in 
case this was a problem of Linux caching SMBIOS table information once.
The values I was referring to might be for older generation dock though,
I'll see if I can find anything else you can check.

RE: Dell docking station & Dell Embedded Controller & PS/2 devices

[Mario.Limonciello]

> -----Original Message-----
> From: Limonciello, Mario
> Sent: Monday, May 7, 2018 3:30 PM
> To: 'Pali Rohár'
> Cc: dmitry.torokhov@gmail.com; linux-input@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: RE: Dell docking station & Dell Embedded Controller & PS/2 devices
> 
> > -----Original Message-----
> > From: Pali Rohár [mailto:pali.rohar@gmail.com]
> > Sent: Monday, May 7, 2018 3:28 PM
> > To: Limonciello, Mario
> > Cc: dmitry.torokhov@gmail.com; linux-input@vger.kernel.org; linux-
> > kernel@vger.kernel.org
> > Subject: Re: Dell docking station & Dell Embedded Controller & PS/2 devices
> >
> > On Monday 07 May 2018 20:18:30 Mario.Limonciello@dell.com wrote:
> > > > > > So I guess you could write a platform driver that would install i8042
> > > > > > filter on Dell laptops/portables, monitor keyboard data stream and kick
> > > > > > of rescans on serio ports. The problem is filter gets "serio" so you do
> > > > > > not really know whether ACK is spurious or not. And I would really
> > > > > > prefer keeping this crap out of atkbd proper... And all of this is racy
> > > > > > as hell. What happens if we get keyboard reconnected as we reinitialize
> > > > > > it?
> > > > >
> > > > > If it's done as a platform driver I would suspect it's possible to tell whether
> > > > > a dock is connected to at least give you some heuristic here to have a better
> > > > > guess whether it's spurious.
> > > >
> > > > Apparently checking for docking station is not enough. There are also
> > > > Dell Legacy Extenders (or how it is called) which exports internal PS/2,
> > > > Parallel and Serial Ports. It is also connecting to bottom of laptop.
> > > > But currently I do not have them for testing.
> > > >
> > > > > Pali on your system that supports this dock, check and see how many
> > > > > System Enclosure SMBIOS tables (structure type 03) are present.
> > > >
> > > > Do you mean DMI type 3 structure? Here is something from dmidecode:
> > > >
> > > > Handle 0x0003, DMI type 3, 22 bytes
> > > > Chassis Information
> > > >         Manufacturer: Dell Inc.
> > > >         Type: Laptop
> > > >         Lock: Not Present
> > > >         Version: Not Specified
> > > >         Serial Number: --REMOVED--
> > > >         Asset Tag: Not Specified
> > > >         Boot-up State: Safe
> > > >         Power Supply State: Safe
> > > >         Thermal State: Safe
> > > >         Security Status: None
> > > >         OEM Information: 0x00000000
> > > >         Height: Unspecified
> > > >         Number Of Power Cords: 1
> > > >         Contained Elements: 0
> > > >         SKU Number: To be filled by O.E.M.
> > > >
> > > > But probably you mean something different?
> > >
> > > Plug in your dock before you boot up and see if you have a second structure like
> > > that type produced.
> >
> > I already started docked laptop via dock power button. And in dmidecode
> > output is only one DMI type 3 block.
> >
> > > If not, then I guess this isn't a reliable way to find the dock
> > > on that system and I'll have to see if there is another.
> >
> > Seems not. Also detection of dock should work also when you connect
> > laptop at system runtime, not only when connected prior to booting.
> >
> 
> The items that show up in this structure are supposed to be dynamic
> values but static addresses.  I was asking to check before bootup in
> case this was a problem of Linux caching SMBIOS table information once.
> The values I was referring to might be for older generation dock though,
> I'll see if I can find anything else you can check.

Can you check if structure type 08 or structure type 09 change based on
dock being plugged in?  Again you might have to do it across a boot
with/without dock in case of Linux kernel caches values.

RE: Dell docking station & Dell Embedded Controller & PS/2 devices

[Mario.Limonciello]

> -----Original Message-----
> From: Limonciello, Mario
> Sent: Monday, May 7, 2018 3:30 PM
> To: 'Pali Rohár'
> Cc: dmitry.torokhov@gmail.com; linux-input@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: RE: Dell docking station & Dell Embedded Controller & PS/2 devices
> 
> > -----Original Message-----
> > From: Pali Rohár [mailto:pali.rohar@gmail.com]
> > Sent: Monday, May 7, 2018 3:28 PM
> > To: Limonciello, Mario
> > Cc: dmitry.torokhov@gmail.com; linux-input@vger.kernel.org; linux-
> > kernel@vger.kernel.org
> > Subject: Re: Dell docking station & Dell Embedded Controller & PS/2 devices
> >
> > On Monday 07 May 2018 20:18:30 Mario.Limonciello@dell.com wrote:
> > > > > > So I guess you could write a platform driver that would install i8042
> > > > > > filter on Dell laptops/portables, monitor keyboard data stream and kick
> > > > > > of rescans on serio ports. The problem is filter gets "serio" so you do
> > > > > > not really know whether ACK is spurious or not. And I would really
> > > > > > prefer keeping this crap out of atkbd proper... And all of this is racy
> > > > > > as hell. What happens if we get keyboard reconnected as we reinitialize
> > > > > > it?
> > > > >
> > > > > If it's done as a platform driver I would suspect it's possible to tell whether
> > > > > a dock is connected to at least give you some heuristic here to have a better
> > > > > guess whether it's spurious.
> > > >
> > > > Apparently checking for docking station is not enough. There are also
> > > > Dell Legacy Extenders (or how it is called) which exports internal PS/2,
> > > > Parallel and Serial Ports. It is also connecting to bottom of laptop.
> > > > But currently I do not have them for testing.
> > > >
> > > > > Pali on your system that supports this dock, check and see how many
> > > > > System Enclosure SMBIOS tables (structure type 03) are present.
> > > >
> > > > Do you mean DMI type 3 structure? Here is something from dmidecode:
> > > >
> > > > Handle 0x0003, DMI type 3, 22 bytes
> > > > Chassis Information
> > > >         Manufacturer: Dell Inc.
> > > >         Type: Laptop
> > > >         Lock: Not Present
> > > >         Version: Not Specified
> > > >         Serial Number: --REMOVED--
> > > >         Asset Tag: Not Specified
> > > >         Boot-up State: Safe
> > > >         Power Supply State: Safe
> > > >         Thermal State: Safe
> > > >         Security Status: None
> > > >         OEM Information: 0x00000000
> > > >         Height: Unspecified
> > > >         Number Of Power Cords: 1
> > > >         Contained Elements: 0
> > > >         SKU Number: To be filled by O.E.M.
> > > >
> > > > But probably you mean something different?
> > >
> > > Plug in your dock before you boot up and see if you have a second structure like
> > > that type produced.
> >
> > I already started docked laptop via dock power button. And in dmidecode
> > output is only one DMI type 3 block.
> >
> > > If not, then I guess this isn't a reliable way to find the dock
> > > on that system and I'll have to see if there is another.
> >
> > Seems not. Also detection of dock should work also when you connect
> > laptop at system runtime, not only when connected prior to booting.
> >
> 
> The items that show up in this structure are supposed to be dynamic
> values but static addresses.  I was asking to check before bootup in
> case this was a problem of Linux caching SMBIOS table information once.
> The values I was referring to might be for older generation dock though,
> I'll see if I can find anything else you can check.

Can you check if structure type 08 or structure type 09 change based on
dock being plugged in?  Again you might have to do it across a boot
with/without dock in case of Linux kernel caches values.

Re: Dell docking station & Dell Embedded Controller & PS/2 devices

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]

On Monday 07 May 2018 20:32:16 Mario.Limonciello@dell.com wrote:
> > The items that show up in this structure are supposed to be dynamic
> > values but static addresses.  I was asking to check before bootup in
> > case this was a problem of Linux caching SMBIOS table information once.
> > The values I was referring to might be for older generation dock though,
> > I'll see if I can find anything else you can check.
> 
> Can you check if structure type 08 or structure type 09 change based on
> dock being plugged in?  Again you might have to do it across a boot
> with/without dock in case of Linux kernel caches values.

The only difference is:

--- dmidecode_laptop_docked	2018-05-07 22:34:02.650325758 +0200
+++ dmidecode_laptop_undocked	2018-05-07 22:39:27.580306838 +0200
@@ -913,7 +913,7 @@ System Power Supply
 	Asset Tag: To Be Filled By O.E.M.
 	Model Part Number: To Be Filled By O.E.M.
 	Revision: To Be Filled By O.E.M.
-	Max Power Capacity: 90 W
+	Max Power Capacity: Unknown
 	Status: Present, OK
 	Type: Switching
 	Input Voltage Range Switching: Auto-switch

And this is in block Handle 0x003E, DMI type 39, 22 bytes - System Power
Supply. So looks like that DMI data are same.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]