[Bug 53387] New: Vernier USB sensors are not usable in WINE
https://bugs.winehq.org/show_bug.cgi?id=53387 Bug ID: 53387 Summary: Vernier USB sensors are not usable in WINE Product: Wine Version: 7.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: tuomas.nurmi(a)opinsys.fi Distribution: --- Created attachment 72775 --> https://bugs.winehq.org/attachment.cgi?id=72775 Logs from various situations described in the bug report Vernier USB student laboratory sensors ( https://www.vernier.com/products/go-direct/ ) are not usable with WINE. Tested on Debian 11 Bullseye (equivalent), kernel 5.10, wine 7.13 from https://wiki.winehq.org/Debian . (Earlier tests with previous wine versions have also been negatives, however, they haven't been as comprehensive and well-documented as this) Tested with an earlier sensor model, a Go! Temp ver 1.53 and a later Go Direct Sensor (idVendor 08f7, idProducts 0002 and 0010, respectively). They show up in Linux syslog as shown in attachment section 1. Udev rules for the devices are in place, as described by (the somewhat outdated) https://wiki.winehq.org/Hid and Vernier's native library guidelines at https://github.com/VernierST/godirect-examples/tree/main/python , as follows: KERNEL=="hidraw*", SUBSYSTEM=="hidraw", GROUP="plugdev", MODE="0666" KERNEL=="hiddev*", MODE="0666" SUBSYSTEM=="usb", ATTRS{idVendor}=="08f7", MODE="0666" SUBSYSTEM=="usb_device", ATTRS{idVendor}=="08f7", MODE="0666" resulting into following permissions with plugged devices crw-rw-rw- 1 root plugdev 242, 0 20. 7. 13:36 /dev/hidraw0 crw-rw-rw- 1 root root 180, 0 20. 7. 13:36 /dev/usb/hiddev0 Resulting in functioning sensors with the native library example software from Vernier (attachment section 2), as well as with an earlier discontinued Linux version of LoggerPro, and the Vernier Graphical Analysis Chrome app ( https://chrome.google.com/webstore/detail/vernier-graphical-analysi/dncgedbn... ) The sensors were tested also Windows 10, and were visible/detected by both the Microsoft hid example application hclient.exe and Vernier LoggerPro3. However, the devices are not recognized by LoggerPro3 nor hclient.exe run through wine-7.13. Logs with WINEDEBUG=+hid,+wineusb,+plugplay of these are shown in attachment sections 3, 4, and 5. Not a specialist in any of the related fields, but the logs show seemingly correctly recognized plugging of the device, 00cc:trace:wineusb:add_usb_device Adding new device 0x7f9330001f80, vendor 08f7, product 0010. 00d0:trace:wineusb:add_unix_device Adding new device 00007F934C016ED0, vendor 08f7, product 0010. ... 00c8:trace:plugplay:enumerate_new_device Creating new device L"USB\\VID_08F7&PID_0010\\0". but the device is not recognized by LoggerPro, nor listed by hclient.exe. (I don't know if the plugplay:install_device_driver error following in the logs is related) -- 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=53387 --- Comment #1 from Tuomas Nurmi <tuomas.nurmi(a)opinsys.fi> --- Created attachment 72776 --> https://bugs.winehq.org/attachment.cgi?id=72776 The USB sensor devices as seen when inspected with hclient.exe on Windows 10. -- 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=53387 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #2 from Zeb Figura <z.figura12(a)gmail.com> --- I'm assuming all the I/O is done over HID, not raw USB, although that could be wrong. Assuming it's right, I suspect the problem is that SDL isn't picking up the device (because it's not a gamepad or controller), in which case the solution is to disable SDL and use hidraw instead. In order to do that, you'll need to open the registry key at HKLM\System\CurrentControlSet\Services\WineBus and set the (new) DWORD value "Enable SDL" to 0. (We really shouldn't be depending on SDL to the exclusion of other backends anymore...) -- 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=53387 --- Comment #3 from Tuomas Nurmi <tuomas.nurmi(a)opinsys.fi> --- Created attachment 72784 --> https://bugs.winehq.org/attachment.cgi?id=72784 Logs with "Enable SDL" set as 0 Thank you very much for the response! Indeed, setting HKLM\System\CurrentControlSet\Services\WineBus -> "Enable SDL" to 0, made notable progress. Now I can observe both sensors in hclient.exe, data looking similar to the data observable on Windows 10 if plugged in before program start. A broken device entry is created if devices plugged in while program is already running ("*Device #4: \", with * indicating errors while opening) However, the older sensor still seems to get in some kind of error loop with the following block repeating (logs attached, sections 1 & 2) 00c4:trace:hid:pdo_create Open handle on device 000000000074B990 00c4:trace:hid:pdo_ioctl device 000000000074B990 code 0xb04b0 00c4:trace:hid:pdo_ioctl device 000000000074B990 code 0xb01a8 0158:err:rawinput:add_device Failed to get collection descriptor, status 0xc00000e8. Unfortunately, neither of them is yet recognized by LoggerPro. With the older sensor, the same error loop is also observable here (section 3). The newer sensor produces cleaner logs (section 4), but is also not recognized by LoggerPro - however, I had some problems with this sensor in LoggerPro on Windows, too, so I will double (or triple) check the functionality of the newer sensor under Windows. -- 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=53387 --- Comment #4 from Zeb Figura <z.figura12(a)gmail.com> --- Can you please attach a log from LoggerPro with WINEDEBUG=+hid,+pid,+timestamp,+setupapi,+plugplay,+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=53387 --- Comment #5 from Tuomas Nurmi <tuomas.nurmi(a)opinsys.fi> --- Created attachment 72797 --> https://bugs.winehq.org/attachment.cgi?id=72797 LoggerPro + Go! Temp sensor, with WINEDEBUG=+hid,+pid,+timestamp,+setupapi,+plugplay,+process Sure thing! Log when (the older) Go! Temp is plugged in, attached. -- 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=53387 --- Comment #6 from Zeb Figura <z.figura12(a)gmail.com> --- Hmm, so it looks like the application is doing a SetupDiGetClassDevsExW(GUID_DEVINTERFACE_HID), enumerating each interface and calling SetupDiGetDeviceRegistryPropertyA(SPDRP_HARDWAREID). I'm not sure why our hardware IDs would be wrong, but since you seem to have access to Windows, this seems easy enough to test. I *think* the right key on Windows is HKLM\System\CurrentControlSet\Enum\HID\VID_08f7&PID_0002&MI_00 but it might be missing the MI suffix. Can you try opening that, and paste the contents of the HardwareID key here? The other possibility, though, since there is an MI suffix, is that we need to properly parse multiple TLCs. I thought we had a FIXME for that, but I guess not... -- 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=53387 --- Comment #7 from Tuomas Nurmi <tuomas.nurmi(a)opinsys.fi> --- Sure. HKLM\System\CurrentControlSet\Enum\HID\VID_08F7&PID_0002 (no MI suffix) contains a folder 6&2095854&0&0000, under which a REG_MULTI_SZ key HardwareID is as follows: HID\VID_08F7&PID_0002&REV_0153 HID\VID_08F7&PID_0002 HID\VID_08F7&UP:FF00_U:0001 HID_DEVICE_UP:FF00_U:0001 HID_DEVICE_UPR:FF00-FFFF HID_DEVICE -- 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=53387 --- Comment #8 from Tuomas Nurmi <tuomas.nurmi(a)opinsys.fi> --- For the sake of completeness and documentation, the corresponding key under WINE 7.16 is HKLM\System\CurrentControlSet\Enum\HID\VID_08F7&PID_0002&MI_00 which contains a folder 339&400454010000&0&0, under which a REG_MULTI_SZ key HardwareID is as follows: HID\VID_08F7&PID_0002&MI_00\339&400454010000&0&0 HID\VID_08F7&PID_0002&MI_00 HID I wonder if this is something I could realistically try fixing myself? (quite experienced developer, but somewhat limited C experience, no previous experience with HID or WINE development) I suppose the right place to look at is dlls/winebus.sys/? -- 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=53387 --- Comment #9 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to Tuomas Nurmi from comment #8)
I wonder if this is something I could realistically try fixing myself? (quite experienced developer, but somewhat limited C experience, no previous experience with HID or WINE development) I suppose the right place to look at is dlls/winebus.sys/?
Yes, sorry, I meant to get to it myself but never managed to find the time. The IDs you want are controlled by IRP_MN_QUERY_ID in pdo_pnp() in dlls/hidclass.sys/pnp.c. We also assume that the device and instance ID should be taken from the parent but I'm not sure that's correct. You'll also want to add conformance tests in dlls/dinput/tests/; note that the tests use a kernel driver (driver_hid.c) but you probably just want to check the registry keys from hid.c. Also, because it's a kernel driver, you'll probably want to get a testbot account (https://testbot.winehq.org/) rather than using your own machine. -- 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=53387 --- Comment #10 from Tuomas Nurmi <tuomas.nurmi(a)opinsys.fi> --- Thank you very much for your insightful response! I will possibly have a look soon and see if this is something even near the scope of my expertise. -- 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=53387 --- Comment #11 from Tuomas Nurmi <tuomas.nurmi(a)opinsys.fi> --- Created attachment 73071 --> https://bugs.winehq.org/attachment.cgi?id=73071 The Go! Temp registry entry on Windows 10 For the sake of documentation, attaching the whole registry entry for a Go! Temp sensor, exported from a Windows 10 system. -- 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=53387 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4(a)web.de --- Comment #12 from Fabian Maurer <dark.shadow4(a)web.de> --- Is this fiex by https://gitlab.winehq.org/wine/wine/-/commit/d15262e464ba3536567ad73f68d95e6... ? -- 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=53387 --- Comment #13 from Tuomas Nurmi <tuomas.nurmi(a)opinsys.fi> --- Yes, indeed mostly fixed in the current git head with that commit. The Go! Temp sensor is recognized, and can be used to collect data, which is absolutely wonderful! However, disconnecting a sensor is not yet detected by LoggerPro, and reconnecting the sensor afterwards causes a duplicate to appear in list (+ disconnected sensor seems to cause high cpu load / stuck busyloop), so although the sensor is usable as the title of this report says, maybe this bug report could still stay open for a short while in case some improvements still come for the disconnecting behaviour. -- 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=53387 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |d15262e464ba3536567ad73f68d | |95e6b7f88f3aa Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #14 from Fabian Maurer <dark.shadow4(a)web.de> --- We don't reuse bug reports, please open a new one for each new issues you found and link it here. Marking fixed. -- 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=53387 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #15 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 7.22. -- 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