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

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

Keyboard prevents screensaver & scrolling terminal window

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

Contents

  Keyboard prevents screensaver & scrolling terminal window Jeff <jffry@posteo.net> - 2021-10-15 13:40 +0200
    Re: Keyboard prevents screensaver & scrolling terminal window "Thomas Schmitt" <scdbackup@gmx.net> - 2021-10-17 14:00 +0200
      Re: Keyboard prevents screensaver & scrolling terminal window Jeff <jffry@posteo.net> - 2021-10-19 21:20 +0200
        Re: Keyboard prevents screensaver & scrolling terminal window "Thomas Schmitt" <scdbackup@gmx.net> - 2021-10-19 22:40 +0200
          Re: Keyboard prevents screensaver & scrolling terminal window Jeff <jffry@posteo.net> - 2021-10-21 18:50 +0200

#241335 — Keyboard prevents screensaver & scrolling terminal window

[Multipart message — attachments visible in raw view] — view raw

Hallo!

I picked up a second-hand Cherry MX 3 keyboard some time ago. The feel 
is very good, but when it is plugged in, I can no longer scroll the 
active terminal window, and the screensaver no longer activates.

I can scroll inactive terminal windows, and everything returns to normal 
if I unplug it.

It is as if the keyboard is constantly sending invisible keystrokes 
(e.g. shift or control), but otherwise it works fine.

Is this a fault with the keyboard, or am I missing a setting somewhere?

Regards

Jeff

Please keep me in cc, as I am not subscribed to the list.

[toc] | [next] | [standalone]

#241402

Hi,

due to the lack of other proposals i now come up with something ancient.
If you are still running the X Window System, then there should be a
program named xev.
Start it in a dedicated terminal window which will get its verbous
text output. Redirect a copy of that output to a file:

  xev | tee -i /tmp/xev.log

xev will pop up a small window, of which it will report the received
X events. Among them are input events of keyboard and mouse.
So give this small window the input focus. (I.e. move mouse cursor into
it. Maybe you need to click at it. Whatever your desktop expects.)

You will see a little storm of events like

  PropertyNotify event, serial 8, synthetic NO, window 0x11400001,
      atom 0x27 (WM_NAME), time 382397390, state PropertyNewValue

  ... more window setup events ...

  MotionNotify event, serial 40, synthetic NO, window 0x11400001,
      root 0xa4, subw 0x0, time 382398675, (59,148), root:(390,245),
      state 0x0, is_hint 0, same_screen YES

  ... more mouse events ...

Next take your hands off mouse and keyboard.
At some point - at least for me - xev stops to report new events and i
can make key tests. E.g. i press "Shift" and see

  KeyPress event, serial 40, synthetic NO, window 0x11400001,
      root 0xa4, subw 0x0, time 382860609, (81,134), root:(412,231),
      state 0x0, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
      XLookupString gives 0 bytes:
      XmbLookupString gives 0 bytes:
      XFilterEvent returns: False

  KeyRelease event, serial 40, synthetic NO, window 0x11400001,
      root 0xa4, subw 0x0, time 382860680, (81,134), root:(412,231),
      state 0x1, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
      XLookupString gives 0 bytes:
      XFilterEvent returns: False

In order to end the program, i put the input focus on the terminal
window, where it reports its events, and press Ctrl+C.

If your suspicion is right, xev should show lots of such Key* events
as soon as its receiver window gets the focus, without you pressing any
key at the keyboard. In that case, end xev and look at the messages
on the terminal window or in file  /tmp/xev.log .


Have a nice day :)

Thomas

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

#241518

[Multipart message — attachments visible in raw view] — view raw

Hi Thomas,

Thanks for your suggestion.

On 17/10/2021 13:53, Thomas Schmitt wrote:
> If your suspicion is right, xev should show lots of such Key* events
> as soon as its receiver window gets the focus, without you pressing any
> key at the keyboard. In that case, end xev and look at the messages
> on the terminal window or in file  /tmp/xev.log .

Yup:

KeyPress event, serial 68, synthetic NO, window 0x6600001,
      root 0x238, subw 0x0, time 3095352, (168,-22), root:(1030,437),
      state 0x110, keycode 248 (keysym 0x0, NoSymbol), same_screen YES,
      XLookupString gives 0 bytes:
      XmbLookupString gives 0 bytes:
      XFilterEvent returns: False

Which sent me here:

https://forums.linuxmint.com/viewtopic.php?t=105326

In my case, there were multiple devices called "Cherry Keyboard", so I 
used the following to disable the one sending the spurious events:

Section "InputClass"
         Identifier "disable cherry key"
         MatchDevicePath "/dev/input/event4"
         Option "Ignore" "on"
EndSection

Thanks for the help!

Regards

Jeff

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

#241521

Hi,

Jeff wrote:
> KeyPress event, [...]
>       keycode 248

Seems to be considered a firmware bug of the keyboard which might become
repairable in the future:
  https://bbs.archlinux.org/viewtopic.php?id=267365


> https://forums.linuxmint.com/viewtopic.php?t=105326

Such old wisdom will probably fade away with the demise of X.
I wonder if the udev rule in above bbs.archlinux.org thread will survive
longer.


Have a nice day :)

Thomas

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

#241564

[Multipart message — attachments visible in raw view] — view raw

Hi Thomas,

On 19/10/2021 22:31, Thomas Schmitt wrote:
> Seems to be considered a firmware bug of the keyboard which might become
> repairable in the future:
>    https://bbs.archlinux.org/viewtopic.php?id=267365

Oh, yes. Even better. Worked a treat.

Thanks again

Jeff

[toc] | [prev] | [standalone]

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

csiph-web