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

On Thursday 01 February 2018 21:23:40 Mario.Limonciello@dell.com wrote:

quoted

-----Original Message-----
From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
Sent: Thursday, February 1, 2018 3:14 PM
To: Limonciello, Mario <redacted>
Cc: Pali Rohár <redacted>; 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,  [off-list ref] wrote:

quoted

quoted

-----Original Message-----
From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
Sent: Thursday, February 1, 2018 1:30 PM
To: Pali Rohár <redacted>
Cc: Limonciello, Mario <redacted>; 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:

quoted

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.

quoted

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.

quoted

quoted

quoted

      /* Check if this is a new device announcement (0xAA 0x00) */
      if (unlikely(psmouse->packet[0] == PSMOUSE_RET_BAT && psmouse-

quoted

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