I have a couple of years old customized thesycon USB driver for an xmos based product. When the product connects to a PC or MAC, it has the text of the customization (i.e. not identified as xmos but a different company).
Recently made a new thesycon USB driver for a newer product. When this driver loads on a PC, it has the text of the customization. But when the product connects to a MAC, it says it is xmos. Obviously the MAC does not care about the PC driver, so presumably there is something in the xmos firmware that tells the MAC whose product is connected? I searched the source code but it wasn't obvious how the MAC would get the product ID. How does that work for MAC?
Where does MAC USB get its VID?
-
infiniteimprobability
- XCore Legend
- Posts: 1126
- Joined: Thu May 27, 2010 10:08 am
- Contact:
I don't think the mac cares about VID and PID and these fields are don't care - the Thesycon driver does care and will only load the driver for the the correct device.
The VID and PID are in the defines - eg. from customdefines.h
These, and all of the strings are should be picked up from the descriptor. It's the device descriptor (top level) that contains the VID/PID.
The VID and PID are in the defines - eg. from customdefines.h
Code: Select all
/***** Defines relating to USB descriptors etc *****/
#define VENDOR_ID (0x20B1) /* XMOS VID */
#define PID_AUDIO_1 (0x0005)
#define PID_AUDIO_2 (0x0004)So back to the original question then: why would one xmos based USB audio product be identified by a Mac as an xmos product, and another xmos based USB audio product be identified as a different manufacturer (not xmos)? It would have to be something in the xmos firmware, right? If it is not the VID/PID, then what?
The vendor name for the finished product is supplied by the device driver that is mated with the hardware.
On OSX, drivers are installed via kextfiles / folders.
Example:
http://www.xbsd.nl/2011/07/pl2303-seria ... -lion.html
Inside the kext file / folder, review the info.plist file for the vendor name. Changing the contents of this file should allow for customization of the specific hardware name.
On Windows, similar details are posted inside the INF file. For 32 bit operating systems, the INF file does not need to be signed to install (ie. paired same named file which is supplied with the .CAT extension).
For 64 bit Windows operating systems, there is a requirement for the .CAT file to be present. The driver package must be stress tested (aka Microsoft DTM tools) -> logs submitted -> Microsoft approves -> Microsoft signs the driver package and returns to the submitter the .CAT file. Any changes to the INF file will invalidate the driver package and will then no longer install on 64 bit Windows operating systems.
On OSX, drivers are installed via kextfiles / folders.
Example:
http://www.xbsd.nl/2011/07/pl2303-seria ... -lion.html
Inside the kext file / folder, review the info.plist file for the vendor name. Changing the contents of this file should allow for customization of the specific hardware name.
On Windows, similar details are posted inside the INF file. For 32 bit operating systems, the INF file does not need to be signed to install (ie. paired same named file which is supplied with the .CAT extension).
For 64 bit Windows operating systems, there is a requirement for the .CAT file to be present. The driver package must be stress tested (aka Microsoft DTM tools) -> logs submitted -> Microsoft approves -> Microsoft signs the driver package and returns to the submitter the .CAT file. Any changes to the INF file will invalidate the driver package and will then no longer install on 64 bit Windows operating systems.
If you have not defined a custom value for one of the strings used in the USB descriptors the default value for that string will be used from devicedefines.h instead. As mentioned by infiniteimprobability, the customdefines.h file is the usual place for product specific defines to be added.kallsop wrote:So back to the original question then: why would one xmos based USB audio product be identified by a Mac as an xmos product, and another xmos based USB audio product be identified as a different manufacturer (not xmos)? It would have to be something in the xmos firmware, right? If it is not the VID/PID, then what?
"XMOS" is the default value for the Vendor String, which is set by the VENDOR_STR define. You may also be seeing the value of the USB Product String (set using the PRODUCT_STR or PRODUCT_STR_A2 and PRODUCT_STR_A1 defines) in Audio MIDI Setup on OS X.
There seems to be some confusion between Vendor ID (VID) and the Manufacturer and Product string descriptors in this thread. xsamc has given the correct answer in my view.
The windows driver uses the string from the customisation, OSX/Linux/Built in Windows Audio Class 1.0 driver will uses the string from the device.
(The windows driver behaviour was a deliberate decision - it uses the string from the customisation so that people cannot steal your driver and use it with their product i.e. it will still pop us with your company/product name - not the string from the device)
The windows driver uses the string from the customisation, OSX/Linux/Built in Windows Audio Class 1.0 driver will uses the string from the device.
(The windows driver behaviour was a deliberate decision - it uses the string from the customisation so that people cannot steal your driver and use it with their product i.e. it will still pop us with your company/product name - not the string from the device)
I think I have it, thanks all. The customdefines.h file that came with the USB reference design kit does not include a VENDOR_STR so the firmware gets it from devicedefines.h. So I will either edit the devicedefines.h or add a VENDOR_STR to customdefines.h.
Just to clarify
If you are working with the development drivers on windows. On a USB Audio 2.0 build with xp_skc_su1.xn as the target, this will always identify itself as XMOS XS1-U8 DJ?
Is this the same for the XMOS stereo driver?
If you are working with the development drivers on windows. On a USB Audio 2.0 build with xp_skc_su1.xn as the target, this will always identify itself as XMOS XS1-U8 DJ?
Is this the same for the XMOS stereo driver?
No luck. Added a VENDOR_STR to customdefines.h, cleaned the project, rebuilt, programmed our xmos board, still seen as XMOS by a MAC. Then also changed the VENDOR_STR in devicedefines.h, cleaned the project, rebuilt, programmed our xmos board, still seen as XMOS by a MAC.
I don't have a MAC so the testing is done at a remote location. Is there any way for me to test the firmware here to see how it identifies on a MAC, without a MAC?
I don't have a MAC so the testing is done at a remote location. Is there any way for me to test the firmware here to see how it identifies on a MAC, without a MAC?
This is a good tool: http://www.thesycon.de/eng/usb_descriptordumper.shtml