Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Mini M keyboard support with the MiniRazz controller #20106
Mini M keyboard support with the MiniRazz controller #20106
Changes from all commits
02ac378
86469fe
58f941d
48cc2c2
7029919
756fb8d
dc0bef8
a28af4e
4053bf7
3af570a
cddf2ec
adbf55e
003390c
8a581c6
3b5ba32
53cbb4f
8dd8515
30db72b
c29b78e
fa74a2b
edbda7b
0bde15f
db0b3fa
d5b3e11
938ebaa
187a297
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Large diffs are not rendered by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most of this (eg everything but the src part) can be moved to info.json, and should be.
qmk info -f ascii
orqmk migrate
can help with that.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This vendor ID is already in use.
https://www.the-sz.com/products/usbid/index.php?v=0x16C0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This vendor ID is provided for free as shared usb id by v-usb:
https://github.com/obdev/v-usb/blob/master/usbdrv/USB-IDs-for-free.txt
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is still an issue as it is not a unique VID/PID combo, and if you or community users wish to use VIA or similar could be considered a blocker.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not planning on supporting VIA ever.
I am supporting VIAL however, but that doesn't require a unique VID/PID. VIAL detects the keyboard by a magic number embedded somewhere in the SERIAL_NUMBER. (Which for VIAL it means that I have to have a serial number like "purdea.ro:minirazz:MAGIC_NUMBER")
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, i don't mean to annoying by refusing to change something, just let me explain my thinking of why I'm resisting this:
If anyone else from my users isn't satisfied with VIAL, and wants to add
VIA support they can of course get a different, unique pair of VID:PID in the future, I'm not gonna block that.
I don't see why I should bother to go requesting a PID code from https://pid.codes/ now, since I don't need it, and occupying a valuable PID code for no reason is wasteful. I am not a keyboard manufacturer, just an open source contributor, I can't afford buying a USB VID, so I must rely on one of the free offerings available.
XAP Also doesn't need Unique VID:PID so hopefully need for unique vid:pid will disappear even for VIA users in the future, so hopefully my hypothetical future users who will want to add VIA support will not need to acquire a vid:pid pair after all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure that using the 16C0:27DB USB ID for a QMK-based device is proper, because QMK can present more than just a HID keyboard device to the host:
These non-HID options are probably the most problematic, because apparently Windows caches the driver configuration by
idVendor:idProduct:bcdDevice
, and can end up using a completely wrong driver if the cached configuration does not match the actual interfaces presented by the device.Also apparently there are already some users of 16C0:27DB in the repo:
dm9records/plaid
dm9records/tartan
ibm/model_m_4th_gen
ibm/model_m_4th_gen/overnumpad_1xb
keyhive/lattice60
ortho5by12
silverbullet44
unicomp/classic_ultracl_post_2013
unicomp/classic_ultracl_pre_2013
unicomp/pc122
unicomp/spacesaver_m_post_2013
unicomp/spacesaver_m_pre_2013
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The
unicomp/*
andibm/*
are mine. I can make changes to them if it becomes necessary. The others are not mine.dm9records/tartan
with16c0:27db
actually has via support: the-via/keyboards#526This isn't really correct, since it's a shared vid:pid, and I don't think there's a way for VIA to differentiate.
dm9records/plaid
has a via keymap, but no matching VIA json in thethe-via/keyboards
repository.When it comes to compliance with the V-USB terms, I think using 16c0/27db is okay: Under the section "IDs FOR DISCRIMINATION BY SERIAL NUMBER", it says "The USB device MUST provide a textual representation of the serial number, unless ONLY the operating system's default class driver is used.", this implies that both vendor class and an OS default class can coexist, as long as the serial number is specified. It is indeed true that combinations of different kinds of HID is not explicitly permitted, but based on the above I don't think they intended to disallow it. They definitely don't use the precise language of 'usage'/'usage page' that HID documentation uses, instead the say 'Description of use'. I read this as a much fuzzier specification, and even though the keyboard can be compiled to act as a USB mouse too, it still fundamentally is a keyboard, so I think the right VID:PID for it is 16c0/27db, and I think using it this way does comply with the V-USB terms. I fired off a message to Objective Development to check if my interpretation is correct, I will report back if/when I get a response.
Regarding windows caching behavior, I am not really able to test this since I don't have any windows systems. I maybe be able to do some directed testing by borrowing a laptop from someone else. Do you have a reference to where I can read more about this behavior, to figure out how I can test for it? It seems to me like this behavior as it has been described here so far, would affect keymaps too, enabling/disabling certain features, and would affect temporary builds too that enable the CONSOLE for debugging, so I'm surprised that I haven't heard about this. Do windows users really have to overwrite DEVICE_VER in custom keymaps, and when changing what features are enabled?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sigprof I have tested the following, in this order, on a borrowed windows 10 machine:
16c0:27db with all features enabled (8 interfaces in use), shows up nicely, this is the view in Device Manager, if you select View > Devices By Connection:
Ableton detects the midi interface nicely.
This vid:pid has never been plugged into this machine before, so should be starting with a fresh "cache".
16c0:27db disabled all of the features, it doesn't show up as a composite device anymore. Ableton doesn't detect the MIDI interface anymore:
c0ff:fffe disabled all of the features (should be starting fresh with no cache)
Same as point 2 above
c0ff:fffe with all features enabled
Same as point 1 above.
Ableton correctly detects the midi interface
I don't see any evidence of caching causing any kind of trouble.
If you think caching really is a problem, then could you give me some set of steps that would reproduce it, or at least some documentation that I can reference to come up with a possible theory as to how it could be causing trouble?