[Feature Request] Hook that runs after device enumeration

[tim-hilt]

Feature Request Type

• Core functionality
• Add-on hardware support (eg. audio, RGB, OLED screen, etc.)
• Alteration (enhancement/optimization) of existing feature(s)
• New behavior

Description

My keyboard is connected to a USB-port on my USB-C monitor. Connecting the keyboard to the laptop is equivalent to connecting it to my monitor.

I have a custom keyboard_post_init_user-function that checks the OS of the connected host and sets the default layer based on the OS being Mac or Windows.

However I learnt, that keyboard_post_init_user runs on boot of the keyboard. Not necessarily when another host is plugged in. This is important, because when I plug in another host (say I'm switching from my work-laptop to my private laptop), then the keyboard still has power, because it's connected to the monitors USB-port. In order to set the default layer, I have to replug the keyboard, which I hoped to avoid with keyboard_post_init_user.

Is there a hook that I can define in my keymap, that hooks in the actual device negotiation, when a keyboard is plugged in?

Here you can see my current implementation: https://github.com/tim-hilt/qmk_firmware/blob/master/keyboards/hillside/46/keymaps/tim-hilt/keymap.c#L91-L93

[drashna]

I think you're looking for void notify_usb_device_state_change_user(enum usb_device_state usb_device_state)

[tim-hilt]

Oh that’s nice! Is there any documentation about this?

[tim-hilt]

Solved by #21777

[andrebrait]

@tim-hilt I see you merged my PR into your fork. Is it working ok for you?

[tim-hilt]

Hi and thanks for your work first and foremost! I did flash my code on three different boards:

• Elite-C based Corne (by splitkb, aurora-line)
• Frood (RPi 2040) based Hillside 46
• Splinky (RPi 2040) based TBK Mini

so I can test some variety like that.

It did work everytime, if I were to plug it directly into one machine. OS detection works and does what I expect. However, if I have it plugged into my USB-C monitor and wake a machine from suspend, then it always runs into OS_UNSURE.

I still have to test how it behaves if I switch out host machines and keep the keyboard plugged into the KVM. Also note, that I haven't played with OS_DETECTION_DEBOUNCE or OS_DETECTION_KEYBOARD_RESET yet. I'll do so and report back though.

If you already know what I could try out next (raising OS_DETECTION_DEBOUNCE I guess?) Feel free to share your suspicions and I'll try it out.

[tim-hilt]

So for the TBK Mini, os-detection worked. After switching from Mac to PC, my default layer is now automatically changed.

[andrebrait]

The reset flag is most useful if the board is switching between computers, but maybe it's still worth a shot, since USB hubs can be a bit weird. If the board still end up with UNSURE, you can increase the debouncing a bit (try something absurd first, like 500ms, and if it works, work it down).

…

On Thu, 16 Nov 2023, 08:25 Tim Hilt, ***@***.***> wrote: Hi and thanks for your work first and foremost! I did flash my code on three different boards: - Elite-C based Corne (by splitkb, aurora-line) - Frood (RPi 2040) based Hillside 46 - Splinky (RPi 2040) based TBK Mini so I can test some variety like that. It did work everytime, if I were to plug it directly into one machine. OS detection works and does what I expect. However, if I have it plugged into my USB-C monitor and wake a machine from suspend, then it always runs into OS_UNSURE. I still have to test how it behaves if I switch out host machines and keep the keyboard plugged into the KVM. Also note, that I haven't played with OS_DETECTION_DEBOUNCE or OS_DETECTION_KEYBOARD_RESET yet. I'll do so and report back though. If you already know what I could try out next (raising OS_DETECTION_DEBOUNCE I guess?) Feel free to share your suspicions and I'll try it out. — Reply to this email directly, view it on GitHub <#22288 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABLX5OSWS46B64LIXIAP7RTYEW5YDAVCNFSM6AAAAAA6EMKNJ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJTHEYTKNBRGU> . You are receiving this because you commented.Message ID: ***@***.***>

[tim-hilt]

@andrebrait actually I was wrong when I said

So for the TBK Mini, os-detection worked. After switching from Mac to PC, my default layer is now automatically changed.

It did in fact switch, but I think it did, because OS_WIN and OS_UNSURE are handled the same in my code:

https://github.com/tim-hilt/qmk_firmware/blob/master/keyboards/bastardkb/tbkmini/keymaps/tim-hilt/keymap.c#L67-L71

so it did at least retrigger, but I'm pretty sure it didn't detect reliably. I started experimenting with OS_DETECTION_DEBOUNCE, but that didn't the behavior, even after bumping it up 1000 ms. So I tried with OS_DETECTION_KEYBOARD_RESET and that finally did the trick.

So I can confirm, that the feature works. However I can't judge whether the fuzzy behavior is because of my KVM or because of the implementation.

[andrebrait]

Most likely it's due to the KVM at some point triggering the reinitialization of the USB interface without cutting power to the board, which causes issues with the detection.

I added that flag because my KVM does that when switching machines, but it's weird that yours does it even when plugging the device in for the first time.... Go figure...

You can always enable debugging there and see what comes out, if you want to understand exactly what's up with it.

[tim-hilt]

On first plug the detection worked. But it didn’t when I kept it plugged into the KVM but switched out host machines. This seems to be consistent with what you were experiencing with your hardware!

[andrebrait]

Oh, I had misunderstood then.

Yeah, then it's 100% expected you need the reset flag. KVMs don't typically cut power, which is the only thing that would cause the USB interface to be completely restarted, so you need to reset the board and force the device descriptor to be generated again so the detection can capture the data from the host and try to detect the OS.

Otherwise, it's never triggered again.

At least that's my understanding of it. Likely the nomenclature is not 100% accurate per se.