How can I debug X11 missing mouse ButtonRelease events that are present in usbmon?
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
A few days ago, my mouse button releases began sometimes not being recognised when I release two of the buttons simultaneously. The logical state of one button therefore gets stuck on "down", causing annoying unintended actions until I press it again to reset it.
I could reproduce the issue monitoring mouse events in xev (output sometimes doesn't show expected key release events). I could not reproduce the issue by monitoring events in /sys/kernel/debug/usb/usbmon (output is always consistent with reality).
So the fault clearly lies with a software component at some abstraction below X11, but above USB.
What could be causing this? How could I narrow this down further?
x11 mouse debugging events
asked Nov 9 '17 at 22:03
Anko
2,62412140
add a comment |Â
up vote
0
down vote
favorite
A few days ago, my mouse button releases began sometimes not being recognised when I release two of the buttons simultaneously. The logical state of one button therefore gets stuck on "down", causing annoying unintended actions until I press it again to reset it.
I could reproduce the issue monitoring mouse events in xev (output sometimes doesn't show expected key release events). I could not reproduce the issue by monitoring events in /sys/kernel/debug/usb/usbmon (output is always consistent with reality).
So the fault clearly lies with a software component at some abstraction below X11, but above USB.
What could be causing this? How could I narrow this down further?
x11 mouse debugging events
asked Nov 9 '17 at 22:03
Anko
2,62412140
For reference, I've reported this upstream on the libinput bug tracker here. I originally noticed this way downstream while playing Dota 2, on which bugtracker I filed this report before self-closing it when I realised the problem is deeper.
– Anko
Nov 10 '17 at 18:31
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
A few days ago, my mouse button releases began sometimes not being recognised when I release two of the buttons simultaneously. The logical state of one button therefore gets stuck on "down", causing annoying unintended actions until I press it again to reset it.
I could reproduce the issue monitoring mouse events in xev (output sometimes doesn't show expected key release events). I could not reproduce the issue by monitoring events in /sys/kernel/debug/usb/usbmon (output is always consistent with reality).
So the fault clearly lies with a software component at some abstraction below X11, but above USB.
What could be causing this? How could I narrow this down further?
x11 mouse debugging events
asked Nov 9 '17 at 22:03
Anko
2,62412140
A few days ago, my mouse button releases began sometimes not being recognised when I release two of the buttons simultaneously. The logical state of one button therefore gets stuck on "down", causing annoying unintended actions until I press it again to reset it.
I could reproduce the issue monitoring mouse events in xev (output sometimes doesn't show expected key release events). I could not reproduce the issue by monitoring events in /sys/kernel/debug/usb/usbmon (output is always consistent with reality).
So the fault clearly lies with a software component at some abstraction below X11, but above USB.
What could be causing this? How could I narrow this down further?
x11 mouse debugging events
asked Nov 9 '17 at 22:03
Anko
2,62412140
asked Nov 9 '17 at 22:03
Anko
2,62412140
asked Nov 9 '17 at 22:03
Anko
2,62412140
asked Nov 9 '17 at 22:03
Anko
2,62412140
2,62412140
For reference, I've reported this upstream on the libinput bug tracker here. I originally noticed this way downstream while playing Dota 2, on which bugtracker I filed this report before self-closing it when I realised the problem is deeper.
– Anko
Nov 10 '17 at 18:31
add a comment |Â
For reference, I've reported this upstream on the libinput bug tracker here. I originally noticed this way downstream while playing Dota 2, on which bugtracker I filed this report before self-closing it when I realised the problem is deeper.
– Anko
Nov 10 '17 at 18:31
For reference, I've reported this upstream on the libinput bug tracker here. I originally noticed this way downstream while playing Dota 2, on which bugtracker I filed this report before self-closing it when I realised the problem is deeper.
– Anko
Nov 10 '17 at 18:31
For reference, I've reported this upstream on the libinput bug tracker here. I originally noticed this way downstream while playing Dota 2, on which bugtracker I filed this report before self-closing it when I realised the problem is deeper.
– Anko
Nov 10 '17 at 18:31
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
The levels between USB events and X events are:
Unless your mouse is special and has its own driver, it's very likely a HID device. Find the corresponding
hidrawdevice (checkdmesg), and verify you get events there. USB to HID translation is done by the kernel.All input events leave the kernel through the input-layer, the corresponding devices are in
/dev/input. Runevtestas root, select your mouse, see if you get events. Translation from HID events to input events is done by the kernel.X automatically loads drivers for all input devices, in most cases the
evdevdriver. See/var/log/Xorg.0.logabout which driver(s) get loaded. These drivers translate input events to X events.
answered Nov 10 '17 at 7:44
dirkt
14.2k2931
i thinklibinputis replacingevdevin X these days.
– quixotic
Nov 10 '17 at 9:37
@quixotic:libinputis for Wayland whatevdevis for X. So unless you are using an X emulation under Wayland instead of "real" X, you are usingevdev.
– dirkt
Nov 10 '17 at 12:32
1
there's a wrapper driver for Xorg as well. on Arch this is provided by thexf86-input-libinputpackage. see wiki.archlinux.org/index.php/Libinput and github.com/freedesktop/xorg-xf86-input-libinput
– quixotic
Nov 10 '17 at 13:09
the stack diagrams at en.wikipedia.org/wiki/Evdev point out the distinction betweenevdevthe kernel driver andxf86-input-evdevthe Xorg driver:kernel > libevdev > xf86-input-evdev > Xserver > Xclientvskernel > libevdev > libinput > xf86-input-libinput > Xserver > Xclient. as you point out, which driver is loaded and used should show up in the Xorg logfile.
– quixotic
Nov 10 '17 at 13:17
1
@quixotic @dirkt Thank you both for your knowledge! Results: Myevtestoutput looks correct even when the issue occurs, so the kernel and libevdev must be innocent. I don't have xf86-input-evdev installed, so the correct route up must be through libinput → xf86-input-libinput → X11. The logging tool for libinput is apparentlylibinput debug-events, where the problem finally appears in the logs! That narrows it down to libinput. I'll contact the developers.
– Anko
Nov 10 '17 at 14:44
 |Â
show 1 more comment
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
The levels between USB events and X events are:
Unless your mouse is special and has its own driver, it's very likely a HID device. Find the corresponding
hidrawdevice (checkdmesg), and verify you get events there. USB to HID translation is done by the kernel.All input events leave the kernel through the input-layer, the corresponding devices are in
/dev/input. Runevtestas root, select your mouse, see if you get events. Translation from HID events to input events is done by the kernel.X automatically loads drivers for all input devices, in most cases the
evdevdriver. See/var/log/Xorg.0.logabout which driver(s) get loaded. These drivers translate input events to X events.
answered Nov 10 '17 at 7:44
dirkt
14.2k2931
i thinklibinputis replacingevdevin X these days.
– quixotic
Nov 10 '17 at 9:37
@quixotic:libinputis for Wayland whatevdevis for X. So unless you are using an X emulation under Wayland instead of "real" X, you are usingevdev.
– dirkt
Nov 10 '17 at 12:32
1
there's a wrapper driver for Xorg as well. on Arch this is provided by thexf86-input-libinputpackage. see wiki.archlinux.org/index.php/Libinput and github.com/freedesktop/xorg-xf86-input-libinput
– quixotic
Nov 10 '17 at 13:09
the stack diagrams at en.wikipedia.org/wiki/Evdev point out the distinction betweenevdevthe kernel driver andxf86-input-evdevthe Xorg driver:kernel > libevdev > xf86-input-evdev > Xserver > Xclientvskernel > libevdev > libinput > xf86-input-libinput > Xserver > Xclient. as you point out, which driver is loaded and used should show up in the Xorg logfile.
– quixotic
Nov 10 '17 at 13:17
1
@quixotic @dirkt Thank you both for your knowledge! Results: Myevtestoutput looks correct even when the issue occurs, so the kernel and libevdev must be innocent. I don't have xf86-input-evdev installed, so the correct route up must be through libinput → xf86-input-libinput → X11. The logging tool for libinput is apparentlylibinput debug-events, where the problem finally appears in the logs! That narrows it down to libinput. I'll contact the developers.
– Anko
Nov 10 '17 at 14:44
 |Â
show 1 more comment
up vote
2
down vote
accepted
The levels between USB events and X events are:
Unless your mouse is special and has its own driver, it's very likely a HID device. Find the corresponding
hidrawdevice (checkdmesg), and verify you get events there. USB to HID translation is done by the kernel.All input events leave the kernel through the input-layer, the corresponding devices are in
/dev/input. Runevtestas root, select your mouse, see if you get events. Translation from HID events to input events is done by the kernel.X automatically loads drivers for all input devices, in most cases the
evdevdriver. See/var/log/Xorg.0.logabout which driver(s) get loaded. These drivers translate input events to X events.
answered Nov 10 '17 at 7:44
dirkt
14.2k2931
i thinklibinputis replacingevdevin X these days.
– quixotic
Nov 10 '17 at 9:37
@quixotic:libinputis for Wayland whatevdevis for X. So unless you are using an X emulation under Wayland instead of "real" X, you are usingevdev.
– dirkt
Nov 10 '17 at 12:32
1
there's a wrapper driver for Xorg as well. on Arch this is provided by thexf86-input-libinputpackage. see wiki.archlinux.org/index.php/Libinput and github.com/freedesktop/xorg-xf86-input-libinput
– quixotic
Nov 10 '17 at 13:09
the stack diagrams at en.wikipedia.org/wiki/Evdev point out the distinction betweenevdevthe kernel driver andxf86-input-evdevthe Xorg driver:kernel > libevdev > xf86-input-evdev > Xserver > Xclientvskernel > libevdev > libinput > xf86-input-libinput > Xserver > Xclient. as you point out, which driver is loaded and used should show up in the Xorg logfile.
– quixotic
Nov 10 '17 at 13:17
1
@quixotic @dirkt Thank you both for your knowledge! Results: Myevtestoutput looks correct even when the issue occurs, so the kernel and libevdev must be innocent. I don't have xf86-input-evdev installed, so the correct route up must be through libinput → xf86-input-libinput → X11. The logging tool for libinput is apparentlylibinput debug-events, where the problem finally appears in the logs! That narrows it down to libinput. I'll contact the developers.
– Anko
Nov 10 '17 at 14:44
 |Â
show 1 more comment
up vote
2
down vote
accepted
up vote
2
down vote
accepted
The levels between USB events and X events are:
Unless your mouse is special and has its own driver, it's very likely a HID device. Find the corresponding
hidrawdevice (checkdmesg), and verify you get events there. USB to HID translation is done by the kernel.All input events leave the kernel through the input-layer, the corresponding devices are in
/dev/input. Runevtestas root, select your mouse, see if you get events. Translation from HID events to input events is done by the kernel.X automatically loads drivers for all input devices, in most cases the
evdevdriver. See/var/log/Xorg.0.logabout which driver(s) get loaded. These drivers translate input events to X events.
answered Nov 10 '17 at 7:44
dirkt
14.2k2931
The levels between USB events and X events are:
Unless your mouse is special and has its own driver, it's very likely a HID device. Find the corresponding
hidrawdevice (checkdmesg), and verify you get events there. USB to HID translation is done by the kernel.All input events leave the kernel through the input-layer, the corresponding devices are in
/dev/input. Runevtestas root, select your mouse, see if you get events. Translation from HID events to input events is done by the kernel.X automatically loads drivers for all input devices, in most cases the
evdevdriver. See/var/log/Xorg.0.logabout which driver(s) get loaded. These drivers translate input events to X events.
answered Nov 10 '17 at 7:44
dirkt
14.2k2931
answered Nov 10 '17 at 7:44
dirkt
14.2k2931
answered Nov 10 '17 at 7:44
dirkt
14.2k2931
answered Nov 10 '17 at 7:44
dirkt
14.2k2931
14.2k2931
i thinklibinputis replacingevdevin X these days.
– quixotic
Nov 10 '17 at 9:37
@quixotic:libinputis for Wayland whatevdevis for X. So unless you are using an X emulation under Wayland instead of "real" X, you are usingevdev.
– dirkt
Nov 10 '17 at 12:32
1
there's a wrapper driver for Xorg as well. on Arch this is provided by thexf86-input-libinputpackage. see wiki.archlinux.org/index.php/Libinput and github.com/freedesktop/xorg-xf86-input-libinput
– quixotic
Nov 10 '17 at 13:09
the stack diagrams at en.wikipedia.org/wiki/Evdev point out the distinction betweenevdevthe kernel driver andxf86-input-evdevthe Xorg driver:kernel > libevdev > xf86-input-evdev > Xserver > Xclientvskernel > libevdev > libinput > xf86-input-libinput > Xserver > Xclient. as you point out, which driver is loaded and used should show up in the Xorg logfile.
– quixotic
Nov 10 '17 at 13:17
1
@quixotic @dirkt Thank you both for your knowledge! Results: Myevtestoutput looks correct even when the issue occurs, so the kernel and libevdev must be innocent. I don't have xf86-input-evdev installed, so the correct route up must be through libinput → xf86-input-libinput → X11. The logging tool for libinput is apparentlylibinput debug-events, where the problem finally appears in the logs! That narrows it down to libinput. I'll contact the developers.
– Anko
Nov 10 '17 at 14:44
 |Â
show 1 more comment
i thinklibinputis replacingevdevin X these days.
– quixotic
Nov 10 '17 at 9:37
@quixotic:libinputis for Wayland whatevdevis for X. So unless you are using an X emulation under Wayland instead of "real" X, you are usingevdev.
– dirkt
Nov 10 '17 at 12:32
1
there's a wrapper driver for Xorg as well. on Arch this is provided by thexf86-input-libinputpackage. see wiki.archlinux.org/index.php/Libinput and github.com/freedesktop/xorg-xf86-input-libinput
– quixotic
Nov 10 '17 at 13:09
the stack diagrams at en.wikipedia.org/wiki/Evdev point out the distinction betweenevdevthe kernel driver andxf86-input-evdevthe Xorg driver:kernel > libevdev > xf86-input-evdev > Xserver > Xclientvskernel > libevdev > libinput > xf86-input-libinput > Xserver > Xclient. as you point out, which driver is loaded and used should show up in the Xorg logfile.
– quixotic
Nov 10 '17 at 13:17
1
@quixotic @dirkt Thank you both for your knowledge! Results: Myevtestoutput looks correct even when the issue occurs, so the kernel and libevdev must be innocent. I don't have xf86-input-evdev installed, so the correct route up must be through libinput → xf86-input-libinput → X11. The logging tool for libinput is apparentlylibinput debug-events, where the problem finally appears in the logs! That narrows it down to libinput. I'll contact the developers.
– Anko
Nov 10 '17 at 14:44
i think
libinput is replacing evdev in X these days.– quixotic
Nov 10 '17 at 9:37
i think
libinput is replacing evdev in X these days.– quixotic
Nov 10 '17 at 9:37
@quixotic:
libinput is for Wayland what evdev is for X. So unless you are using an X emulation under Wayland instead of "real" X, you are using evdev.– dirkt
Nov 10 '17 at 12:32
@quixotic:
libinput is for Wayland what evdev is for X. So unless you are using an X emulation under Wayland instead of "real" X, you are using evdev.– dirkt
Nov 10 '17 at 12:32
1
1
there's a wrapper driver for Xorg as well. on Arch this is provided by the
xf86-input-libinput package. see wiki.archlinux.org/index.php/Libinput and github.com/freedesktop/xorg-xf86-input-libinput– quixotic
Nov 10 '17 at 13:09
there's a wrapper driver for Xorg as well. on Arch this is provided by the
xf86-input-libinput package. see wiki.archlinux.org/index.php/Libinput and github.com/freedesktop/xorg-xf86-input-libinput– quixotic
Nov 10 '17 at 13:09
the stack diagrams at en.wikipedia.org/wiki/Evdev point out the distinction between
evdev the kernel driver and xf86-input-evdev the Xorg driver: kernel > libevdev > xf86-input-evdev > Xserver > Xclient vs kernel > libevdev > libinput > xf86-input-libinput > Xserver > Xclient. as you point out, which driver is loaded and used should show up in the Xorg logfile.– quixotic
Nov 10 '17 at 13:17
the stack diagrams at en.wikipedia.org/wiki/Evdev point out the distinction between
evdev the kernel driver and xf86-input-evdev the Xorg driver: kernel > libevdev > xf86-input-evdev > Xserver > Xclient vs kernel > libevdev > libinput > xf86-input-libinput > Xserver > Xclient. as you point out, which driver is loaded and used should show up in the Xorg logfile.– quixotic
Nov 10 '17 at 13:17
1
1
@quixotic @dirkt Thank you both for your knowledge! Results: My
evtest output looks correct even when the issue occurs, so the kernel and libevdev must be innocent. I don't have xf86-input-evdev installed, so the correct route up must be through libinput → xf86-input-libinput → X11. The logging tool for libinput is apparently libinput debug-events, where the problem finally appears in the logs! That narrows it down to libinput. I'll contact the developers.– Anko
Nov 10 '17 at 14:44
@quixotic @dirkt Thank you both for your knowledge! Results: My
evtest output looks correct even when the issue occurs, so the kernel and libevdev must be innocent. I don't have xf86-input-evdev installed, so the correct route up must be through libinput → xf86-input-libinput → X11. The logging tool for libinput is apparently libinput debug-events, where the problem finally appears in the logs! That narrows it down to libinput. I'll contact the developers.– Anko
Nov 10 '17 at 14:44
 |Â
show 1 more comment
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f403616%2fhow-can-i-debug-x11-missing-mouse-buttonrelease-events-that-are-present-in-usbmo%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
For reference, I've reported this upstream on the libinput bug tracker here. I originally noticed this way downstream while playing Dota 2, on which bugtracker I filed this report before self-closing it when I realised the problem is deeper.
– Anko
Nov 10 '17 at 18:31