Requested device or endpoint not found: 1038:183a:03 on MacOS Ventura about rivalcfg HOT 38 CLOSED

I am on Ventura, experiencing the issue. I will test by end of week. Thanks!

from rivalcfg.

I do not know why the mouse is listed bu is not found when trying to open it... I do not have macOS to help debuging this :(

from rivalcfg.

I put up a PR for this, #202, since I was having this issue with my mouse too. I don't know when it started occurring, but "when upgrading to Ventura" seems plausible.

from rivalcfg.

I published the v4.9.0 where hidapi is updated to v0.14, so it should work on macOS Ventura. Please let me know if it is not the case. :)

from rivalcfg.

Looking good: https://gist.github.com/glyph/e858a95d4008f905ae6e4516aaa6563d

from rivalcfg.

Hi Fabien :)
Do you want some debuging trace or something ?
Maybe rivalcfg is not supported under macOS Ventura ? (I think this is not the issue here)

I tried to put my mousse on usb, then bluetooth and then wifi but it's every time the same error.

from rivalcfg.

I think I do not know macOS enough to be really helpful here... :(

What is strange here is that you have 6 endpoints for the device but all are displayed as being the "endpoint 0"... Maybe an other software or a kernel diver is already attached to the device and makes some interference?

from rivalcfg.

I don't have steelseries driver installed.

I could try to make it work myself by cloning the repo and try in local.
I'll keep you in touch :)

from rivalcfg.

I have this issue as well.

here's what a full dump of my enumerated devices looks like:

{'interface_number': 0,
 'manufacturer_string': 'SteelSeries',
 'path': b'DevSrvsID:4294982071',
 'product_id': 5926,
 'product_string': 'SteelSeries Rival 650 Wireless',
 'release_number': 294,
 'serial_number': '000000000000',
 'usage': 1,
 'usage_page': 65473,
 'vendor_id': 4152}
{'interface_number': 0,
 'manufacturer_string': 'SteelSeries',
 'path': b'DevSrvsID:4294982077',
 'product_id': 5926,
 'product_string': 'SteelSeries Rival 650 Wireless',
 'release_number': 294,
 'serial_number': '000000000000',
 'usage': 2,
 'usage_page': 1,
 'vendor_id': 4152}
{'interface_number': 0,
 'manufacturer_string': 'SteelSeries',
 'path': b'DevSrvsID:4294982077',
 'product_id': 5926,
 'product_string': 'SteelSeries Rival 650 Wireless',
 'release_number': 294,
 'serial_number': '000000000000',
 'usage': 1,
 'usage_page': 1,
 'vendor_id': 4152}
{'interface_number': 0,
 'manufacturer_string': 'SteelSeries',
 'path': b'DevSrvsID:4294982075',
 'product_id': 5926,
 'product_string': 'SteelSeries Rival 650 Wireless',
 'release_number': 294,
 'serial_number': '000000000000',
 'usage': 6,
 'usage_page': 1,
 'vendor_id': 4152}
{'interface_number': 0,
 'manufacturer_string': 'SteelSeries',
 'path': b'DevSrvsID:4294982075',
 'product_id': 5926,
 'product_string': 'SteelSeries Rival 650 Wireless',
 'release_number': 294,
 'serial_number': '000000000000',
 'usage': 1,
 'usage_page': 12,
 'vendor_id': 4152}

As you can see, interface_number is not unique here, so filtering on it selects a device at random. After some trial and error, I discovered that filtering on interface["usage_page"] == 65472 allowed me to find the one that would report battery status reliably. I don't know if this is the same device used for other stuff; I have only the vaguest idea what "usage pages" are or how HID devices work.

from rivalcfg.

on my rival 100 it seems to be 0:

 {'path': b'5-2:1.0',
  'vendor_id': 4152,
  'product_id': 5890,
  'serial_number': '',
  'release_number': 101,
  'manufacturer_string': 'SteelSeries',
  'product_string': 'SteelSeries Rival 100 Gaming Mouse',
  'usage_page': 0,
  'usage': 0,
  'interface_number': 0},
 {'path': b'5-2:1.1',
  'vendor_id': 4152,
  'product_id': 5890,
  'serial_number': '',
  'release_number': 101,
  'manufacturer_string': 'SteelSeries',
  'product_string': 'SteelSeries Rival 100 Gaming Mouse',
  'usage_page': 0,
  'usage': 0,
  'interface_number': 1},

I will check with all my other SteelSeries mice to see if it is specific to Aerox and Rival 650 / or if it may be specific to macOS Ventura...

from rivalcfg.

Ok I made some test on Linux with my Rival 650.

When I enumerate interfaces I have:

 {'path': b'2-7:1.0',
  'vendor_id': 4152,
  'product_id': 5926,
  'serial_number': '000000000000',
  'release_number': 294,
  'manufacturer_string': 'SteelSeries',
  'product_string': 'SteelSeries Rival 650 Wireless',
  'usage_page': 0,
  'usage': 0,
  'interface_number': 0},
 {'path': b'2-7:1.1',
  'vendor_id': 4152,
  'product_id': 5926,
  'serial_number': '000000000000',
  'release_number': 294,
  'manufacturer_string': 'SteelSeries',
  'product_string': 'SteelSeries Rival 650 Wireless',
  'usage_page': 0,
  'usage': 0,
  'interface_number': 1},
 {'path': b'2-7:1.2',
  'vendor_id': 4152,
  'product_id': 5926,
  'serial_number': '000000000000',
  'release_number': 294,
  'manufacturer_string': 'SteelSeries',
  'product_string': 'SteelSeries Rival 650 Wireless',
  'usage_page': 0,
  'usage': 0,
  'interface_number': 2},
 {'path': b'2-7:1.3',
  'vendor_id': 4152,
  'product_id': 5926,
  'serial_number': '000000000000',
  'release_number': 294,
  'manufacturer_string': 'SteelSeries',
  'product_string': 'SteelSeries Rival 650 Wireless',
  'usage_page': 0,
  'usage': 0,
  'interface_number': 3},

With Wireshark I can capture this:

So the problem is:

• On macOS (at least in your enum), all endpoints are numbered as "0". This is a very strange behaviour :/
• On Linux, the usage page seems to not be exposed by the hidraw API of the kernel (probably not useful in this context)
• The usage page seems to be an id that defines the data type used by the endpoint (so it should probably not be used to locate the right endpoint)... Example of generic usage pages (from Microsoft doc):

I do not know what is going on on macOS Ventura, but there is clearly an issue somewhere. We will have to find a way to know which interface is the right one without using the usage page and the interface_number :/

from rivalcfg.

I had an idea to fix the issue on macOS Ventura (without breaking Linux). I pushed it on the 200-macos-ventura-endpoint branch. Can someone test if it works? :)

git clone https://github.com/flozz/rivalcfg.git
cd rivalcfg
git checkout 200-macos-ventura-endpoint
python3 -m venv __env__
source __env__/bin/activate
pip install -e .

python -m rivalcfg [...]

See changes: 57756e9

from rivalcfg.

UP

I really need someone on macOS Ventura to test it work :)

from rivalcfg.

I just checked out the 200-macos-ventura-endpoint branch and it worked, it seems fixed to me 👍. Way to go @flozz :)

from rivalcfg.

Sadly 200-macos-ventura-endpoint doesn't fix it for me. As before, the connection is still unreliable, and I freaquently get.

Traceback (most recent call last):
  File "/Users/glyph/.local/bin/rivalcfg", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/Users/glyph/Projects/rivalcfg/rivalcfg/__main__.py", line 81, in main
    raise error
  File "/Users/glyph/Projects/rivalcfg/rivalcfg/__main__.py", line 78, in main
    mouse = get_first_mouse()
            ^^^^^^^^^^^^^^^^^
  File "/Users/glyph/Projects/rivalcfg/rivalcfg/__init__.py", line 29, in get_first_mouse
    return mouse.get_mouse(
           ^^^^^^^^^^^^^^^^
  File "/Users/glyph/Projects/rivalcfg/rivalcfg/mouse.py", line 36, in get_mouse
    hid_device = usbhid.open_device(vendor_id, product_id, profile["endpoint"])
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/glyph/Projects/rivalcfg/rivalcfg/usbhid.py", line 101, in open_device
    device.open_path(path)
  File "hid.pyx", line 154, in hid.device.open_path
OSError: open failed

from rivalcfg.

I also still get Unable to get the battery level sometimes, so the behavior seems identical.

from rivalcfg.

I also double checked to make sure it wasn't a wired/wireless issue; I tried while wired, while on wireless, and wired with the wireless entirely disconnected.

from rivalcfg.

@johnelliott Thank you for the feedback!

@glyph Your issue seems de be different from the previous one:

rivalcfg.usbhid.DeviceNotFound: Requested device or endpoint not found

— VS —

OSError: open failed

The endpoint seems to be found but hidapi is not able to open it (an other software or driver is attached to the device? or a permission issue?). We will have to find why it cannot be opened ^^"

from rivalcfg.

@glyph I turned your comment as a new issue as it is not the same problem.

I close this issue as the initial problem is solved. The fix will be released soon :)

from rivalcfg.

@glyph I turned your comment as a new issue as it is not the same problem.

I close this issue as the initial problem is solved. The fix will be released soon :)

Sounds good. Looking forward to a fix for that one :)

from rivalcfg.

The endpoint seems to be found but hidapi is not able to open it (an other software or driver is attached to the device? or a permission issue?). We will have to find why it cannot be opened ^^"

I should ask, is there anything diagnostic you'd like me to do? I'm sure it's not permissions, but I don't know what else it might be.

from rivalcfg.

I do also notice some intermittent issues with Ventura. Before the 200-macos-ventura-endpoint branch it would never work.

Now when I wake my mac from sleep and the mouse and usb adapter seem to have disassociated I need to run the script again, and it seems to work within 30 seconds or so after a few tries. Perhaps I'm seeing the same issues as @glyph.

from rivalcfg.

I reopened the issue because I think my fix work for some devices (the ones that use an endpoint != 0, like Aerox) but not for devices that use endpoint 0... For those one, the first endpoint listed will be used and it can be the wrong one. I have to tweak the code a bit more... :)

from rivalcfg.

Can someone on macOS Ventura give me the result of the following command?

python3 -c "import platform ; print(platform.system()) ; print(platform.version()) ; print(platform.mac_ver())"

→ Someone on Twitter gave me the answer:

Darwin
Darwin Kernel Version 22.5.0: Mon Apr 24 20:53:44 PDT 2023; root:xnu-8796.121.2~5/RELEASE_ARM64_T8103
('13.4', ('', '', ''), 'arm64')

from rivalcfg.

I pushed a new fix on the 200-macos-ventura-endpoint branch: 0ed4226

→ Can you test if it work?
→ Please remind me what mouse model you are using (to allow me to know if it works for both devices that use endpoint 3 and 0).

:)

from rivalcfg.

('13.4', ('', '', ''), 'arm64')

Same here.

from rivalcfg.

→ Can you test if it work?

Kind of. It's better now, but still not completely reliable:

  ★ for each in $(seq 20); do rivalcfg --battery-level; done
Unable to get the battery level
Charging [========  ] 89 %
Charging [========  ] 89 %
Charging [========  ] 89 %
Unable to get the battery level
Unable to get the battery level
Charging [========  ] 89 %
Charging [========  ] 89 %
Unable to get the battery level
Charging [========  ] 89 %
Charging [========  ] 89 %
Unable to get the battery level
Unable to get the battery level
Charging [========  ] 89 %
Unable to get the battery level
Unable to get the battery level
Charging [========  ] 89 %
Unable to get the battery level
Charging [========  ] 89 %
Unable to get the battery level

from rivalcfg.

Contrast my usage-page branch:

  ★ for each in $(seq 20); do rivalcfg --battery-level; done
Charging [========  ] 89 %
Charging [========  ] 89 %
Charging [========  ] 89 %
Charging [========  ] 89 %
Charging [========  ] 89 %
Charging [========  ] 89 %
Charging [========  ] 89 %
Charging [========  ] 89 %
Charging [========  ] 89 %
Charging [========  ] 89 %
Charging [========  ] 89 %
Charging [========  ] 89 %
Charging [========  ] 89 %
Charging [========  ] 89 %
Charging [========  ] 89 %
Charging [========  ] 89 %
Charging [========  ] 89 %
Charging [========  ] 89 %
Charging [========  ] 89 %
Charging [========  ] 89 %

from rivalcfg.

As far as what hardware I'm using: "1038:172b | 00 | SteelSeries Rival 650 Wireless (firmware v0)"

from rivalcfg.

Ok... I need more info to figure what is happening... I pushed a new version of the code in a new branch : 200-macos-ventura-endpoint-test that prints some debug information.

Can you run it multiple times like you did just before and then share results here? :)

from rivalcfg.

200-macos-ventura-endpoint-test ... run it multiple times like you did just before and then share results here? :)

Ran my shell script invoking the program with my flags, this time I didn't see the lights on the mouse change:

$ ./aerox.sh
================================================================================
_IS_MACOS_VENTURA: 1
--------------------------------------------------------------------------------
All interfaces:
[{'interface_number': 0,
  'manufacturer_string': 'SteelSeries',
  'path': b'DevSrvsID:4295010661',
  'product_id': 6200,
  'product_string': 'SteelSeries Aerox 3 Wireless',
  'release_number': 299,
  'serial_number': '',
  'usage': 6,
  'usage_page': 1,
  'vendor_id': 4152},
 {'interface_number': 0,
  'manufacturer_string': 'SteelSeries',
  'path': b'DevSrvsID:4295010657',
  'product_id': 6200,
  'product_string': 'SteelSeries Aerox 3 Wireless',
  'release_number': 299,
  'serial_number': '',
  'usage': 1,
  'usage_page': 12,
  'vendor_id': 4152},
 {'interface_number': 0,
  'manufacturer_string': 'SteelSeries',
  'path': b'DevSrvsID:4295010659',
  'product_id': 6200,
  'product_string': 'SteelSeries Aerox 3 Wireless',
  'release_number': 299,
  'serial_number': '',
  'usage': 1,
  'usage_page': 65473,
  'vendor_id': 4152},
 {'interface_number': 0,
  'manufacturer_string': 'SteelSeries',
  'path': b'DevSrvsID:4295010663',
  'product_id': 6200,
  'product_string': 'SteelSeries Aerox 3 Wireless',
  'release_number': 299,
  'serial_number': '',
  'usage': 1,
  'usage_page': 65472,
  'vendor_id': 4152},
 {'interface_number': 0,
  'manufacturer_string': 'SteelSeries',
  'path': b'DevSrvsID:4295010665',
  'product_id': 6200,
  'product_string': 'SteelSeries Aerox 3 Wireless',
  'release_number': 299,
  'serial_number': '',
  'usage': 2,
  'usage_page': 1,
  'vendor_id': 4152},
 {'interface_number': 0,
  'manufacturer_string': 'SteelSeries',
  'path': b'DevSrvsID:4295010665',
  'product_id': 6200,
  'product_string': 'SteelSeries Aerox 3 Wireless',
  'release_number': 299,
  'serial_number': '',
  'usage': 1,
  'usage_page': 1,
  'vendor_id': 4152}]
--------------------------------------------------------------------------------
macOS Ventura found interface:
{'interface_number': 0,
 'manufacturer_string': 'SteelSeries',
 'path': b'DevSrvsID:4295010659',
 'product_id': 6200,
 'product_string': 'SteelSeries Aerox 3 Wireless',
 'release_number': 299,
 'serial_number': '',
 'usage': 1,
 'usage_page': 65473,
 'vendor_id': 4152}
--------------------------------------------------------------------------------

from rivalcfg.

Here's a log of me running it 20 times:

https://gist.github.com/glyph/09d9b3db000e04634bc66dced662a3db

from rivalcfg.

Thank you for the feedbacks.

It found the following issue on the HIDAPI lib that is used by Rivalcfg to access USB devices: libusb/hidapi#531

They released a fix 3 days ago!

https://github.com/libusb/hidapi/releases/tag/hidapi-0.14.0

Once the Python binding of HIDAPI released we will be able to test if it fixes the issue for us, else we will hack in Rivalcfg. :)

I will revert the change on master waiting for the update.

from rivalcfg.

I just logged back on to say I'd found a way to more reliably reproduce the bug: after the system goes to sleep and the usb mouse RF receiver is off, the bug happens until I switch the mouse off and back on again.

Now as I read the above, it looks like the problem is upstream.

from rivalcfg.

They released a fix 3 days ago!

This makes me feel a little less crazy — as I was hacking around the shifting USB endpoint attributes, I was thinking "this… can't be how it's supposed to work, right?" Glad that this is getting fixed in the right place!

from rivalcfg.

Went to go check whether cython-hidapi had an issue to update to the next release, and I saw @flozz was already on it :). For those following along at home, here's the link: trezor/cython-hidapi#151

from rivalcfg.

Thanks so much all, I wish I was more of a help. :)

from rivalcfg.

hidapi was updated to v0.14! If someone can test on macOS with the master branch and this version (pip install hidapi==0.14) :)

from rivalcfg.