Fix Usb Gadget when attached after power-up

[IDisposable]

Fixes #128

Summary

• Revamped the polling and writing of the USB gadget to correct for dropped connections
• Corrected the initialization order to ensure we run even if the USB is disconnected (and we're getting power from the y-splitter/POE)
• Ensured that we restart the LED listening polling
• If we exceed too many consecutive write errors, close and reopen the gadget

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Pull request overview

Copilot reviewed 42 out of 42 changed files in this pull request and generated 17 comments.

Comments suppressed due to low confidence (2)

internal/usbgadget/usbgadget.go:185

• File handle may be writable as a result of data flow from a call to OpenFile and closing it may result in data loss upon failure, which is not handled explicitly.

		u.absMouseHidFile.Close()

internal/usbgadget/usbgadget.go:189

• File handle may be writable as a result of data flow from a call to OpenFile and closing it may result in data loss upon failure, which is not handled explicitly.

		u.relMouseHidFile.Close()

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[adamshiervani]

LED state synchronization stops working after 1-2 runs of make test_e2e. The keyboard and mouse movement both work, it's just the LED state that stops updating. A restart fixes the issue.

Also, worth mentioning is that I can also reproduce this issue latest dev without this PR.

[IDisposable]

I will look into the LED state issue. When you say it "stops working" do you mean that the client doesn't track the server state, or do you mean the UI doesn't track the RPC pushes?

[adamshiervani]

The remote host receives all keys and mouse events, it's just that the UI doesn't properly reflect the LED State. This makes the make test_e2e fail, as it uses the LED State to determine whether the remote host handles keyboard presses.

[IDisposable]

The remote host receives all keys and mouse events, it's just that the UI doesn't properly reflect the LED State. This makes the make test_e2e fail, as it uses the LED State to determine whether the remote host handles keyboard presses.

I'll dig in this weekend... what LED state are we tracking, and what is the test JetKVM physically attached to on the USB port? I notice that MacOS doesn't light the CapsLock LED as I would expect (never really has...) Do you know what kind of machine the Jet is driving?

[adamshiervani]

The remote host i'm testing on is on Ubuntu 24.04.

[IDisposable]

So I did a few things:

• Switched the push-based LED state reporting to follow the same pattern as the pushed key-down state reporting to use a channel so that we won't block when trying to send back the LED state
• Added an OverwriteChan go chan wrapper that discards the oldest entry when asked to queue something and the channel is full
• Switch both LED and key-down state reporting channels to use the OverwriteChan such that when we start a session, the channels get initialized with a limit of 4 (for LED) and 16 (for key-down) pending messages... if we have more backed up, the oldest one(s) get discarded and the channel is never full. I suspect that both of those limits are much higher than needed (probably only need most recent one).
• Updated the devices.$id.tsx to always ask for LED and key-down state at route load, and setup a 30-second polling for state in case we miss the state being pushed.
• Removed the LED "Shift" state as that was not reliable across machines

[adamshiervani]

Updated the devices.$id.tsx to always ask for LED and key-down state at route load, and setup a 30-second polling for state in case we miss the state being pushed.

This feels like something is broken. Any special reason for this?

[IDisposable]

Updated the devices.$id.tsx to always ask for LED and key-down state at route load, and setup a 30-second polling for state in case we miss the state being pushed.

This feels like something is broken. Any special reason for this?

Honestly, this was to address your observation that we were failing occasionally to track the LED state in E2E. I didn't really ever see that, but put this in as a backup plan. We could not do it at all, or change the poll rate.