[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(a)winehq.org Reporter: dixonte+winehq(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 --- Comment #1 from T E Dixon <dixonte+winehq(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 --- Comment #2 from Rafał Mużyło <galtgendo(a)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... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 --- Comment #3 from T E Dixon <dixonte+winehq(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |hardware -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 Bernhard Übelacker <bernhardu(a)mailbox.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu(a)mailbox.org --- Comment #4 from Bernhard Übelacker <bernhardu(a)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"? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 --- Comment #5 from T E Dixon <dixonte+winehq(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 T E Dixon <dixonte+winehq(a)stc-networks.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #77615|0 |1 is obsolete| | --- Comment #6 from T E Dixon <dixonte+winehq(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 --- Comment #7 from T E Dixon <dixonte+winehq(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 --- Comment #8 from Bernhard Übelacker <bernhardu(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 --- Comment #9 from T E Dixon <dixonte+winehq(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 --- Comment #10 from T E Dixon <dixonte+winehq(a)stc-networks.com> --- Just in case, I created a new prefix using this version of wine. Same issue. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 --- Comment #11 from Bernhard Übelacker <bernhardu(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 --- Comment #12 from T E Dixon <dixonte+winehq(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 --- Comment #13 from T E Dixon <dixonte+winehq(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 --- Comment #14 from T E Dixon <dixonte+winehq(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 --- Comment #15 from Bernhard Übelacker <bernhardu(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 --- Comment #16 from T E Dixon <dixonte+winehq(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 --- Comment #17 from T E Dixon <dixonte+winehq(a)stc-networks.com> --- CFLAGS="-Og" rather, sorry. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 --- Comment #18 from Bernhard Übelacker <bernhardu(a)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:") -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 --- Comment #19 from T E Dixon <dixonte+winehq(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 --- Comment #20 from T E Dixon <dixonte+winehq(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 --- Comment #21 from T E Dixon <dixonte+winehq(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 Rémi Bernon <rbernon(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon(a)codeweavers.com --- Comment #22 from Rémi Bernon <rbernon(a)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). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 --- Comment #23 from T E Dixon <dixonte+winehq(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 --- Comment #24 from T E Dixon <dixonte+winehq(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 --- Comment #25 from Rémi Bernon <rbernon(a)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). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 --- Comment #26 from T E Dixon <dixonte+winehq(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 --- Comment #27 from T E Dixon <dixonte+winehq(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 --- Comment #28 from T E Dixon <dixonte+winehq(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 --- Comment #29 from Rafał Mużyło <galtgendo(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 --- Comment #30 from T E Dixon <dixonte+winehq(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57547 T E Dixon <dixonte+winehq(a)stc-networks.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|10.0-rc2 |10.4 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=57547 --- Comment #31 from T E Dixon <dixonte+winehq(a)stc-networks.com> --- I never got around to making different udev rules. But today I decided to remove the patch I'd been using to work around this issue, and found the issue no longer seems to exist on Wine 10.15 and with kernel 6.16.9. I assume I mark this resolved now? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla