Bug 1098392 - Regression with Kernel 4.17: Missing events with pointer devices (affects libinput)
Regression with Kernel 4.17: Missing events with pointer devices (affects lib...
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kernel
Current
Other Other
: P5 - None : Major (vote)
: ---
Assigned To: E-mail List
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-06-20 10:36 UTC by Rihards Olups
Modified: 2022-07-21 17:23 UTC (History)
9 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
lsusb -v (4.20 KB, text/plain)
2018-06-21 09:21 UTC, Michal Srb
Details
Bisection Log (2.80 KB, text/plain)
2018-06-25 16:39 UTC, Larry Finger
Details
output of "cat /proc/bus/input/devices for faulty case - kernel 04bb1719 (2.02 KB, text/plain)
2018-06-25 18:42 UTC, Larry Finger
Details
output of "cat /proc/bus/input/devices for good case - kernel 4.16.2 (2.03 KB, text/plain)
2018-06-25 18:43 UTC, Larry Finger
Details
dmesg output for faulty case (32.79 KB, text/plain)
2018-06-25 20:08 UTC, Larry Finger
Details
Differences in Xorg.0.log between first login, and after lof off and back on (4.34 KB, patch)
2018-06-27 14:35 UTC, Larry Finger
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Rihards Olups 2018-06-20 10:36:27 UTC
After upgrading to Tumbleweed 2018-06-18, mouse started acting weird. After startup, the first click worked as expected, but all further clicks registered in that same location only.

Eventually, commenting out the "pointer" section in /etc/X11/xorg.conf.d/40-libinput.conf resolved the problem.

A somewhat similar solution to https://lists.opensuse.org/opensuse-factory/2015-04/msg00235.html .
Comment 1 Stefan Dirsch 2018-06-20 10:45:50 UTC
What do you mean exactly with "all further clicks registered in that same location only" ? Does that mean, that no matter where you click the  ButtonPress event always is on the same coordinates? Can you move the mouse normally? Please check with xev.

Disabling libinput driver for every mouse user is for sure no generic solution. I would even expect no mouse support at all any longer with evdev/mouse drivers no longer been installed by default.
Comment 2 Rihards Olups 2018-06-20 10:53:06 UTC
Yes, all further clicks went to that first location. For example, if I click on klauncher first, all further clicks would open that menu. Same with taskbar or any other place on the desktop.

Mouse cursor was moving around as usual, and mouseover actions also worked (tooltips appeared etc).

I didn't mean to suggest commenting out that section as a generic solution, just as something that helped me and could point (ha) at the cause.

Before that, two packages were uninstalled, but this made no difference:

* xf86-input-mouse
* xf86-input-libinput
Comment 3 Stefan Dirsch 2018-06-20 10:58:27 UTC
Ok. I'm wondering which input driver is active now. Can you attach X logfile for now working configuration?
Comment 4 Rihards Olups 2018-06-20 11:21:54 UTC
Logfile says:

[  1622.008] (II) Using input driver 'evdev' for 'VirtualBox mouse integration'

Please let me know if full logfile is still needed.
Comment 5 Stefan Dirsch 2018-06-20 12:20:15 UTC
Ok. So as assumed evdev driver took over. Ah. But that's a vm using Virtualbox apparently!
Comment 6 Stefan Dirsch 2018-06-20 12:27:56 UTC
Larry,  as  bugowner/maintainer of virtualbox. Can you easily reproduce this issue when installing TW in a virtualbox VM?
Comment 7 Larry Finger 2018-06-20 18:25:35 UTC
I can confirm the problem for TW KDE desktops in VirtualBox. Gnome desktops are OK.

I tested using gdm as the display manager in the KDE version. Nothing changed, thus whatever the problem is, it is not the display manager.
Comment 8 Achim Gratz 2018-06-20 18:53:39 UTC
This can not be related to VirtualBox (although that might be a good way to reproduce the bug), I have the exact same problem on bare iron (a Dell T20).  Going back to kernel version 4.16.12-3 fixes the problem, so it can't be a problem in libinput alone, either.

The Xorg log on the working configuration shows this:

[    17.501] (II) event0  - AT Translated Set 2 keyboard: is tagged by udev as: Keyboard
[    17.501] (II) event0  - AT Translated Set 2 keyboard: device is a keyboard
[    17.502] (II) config/udev: Adding input device ImExPS/2 Logitech Explorer Mouse (/dev/input/event1)
[    17.502] (**) ImExPS/2 Logitech Explorer Mouse: Applying InputClass "evdev pointer catchall"
[    17.502] (**) ImExPS/2 Logitech Explorer Mouse: Applying InputClass "evdev pointer catchall"
[    17.502] (**) ImExPS/2 Logitech Explorer Mouse: Applying InputClass "libinput pointer catchall"
[    17.502] (II) Using input driver 'libinput' for 'ImExPS/2 Logitech Explorer Mouse'
[    17.502] (**) ImExPS/2 Logitech Explorer Mouse: always reports core events
[    17.502] (**) Option "Device" "/dev/input/event1"
[    17.502] (**) Option "_source" "server/udev"
[    17.503] (II) event1  - ImExPS/2 Logitech Explorer Mouse: is tagged by udev as: Mouse
[    17.503] (II) event1  - ImExPS/2 Logitech Explorer Mouse: device is a pointer
[    17.503] (II) event1  - ImExPS/2 Logitech Explorer Mouse: device removed
[    17.544] (**) Option "config_info" "udev:/sys/devices/platform/i8042/serio1/input/input2/event1"
[    17.544] (II) XINPUT: Adding extended input device "ImExPS/2 Logitech Explorer Mouse" (type: MOUSE, id 11)
[    17.544] (**) Option "AccelerationScheme" "none"
[    17.544] (**) ImExPS/2 Logitech Explorer Mouse: (accel) selected scheme none/0
[    17.544] (**) ImExPS/2 Logitech Explorer Mouse: (accel) acceleration factor: 2.000
[    17.544] (**) ImExPS/2 Logitech Explorer Mouse: (accel) acceleration threshold: 4
[    17.545] (II) event1  - ImExPS/2 Logitech Explorer Mouse: is tagged by udev as: Mouse
[    17.545] (II) event1  - ImExPS/2 Logitech Explorer Mouse: device is a pointer
[    17.546] (II) config/udev: Adding input device ImExPS/2 Logitech Explorer Mouse (/dev/input/mouse0)
Comment 9 Larry Finger 2018-06-20 20:51:33 UTC
I can confirm that when I boot kernel 4.16.12, all is OK. It is kernel 4.17.1 that has the problem.
Comment 10 Larry Finger 2018-06-21 00:56:29 UTC
The problem also occurs with kernel 4.17.0 from mainline. I am currently bisecting to find the offending commit. It will take a while (13 builds estimated).
Comment 11 Jiri Slaby 2018-06-21 07:35:25 UTC
In the meantime, could you do with a corresponding device instead of "…":
cat /sys/kernel/debug/hid/0003\:046D\:…/events

and see if the button clicks are reported?

Button.0001 etc should change to 1.
Comment 12 Jiri Slaby 2018-06-21 07:35:53 UTC
Also, could somebody attach lsusb -v of the device?
Comment 13 Michal Srb 2018-06-21 09:21:46 UTC
Created attachment 774812 [details]
lsusb -v

I was also able to reproduce it with Tumbleweed in Virtualbox.

The lsusb -v out is attached.

These devices are reported by evtest:
/dev/input/event0:      AT Translated Set 2 keyboard
/dev/input/event1:      ImExPS/2 Generic Explorer Mouse
/dev/input/event2:      VirtualBox mouse integration
/dev/input/event3:      PC Speaker
/dev/input/event4:      Power Button
/dev/input/event5:      Sleep Button
/dev/input/event6:      Video Bus
/dev/input/event7:      VirtualBox USB Tablet

The event7 produces no events. The event1 produces only BTN_LEFT, BTN_RIGHT, REL_WHEEL events, but no motion events at all.
Comment 14 Michal Srb 2018-06-21 09:28:45 UTC
PS: And event2 gives only ABS_X, ABS_Y events.
Comment 15 Stefan Dirsch 2018-06-21 09:30:30 UTC
Ok. Let's reassign this to our kernel component.
Comment 16 Larry Finger 2018-06-23 00:36:33 UTC
I have completed the bisection. Although it sounds improbable, the bad commit is

commit 04bb1719c4de94700056241d4c0fe3c1413f5aff
Author: Ondrej Zary <linux@rainbow-software.org>
Date:   Tue Apr 3 10:24:34 2018 -0700

    Input: i8042 - enable MUX on Sony VAIO VGN-CS series to fix touchpad
    
    The touch sensor buttons on Sony VAIO VGN-CS series laptops (e.g.
    VGN-CS31S) are a separate PS/2 device. As the MUX is disabled for all
    VAIO machines by the nomux blacklist, the data from touch sensor
    buttons and touchpad are combined. The protocol used by the buttons is
    probably similar to the touchpad protocol (both are Synaptics) so both
    devices get enabled. The controller combines the data, creating a mess
    which results in random button clicks, touchpad stopping working and
    lost sync error messages:
    psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 4
    psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
    psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
    psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
    psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
    psmouse serio1: issuing reconnect request
    
    Add a new i8042_dmi_forcemux_table whitelist with VGN-CS.
    With MUX enabled, touch sensor buttons are detected as separate device
    (and left disabled as there's currently no driver), fixing all touchpad
    problems.
    
    Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

At this point, I have no idea how a fix for Sony VAIO boxes affects my Toshiba hardware, but the bisection was straight forward. Apparently, the patch affects more touchpads than that of Sony.
Comment 17 Achim Gratz 2018-06-23 09:23:31 UTC
I have no idea how this can happen either, but I note that the _initconst pragma qualifier is in a different place than for all other tables in that file.  Maybe it mucks up compilation and produces a different table than what was intended?
Comment 18 Achim Gratz 2018-06-23 10:21:01 UTC
I've just updated Tumbleweed to kernel 4.17.2 and as expected the problem persists.  Some more details:

I've connected three different mice now (Generic PS/2, Primax USB and Primax USB wireless).  These all work, but if I connect the Logitech and move it just once, all mice stop working.  That's probably the part where libinput is involved and runs into the weeds.  I figured out that I can get mouse operation back by restarting the graphical environment (Ctrl-Alt-Backspace on the login screen) without a reboot.

Here's what the kernel saw:
Jun 23 11:57:59 Gertrud kernel: serio: i8042 KBD port at 0x60,0x64 irq 1
Jun 23 11:57:59 Gertrud kernel: serio: i8042 AUX port at 0x60,0x64 irq 12
Jun 23 11:57:59 Gertrud kernel: input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0
Jun 23 11:57:59 Gertrud kernel: psmouse serio1: logips2pp: Detected unknown Logitech mouse model 62
Jun 23 11:57:59 Gertrud kernel: input: ImExPS/2 Logitech Explorer Mouse as /devices/platform/i8042/serio1/input/input2
                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                       This mouse doesn't work and stops all other mice from working.
Jun 23 12:00:17 Gertrud kernel: input: ImPS/2 Generic Wheel Mouse as /devices/platform/i8042/serio1/input/input15
                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^
                                       Replaced with different PS/2 mouse and restarted login screen.

The other two mice are connected via USB:
Bus 003 Device 002: ID 0461:4dfb Primax Electronics, Ltd 
Bus 003 Device 003: ID 0461:4d23 Primax Electronics, Ltd 

evtest sees the three working mice at the moment as:
/dev/input/event1:      ImPS/2 Generic Wheel Mouse
/dev/input/event5:      USB Optical Mouse
/dev/input/event6:      Primax Electronics Wireless Mini Mouse
Comment 19 Achim Gratz 2018-06-23 14:09:32 UTC
Connecting the Logitech Desktop combo via USB instead of PS/2 doesn't seem to trigger the bug.  evtest sees:

/dev/input/event13:     Logitech USB Receiver
  ^^^ this is the leyboard part, sans the function keys
/dev/input/event14:     Logitech USB Receiver
  ^^^ this is the mouse plus all extra button events on the keyboard

lsusb:
Bus 003 Device 004: ID 046d:c505 Logitech, Inc. Cordless Mouse+Keyboard Receiver

as seen by the kernel:
[14308.760708] input: Logitech USB Receiver as /devices/pci0000:00/0000:00:14.0/usb3/3-9/3-9:1.0/0003:046D:C505.0003/input/input16
[14308.819152] hid-generic 0003:046D:C505.0003: input,hidraw2: USB HID v1.10 Keyboard [Logitech USB Receiver] on usb-0000:00:14.0-9/input0
[14308.825331] input: Logitech USB Receiver as /devices/pci0000:00/0000:00:14.0/usb3/3-9/3-9:1.1/0003:046D:C505.0004/input/input17
[14308.882641] hid-generic 0003:046D:C505.0004: input,hidraw3: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-0000:00:14.0-9/input1
Comment 20 Achim Gratz 2018-06-23 14:22:14 UTC
Going back to PS/2 connection:

evtest:
/dev/input/event0:      AT Translated Set 2 keyboard
/dev/input/event1:      ImExPS/2 Logitech Explorer Mouse

[15141.640865] input: ImExPS/2 Logitech Explorer Mouse as /devices/platform/i8042/serio1/input/input21

Running evtest on the mouse works, but I have just lost all other mice, this time completeley.  After some seconds and switching screens, they are back to working order, clicking and scrolling still works.  So beyond all other things it seems the error only triggers when the device is already present when the graphical desktop gets initialized?
Comment 21 Achim Gratz 2018-06-23 14:33:08 UTC
No sooner than I said that mouse clicks stopped working on all mice.  evtests still sees the mouse button events though, and no new sources of events have appeared.  So that part of the behaviour is probably _not_ done by the kernel.

I got full utility back by removing all mice (which didn't recognize that there was no PS/2 mouse anymore) and then connecting the working PS/2 mouse ("Generic").  Whatever thing had blocked the click and scroll events now works again.
Comment 22 Larry Finger 2018-06-23 15:36:02 UTC
(In reply to Achim Gratz from comment #17)
> I have no idea how this can happen either, but I note that the _initconst
> pragma qualifier is in a different place than for all other tables in that
> file.  Maybe it mucks up compilation and produces a different table than
> what was intended?

Something with this patch is definitely flaky. I tried debugging it, but once I changed anything, then it stopped failing, even when I returned it to its original form. At the moment, commit 04bb1719c4de9 is running correctly, even though it failed earlier. :( Is it too late to change my interests to basket weaving? :)

The placement of the __initconst in the dmi_system_id struct seems to vary widely. It is placed before, and after the variable name, and many do not use the qualifier at all. If the placement were an issue, I would expect more failures, but I'm still not sure that we are not seeing a compiler issue with gcc8. That brings up the question "Why is my TW KDE instance in a guest using gcc8, while my host TW KDE uses gcc7?"

I will send mail to LKML, the patch author, and the subsystem maintainer to see if anyone can shed some light on this issue.
Comment 23 Takashi Iwai 2018-06-23 16:11:51 UTC
I guess that the bisection was false-positive.  If that change matters, it means something else is already wrong.  And the __initconst usage there looks correct.

Could you try the latest kernel in OBS Kernel:stable repo?  I fixed an ACPI bug that leaded to a problem of PS/2 keyboard / mouse.
Not sure whether it's the same issue, but just to be sure.
Comment 24 Larry Finger 2018-06-24 23:38:02 UTC
I now know a bit more about this problem. Firstly, your revised kernel did not fix this problem. In fact, a kernel 4.18-rc1 generated from the HEAD of Linus' tree has the same problem, thus the regression has not yet been fixed, and likely not recognized as a bug by the community. I then added an external trackball to my VM and got the same result.

I re-verified that if I checkout commit 04bb1719, the resulting kernel is faulty, and that the one built from commit adf313f is OK. As they are sequential, this seemed to confirm that 04bb1719 is indeed triggering the problem. I then used adf313f as a base and added the patch from 04bb1719, and found that the resulting kernel is OK! :(

I am redoing the entire bisection just to make sure that my results for that part are OK.
Comment 25 Jiri Slaby 2018-06-25 06:08:32 UTC
(In reply to Larry Finger from comment #24)
> I am redoing the entire bisection just to make sure that my results for that
> part are OK.

It might be interesting to see the git bisect log output too. It still might narrow the range by the "bad" markings a bit.
Comment 26 Larry Finger 2018-06-25 16:39:42 UTC
Created attachment 775213 [details]
Bisection Log

Here is the initial bisection log.

I have reduced the number of modules generated, and moved the bisection to a host with more resources. This one will finish much more quickly.
Comment 27 Jiri Slaby 2018-06-25 18:19:23 UTC
Ugh, looking into the bisect log, these two commits are complete *mess*. Unreviewable crap!

commit ba667650c568d55f6b80be54951b098f86939f2d
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Wed Mar 22 16:28:48 2017 -0700

    Input: psmouse - clean up code

commit 1ef8580539d0b9282b726a2c9b7aa25057040cfe
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Tue Feb 7 17:07:44 2017 -0800

    Input: psmouse - create helper for reporting standard buttons/motion



At least the former contains bugs AFAICS:
-                       input_report_rel(dev, REL_WHEEL, (int) (packet[3] & 8) - (int) (packet[3] & 7));
-                       input_report_key(dev, BTN_SIDE, (packet[3] >> 4) & 1);
-                       input_report_key(dev, BTN_EXTRA, (packet[3] >> 5) & 1);
+                       input_report_rel(dev, REL_WHEEL,
+                                        -sign_extend32(packet[3], 3));
+                       input_report_key(dev, BTN_SIDE,  BIT(4));
+                       input_report_key(dev, BTN_EXTRA, BIT(5));
Comment 28 Jiri Slaby 2018-06-25 18:23:35 UTC
Could somebody attach /proc/bus/input/devices from both non-working and working kernels?
Comment 29 Larry Finger 2018-06-25 18:42:45 UTC
Created attachment 775218 [details]
output of "cat /proc/bus/input/devices for faulty case - kernel 04bb1719
Comment 30 Larry Finger 2018-06-25 18:43:57 UTC
Created attachment 775219 [details]
output of "cat /proc/bus/input/devices for good case - kernel 4.16.2
Comment 31 Jiri Slaby 2018-06-25 19:11:29 UTC
So we have a first fix here:
https://lore.kernel.org/lkml/20180625190957.GA187975@dtor-ws/T/#u

I don't think it will fix the issue reported here, though.
Comment 32 Jiri Slaby 2018-06-25 19:28:07 UTC
(In reply to Jiri Slaby from comment #31)
> So we have a first fix here:
> https://lore.kernel.org/lkml/20180625190957.GA187975@dtor-ws/T/#u
> 
> I don't think it will fix the issue reported here, though.

I pushed it to the stable branch nevertheless.

I don't see any dmesg attached here, can anyone attach one?

(In reply to Larry Finger from comment #30)
> Created attachment 775219 [details]
> output of "cat /proc/bus/input/devices for good case - kernel 4.16.2

The bits are set correctly on both kernels, so this part is OK.
Comment 33 Larry Finger 2018-06-25 20:08:00 UTC
Created attachment 775223 [details]
dmesg output for faulty case
Comment 34 Rihards Olups 2018-06-27 10:45:27 UTC
Here's something that might be obvious by now, or might be interesting.

Even with the "pointer" section commented out in the libinput file, mouse fails to work properly after boot. If I log out/in, it starts working.
Comment 35 Raymond Wooninck 2018-06-27 11:57:05 UTC
(In reply to Rihards Olups from comment #34)
> Here's something that might be obvious by now, or might be interesting.
> 
> Even with the "pointer" section commented out in the libinput file, mouse
> fails to work properly after boot. If I log out/in, it starts working.

Indeed. I just tried this and indeed it made the mouse work as expected.

This morning I switched to the kernel in Kernel:HEAD (4.18rc2) of my virtualbox environment, but it was not fixed yet in upstream. Logging out and in again makes the mouse work.

Could it be that libinput gets initialed wrongly the first time and that with logging off and on again, libinput is reinitialized? 

At least logging off and on again is an easy fix which makes the virtualbox environment workable again
Comment 36 Larry Finger 2018-06-27 14:35:55 UTC
Created attachment 775438 [details]
Differences in Xorg.0.log between first login, and after lof off and back on
Comment 37 Larry Finger 2018-06-27 14:37:45 UTC
This problem has not yet been fixed upstream.

I confirm that logging off and on does indeed clear the problem for me. This behavior does explain some of the inconsistencies that I found earlier when certain kernels failed, and then inexplicably worked.

My second bisection on a different host and a new guest setup got the same result, namely that commit 04bb1719c4de is the faulty one. How this seemingly unrelated change affects the mouse is still difficult to see. I am attaching the differences between /var/log/Xorg.0.log (new) from the re-login, and the log from the first login (old).
Comment 38 Jiri Slaby 2018-06-27 15:31:20 UTC
(In reply to Larry Finger from comment #37)
> My second bisection on a different host and a new guest setup got the same
> result, namely that commit 04bb1719c4de is the faulty one. How this
> seemingly unrelated change affects the mouse is still difficult to see.

I also doubt this is the culprit. May I ask you for the third round of bisection, having in mind you have to decide good/bad only by the first login?

I cannot find what the problem could be.
Comment 39 Larry Finger 2018-06-27 16:43:43 UTC
All of my tests were based on first login; however, I have saved all the kernels from the second bisection, thus I can recheck that I did it correctly.
Comment 40 Raymond Wooninck 2018-06-28 07:16:35 UTC
(In reply to Jiri Slaby from comment #31)
> So we have a first fix here:
> https://lore.kernel.org/lkml/20180625190957.GA187975@dtor-ws/T/#u

Hi Jiri,

I believe that you also added this commit to Kernel:HEAD which delivered the kernel 4.18.0-rc2-2.gbe969c3-default. 

This kernel resolves for me the issue on first login. With this kernel, the mouse works normal on first login. 

Also the Xorg.0.log file shows now that libinput is loaded. Seems that this commit still did the magic
Comment 41 Jiri Slaby 2018-06-28 09:41:29 UTC
That is correct. Both Kernel:HEAD and Kernel:stable contain the commit. So everyone else should try out those kernels too...
Comment 42 Larry Finger 2018-06-28 20:25:38 UTC
Suddenly, all recompiled kernels now work!!! I have no idea what changed. Very, very curious. :(

I expect the problem will return, but who knows?
Comment 43 Jiri Slaby 2018-06-29 05:23:09 UTC
Have you updated tumbleweed which contains new libinput 1.11.1 now?
Comment 44 Raymond Wooninck 2018-06-29 05:59:13 UTC
(In reply to Jiri Slaby from comment #43)
> Have you updated tumbleweed which contains new libinput 1.11.1 now?

Hi Jiri, 

I also saw that tumbleweed had the new libinput version, but my test with the kernel from Kernel:HEAD was based with libinput 1.11.0. I tried the kernel first before I upgraded to the latest tumbleweed :)
Comment 45 Larry Finger 2018-06-29 15:11:31 UTC
No, I have avoided updating Tumbleweed until this issue is resolved. I am running version 1.11.0-1.1 of libinput. Of course, YaST tells me that 1.11.1 is available, but not yet installed.
Comment 46 Charlie Chan 2018-07-01 03:19:05 UTC
With the current snapshot 20180628, the situation backs to normal again.
Comment 47 Jiri Slaby 2018-07-02 10:46:26 UTC
So it really seems to be it.
Comment 48 Achim Gratz 2018-07-03 18:00:36 UTC
I confirm that since snapshot 20180628 things are back to normal, I've switched the keyboard/mouse back from USB to PS/2 and it's working OK.