[Bug 57547] New: All HIDRAW devices stop working after pressing extra button on Logitech G903 mouse
https://bugs.winehq.org/show_bug.cgi?id=57547
Bug ID: 57547 Summary: All HIDRAW devices stop working after pressing extra button on Logitech G903 mouse Product: Wine Version: 10.0-rc2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: hid Assignee: wine-bugs@winehq.org Reporter: dixonte+winehq@stc-networks.com Distribution: ---
Created attachment 77615 --> https://bugs.winehq.org/attachment.cgi?id=77615 WINEDEBUG=+hid,+plugplay,+dinput,+rawinput WINEPREIF=$HOME/Games/star-citizen /usr/lib/wine-staging-10.0_rc2/bin/wine control
I have my G903 configured such that pressing one of the extra buttons emulates pressing F14 on a keyboard. I have also built a foot pedal using a microcontroller that does the same thing. I use this for push-to-talk in Discord.
When I press the extra button on my mouse, this seems to cause an error in wine that stops all HIDRAW devices from working until I restart wineserver. Oddly and importantly, the foot pedal does not cause the same issue. (I'm vaguely aware this mouse is what Logitech calls 'HID++', so I wouldn't be surprised if they are doing something weird that is tripping wine up.)
I've attached a log of reproducing the issue by running 'wine control' with WINEDEBUG=+hid,+plugplay,+dinput,+rawinput
Now that I know how to do it I can reproduce the issue 100% of the time.
https://bugs.winehq.org/show_bug.cgi?id=57547
--- Comment #1 from T E Dixon dixonte+winehq@stc-networks.com --- Further testing shows pressing the right side back button on the G903 also causes this issue. This button hasn't been reconfigured to emulate a key.
https://bugs.winehq.org/show_bug.cgi?id=57547
--- Comment #2 from Rafał Mużyło galtgendo@o2.pl --- Odd that the output doesn't include a backtrace, even though a crash happens.
Though none of the channels show anything special about the crash...
https://bugs.winehq.org/show_bug.cgi?id=57547
--- Comment #3 from T E Dixon dixonte+winehq@stc-networks.com --- (In reply to Rafał Mużyło from comment #2)
Odd that the output doesn't include a backtrace, even though a crash happens.
Though none of the channels show anything special about the crash...
Is there anything else I can do to get you the info you need? Happy to apply patches to add extra debug output if need be.
https://bugs.winehq.org/show_bug.cgi?id=57547
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |hardware
https://bugs.winehq.org/show_bug.cgi?id=57547
Bernhard Übelacker bernhardu@mailbox.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu@mailbox.org
--- Comment #4 from Bernhard Übelacker bernhardu@mailbox.org --- (In reply to T E Dixon from comment #0)
... WINEPREIF=...
Is this just a copy and paste error in this bug report? Wine might not operate on the expected prefix?
(In reply to Rafał Mużyło from comment #2)
Odd that the output doesn't include a backtrace, even though a crash happens. Though none of the channels show anything special about the crash...
(In reply to T E Dixon from comment #3)
Is there anything else I can do to get you the info you need? Happy to apply patches to add extra debug output if need be.
If the crash happens in winedevice.exe the crash dialog is currently suppressed for some reason. See below patch to remove this special handling from winedevice.exe, maybe with it applied the expected crash dialog is shown?
https://gitlab.winehq.org/bernhardu/wine/-/commit/63036db6876eb57b0c528ed0b5...
Would be an improvement to make this visible via a debug channel e.g. "winedevicecrash"?
https://bugs.winehq.org/show_bug.cgi?id=57547
--- Comment #5 from T E Dixon dixonte+winehq@stc-networks.com --- (In reply to Bernhard Übelacker from comment #4)
(In reply to T E Dixon from comment #0)
... WINEPREIF=...
Is this just a copy and paste error in this bug report? Wine might not operate on the expected prefix?
Ah, the WINEPREIF was a typo, yes. I just verified the same thing happens when I correct it to WINEPREFIX though. Attaching a log with that corrected, just in case.
(In reply to Bernhard Übelacker from comment #4)
If the crash happens in winedevice.exe the crash dialog is currently suppressed for some reason. See below patch to remove this special handling from winedevice.exe, maybe with it applied the expected crash dialog is shown?
https://gitlab.winehq.org/bernhardu/wine/-/commit/ 63036db6876eb57b0c528ed0b52807680ca2a697
I'll perform another test with this patch applied ASAP.
https://bugs.winehq.org/show_bug.cgi?id=57547
T E Dixon dixonte+winehq@stc-networks.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #77615|0 |1 is obsolete| |
--- Comment #6 from T E Dixon dixonte+winehq@stc-networks.com --- Created attachment 77644 --> https://bugs.winehq.org/attachment.cgi?id=77644 WINEDEBUG=+hid,+plugplay,+dinput,+rawinput WINEPREFIX=$HOME/Games/star-citizen /usr/lib/wine-staging-10.0_rc2/bin/wine control
Fixed typo in WINEPREFIX envvar.
https://bugs.winehq.org/show_bug.cgi?id=57547
--- Comment #7 from T E Dixon dixonte+winehq@stc-networks.com --- Created attachment 77645 --> https://bugs.winehq.org/attachment.cgi?id=77645 winedevice.exe stacktrace
Reproducing the issue with the supplied patch produces a dialogue with this text. Unfortunately the dialogue cannot be interacted with beyond resizing it, so I cannot scroll down for more details, select text, or click the 'Save as...' button. I hope this image provides enough info.
https://bugs.winehq.org/show_bug.cgi?id=57547
--- Comment #8 from Bernhard Übelacker bernhardu@mailbox.org --- (In reply to T E Dixon from comment #7)
Reproducing the issue with the supplied patch produces a dialogue with this text. Unfortunately the dialogue cannot be interacted with beyond resizing it, so I cannot scroll down for more details, select text, or click the 'Save as...' button. I hope this image provides enough info.
Thank you for working on this, but unfortunately the callstack has no debug symbols.
Maybe you can recompile with such flags to configure: CFLAGS="-Og" CROSSCFLAGS="-Og" or CFLAGS="-g" CROSSCFLAGS="-g"
https://gitlab.winehq.org/wine/wine/-/wikis/Building-Wine#compiler-optimizat...
Because this issue is triggered by some interactive action, you might be able to attach a winedbg to the later failing winedevice.exe. Unfortunately there are three of it, in my environment that one with hidclass.sys loaded is in the "middle".
https://gitlab.winehq.org/wine/wine/-/wikis/Commands/winedbg
Beyond this there is the possibility to add statements like this through the source. TRACE("%d\n", __LINE__); A starting point could be the big loop in hid_device_thread.
https://bugs.winehq.org/show_bug.cgi?id=57547
--- Comment #9 from T E Dixon dixonte+winehq@stc-networks.com --- Created attachment 77650 --> https://bugs.winehq.org/attachment.cgi?id=77650 1st attempt to use winedbg
(In reply to Bernhard Übelacker from comment #8)
Maybe you can recompile with such flags to configure: CFLAGS="-Og" CROSSCFLAGS="-Og" or CFLAGS="-g" CROSSCFLAGS="-g"
https://gitlab.winehq.org/wine/wine/-/wikis/Building-Wine#compiler- optimizations--call-stacks
Because this issue is triggered by some interactive action, you might be able to attach a winedbg to the later failing winedevice.exe. Unfortunately there are three of it, in my environment that one with hidclass.sys loaded is in the "middle".
https://gitlab.winehq.org/wine/wine/-/wikis/Commands/winedbg
Okay, so I rebuilt with this: CFLAGS="-Og -fno-omit-frame-pointer" CROSSCFLAGS="-Og -fno-omit-frame-pointer"
I then tried reproducing the issue without the debugger. This time when the error dialogue pops up and I click Show Details, I get an empty dialogue box which instantly disappears.
I then tried using winedbg. This is new to me so I'm not sure if I'm doing it right. On my system there were either 1 or 2 winedevice.exe processes. I have tried attaching to both, and the debugger will stop the error dialogue from popping up if attached to the first one, so I assume that is the correct one.
This attachment is a log of the output from winedbg. I made sure to use the same WINEPREFIX for it as the 'wine control' command. Looks like I need to do something else to get the debug symbols?
https://bugs.winehq.org/show_bug.cgi?id=57547
--- Comment #10 from T E Dixon dixonte+winehq@stc-networks.com --- Just in case, I created a new prefix using this version of wine. Same issue.
https://bugs.winehq.org/show_bug.cgi?id=57547
--- Comment #11 from Bernhard Übelacker bernhardu@mailbox.org --- (In reply to T E Dixon from comment #7)
Reproducing the issue with the supplied patch produces a dialogue with this text. Unfortunately the dialogue cannot be interacted with beyond resizing it, so I cannot scroll down for more details, select text, or click the 'Save as...' button. I hope this image provides enough info.
Interacting with the crash dialog probably also relies on the crashed winedevice/hidclass.sys process.
https://bugs.winehq.org/show_bug.cgi?id=57547
--- Comment #12 from T E Dixon dixonte+winehq@stc-networks.com --- Any suggestions what I might be doing wrong regarding the lack of callstack details even after recompiling with the CFLAGS?
I'll try adding trace statements but I'm not at this level with my C/C++ knowledge.
https://bugs.winehq.org/show_bug.cgi?id=57547
--- Comment #13 from T E Dixon dixonte+winehq@stc-networks.com --- In my efforts to try and get a build that has correct debugging symbols, I tried getting wine from git manually and compiling it via the following:
./configure CFLAGS="-Og" CROSSCFLAGS="-Og" make
And then just running `WINEPREFIX=$HOME/winetest ./wine control`
This apparently created a 32 bit version of wine that was incompatible with the 64 bit prefix I had created in $HOME/winetest with earlier testing. I wiped the directory and tried again. I was UNABLE to reproduce the error.
I then tried running `WINEPREFIX=$HOME/winetest/ /usr/lib/wine-staging-10.0_rc2/bin/wine control`, and was again unable to reproduce the error.
Wiping $HOME/winetest and retrying 10.0_rc2 led to me being able to reproduce the error. However I am still unable to get useful output from the error dialogue box or from winedbg.
I'll keep trying, but thought this might be useful info.
https://bugs.winehq.org/show_bug.cgi?id=57547
--- Comment #14 from T E Dixon dixonte+winehq@stc-networks.com --- I ended up copying the configure parameters from the gentoo ebuild and adding the CFLAGS to it:
./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --datarootdir=/usr/share --docdir=/usr/share/doc/wine-staging-9999 --htmldir=/usr/share/doc/wine-staging-9999/html --prefix=/usr/lib/wine-staging-9999 --datadir=/usr/share/wine-staging-9999 --includedir=/usr/include/wine-staging-9999 --libdir=/usr/lib/wine-staging-9999 --mandir=/usr/share/wine-staging-9999/man --enable-mshtml --enable-mscoree --disable-tests --with-x --with-alsa --without-capi --with-cups --without-ffmpeg --with-fontconfig --without-gphoto --with-gstreamer --without-gssapi --without-krb5 --with-mingw --without-netapi --with-gettext --without-opencl --with-opengl --without-osmesa --without-oss --without-pcap --with-pulse --without-sane --with-sdl --without-pcsclite --with-gnutls --with-freetype --with-udev --with-dbus --with-unwind --with-usb --without-v4l2 --with-vulkan --with-wayland --with-xcomposite --without-xinerama ac_cv_lib_soname_odbc= ac_cv_prog_x86_64_CC=x86_64-w64-mingw32-gcc ac_cv_prog_i386_CC=i686-w64-mingw32-gcc CFLAGS="-Og" CROSSCFLAGS=-Og --enable-win64
With this build I'm able to run wine64 and winedbg from the build directory. However the windbg output is still the same unhelpful page fault on write access in 64-bit code. I'm unsure how to proceed from here.
https://bugs.winehq.org/show_bug.cgi?id=57547
--- Comment #15 from Bernhard Übelacker bernhardu@mailbox.org ---
Does this crash in winedevice happen just with wine-staging, or are your own builds regular wine?
With "--enable-win64" you were building just the 64-bit side. The build ommitting this was therefore just a 32-bit one. The "Building Wine" describes how to configure to tie both together.
But if the error was already visible either 32-bit or 64-bit it could be still sufficient to further debug.
You seem to have a few input devices connected - maybe you could disconnect some, so there is less output, and if just the mouse (and keyboard) is involved chances get better someone can replicate the crash.
(In reply to T E Dixon from comment #14)
With this build I'm able to run wine64 and winedbg from the build directory. However the windbg output is still the same unhelpful page fault on write access in 64-bit code. I'm unsure how to proceed from here.
Does the output below "Backtrace:" still show only "hidclass.sys", or has it changed to a function name and maybe a line number?
https://bugs.winehq.org/show_bug.cgi?id=57547
--- Comment #16 from T E Dixon dixonte+winehq@stc-networks.com --- (In reply to Bernhard Übelacker from comment #15)
Does this crash in winedevice happen just with wine-staging, or are your own builds regular wine?
My own builds are regular wine.
With "--enable-win64" you were building just the 64-bit side. The build ommitting this was therefore just a 32-bit one. The "Building Wine" describes how to configure to tie both together.
That makes sense. So it seems the error only occurs in 64-bit builds, or with a 64-bit prefix at least.
You seem to have a few input devices connected - maybe you could disconnect some, so there is less output, and if just the mouse (and keyboard) is involved chances get better someone can replicate the crash.
I'll try that later today.
(In reply to T E Dixon from comment #14)
With this build I'm able to run wine64 and winedbg from the build directory. However the windbg output is still the same unhelpful page fault on write access in 64-bit code. I'm unsure how to proceed from here.
Does the output below "Backtrace:" still show only "hidclass.sys", or has it changed to a function name and maybe a line number?
If CFLAGS=-0g, regardless of if it was built by portage or by myself, the output is basically only what you can see in https://bugs.winehq.org/attachment.cgi?id=77650
https://bugs.winehq.org/show_bug.cgi?id=57547
--- Comment #17 from T E Dixon dixonte+winehq@stc-networks.com --- CFLAGS="-Og" rather, sorry.
https://bugs.winehq.org/show_bug.cgi?id=57547
--- Comment #18 from Bernhard Übelacker bernhardu@mailbox.org --- (In reply to T E Dixon from comment #16)
If CFLAGS=-0g, regardless of if it was built by portage or by myself, the output is basically only what you can see in https://bugs.winehq.org/attachment.cgi?id=77650
(In reply to T E Dixon from comment #17)
CFLAGS="-Og" rather, sorry.
Thanks for your patience, but I was currently not about the manual winedbg output, but has the "automatic" crash dialog content changed, like you attached as picture before? (Which was not interactively operatable?) (Especially below the "Backtrace:")
https://bugs.winehq.org/show_bug.cgi?id=57547
--- Comment #19 from T E Dixon dixonte+winehq@stc-networks.com --- (In reply to Bernhard Übelacker from comment #18)
(In reply to T E Dixon from comment #16)
If CFLAGS=-0g, regardless of if it was built by portage or by myself, the output is basically only what you can see in https://bugs.winehq.org/attachment.cgi?id=77650
(In reply to T E Dixon from comment #17)
CFLAGS="-Og" rather, sorry.
Thanks for your patience, but I was currently not about the manual winedbg output, but has the "automatic" crash dialog content changed, like you attached as picture before? (Which was not interactively operatable?) (Especially below the "Backtrace:")
Ah, I see. Sadly that dialogue disappears the instant it appears with -Og, but it appears empty, maybe a single line but I could be imagining it; it's really quick.
https://bugs.winehq.org/show_bug.cgi?id=57547
--- Comment #20 from T E Dixon dixonte+winehq@stc-networks.com --- (In reply to Bernhard Übelacker from comment #15)
You seem to have a few input devices connected - maybe you could disconnect some, so there is less output, and if just the mouse (and keyboard) is involved chances get better someone can replicate the crash.
Tonight I tried disconnecting all input devices other than mouse and keyboard, and the same issue happens. I've tried this with the hand-compiled wine and the git build from portage.
Also, more oddness; for some reason now with my hand-compiled wine, the error dialogue box does not appear even though I've manually edited crashdlg.c and completely deleted the prefix directory before trying the newly compiled wine64. I suspect maybe this is somehow because I'm not taking the extra steps to build wow64? But then neither is portage, according to the use flags.
Using wine-staging as built by portage from git with the patch applied, I get the dialogue. I might stick to letting portage handle the build from now on, but will test if a git build of wine-vanilla has the issue next.
https://bugs.winehq.org/show_bug.cgi?id=57547
--- Comment #21 from T E Dixon dixonte+winehq@stc-networks.com --- Fresh build of both wine-vanilla and wine-staging, from git, with the patch applied to each, CFLAGS=-Og CROSSCFLAGS="-Og".
Tested the following: rm -rf ~/winetest WINEPREFIX=$HOME/winetest /usr/lib/wine-vanilla-9999/bin/wine control rm -rf ~/winetest WINEPREFIX=$HOME/winetest /usr/lib/wine-vanilla-9999/bin/wine64 control rm -rf ~/winetest WINEPREFIX=$HOME/winetest /usr/lib/wine-staging-9999/bin/wine control rm -rf ~/winetest WINEPREFIX=$HOME/winetest /usr/lib/wine-staging-9999/bin/wine64 control
Error is reproducible in all, but the crash dialogue only shows in wine-staging. And in both cases when I click the details button, the details dialogue pops up then instantly vanishes. I did manage to catch a screenshot of it where I can see it says "Loading detailed information, please wait...", but I don't feel that's worth uploading. Have it saved in case you want to see it, though.
winedbg output: Unhandled exception: page fault on write access to 0x0000000102af0fb8 in 64-bit code (0x006fffffb89c3d). 0168:fixme:dbghelp:elf_search_auxv can't find symbol in module
Exception c0000005
https://bugs.winehq.org/show_bug.cgi?id=57547
Rémi Bernon rbernon@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon@codeweavers.com
--- Comment #22 from Rémi Bernon rbernon@codeweavers.com --- The issue is likely that Wine got access to mouse and keyboard devices, through hidraw or evdev. This is possibly the case if you have added your user to the input group, because you run wine as root, or because of some unrestricted udev rules.
We don't support mouse and keyboard devices in winebus and in the HID stack at the moment, and they are known to crash somewhere in the stack.
You should also probably not give access of such devices directly to user-space applications, and only game controller are usually considered safe to access (and they are openly accessible through evdev, to the contrary to the mouse and keyboard evdev devices which are usually exclusively opened by the display server on startup).
https://bugs.winehq.org/show_bug.cgi?id=57547
--- Comment #23 from T E Dixon dixonte+winehq@stc-networks.com --- (In reply to Rémi Bernon from comment #22)
The issue is likely that Wine got access to mouse and keyboard devices, through hidraw or evdev. This is possibly the case if you have added your user to the input group, because you run wine as root, or because of some unrestricted udev rules.
This checks out. I'm not sure why but all the hidraw devices related to my G903 and its charging mat -- and there are a bunch of them -- are set RW for my user. I'll see if I can figure out why and check if this issue goes away. It's not because of udev rules, but perhaps it's Solaar or Piper...
Anyway, thanks. If fixing those permissions fixes this issue I'll let you know.
https://bugs.winehq.org/show_bug.cgi?id=57547
--- Comment #24 from T E Dixon dixonte+winehq@stc-networks.com --- Looks like it was Solaar, it puts a file in /usr/lib/udev/rules.d/ called 42-logitech-unify-permissions.rules which adds TAG+="uaccess" and GROUP+="plugdev" to anything Logitech. I can probably live without this, but I'm wondering if there's a way to block wine from touching these devices without removing it?
https://bugs.winehq.org/show_bug.cgi?id=57547
--- Comment #25 from Rémi Bernon rbernon@codeweavers.com --- Not without a patch, we open every device that's accessible and try to expose it to the Windows world.
Of course one could argue that we should handle mouse and keyboard correctly, and that may be true and we could perhaps fix it at some point, but that's not usually an issue because they shouldn't be accessible, and crashing is also some sort of safeguard (a brittle one in many ways, yes).
https://bugs.winehq.org/show_bug.cgi?id=57547
--- Comment #26 from T E Dixon dixonte+winehq@stc-networks.com --- (In reply to Rémi Bernon from comment #25)
Not without a patch, we open every device that's accessible and try to expose it to the Windows world.
Of course one could argue that we should handle mouse and keyboard correctly, and that may be true and we could perhaps fix it at some point, but that's not usually an issue because they shouldn't be accessible, and crashing is also some sort of safeguard (a brittle one in many ways, yes).
That's fair enough. I do still think this should be looked at at some point, since the issue does not present on 32-bit wine but does on 64-bit. But I think my issue is solved, or at least worked around for now.
https://bugs.winehq.org/show_bug.cgi?id=57547
--- Comment #27 from T E Dixon dixonte+winehq@stc-networks.com --- Created attachment 77688 --> https://bugs.winehq.org/attachment.cgi?id=77688 Adds IgnoreHidraw registry string
Adds a multi-line string registry entry under the winbus service named 'IgnoreHidraw', add VID:PID values to this list to prevent them from being exposed as hidraw devices.
I would like to make this an env var, but I'm testing the waters with this.
https://bugs.winehq.org/show_bug.cgi?id=57547
--- Comment #28 from T E Dixon dixonte+winehq@stc-networks.com --- In case you're wondering 'why?', I want to keep using Solaar to configure my mouse, and the package contains a udev rule file that exposes the hidraw nodes for these devices so that it can do its work. I could remember to delete that file every time I update it, but that still leaves me having to run Solaar as root.
So I'd like to propose the above patch to allow wine to ignore problem hidraw devices, via a registry entry under the winebus service.
https://bugs.winehq.org/show_bug.cgi?id=57547
--- Comment #29 from Rafał Mużyło galtgendo@o2.pl --- You could, you know, bug Solaar upstream (whatever that is) to ship a sane udev rule instead.
After all, there's plenty values udev can access to use them as a condition.
https://bugs.winehq.org/show_bug.cgi?id=57547
--- Comment #30 from T E Dixon dixonte+winehq@stc-networks.com --- (In reply to Rafał Mużyło from comment #29)
You could, you know, bug Solaar upstream (whatever that is) to ship a sane udev rule instead.
After all, there's plenty values udev can access to use them as a condition.
I'll see if I can write a rules file that allows Solaar to work but doesn't present the device to wine. I'm not sure if that'll be possible, though. The whole point of Solaar is that it can program the mouse's buttons so I assume it needs to write to hidraw.
https://bugs.winehq.org/show_bug.cgi?id=57547
T E Dixon dixonte+winehq@stc-networks.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|10.0-rc2 |10.4
-
WineHQ Bugzilla