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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 1 Feb 2018 13:14:29 -0800
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Mario Limonciello <Mario.Limonciello@...l.com>
Cc:     Pali Rohár <pali.rohar@...il.com>,
        "linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: Dell docking station & Dell Embedded Controller & PS/2 devices

On Thu, Feb 1, 2018 at 11:35 AM,  <Mario.Limonciello@...l.com> wrote:
>
>
>> -----Original Message-----
>> From: Dmitry Torokhov [mailto:dmitry.torokhov@...il.com]
>> Sent: Thursday, February 1, 2018 1:30 PM
>> To: Pali Rohár <pali.rohar@...il.com>
>> Cc: Limonciello, Mario <Mario_Limonciello@...l.com>; linux-
>> input@...r.kernel.org; linux-kernel@...r.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