Message-ID: <20180507195855.b347ppcmg4hnzqwf@pali>
Date:   Mon, 7 May 2018 21:58:55 +0200
From:   Pali Rohár <pali.rohar@...il.com>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:     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

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@...il.com

Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)

Powered by blists - more mailing lists