I have a laptop (thinkpad t450s) running mostly Debian Jessie (stable
system). Now with debian backport kernel 4.6 (package:
linux-image-4.6.0-0.bpo.1-amd64 version: 4.6.4-1~bpo8+1).
CPU is Intel Broadwell i5-5200U and HD5500 (Broadwell-U) integrated graphics.
Kernel loads i915.ko as the kernel graphics driver.
The X desktop uses stock xfce from Debian.

For the past few days I have been experimenting to use "modesetting" video
driver for my graphics card instead of the (older) Intel DDX driver
(xserver-xorg-video-intel).
The relevant segment of my xorg.conf is simply:

    Section "Device"
       Identifier  "Intel Graphics"
       Driver      "modesetting"
    EndSection

In general it has been doing well, except that I faced several occasion of
bugs wherein the keyboard/mouse interaction becomes extremely laggish
after certain things happened.

I noticed two instances that can trigger this sluggish behavior:
perhaps there are more with the same underlying issue:

1) using osd_cat (package: xosd-bin). example command was like this:

   osd_cat -w -p top -c green -s 2 -a 0 -d 1 -o 32 \
       -A right -b percentage -P 19 \
       -f "-*-helvetica-medium-r-*-*-*-200-*-*-*-*-*-*" \
       -l 1 -T "Volume: 19"

This was derived from a script in here:

https://ubuntuforums.org/showthread.php?t=1313831&page=2&p=8247224#post8247224

A much-reduced dummy script that can successfully reproduce this
bug on my system is this:

    #!/bin/bash
    CHANNEL=Master
    amixer set $CHANNEL 4096+
    osd_cat -w -p top -c green -s 2 -a 0 -d 1 -o 32 \
           -A right -b percentage -P 19 \
           -f "-*-helvetica-medium-r-*-*-*-200-*-*-*-*-*-*" \
           -l 1 -T "Volume: 19"

This worked ok when I used "intel" driver, until I started using
"modesetting" driver.
After I run that script above, whatever I typed using my
keyboard will not show up until 2-3 seconds later (or more, could be 5
seconds, probably).
If I type a lot of letterrr, then after those 2-3 seconds lag then all the
typed letters would show up.
Then the whole desktop became useless until I restarted the "lightdm"
service (i.e. restarted the X session).

I also found out that the lagginess applies to the X11 display after
the osd_cat call above.
I invoked `screen` from a terminal session on this laptop, then
ssh-ing from outside and reconnect via `screen -x`.
The screen session that was from outside the laptop has no laggy
behavior whatsoever, but inside the laptop (X11 desktop), the same
screen session is very laggy.

What frustrating was that no error was shown on /var/log/syslog, or
/var/log/Xorg.0.log, dmesg, or ~/.xsession-errors that relates to this
change of behavior of X input.

At the virtual console (Ctrl+Alt+F1 for example), this lagging behavior
was not observed at all.
Strangely, if at this moment I fired up another X desktop (i.e. log in via
second virtual console as another user then invoke startx), then this
second desktop has no laggy issue whatsoever.


2) I have another way to trigger this problem, which was accidentally
found by trying to display a corrupted PDF file on xpdf.  I can attach
this file if someone wants to try it.

I downgraded the kernel to package linux-image-4.3.0-0.bpo.1-amd64
version 4.3.5-1~bpo8+1 , then with modesetting DDS there was no
laggy problem like the above.
I have tested two version of the 4.6 kernel line, the laggy behavior
is observed in both.

So the bug is either in the modesetting driver (and wasn't exposed
until the newer kernel), or a newer kernel's i915 driver has that bug
in it.
I am posting this for further investigation.


Thanks,
Wirawan