Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #247370 > unrolled thread

Debian 9 Xfce intermittent keyboard and mouse erratic behavior or lockup

Back to article view | Back to linux.debian.user

Contents

  Debian 9 Xfce intermittent keyboard and mouse erratic behavior or  lockup David Christensen <dpchrist@holgerdanske.com> - 2022-04-20 09:50 +0200
    Re: Debian 9 Xfce intermittent keyboard and mouse erratic behavior or  lockup David Christensen <dpchrist@holgerdanske.com> - 2022-04-20 10:30 +0200
    Re: Debian 9 Xfce intermittent keyboard and mouse erratic behavior  or lockup Dieter Rohlfing <dr-erc@gmx.net> - 2022-04-20 11:30 +0200
      Re: Debian 9 Xfce intermittent keyboard and mouse erratic behavior or lockup Cindy Sue Causey <butterflybytes@gmail.com> - 2022-04-20 12:50 +0200
        Re: Debian 9 Xfce intermittent keyboard and mouse erratic behavior or  lockup David Christensen <dpchrist@holgerdanske.com> - 2022-04-20 19:50 +0200
      Re: Debian 9 Xfce intermittent keyboard and mouse erratic behavior  or lockup songbird <songbird@anthive.com> - 2022-04-20 14:00 +0200
        Re: Debian 9 Xfce intermittent keyboard and mouse erratic behavior or  lockup David Christensen <dpchrist@holgerdanske.com> - 2022-04-20 20:00 +0200
      Re: Debian 9 Xfce intermittent keyboard and mouse erratic behavior or  lockup David Christensen <dpchrist@holgerdanske.com> - 2022-04-20 19:40 +0200
        Re: Debian 9 Xfce intermittent keyboard and mouse erratic behavior or  lockup Felix Miata <mrmazda@earthlink.net> - 2022-04-20 20:30 +0200
          Re: Debian 9 Xfce intermittent keyboard and mouse erratic behavior or  lockup David Christensen <dpchrist@holgerdanske.com> - 2022-04-20 23:20 +0200
            Re: Debian 9 Xfce intermittent keyboard and mouse erratic behavior or  lockup Felix Miata <mrmazda@earthlink.net> - 2022-04-20 23:50 +0200
              Re: Debian 9 Xfce intermittent keyboard and mouse erratic behavior or  lockup David Christensen <dpchrist@holgerdanske.com> - 2022-04-21 00:40 +0200
                Re: Debian 9 Xfce intermittent keyboard and mouse erratic behavior or  lockup David Christensen <dpchrist@holgerdanske.com> - 2022-04-21 10:10 +0200
                  Re: Debian 9 Xfce intermittent keyboard and mouse erratic behavior  or lockup David Wright <deblis@lionunicorn.co.uk> - 2022-04-21 23:00 +0200
                    Re: Debian 9 Xfce intermittent keyboard and mouse erratic behavior or  lockup David Christensen <dpchrist@holgerdanske.com> - 2022-04-22 02:30 +0200
                      Re: Debian 9 Xfce intermittent keyboard and mouse erratic behavior  or lockup "Andrew M.A. Cater" <amacater@einval.com> - 2022-04-22 13:10 +0200
                      Re: Debian 9 Xfce intermittent keyboard and mouse erratic behavior or  lockup David Christensen <dpchrist@holgerdanske.com> - 2022-04-22 23:10 +0200
    Re: Debian 9 Xfce intermittent keyboard and mouse erratic behavior or  lockup David Christensen <dpchrist@holgerdanske.com> - 2022-05-13 01:30 +0200

#247370 — Debian 9 Xfce intermittent keyboard and mouse erratic behavior or lockup

debian-user:

I have an SSD with Debian:

2022-04-19 23:24:11 dpchrist@tinkywinky ~
$ cat /etc/debian_version ; uname -a
9.13
Linux tinkywinky 4.9.0-18-amd64 #1 SMP Debian 4.9.303-1 (2022-03-07) 
x86_64 GNU/Linux


I have been experiencing intermittent storms of random keyboard and 
mouse GUI events over the past year or more:

a.  Windows are opened, closed, minimized, resized, etc..

b.  Windows and/or desktop pop-up menus are opened, and random items are 
activated.

c.  Text that I have previously typed is pasted into random windows.

d.  Sometimes the mouse is left in a desktop rectangular selection mode (?).


The storms are triggered when I move the mouse in an active window.  A 
storm consists of dozens of individual random GUI events per second. The 
storms typically end when I stop moving the mouse.  The next time I move 
the mouse, another storm may start or may not.  I typically reboot if 
there is more than one storm.  Firefox (on heavy JavaScript sites) and 
FreeCiv are applications that are likely to trigger storms.


Alternatively, instead of a GUI random event storm, the keyboard and 
mouse lock up.  Disconnecting and reconnecting the keyboard and mouse 
has no effect; the only cure is to reboot.


I have tried various measures to isolate the problem, to no avail:

1.  Power cycling and/or bypassing the KVM switch.

2.  Moving the OS disk into another machine with different hardware.

3.  Installing Debian 10 on another SSD and testing.  Same for Debian 11.


Is anyone else seeing these GUI event storms?


I was enjoying a game of FreeCiv this evening on a desktop computer with 
the KVM switch connected, and a storm occurred.  I shut down, connected 
the keyboard and mouse directly to the computer, and resumed my game. 
Perhaps an hour later, the keyboard and mouse locked up.


If I login from another machine via SSH, disconnect the keyboard, count 
to 10, and reconnect the keyboard:

2022-04-20 00:22:52 root@tinkywinky /var/log
# tail -n 17 messages
Apr 20 00:21:40 tinkywinky kernel: [18629.457897] usb 3-1.5: USB 
disconnect, device number 9
Apr 20 00:21:50 tinkywinky kernel: [18640.176348] usb 3-1.5: new 
low-speed USB device number 11 using ehci-pci
Apr 20 00:21:50 tinkywinky kernel: [18640.314951] usb 3-1.5: New USB 
device found, idVendor=04d9, idProduct=a0b9
Apr 20 00:21:50 tinkywinky kernel: [18640.314957] usb 3-1.5: New USB 
device strings: Mfr=1, Product=2, SerialNumber=0
Apr 20 00:21:50 tinkywinky kernel: [18640.314961] usb 3-1.5: Product: ES-87
Apr 20 00:21:50 tinkywinky kernel: [18640.314963] usb 3-1.5: 
Manufacturer: Keyed Up Labs
Apr 20 00:21:50 tinkywinky kernel: [18640.329387] input: Keyed Up Labs 
ES-87 as 
/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.0/0003:04D9:A0B9.000C/input/input23
Apr 20 00:21:50 tinkywinky kernel: [18640.388751] hid-generic 
0003:04D9:A0B9.000C: input,hidraw0: USB HID v1.10 Keyboard [Keyed Up 
Labs ES-87] on usb-0000:00:1a.0-1.5/input0
Apr 20 00:21:50 tinkywinky kernel: [18640.408155] input: Keyed Up Labs 
ES-87 as 
/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.1/0003:04D9:A0B9.000D/input/input24
Apr 20 00:21:51 tinkywinky kernel: [18640.464649] hid-generic 
0003:04D9:A0B9.000D: input,hidraw1: USB HID v1.10 Device [Keyed Up Labs 
ES-87] on usb-0000:00:1a.0-1.5/input1
Apr 20 00:21:51 tinkywinky mtp-probe: checking bus 3, device 11: 
"/sys/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5"
Apr 20 00:21:51 tinkywinky mtp-probe: bus: 3, device: 11 was not an MTP 
device
Apr 20 00:21:51 tinkywinky org.xfce.FileManager[1155]: thunar-volman: 
Unsupported USB device type "usb".
Apr 20 00:21:51 tinkywinky org.xfce.FileManager[1155]: thunar-volman: 
Unsupported input device type "/dev/input/event1".
Apr 20 00:21:51 tinkywinky org.xfce.FileManager[1155]: thunar-volman: 
Unsupported input device type "(null)".
Apr 20 00:21:51 tinkywinky org.xfce.FileManager[1155]: thunar-volman: 
Unsupported USB device type "usbhid".
Apr 20 00:21:51 tinkywinky org.xfce.FileManager[1155]: thunar-volman: 
Unsupported USB device type "usbhid".


If I cycle the mouse:

2022-04-20 00:24:36 root@tinkywinky /var/log
# tail -n 13 messages
Apr 20 00:24:00 tinkywinky kernel: [18769.493620] usb 3-1.6: USB 
disconnect, device number 10
Apr 20 00:24:13 tinkywinky kernel: [18782.515065] usb 3-1.6: new 
low-speed USB device number 12 using ehci-pci
Apr 20 00:24:13 tinkywinky kernel: [18782.645247] usb 3-1.6: New USB 
device found, idVendor=045e, idProduct=0040
Apr 20 00:24:13 tinkywinky kernel: [18782.645253] usb 3-1.6: New USB 
device strings: Mfr=1, Product=2, SerialNumber=0
Apr 20 00:24:13 tinkywinky kernel: [18782.645257] usb 3-1.6: Product: 
Microsoft Wheel Mouse Optical®
Apr 20 00:24:13 tinkywinky kernel: [18782.645260] usb 3-1.6: 
Manufacturer: Microsoft
Apr 20 00:24:13 tinkywinky mtp-probe: checking bus 3, device 12: 
"/sys/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.6"
Apr 20 00:24:13 tinkywinky kernel: [18782.655370] input: Microsoft 
Microsoft Wheel Mouse Optical® as 
/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.6/3-1.6:1.0/0003:045E:0040.000E/input/input25
Apr 20 00:24:13 tinkywinky kernel: [18782.655660] hid-generic 
0003:045E:0040.000E: input,hidraw2: USB HID v1.00 Mouse [Microsoft 
Microsoft Wheel Mouse Optical®] on usb-0000:00:1a.0-1.6/input0
Apr 20 00:24:13 tinkywinky mtp-probe: bus: 3, device: 12 was not an MTP 
device
Apr 20 00:24:13 tinkywinky org.xfce.FileManager[1155]: thunar-volman: 
Unsupported USB device type "usb".
Apr 20 00:24:13 tinkywinky org.xfce.FileManager[1155]: thunar-volman: 
Unsupported USB device type "usbhid".
Apr 20 00:24:13 tinkywinky org.xfce.FileManager[1155]: thunar-volman: 
Unsupported input device type "/dev/input/event2".


Any ideas for where to look for clues?


I can leave the machine running for a while, if anyone has suggestions 
for commands to try.


David

[toc] | [next] | [standalone]

#247371

On 4/20/22 12:43 AM, David Christensen wrote:
> debian-user:
> 
> I have an SSD with Debian:
> 
> 2022-04-19 23:24:11 dpchrist@tinkywinky ~
> $ cat /etc/debian_version ; uname -a
> 9.13
> Linux tinkywinky 4.9.0-18-amd64 #1 SMP Debian 4.9.303-1 (2022-03-07) 
> x86_64 GNU/Linux
> 
> 
> I have been experiencing intermittent storms of random keyboard and 
> mouse GUI events over the past year or more:
> 
> a.  Windows are opened, closed, minimized, resized, etc..
> 
> b.  Windows and/or desktop pop-up menus are opened, and random items are 
> activated.
> 
> c.  Text that I have previously typed is pasted into random windows.
> 
> d.  Sometimes the mouse is left in a desktop rectangular selection mode 
> (?).
> 
> 
> The storms are triggered when I move the mouse in an active window.  A 
> storm consists of dozens of individual random GUI events per second. The 
> storms typically end when I stop moving the mouse.  The next time I move 
> the mouse, another storm may start or may not.  I typically reboot if 
> there is more than one storm.  Firefox (on heavy JavaScript sites) and 
> FreeCiv are applications that are likely to trigger storms.
> 
> 
> Alternatively, instead of a GUI random event storm, the keyboard and 
> mouse lock up.  Disconnecting and reconnecting the keyboard and mouse 
> has no effect; the only cure is to reboot.
> 
> 
> I have tried various measures to isolate the problem, to no avail:
> 
> 1.  Power cycling and/or bypassing the KVM switch.
> 
> 2.  Moving the OS disk into another machine with different hardware.
> 
> 3.  Installing Debian 10 on another SSD and testing.  Same for Debian 11.
> 
> 
> Is anyone else seeing these GUI event storms?
> 
> 
> I was enjoying a game of FreeCiv this evening on a desktop computer with 
> the KVM switch connected, and a storm occurred.  I shut down, connected 
> the keyboard and mouse directly to the computer, and resumed my game. 
> Perhaps an hour later, the keyboard and mouse locked up.
> 
> 
> If I login from another machine via SSH, disconnect the keyboard, count 
> to 10, and reconnect the keyboard:
> 
> 2022-04-20 00:22:52 root@tinkywinky /var/log
> # tail -n 17 messages
> Apr 20 00:21:40 tinkywinky kernel: [18629.457897] usb 3-1.5: USB 
> disconnect, device number 9
> Apr 20 00:21:50 tinkywinky kernel: [18640.176348] usb 3-1.5: new 
> low-speed USB device number 11 using ehci-pci
> Apr 20 00:21:50 tinkywinky kernel: [18640.314951] usb 3-1.5: New USB 
> device found, idVendor=04d9, idProduct=a0b9
> Apr 20 00:21:50 tinkywinky kernel: [18640.314957] usb 3-1.5: New USB 
> device strings: Mfr=1, Product=2, SerialNumber=0
> Apr 20 00:21:50 tinkywinky kernel: [18640.314961] usb 3-1.5: Product: ES-87
> Apr 20 00:21:50 tinkywinky kernel: [18640.314963] usb 3-1.5: 
> Manufacturer: Keyed Up Labs
> Apr 20 00:21:50 tinkywinky kernel: [18640.329387] input: Keyed Up Labs 
> ES-87 as 
> /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.0/0003:04D9:A0B9.000C/input/input23 
> 
> Apr 20 00:21:50 tinkywinky kernel: [18640.388751] hid-generic 
> 0003:04D9:A0B9.000C: input,hidraw0: USB HID v1.10 Keyboard [Keyed Up 
> Labs ES-87] on usb-0000:00:1a.0-1.5/input0
> Apr 20 00:21:50 tinkywinky kernel: [18640.408155] input: Keyed Up Labs 
> ES-87 as 
> /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.1/0003:04D9:A0B9.000D/input/input24 
> 
> Apr 20 00:21:51 tinkywinky kernel: [18640.464649] hid-generic 
> 0003:04D9:A0B9.000D: input,hidraw1: USB HID v1.10 Device [Keyed Up Labs 
> ES-87] on usb-0000:00:1a.0-1.5/input1
> Apr 20 00:21:51 tinkywinky mtp-probe: checking bus 3, device 11: 
> "/sys/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5"
> Apr 20 00:21:51 tinkywinky mtp-probe: bus: 3, device: 11 was not an MTP 
> device
> Apr 20 00:21:51 tinkywinky org.xfce.FileManager[1155]: thunar-volman: 
> Unsupported USB device type "usb".
> Apr 20 00:21:51 tinkywinky org.xfce.FileManager[1155]: thunar-volman: 
> Unsupported input device type "/dev/input/event1".
> Apr 20 00:21:51 tinkywinky org.xfce.FileManager[1155]: thunar-volman: 
> Unsupported input device type "(null)".
> Apr 20 00:21:51 tinkywinky org.xfce.FileManager[1155]: thunar-volman: 
> Unsupported USB device type "usbhid".
> Apr 20 00:21:51 tinkywinky org.xfce.FileManager[1155]: thunar-volman: 
> Unsupported USB device type "usbhid".
> 
> 
> If I cycle the mouse:
> 
> 2022-04-20 00:24:36 root@tinkywinky /var/log
> # tail -n 13 messages
> Apr 20 00:24:00 tinkywinky kernel: [18769.493620] usb 3-1.6: USB 
> disconnect, device number 10
> Apr 20 00:24:13 tinkywinky kernel: [18782.515065] usb 3-1.6: new 
> low-speed USB device number 12 using ehci-pci
> Apr 20 00:24:13 tinkywinky kernel: [18782.645247] usb 3-1.6: New USB 
> device found, idVendor=045e, idProduct=0040
> Apr 20 00:24:13 tinkywinky kernel: [18782.645253] usb 3-1.6: New USB 
> device strings: Mfr=1, Product=2, SerialNumber=0
> Apr 20 00:24:13 tinkywinky kernel: [18782.645257] usb 3-1.6: Product: 
> Microsoft Wheel Mouse Optical®
> Apr 20 00:24:13 tinkywinky kernel: [18782.645260] usb 3-1.6: 
> Manufacturer: Microsoft
> Apr 20 00:24:13 tinkywinky mtp-probe: checking bus 3, device 12: 
> "/sys/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.6"
> Apr 20 00:24:13 tinkywinky kernel: [18782.655370] input: Microsoft 
> Microsoft Wheel Mouse Optical® as 
> /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.6/3-1.6:1.0/0003:045E:0040.000E/input/input25 
> 
> Apr 20 00:24:13 tinkywinky kernel: [18782.655660] hid-generic 
> 0003:045E:0040.000E: input,hidraw2: USB HID v1.00 Mouse [Microsoft 
> Microsoft Wheel Mouse Optical®] on usb-0000:00:1a.0-1.6/input0
> Apr 20 00:24:13 tinkywinky mtp-probe: bus: 3, device: 12 was not an MTP 
> device
> Apr 20 00:24:13 tinkywinky org.xfce.FileManager[1155]: thunar-volman: 
> Unsupported USB device type "usb".
> Apr 20 00:24:13 tinkywinky org.xfce.FileManager[1155]: thunar-volman: 
> Unsupported USB device type "usbhid".
> Apr 20 00:24:13 tinkywinky org.xfce.FileManager[1155]: thunar-volman: 
> Unsupported input device type "/dev/input/event2".
> 
> 
> Any ideas for where to look for clues?
> 
> 
> I can leave the machine running for a while, if anyone has suggestions 
> for commands to try.


Some more troubleshooting clues:

1.  I have previously run Windows 7 on the same computers and have not 
seen the same keyboard and mouse problems.

2.  When I connect the keyboard and mouse to a MacBook Pro, the mouse 
works correctly and the keyboard works (differently; it's an Apple).


David

[toc] | [prev] | [next] | [standalone]

#247372 — Re: Debian 9 Xfce intermittent keyboard and mouse erratic behavior or lockup

Am Wed, 20 Apr 2022 00:43:35 -0700
schrieb David Christensen <dpchrist@holgerdanske.com>:

>I have been experiencing intermittent storms of random keyboard and
>mouse GUI events over the past year or more:

Same for me.

System is Debian 9.13 (kernel 4.19.0-0.bpo.19-amd64, XFCE desktop) running
on an ASRock DeskMini H110M.

I'm running this combination with several hosts, but the storm only
appears with the ASRock PC. Even with another mouse and keyboard the
symptoms remain. So I think the storm mainly depends on the bare host and
not on the peripheral components.

At the moment I'm tinkering with the C-states. I disabled C6 and C7 in the
BIOS and added the following options to the kernel command line:

> processor.max_cstate=3 intel_idle.max_cstate=3

Because the symptoms appear randomly, I can't say anything about a
possible solution. I'll continue watching and will report, when I have any
news.

Dieter

[toc] | [prev] | [next] | [standalone]

#247377 — Re: Debian 9 Xfce intermittent keyboard and mouse erratic behavior or lockup

On 4/20/22, Dieter Rohlfing <dr-erc@gmx.net> wrote:
> Am Wed, 20 Apr 2022 00:43:35 -0700
> schrieb David Christensen <dpchrist@holgerdanske.com>:
>
>>I have been experiencing intermittent storms of random keyboard and
>>mouse GUI events over the past year or more:
>
> Same for me.
>
> System is Debian 9.13 (kernel 4.19.0-0.bpo.19-amd64, XFCE desktop) running
> on an ASRock DeskMini H110M.
>
> I'm running this combination with several hosts, but the storm only
> appears with the ASRock PC. Even with another mouse and keyboard the
> symptoms remain. So I think the storm mainly depends on the bare host and
> not on the peripheral components.


"Sticky keys", an accessibility feature, come to mind as needing to be
ruled out. I've accidentally triggered mine multiple times over the
last couple of years. To this day, I have no idea what combination of
keys I'm hitting that does it. I'll just see a 2-second flash of an
onscreen notification that they've been triggered on... again.


> At the moment I'm tinkering with the C-states. I disabled C6 and C7 in the
> BIOS and added the following options to the kernel command line:
>
>> processor.max_cstate=3 intel_idle.max_cstate=3
>
> Because the symptoms appear randomly, I can't say anything about a
> possible solution. I'll continue watching and will report, when I have any
> news.


I've also occasionally experienced erratic behavior that's hardware
caused by two different, unrelated instances. One has been that my
laptop keys are, for example, worn out and/or overheating and
"sticking" as though permanently depressed (being physically held
down).

The erratic appearance of this particular behavior will occur when I'm
typing out posts or whatever and incidentally hit a declared hotkey
that becomes triggered because e.g. the likewise declared CTRL key is
physically stuck in the ON position. This scenario occurs because I
have to buy old equipment that eventually overheats and causes things
like the onboard keyboard to inevitably have a limited lifetime
expectancy based meltdown.

The secondary cause for seemingly erratic behavior is easier to fix.
It's when the dogs or I are somehow leaning on any of my mouse's
buttons. That will occur sometimes when I've set the mouse down to the
side and am using a laptop's touchpad, instead. The mouse and the
touchpad will end up conflicting with each other over which one has
control of the situation.

XFCE4 just coincidentally happens to be what I'm using for the above.
My guess is that, since my situations are hardware based, they would
likely occur regardless of what desktop environment happens to be in
use at the time.

Cindy :)
-- 
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *

[toc] | [prev] | [next] | [standalone]

#247387

On 4/20/22 3:43 AM, Cindy Sue Causey wrote:
> On 4/20/22, Dieter Rohlfing <dr-erc@gmx.net> wrote:
>> Am Wed, 20 Apr 2022 00:43:35 -0700
>> schrieb David Christensen <dpchrist@holgerdanske.com>:
>>
>>> I have been experiencing intermittent storms of random keyboard and
>>> mouse GUI events over the past year or more:
>>
>> Same for me.
>>
>> System is Debian 9.13 (kernel 4.19.0-0.bpo.19-amd64, XFCE desktop) running
>> on an ASRock DeskMini H110M.
>>
>> I'm running this combination with several hosts, but the storm only
>> appears with the ASRock PC. Even with another mouse and keyboard the
>> symptoms remain. So I think the storm mainly depends on the bare host and
>> not on the peripheral components.
> 
> 
> "Sticky keys", an accessibility feature, come to mind as needing to be
> ruled out. I've accidentally triggered mine multiple times over the
> last couple of years. To this day, I have no idea what combination of
> keys I'm hitting that does it. I'll just see a 2-second flash of an
> onscreen notification that they've been triggered on... again.
> 
> 
>> At the moment I'm tinkering with the C-states. I disabled C6 and C7 in the
>> BIOS and added the following options to the kernel command line:
>>
>>> processor.max_cstate=3 intel_idle.max_cstate=3
>>
>> Because the symptoms appear randomly, I can't say anything about a
>> possible solution. I'll continue watching and will report, when I have any
>> news.
> 
> 
> I've also occasionally experienced erratic behavior that's hardware
> caused by two different, unrelated instances. One has been that my
> laptop keys are, for example, worn out and/or overheating and
> "sticking" as though permanently depressed (being physically held
> down).
> 
> The erratic appearance of this particular behavior will occur when I'm
> typing out posts or whatever and incidentally hit a declared hotkey
> that becomes triggered because e.g. the likewise declared CTRL key is
> physically stuck in the ON position. This scenario occurs because I
> have to buy old equipment that eventually overheats and causes things
> like the onboard keyboard to inevitably have a limited lifetime
> expectancy based meltdown.
> 
> The secondary cause for seemingly erratic behavior is easier to fix.
> It's when the dogs or I are somehow leaning on any of my mouse's
> buttons. That will occur sometimes when I've set the mouse down to the
> side and am using a laptop's touchpad, instead. The mouse and the
> touchpad will end up conflicting with each other over which one has
> control of the situation.
> 
> XFCE4 just coincidentally happens to be what I'm using for the above.
> My guess is that, since my situations are hardware based, they would
> likely occur regardless of what desktop environment happens to be in
> use at the time.


Those sounds like different failure modes that what I posted, but I also 
get stuck keys and/or accidentally lean on keys intermittently.  I will 
need to pay more attention to those failures.


I have also read that multiple pointing devices -- mouse, touch pad, 
mouse button, etc. -- can fight each other for GUI input.  I disabled 
everything except the mouse via Xfce, but the problems continued.


David

[toc] | [prev] | [next] | [standalone]

#247380 — Re: Debian 9 Xfce intermittent keyboard and mouse erratic behavior or lockup

Dieter Rohlfing wrote:
> Am Wed, 20 Apr 2022 00:43:35 -0700
> schrieb David Christensen <dpchrist@holgerdanske.com>:
>
>>I have been experiencing intermittent storms of random keyboard and
>>mouse GUI events over the past year or more:
>
> Same for me.
>
> System is Debian 9.13 (kernel 4.19.0-0.bpo.19-amd64, XFCE desktop) running
> on an ASRock DeskMini H110M.
>
> I'm running this combination with several hosts, but the storm only
> appears with the ASRock PC. Even with another mouse and keyboard the
> symptoms remain. So I think the storm mainly depends on the bare host and
> not on the peripheral components.
>
> At the moment I'm tinkering with the C-states. I disabled C6 and C7 in the
> BIOS and added the following options to the kernel command line:
>
>> processor.max_cstate=3 intel_idle.max_cstate=3
>
> Because the symptoms appear randomly, I can't say anything about a
> possible solution. I'll continue watching and will report, when I have any
> news.

  some things to look into.  Mouse sensitivity in the desktop 
hardware settings.  changing the batteries.  using different 
USB ports for the dongle.  replacing the keyboard or mouse.

  it might be the case that your dongle is getting stray 
signals from some other device.  if you have a lot if 
devices sending signals perhaps they're interferring with
each other somehow.  i've only had the mouse being run by
a dongle and that has never had issues.  instead i have
issues with keyboards not lasting very long (but they are
corded ones since i don't like the cordless types).


  songbird

[toc] | [prev] | [next] | [standalone]

#247389

On 4/20/22 4:51 AM, songbird wrote:
> Dieter Rohlfing wrote:
>> Am Wed, 20 Apr 2022 00:43:35 -0700
>> schrieb David Christensen <dpchrist@holgerdanske.com>:
>>
>>> I have been experiencing intermittent storms of random keyboard and
>>> mouse GUI events over the past year or more:
>>
>> Same for me.
>>
>> System is Debian 9.13 (kernel 4.19.0-0.bpo.19-amd64, XFCE desktop) running
>> on an ASRock DeskMini H110M.
>>
>> I'm running this combination with several hosts, but the storm only
>> appears with the ASRock PC. Even with another mouse and keyboard the
>> symptoms remain. So I think the storm mainly depends on the bare host and
>> not on the peripheral components.
>>
>> At the moment I'm tinkering with the C-states. I disabled C6 and C7 in the
>> BIOS and added the following options to the kernel command line:
>>
>>> processor.max_cstate=3 intel_idle.max_cstate=3
>>
>> Because the symptoms appear randomly, I can't say anything about a
>> possible solution. I'll continue watching and will report, when I have any
>> news.
> 
>    some things to look into.  Mouse sensitivity in the desktop
> hardware settings. 


I have adjusted that in the past, and typically have it up fairly high, 
but I do not believe it is related to the keyboard/ mouse random GUI 
event storms.


> changing the batteries. 


I typically run the laptops with the AC adapter connected, and the 
desktop has a PSU.


> using different USB ports for the dongle. 


My keyboard and mouse are wired USB.

One front USB 2.0 port works (I seem to recall the other died years ago).

All four rear USB 2.0 ports are useless.

Both rear USB 3.0 ports work.


Now I'm starting to suspect the USB subsystem of X...


> replacing the keyboard or mouse.


I seem to be running my last USB keyboard and USB mouse.


David

[toc] | [prev] | [next] | [standalone]

#247386

On 4/20/22 2:23 AM, Dieter Rohlfing wrote:
> Am Wed, 20 Apr 2022 00:43:35 -0700
> schrieb David Christensen <dpchrist@holgerdanske.com>:
> 
>> I have been experiencing intermittent storms of random keyboard and
>> mouse GUI events over the past year or more:
> 
> Same for me.
> 
> System is Debian 9.13 (kernel 4.19.0-0.bpo.19-amd64, XFCE desktop) running
> on an ASRock DeskMini H110M.


Thank you for the confirmation.


STFW:

https://www.asrock.com/microsite/DeskMini/#Specification

It appears that platform supports Intel processors with integrated graphics:

CPU 	Supports 7th and 6th Generation Intel® Core™ 
i7/i5/i3/Pentium®/Celeron® Processors (Socket 1151) (Max. TDP 65W)


I have seen the keyboard and mouse issues on the following hardware:

1.  Dell Inspiron E1505, Intel Core 2 Duo T7400 processor, Intel GM 945 
chipset (Intel® 82945GM Graphics and Memory Controller).  I believe 
Debian uses the xserver-xorg-video-intel driver.

2.  Dell Latitude E6520, Intel Core i7-2720QM processor, Optimus 
graphics (Intel HD Graphics 3000 and NVIDIA NVS 4200M discrete 
graphics).  I typically disable Optimus in the CMOS setup, which 
disables the Intel graphics.  Debian uses the nouveau driver.

3.  Desktop with Intel DQ67SW motherboard, Intel i7-2600S processor with 
Intel HD Graphics 2000.  I believe Debian uses the 
xserver-xorg-video-intel driver.


> I'm running this combination with several hosts, but the storm only
> appears with the ASRock PC. Even with another mouse and keyboard the
> symptoms remain. So I think the storm mainly depends on the bare host and
> not on the peripheral components.


My WAG is that a bug was introduced in the X Windows and/or desktop 
drivers 1~2 years ago on Debian 9, 10, and 11.


> At the moment I'm tinkering with the C-states. I disabled C6 and C7 in the
> BIOS and added the following options to the kernel command line:
> 
>> processor.max_cstate=3 intel_idle.max_cstate=3
> 
> Because the symptoms appear randomly, I can't say anything about a
> possible solution. I'll continue watching and will report, when I have any
> news.


Please let us know if you make any progress.


David

[toc] | [prev] | [next] | [standalone]

#247390

David Christensen composed on 2022-04-20 10:31 (UTC-0700):

> 1.  Dell Inspiron E1505, Intel Core 2 Duo T7400 processor, Intel GM 945 
> chipset (Intel® 82945GM Graphics and Memory Controller).  I believe 
> Debian uses the xserver-xorg-video-intel driver.

> 3.  Desktop with Intel DQ67SW motherboard, Intel i7-2600S processor with 
> Intel HD Graphics 2000.  I believe Debian uses the 
> xserver-xorg-video-intel driver.																			
There are two different technologies for X display drivers.
xserver-xorg-video-intel uses the older, DDX. It hasn't had an official release in
nearly a decade. Unofficially it's in maintenance mode. The newer technology
driver, modesetting DIX, is provided by the same package that provides the Xorg
server, so cannot be removed independently of the server. The 945GM is the among
the newest Intel IGPs not supported by the newer driver. By removing
xserver-xorg-video-intel, the newer DIX display driver should automatically be
utilized by your i7's IGP. It may be worth trying to solve your issue, if indeed
you're not already running the DIX on your i7.
-- 
Evolution as taught in public schools is, like religion,
	based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

[toc] | [prev] | [next] | [standalone]

#247397

On 4/20/22 11:23, Felix Miata wrote:
> David Christensen composed on 2022-04-20 10:31 (UTC-0700):
> 
>> 1.  Dell Inspiron E1505, Intel Core 2 Duo T7400 processor, Intel GM 945
>> chipset (Intel® 82945GM Graphics and Memory Controller).  I believe
>> Debian uses the xserver-xorg-video-intel driver.
> 
>> 3.  Desktop with Intel DQ67SW motherboard, Intel i7-2600S processor with
>> Intel HD Graphics 2000.  I believe Debian uses the
>> xserver-xorg-video-intel driver.																			
> There are two different technologies for X display drivers.
> xserver-xorg-video-intel uses the older, DDX. It hasn't had an official release in
> nearly a decade. Unofficially it's in maintenance mode. The newer technology
> driver, modesetting DIX, is provided by the same package that provides the Xorg
> server, so cannot be removed independently of the server. The 945GM is the among
> the newest Intel IGPs not supported by the newer driver. By removing
> xserver-xorg-video-intel, the newer DIX display driver should automatically be
> utilized by your i7's IGP. It may be worth trying to solve your issue, if indeed
> you're not already running the DIX on your i7.


Can you suggestion and commands to run that might provide clues?


David

[toc] | [prev] | [next] | [standalone]

#247398

David Christensen composed on 2022-04-20 14:14 (UTC-0700):

> Felix Miata wrote:

>> There are two different technologies for X display drivers.
>> xserver-xorg-video-intel uses the older, DDX. It hasn't had an official release in
>> nearly a decade. Unofficially it's in maintenance mode. The newer technology
>> driver, modesetting DIX, is provided by the same package that provides the Xorg
>> server, so cannot be removed independently of the server. The 945GM is the among
>> the newest Intel IGPs not supported by the newer driver. By removing
>> xserver-xorg-video-intel, the newer DIX display driver should automatically be
>> utilized by your i7's IGP. It may be worth trying to solve your issue, if indeed
>> you're not already running the DIX on your i7.

> Can you suggestion and commands to run that might provide clues?

Other than switching between use of DDX display drivers (intel, nouveau) and DIX
driver (modesetting, which supports: AMD, Intel, NVidia, other) to see if bad
behavior persists, I have only one other possible suggestion:

Older systems used only various specific input drivers, e.g.:

	xserver-xorg-input-kbd
	xserver-xorg-input-mouse
	xserver-xorg-input-evdev

If these are installed, you might try removing them, thus having only the newer
*libinput* drivers available for use.

# dpkg -l | grep input-kbd
# dpkg -l | grep xorg-input
ii  xserver-xorg-input-all               1:7.7+23                            amd64
       X.Org X server -- input driver metapackage
ii  xserver-xorg-input-libinput          1.2.1-1+b1                          amd64
       X.Org X server -- libinput input driver
-- 
Evolution as taught in public schools is, like religion,
	based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

[toc] | [prev] | [next] | [standalone]

#247399

On 4/20/22 14:40, Felix Miata wrote:
> David Christensen composed on 2022-04-20 14:14 (UTC-0700):

>> Can you suggestion and commands to run that might provide clues?
> 
> Other than switching between use of DDX display drivers (intel, nouveau) and DIX
> driver (modesetting, which supports: AMD, Intel, NVidia, other) to see if bad
> behavior persists, I have only one other possible suggestion:
> 
> Older systems used only various specific input drivers, e.g.:
> 
> 	xserver-xorg-input-kbd
> 	xserver-xorg-input-mouse
> 	xserver-xorg-input-evdev
> 
> If these are installed, you might try removing them, thus having only the newer
> *libinput* drivers available for use.
> 
> # dpkg -l | grep input-kbd
> # dpkg -l | grep xorg-input
> ii  xserver-xorg-input-all               1:7.7+23                            amd64
>         X.Org X server -- input driver metapackage
> ii  xserver-xorg-input-libinput          1.2.1-1+b1                          amd64
>         X.Org X server -- libinput input driver


2022-04-20 15:27:34 root@tinkywinky ~
# dpkg -l | grep input-kbd

2022-04-20 15:28:12 root@tinkywinky ~
# dpkg -l | grep xorg-input
ii  xserver-xorg-input-all                1:7.7+19 
     amd64        X.Org X server -- input driver metapackage
ii  xserver-xorg-input-libinput           0.23.0-2 
     amd64        X.Org X server -- libinput input driver
ii  xserver-xorg-input-wacom              0.34.0-1 
     amd64        X.Org X server -- Wacom input driver


Any other commands?


The rear USB 2.0 ports are down right now.  Are there any commands I 
should run before rebooting (to test if the problem is hardware software)?


David

[toc] | [prev] | [next] | [standalone]

#247404

On 4/20/22 15:31, David Christensen wrote:

> The rear USB 2.0 ports are down right now.  Are there any commands I 
> should run before rebooting (to test if the problem is hardware software)?


I ran the desktop with the keyboard and mouse connected directly to the 
rear USB 3.0 ports.  I did not see any random GUI input event storms. 
The keyboard and mouse did not lock up.


I powered down, reconnected the keyboard and mouse to the KVM switch, 
connected the KVM cable to the desktop computer, and booted.  The four 
(4) rear USB 2.0 ports and the two (2) rear USB 3.0 ports work correctly.


Therefore, I conclude the problem is software -- whatever in Debian 9 
Xfce deals with X Windows input via USB 2.0 keyboards and mice.


What package do I file a bug report against?


David

[toc] | [prev] | [next] | [standalone]

#247438 — Re: Debian 9 Xfce intermittent keyboard and mouse erratic behavior or lockup

On Thu 21 Apr 2022 at 01:02:56 (-0700), David Christensen wrote:
> On 4/20/22 15:31, David Christensen wrote:
> 
> > The rear USB 2.0 ports are down right now.  Are there any commands
> > I should run before rebooting (to test if the problem is hardware
> > software)?
> 
> 
> I ran the desktop with the keyboard and mouse connected directly to
> the rear USB 3.0 ports.  I did not see any random GUI input event
> storms. The keyboard and mouse did not lock up.
> 
> 
> I powered down, reconnected the keyboard and mouse to the KVM switch,
> connected the KVM cable to the desktop computer, and booted.  The four
> (4) rear USB 2.0 ports and the two (2) rear USB 3.0 ports work
> correctly.
> 
> 
> Therefore, I conclude the problem is software -- whatever in Debian 9
> Xfce deals with X Windows input via USB 2.0 keyboards and mice.
> 
> 
> What package do I file a bug report against?

It's not clear from reading your posts (unless it requires some
correlation, on my part, of your observations) whether you have
had storms on USB2 ports on several machines, or only on ones
that appear to work intermittently.

If the former, have they always involved the KVM?

Do you configure the mouse at all, bearing in mind that unplugging
and replugging it may lose that configuration. (I don't know how
KVMs fit into this model.)

Always bearing in mind that reporting against Debian 9 might only
result in a stifled yawn.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#247444

On 4/21/22 13:50, David Wright wrote:
> On Thu 21 Apr 2022 at 01:02:56 (-0700), David Christensen wrote:

>> What package do I file a bug report against?
> 
> It's not clear from reading your posts (unless it requires some
> correlation, on my part, of your observations) whether you have
> had storms on USB2 ports on several machines, 


Yes -- at least two laptops and one desktop.


> or only on ones that appear to work intermittently.


The USB 2.0 ports in the desktop are the most recent lock up.  I do not 
recall a lock up in the laptops recently; just GUI random pointing 
device storms.


> If the former, have they always involved the KVM?


The USB 2.0 failures occur with and without the KVM switch.


The USB 3.0 correct behavior occurs with and without the KVM switch.


> Do you configure the mouse at all, bearing in mind that unplugging
> and replugging it may lose that configuration. (I don't know how
> KVMs fit into this model.)


Changing pointing device settings via Xfce Applications Menu -> Settings 
-> Mouse and Touchpad does not seem to affect the failures, but I have 
not made many changes.


> Always bearing in mind that reporting against Debian 9 might only
> result in a stifled yawn.


The same problem exists in Debian 9, 10, and 11.  I can readily file bug 
reports against Debian 9 and 11 (I wiped and reused my Debian 10 SSD).


David

[toc] | [prev] | [next] | [standalone]

#247451 — Re: Debian 9 Xfce intermittent keyboard and mouse erratic behavior or lockup

On Thu, Apr 21, 2022 at 05:28:35PM -0700, David Christensen wrote:
> On 4/21/22 13:50, David Wright wrote:
> > On Thu 21 Apr 2022 at 01:02:56 (-0700), David Christensen wrote:
> 
> > > What package do I file a bug report against?
> > 
> > It's not clear from reading your posts (unless it requires some
> > correlation, on my part, of your observations) whether you have
> > had storms on USB2 ports on several machines,
> 
> 
> Yes -- at least two laptops and one desktop.
> 
> 
> > or only on ones that appear to work intermittently.
> 
> 
> The USB 2.0 ports in the desktop are the most recent lock up.  I do not
> recall a lock up in the laptops recently; just GUI random pointing device
> storms.
> 
> 
> > If the former, have they always involved the KVM?
> 
> 
> The USB 2.0 failures occur with and without the KVM switch.
> 
> 
> The USB 3.0 correct behavior occurs with and without the KVM switch.
> 
> 
> > Do you configure the mouse at all, bearing in mind that unplugging
> > and replugging it may lose that configuration. (I don't know how
> > KVMs fit into this model.)
> 
> 
> Changing pointing device settings via Xfce Applications Menu -> Settings ->
> Mouse and Touchpad does not seem to affect the failures, but I have not made
> many changes.
> 
> 
> > Always bearing in mind that reporting against Debian 9 might only
> > result in a stifled yawn.
> 
> 
> The same problem exists in Debian 9, 10, and 11.  I can readily file bug
> reports against Debian 9 and 11 (I wiped and reused my Debian 10 SSD).
> 
> 
> David
>

Hello David(s)

Bearing in mind that LTS support for Debian 9 Stretch ends in approximately
two months (2022-06-30), I'd suggest that a bug report there will probably 
not attract significant attention, though there is likely to be a final
point release as it goes out of LTS.

I would advise anybody running Debian 9 now to consider moving forwards to
10 or 11. Debian 10's EOL for stable support before transition to LTS is 
approximately 2022-08 - https://wiki.debian.org/DebianReleases

If it's a bug on 9/10/11 and there's a KVM involved - it's likely to be 
the KVM in all honesty - I have similar problems with a KVM not recognising
a trackball until it's unplugged/replugged. USB 2.0 for that one.

All the very best, as ever, 

Andy Cater

[toc] | [prev] | [next] | [standalone]

#247461

On 4/21/2022 5:28 PM, David Christensen wrote:
> On 4/21/22 13:50, David Wright wrote:
>> On Thu 21 Apr 2022 at 01:02:56 (-0700), David Christensen wrote:
> 
>>> What package do I file a bug report against?
>>
>> It's not clear from reading your posts (unless it requires some
>> correlation, on my part, of your observations) whether you have
>> had storms on USB2 ports on several machines, 
> 
> 
> Yes -- at least two laptops and one desktop.
> 
> 
>> or only on ones that appear to work intermittently.
> 
> 
> The USB 2.0 ports in the desktop are the most recent lock up.  I do not 
> recall a lock up in the laptops recently; just GUI random pointing 
> device storms.
> 
> 
>> If the former, have they always involved the KVM?
> 
> 
> The USB 2.0 failures occur with and without the KVM switch.
> 
> 
> The USB 3.0 correct behavior occurs with and without the KVM switch.
> 
> 
>> Do you configure the mouse at all, bearing in mind that unplugging
>> and replugging it may lose that configuration. (I don't know how
>> KVMs fit into this model.)
> 
> 
> Changing pointing device settings via Xfce Applications Menu -> Settings 
> -> Mouse and Touchpad does not seem to affect the failures, but I have 
> not made many changes.
> 
> 
>> Always bearing in mind that reporting against Debian 9 might only
>> result in a stifled yawn.
> 
> 
> The same problem exists in Debian 9, 10, and 11.  I can readily file bug 
> reports against Debian 9 and 11 (I wiped and reused my Debian 10 SSD).


I saw one GUI input event storm in ~6 hours of use following the above 
post with Debian 9, KVM, and USB 3.0.


David

[toc] | [prev] | [next] | [standalone]

#248141

On 4/20/22 00:43, David Christensen wrote:

> I have been experiencing intermittent storms of random keyboard and 
> mouse GUI events over the past year or more:

I found my spare mouse last week and swapped out the mouse I have been 
using for the past few years.  The problems went away.  The bad mouse is 
now on the recycle pile.


Thank you, everyone, for your help.  Sorry for the confusion.


David

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web