Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow overriding USB_MANUFACTURER from Kconfig #576

Merged
merged 1 commit into from
Feb 18, 2025

Conversation

vvuk
Copy link
Contributor

@vvuk vvuk commented Feb 17, 2025

This is a small quality of life thing -- I got annoyed at having 3+ different serial (or canbus) devices all named "Klipper". This lets you override the manufacturer via menuconfig so you can get /dev/serial/by-ud/usb-Eddy_rp2040_... and similar.

(also the u""CONFIG_USB.. is intentional; only way to get a utf16 string from a string literal #define!) (I have no idea why my brain filtered out the existing CONCAT)

Checklist

  • pr title makes sense
  • squashed to 1 commit
  • added a test case if possible
  • if new feature, added to the readme
  • ci is happy and green

@vvuk vvuk requested a review from a team as a code owner February 17, 2025 04:10
@rogerlz
Copy link
Contributor

rogerlz commented Feb 17, 2025

Can we default to Kalico instead?
I know the code still has USB_STR_MANUFACTURER u"Klipper", but if you are testing with a different name and proposing to expose that to users, I believe we can safely default to Kalico now.

@vvuk
Copy link
Contributor Author

vvuk commented Feb 17, 2025

Well.. the only issue with defaulting to Kalico is that we'd break everyone's printer config (because the usb serial port name will switch to Kalico), unless I make the override explicitly something you turn on and off... but in that case the default just goes back to being Klipper anyway. I'd say save making that change for a future break point, where a bunch of breaking changes happen at once once there's a compelling reason to do so?

@rogerlz
Copy link
Contributor

rogerlz commented Feb 18, 2025

It'd only happen when the user reflashes their mcu, which doesn't happen as often as I could wish for, but I will leave that chang for another time.
Thanks

@rogerlz rogerlz merged commit 350ab9e into KalicoCrew:main Feb 18, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants