| For the curious, there's a hierarchy defined by the USB-C cable spec. Table 4-17 Precedence of power source usage
https://www.usb.org/sites/default/files/USB%20Type-C%20Spec%... - Baseline: it behaves like a USB cable from 1996. Sync gets 100mA@5V (USB2) or 150mA@5V (USB3), and then as part of USB enumeration you can get up to 500mA@5V (USB2) or 900/1500mA@5V (USB3 single/dual lane) depending on what happens during USB enumeration. Then, in priority order: - USB PD: If both sides negotiate a USB PD contract, that overrides baseline, and you get up to 5A@20V (or more now with the new EPR stuff) - USB Type-C current: The source drives a voltage on USB-C CC (pin only in USB-C cables) to say if it can give 1.5A@5V or 3A@5V, the sync pulls CC to say if it wants it (what the author is talking about here). If both sides have the right signaling, the source gives the current requested to the sync. - USB BC 1.2: Intended for charging bricks; brick shorts the USB2 D+/D- together to signal device it gets up to 1.5A@5V. Or 2.4A@5V if you use Apple's extension (see, every iPad brick back in the day) So, wonder if the USB-C to USB-A case in the article is just working because it's hooking up to a USB BC brick with that USB-C to USB-A cable, and the remote needs more than 100mA to charge and only supports the USB BC case? Note only baseline is required to be compliant with the spec; there's no rule that the device has to use any of the other features. Welcome to USB :) |
The spec is specifically designed to allow this, because USB has backwards compatibility as a core tenant (i.e. you can plug in your USB keyboard from 1996 and it will probably still work). Also a USB-C to micro USB-B cable or USB-C to USB-A cable is explicitly allowed in the spec, and how could such a thing possibly work if the spec somehow required using the new CC pins instead of making them optional, since those pins are not in USB-A/USB-B?
Still, not the nicest experience for users :(