JetKVM doesn't wake PC from sleep #89

Open
opened 2026-02-20 08:20:13 -05:00 by deekerman · 6 comments
Owner

Originally created by @cuter-doc0 on GitHub (Jan 30, 2025).

I'm using JetKVM to setup a new Dell OptiPlex Micro 7020
I already know about the issue where keyboard and mouse are not detected by bios/firmware (of the pre-boot environment)

New issue I wasn't able to find a issue raise on is that JetKVM will not wake my sleeping PC.

Symptom are that JetKVM will show USB connected but no HDMI input.

Troubleshooting on a sleeping PC:

  • JetKVM web ui will load and
  • present user with USB in Connected state
  • shows user "No HDMI signal detected."
  • clicking on the screen output region will not wake the PC
  • pressing keyboard keys in the screen output region will not wake the PC
  • using Virtual keyboard to send keystrokes or keystroke combinations will not wake the PC
  • enabling "Jiggler" after the PC is in sleep mode will not wake the PC

What has worked to wake the PC:

  • using a separate, already connected, 3rd party external keyboard/mouse connected to the sleeping PC will wake the PC
  • rebooting JetKVM via Web Terminal and using the Virtual Keyboard will wake the PC (but not native keyboard/mouse inputs to the screen output region)
  • if attempting to wake a sleeping PC within seconds of it sleeping via JetKVM, it will wake with Virtual Keyboard inputs.

App: 0.3.5-dev202501291218
System: 0.2.0

Image

What I'd like to see is that keyboard and mouse inputs from JetKVM continue to be sent to the PC regardless of HDMI input status. Although I'm not sure if it is or isn't at this stage...

Originally created by @cuter-doc0 on GitHub (Jan 30, 2025). I'm using JetKVM to setup a new Dell OptiPlex Micro 7020 I already know about the issue where keyboard and mouse are not detected by bios/firmware (of the pre-boot environment) New issue I wasn't able to find a issue raise on is that **JetKVM will not wake my sleeping PC**. Symptom are that JetKVM will show USB connected but no HDMI input. Troubleshooting on a sleeping PC: - JetKVM web ui will load and - present user with USB in Connected state - shows user "No HDMI signal detected." - clicking on the screen output region will not wake the PC - pressing keyboard keys in the screen output region will not wake the PC - using Virtual keyboard to send keystrokes or keystroke combinations will not wake the PC - enabling "Jiggler" after the PC is in sleep mode will not wake the PC What has worked to wake the PC: - using a separate, already connected, 3rd party external keyboard/mouse connected to the sleeping PC **will** wake the PC - rebooting JetKVM via Web Terminal **and** using the Virtual Keyboard **will** wake the PC (but not native keyboard/mouse inputs to the screen output region) - if attempting to wake a sleeping PC within seconds of it sleeping via JetKVM, it will wake with Virtual Keyboard inputs. App: 0.3.5-dev202501291218 System: 0.2.0 <img width="1303" alt="Image" src="https://github.com/user-attachments/assets/30723a69-10c8-4497-bdb6-166b9bcd7e4b" /> What I'd like to see is that keyboard and mouse inputs from JetKVM continue to be sent to the PC regardless of HDMI input status. Although I'm not sure if it is or isn't at this stage...
Author
Owner

@Nevexo commented on GitHub (Jan 30, 2025):

USB input is sent regardless of HDMI state, the computer is just ignoring it.

This might be fixed by #113? I'm not 100% sure what's responsible for waking the machine out of sleep, I assume the firmware is.

In which case, I think it's fairly likely that PR would resolve it.

There's a test build that has the fix and jetkvm-next-7 also includes it.

@Nevexo commented on GitHub (Jan 30, 2025): USB input is sent regardless of HDMI state, the computer is just ignoring it. This might be fixed by #113? I'm not 100% sure what's responsible for waking the machine out of sleep, I assume the firmware is. In which case, I think it's fairly likely that PR would resolve it. There's a test build that has the fix and jetkvm-next-7 also includes it.
Author
Owner

@FloobyFlaps commented on GitHub (Jan 24, 2026):

Hi, I'm seeing the same behavior.

My Setup:

  • JetKVM connected to a Windows laptop (acting as USB HID keyboard/mouse via the KVM)
  • The laptop keeps USB power during sleep/hibernation, but input events from JetKVM don't wake the system (Windows seems to ignore/reject them while sleeping, Jiggler does also not work in sleep)
  • A regular USB mouse does wake the laptop reliably
  • App version 0.5.2, System Version 0.2.5 of JetKVM

What I found (Windows Device Manager → Power Data / Capabilities)

A USB mouse that can wake the laptop reports these capabilities:

0000007F
PDCAP_D0_SUPPORTED
PDCAP_D1_SUPPORTED
PDCAP_D2_SUPPORTED
PDCAP_D3_SUPPORTED
PDCAP_WAKE_FROM_D0_SUPPORTED
PDCAP_WAKE_FROM_D1_SUPPORTED
PDCAP_WAKE_FROM_D2_SUPPORTED

JetKVM reports:

00000019
PDCAP_D0_SUPPORTED
PDCAP_D3_SUPPORTED
PDCAP_WAKE_FROM_D0_SUPPORTED

System mapping shown by Windows:

S0 -> D0
S1 -> D3
S2 -> D3
S3 -> D3
S4 -> D3
S5 -> D3

Observations:

  • During sleep (S3/S4), devices are in D3 according to Windows.
  • JetKVM only advertises PDCAP_WAKE_FROM_D0_SUPPORTED, so Windows may not treat it as a wake-capable device in sleep states.
  • Interestingly, my mouse does not explicitly list PDCAP_WAKE_FROM_D3_SUPPORTED, but it still wakes the system - so Windows might be using different wake paths (USB remote wake / selective suspend / HID rules), or it may not expose all wake details in that view.

I hope this information helps.
If you need more information, just ping me.

Thank you

@FloobyFlaps commented on GitHub (Jan 24, 2026): Hi, I'm seeing the same behavior. **My Setup:** - JetKVM connected to a Windows laptop (acting as USB HID keyboard/mouse via the KVM) - The laptop keeps USB power during sleep/hibernation, but input events from JetKVM don't wake the system (Windows seems to ignore/reject them while sleeping, Jiggler does also not work in sleep) - A regular USB mouse does wake the laptop reliably - App version 0.5.2, System Version 0.2.5 of JetKVM **What I found (Windows Device Manager → Power Data / Capabilities)** A USB mouse that can wake the laptop reports these capabilities: ``` 0000007F PDCAP_D0_SUPPORTED PDCAP_D1_SUPPORTED PDCAP_D2_SUPPORTED PDCAP_D3_SUPPORTED PDCAP_WAKE_FROM_D0_SUPPORTED PDCAP_WAKE_FROM_D1_SUPPORTED PDCAP_WAKE_FROM_D2_SUPPORTED ``` JetKVM reports: ``` 00000019 PDCAP_D0_SUPPORTED PDCAP_D3_SUPPORTED PDCAP_WAKE_FROM_D0_SUPPORTED ``` System mapping shown by Windows: ``` S0 -> D0 S1 -> D3 S2 -> D3 S3 -> D3 S4 -> D3 S5 -> D3 ``` **Observations:** - During sleep (S3/S4), devices are in D3 according to Windows. - JetKVM only advertises `PDCAP_WAKE_FROM_D0_SUPPORTED`, so Windows may not treat it as a wake-capable device in sleep states. - Interestingly, my mouse does not explicitly list `PDCAP_WAKE_FROM_D3_SUPPORTED`, but it still wakes the system - so Windows might be using different wake paths (USB remote wake / selective suspend / HID rules), or it may not expose all wake details in that view. I hope this information helps. If you need more information, just ping me. Thank you
Author
Owner

@FloobyFlaps commented on GitHub (Jan 24, 2026):

Probably related to #674

@FloobyFlaps commented on GitHub (Jan 24, 2026): Probably related to #674
Author
Owner

@FloobyFlaps commented on GitHub (Jan 24, 2026):

I think this issue is related to the USB gadget configuration.

Looking at the code here:
https://github.com/jetkvm/kvm/blob/dev/internal/usbgadget/config.go#L37

I noticed that only MaxPower is configured for the USB configuration descriptor.
However, the USB specification also defines a bmAttributes field, which is currently missing.

Relevant documentation: Source 1 Source 2 Source 3

bmAttributes is a bitmap:

  • Bit 5: Remote Wakeup support
  • Bit 6: Self-powered
  • Bit 7: Must be set (bus-powered indicator)

I don't know what the best default value is, but typical candidates would be:

  • 0xA0 -> bus-powered + remote wakeup
  • 0xE0 -> self-powered + remote wakeup

Based on #674, 0xE0 is probably the correct default.
In my personal setup the device is bus-powered, so 0xA0 would apply.

I’m not sure whether setting bmAttributes alone is sufficient for wake to work in all cases, or if additional handling is required in the gadget/UDC layer.
If I have time, I will try to test this change myself and report back.

Thanks!

@FloobyFlaps commented on GitHub (Jan 24, 2026): I think this issue is related to the USB gadget configuration. Looking at the code here: https://github.com/jetkvm/kvm/blob/dev/internal/usbgadget/config.go#L37 I noticed that only `MaxPower` is configured for the USB configuration descriptor. However, the USB specification also defines a `bmAttributes` field, which is currently missing. Relevant documentation: [Source 1](https://www.keil.com/pack/doc/mw/usb/html/_u_s_b__configuration__descriptor.html) [Source 2](https://www.beyondlogic.org/usbnutshell/usb5.shtml) [Source 3](https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-configuration-descriptors) `bmAttributes` is a bitmap: - Bit 5: Remote Wakeup support - Bit 6: Self-powered - Bit 7: Must be set (bus-powered indicator) I don't know what the best default value is, but typical candidates would be: - `0xA0` -> bus-powered + remote wakeup - `0xE0` -> self-powered + remote wakeup Based on #674, `0xE0` is probably the correct default. In my personal setup the device is bus-powered, so `0xA0` would apply. I’m not sure whether setting bmAttributes alone is sufficient for wake to work in all cases, or if additional handling is required in the gadget/UDC layer. If I have time, I will try to test this change myself and report back. Thanks!
Author
Owner

@jlian commented on GitHub (Feb 1, 2026):

I don't have a JetKVM (yet) but I've fixed this on my TinyPilot.

I had to do a patch and recompile the RPi 5.15 Linux kernel. The most important part is below that fixes the dwc2.

+static int dwc2_hsotg_wakeup(struct usb_gadget *gadget)
+{
+    struct dwc2_hsotg *hsotg = to_hsotg(gadget);
+    ...
+    if (hsotg->params.power_down == DWC2_POWER_DOWN_PARAM_NONE && hsotg->bus_suspended) {
+        /* exit clock gating so the PHY can toggle remote wake */
+        pcgctl = dwc2_readl(hsotg, PCGCTL);
+        pcgctl &= ~PCGCTL_GATEHCLK;
+        dwc2_writel(hsotg, pcgctl, PCGCTL);
+        udelay(5);
+        ...
+    }
+
+    dwc2_set_bit(hsotg, DCTL, DCTL_RMTWKUPSIG);
+    mdelay(10);
+    dwc2_clear_bit(hsotg, DCTL, DCTL_RMTWKUPSIG);
+    ...
+}
+
+static const struct usb_gadget_ops dwc2_hsotg_gadget_ops = {
+    ...
+    .wakeup = dwc2_hsotg_wakeup,
+};

I also had to fix the USB gadget configuration to add wakeup_on_write and bmAttributes=0xa0 so the USB descriptor advertises suspend + wake support:

@@
 echo 8 > "${USB_KEYBOARD_FUNCTIONS_DIR}/report_length"
+echo 1 > "${USB_KEYBOARD_FUNCTIONS_DIR}/wakeup_on_write"
@@
 echo 7 > "${USB_MOUSE_FUNCTIONS_DIR}/report_length"
+echo 1 > "${USB_MOUSE_FUNCTIONS_DIR}/wakeup_on_write"
@@
+echo 0xa0 > "${USB_CONFIG_DIR}/bmAttributes"
 echo 250 > "${USB_CONFIG_DIR}/MaxPower"

If interested, you can read my long write up about this.

Once I get my hands on a JetKVM I plan on trying this more, but I hope this helps in the meantime. I don't know if the kernel JetKVM uses needs the same patch or not, but at the minimum it seems the USB gadget configuration is missing wakeup_on_write.

@jlian commented on GitHub (Feb 1, 2026): I don't have a JetKVM (yet) but I've fixed this on my TinyPilot. I had to do a [patch](https://github.com/raspberrypi/linux/compare/rpi-5.15.y...jlian:linux:rpi-5.15.y) and recompile the RPi 5.15 Linux kernel. The most important part is below that fixes the `dwc2`. ```diff +static int dwc2_hsotg_wakeup(struct usb_gadget *gadget) +{ + struct dwc2_hsotg *hsotg = to_hsotg(gadget); + ... + if (hsotg->params.power_down == DWC2_POWER_DOWN_PARAM_NONE && hsotg->bus_suspended) { + /* exit clock gating so the PHY can toggle remote wake */ + pcgctl = dwc2_readl(hsotg, PCGCTL); + pcgctl &= ~PCGCTL_GATEHCLK; + dwc2_writel(hsotg, pcgctl, PCGCTL); + udelay(5); + ... + } + + dwc2_set_bit(hsotg, DCTL, DCTL_RMTWKUPSIG); + mdelay(10); + dwc2_clear_bit(hsotg, DCTL, DCTL_RMTWKUPSIG); + ... +} + +static const struct usb_gadget_ops dwc2_hsotg_gadget_ops = { + ... + .wakeup = dwc2_hsotg_wakeup, +}; ``` I also had to fix the USB gadget configuration to add `wakeup_on_write` and `bmAttributes=0xa0` so the USB descriptor advertises suspend + wake support: ```diff @@ echo 8 > "${USB_KEYBOARD_FUNCTIONS_DIR}/report_length" +echo 1 > "${USB_KEYBOARD_FUNCTIONS_DIR}/wakeup_on_write" @@ echo 7 > "${USB_MOUSE_FUNCTIONS_DIR}/report_length" +echo 1 > "${USB_MOUSE_FUNCTIONS_DIR}/wakeup_on_write" @@ +echo 0xa0 > "${USB_CONFIG_DIR}/bmAttributes" echo 250 > "${USB_CONFIG_DIR}/MaxPower" ``` If interested, you can read my [long write up about this](https://johnlian.net/posts/tinypilot-usb-wake/). Once I get my hands on a JetKVM I plan on trying this more, but I hope this helps in the meantime. I don't know if the kernel JetKVM uses needs the same patch or not, but at the minimum it seems the USB gadget configuration is missing `wakeup_on_write`.
Author
Owner

@JeremiahGillis commented on GitHub (Feb 16, 2026):

I also have the same issue on my Windows 11 machine.

@JeremiahGillis commented on GitHub (Feb 16, 2026): I also have the same issue on my Windows 11 machine.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/kvm#89
No description provided.