Logi MeetUp 2 (046d:0963) cannot be reset / captured by VirtualHere on Linux

Submitted by mix on #1

Hello,

we are trying to use a Logitech Logi MeetUp 2 (VID 046d:0963) with VirtualHere USB Server on a Linux server, but we cannot get the device to work correctly.

The device is detected normally by Linux:

Bus 001 Device 007: ID 046d:0963 Logitech, Inc. Logi MeetUp 2

It is connected as a High Speed USB device:

usb 1-4: new high-speed USB device number 7 using xhci_hcd usb 1-4: New USB device found, idVendor=046d, idProduct=0963, bcdDevice=2.25 usb 1-4: Product: Logi MeetUp 2 usb 1-4: Manufacturer: Logitech usb 1-4: SerialNumber: 2543FDN06P78 usb 1-4: Found UVC 1.00 device Logi MeetUp 2 (046d:0963)

Linux also detects the UVC and HID interfaces correctly.

However, when VirtualHere tries to capture the device, we get:

Error -1 resetting device 0x046d/0x0963 for capture Error binding device 14 [046d:0963] to connection 3, BIND_ERROR Unmanaging device 14 [046d:0963]

At the same time, the USB device disappears and is re-enumerated:

usb 1-4: USB disconnect, device number 6 usb 1-4: new high-speed USB device number 7 using xhci_hcd

We also tested the device without VirtualHere running.

The device remains visible:

lsusb -d 046d:0963 Bus 001 Device 007: ID 046d:0963 Logitech, Inc. Logi MeetUp 2

but attempting to reset it directly with usbreset:

sudo usbreset /dev/bus/usb/001/007

returns:

No such device found

Interestingly, lsusb continues to detect the device normally afterwards.

So at this point we are unable to determine whether this is related to the MeetUp 2 firmware, its USB implementation, the Linux USB stack/xHCI controller, or something specific to the way the device handles USB reset.

System:

  • Linux / Debian 13
  • USB controller: Intel xHCI
  • Device: Logitech Logi MeetUp 2
  • VID:PID: 046d:0963
  • Firmware/device revision reported by USB: 2.25
  • Serial: 2543FDN06P78

Has anyone encountered this behavior with the MeetUp 2 on Linux or with USB redirection software such as VirtualHere?

Is there a recommended way to reset/reinitialize the MeetUp 2 from Linux, or any known firmware/USB compatibility issue that could explain this behavior?

Any suggestions or diagnostic steps would be greatly appreciated.

Submitted by Michael on Sat, 2026/09/26 - 07:24

#2

You can turn off reset in virtualhere.

In the virtualhere client, right click on the Meetup camera and select Custom Event Handler and type in

onReset.$VENDOR_ID$.$PRODUCT_ID$=

then press OK. Then try.

Submitted by mix on Mon, 2026/09/28 - 16:42

#3

The workaround worked on the first attempt, but the issue returned on subsequent attempts.

Could this possibly be related to the Windows VirtualHere client rather than the Linux USB server? Is there any known issue with Windows reinitializing USB devices or interfaces when reconnecting a Logitech MeetUp 2?

I'd like to determine whether the reset is being triggered by the client or whether the device itself is causing the problem.

Submitted by mix on Mon, 2026/09/28 - 17:04

#4

I did some additional testing and found that the issue is not Windows-specific.

I tested the Logitech MeetUp 2 with another computer running Manjaro Linux, and the exact same problem occurs.

The suggested custom event handler (onReset.$VENDOR_ID$.$PRODUCT_ID$=) worked only on the first attempt. Subsequent connection attempts resulted in the same issue.

This seems to point to the VirtualHere USB server, the Linux USB stack, or a compatibility issue with the MeetUp 2.

Could you advise how to troubleshoot this further, or whether there are any known compatibility issues with this device?

Submitted by Michael on Mon, 2026/09/28 - 17:15

#5

Try right clicking on the camera and selecting Custom Event Handler... and pasting this in 

onReset=

That is a more generic and will skip reset for all devices. I suspect the vendor id or product id of that device is changing after the first attempt. Can you see if the VID/PID is the same or changes?


 

Submitted by mix on Mon, 2026/09/28 - 17:22

#6

Unfortunately, the generic onReset= handler does not solve the problem either.

The device still behaves exactly as before: it connects successfully on the first attempt, but subsequent connection attempts fail with the same reset error and BIND_ERROR.

The VID/PID reported by Linux remains 046d:0963 after the device is re-enumerated. The USB device number changes, but the vendor and product IDs remain the same.

I have tested this with the VirtualHere server running on Debian 13 (kernel 6.12) and clients on both Windows and Manjaro Linux (kernel 7.x), with the same result.

Could you suggest any further diagnostic steps or explain why the device cannot be captured again after the first successful connection, even with reset disabled?

Submitted by Michael on Mon, 2026/09/28 - 17:46

#7

"it connects successfully on the first attempt"

When it does that can you see the image ok?

 

Submitted by mix on Mon, 2026/09/28 - 18:54

#8

Hello,

I first posted about this issue last Friday.

I have attached a screenshot showing that the VirtualHere server detects both Logitech MeetUp devices. Interestingly, the problem occurs exclusively with the camera interface of the Logi MeetUp 2. As shown in the screenshot, the separate USB Audio and HID interface connects successfully and works without any issues.

The onReset.$VENDOR_ID$.$PRODUCT_ID$= configuration you suggested worked only once, after the weekend. However, the issue has since returned, and the camera resets every time VirtualHere attempts to bind it to a client, regardless of whether onReset is configured or which form of the setting is used.

The logs consistently show the following sequence:

Device 14 [046d:0963] BOUND to connection 1 Device 14 [046d:0963] SURPRISE UNBOUND from connection 1 Unmanaging device 14 [046d:0963]

At the same time, the Linux kernel reports a USB disconnect, followed by the camera being detected again a few seconds later. The camera's VID/PID and serial number remain unchanged; only its USB device number changes after re-enumeration.

Since the USB Audio and HID interface connects successfully, the issue appears to be specific to the camera interface rather than the entire device or the general USB connection.

Could you please advise how to proceed with troubleshooting this issue? The suggested onReset configuration has not provided a reliable solution, and the problem appears to occur during the camera interface's binding/capture process.

https://saviogroup.pl/it/image.jpg

Best regards,

Submitted by Michael on Mon, 2026/09/28 - 19:10

#9

Try this:

  1. Stop the virtualhere server by typing systemctl stop virtualhere

  2. Edit the /usr/local/etc/virtualhere/config.ini file and add the line

    ClaimPorts=1

    then save the change and reboot the server

3. Use the camera via virtualhere again after the reboot.

This setting will turn off a built-in sequence of commands that run when a device is plugged in. It will disable driver binding before virtualhere can redirect the camera and it will also disable the initial set configuration. This might be confusing the logitech firmware

Submitted by mix on Mon, 2026/09/28 - 20:34

#10

We have updated the firmware of our Logitech Logi MeetUp 2 from version 2.0.70 to 2.1.208.

Since the update, the behavior appears to have changed. The camera still resets, which is rather strange, considering that the configuration is supposed to prevent this from happening. However, at least it no longer resets during connection; instead, it happens after the client disconnects.

It is possible that the issue is related to the camera's firmware, but I cannot confirm this with 100% certainty. The only thing I can say for sure is that the behavior changed after the firmware upgrade.

For now, we will continue monitoring the device to see whether the original issue has been resolved and whether the current behavior remains stable.

We will keep you informed if we notice any further changes or if the problem reoccurs.

Best regards,
Mirek