lkml.org 
[lkml]   [2018]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: Dell docking station & Dell Embedded Controller & PS/2 devices
Date
> -----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.
\
 
 \ /
  Last update: 2018-02-01 22:24    [W:0.047 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site