> Application notes from several USB controller vendors explain that, oddly enough, the only way to perform role reversal with USB-C is to implement USB Power Delivery (PD) and use the PD negotiation protocol to change the source of power. In other words, while OTG allows reversing host and device roles independently of the bus power source, USB-C does not. The end supplying power is always the host end.
This isn't true. USB PD has both "data role swap" and "power role swap" commands, and they are independent from each other.
It even allows for things like a "fast role swap", where you can unplug the power source from a dock (so power now has to flow from laptop to dock, instead of dock to laptop) without any interruption of the data connection.
Yes, the article kind of describes the default behaviour, but after the initial source/sink selection one end or the other can then independently request power role swaps and data role swaps, which the other end can either accept or reject.
For example if you ask a USB-C power brick to let you swap to providing it power, it will reject that. Then some devices (like phones, tablets etc.) will only accept power when they're switched off, but will do either when they’re on. But some will happily let you switch to device mode and be a sink when they’re off, until the battery gets below a certain level and then they’ll only accept you providing it power. It all gets quite complex!
The company I work for makes devices that are always in device mode (called upstream facing port or UFP mode) but can provide power when they are plugged in themselves, so have to swap between source and sink. I’ve spent far too long debugging firmware issues with PD controllers because of this!
That reminds me of a while back, my phone battery was getting really low, like 1%. I grabbed a power bank and connected it, USB-C to USB-C, and for whatever reason, the two devices decided that the phone should be charging the power bank instead of vice-versa. Then the phone died a few seconds later. (Then the powerbank started charging the phone!)
With apologies to stephen_g, who I'm sure writes excellent firmware, this is the quality of decision making I would expect from median firmware.
My impression from the article is that what you're saying is in line with it: if you implement PD, you can do either.
It sounded like the line you quote was expressing suprise that baseline USB power supply in USB-C - without implementing PD - can't do that. But apparently could with older USB OTG.
Aren't you agreeing with TFA then?
Yes, my Surface USB-C dock does switch so fast that if I want to power cycle it, I have to remember to unplug it from my laptop and the wall.
It sounds like you’re talking about protocol, and the article is talking about implementations.
Every USB-C docking station that exposes USB ports while also supplying the attached computer with power uses this feature, letting the computer act as a host and the docking station as the power source
I have a power bank that is PD capable, but I cannot charge it from my MacBook even if the MacBook is plugged in to power. I get around it by using a USB-C/A dongle and corresponding USB-C/A cable. Presumably this "downgrades" the connection and since the MacBook doesn't support traditional USB charging it has to charge the power bank. Does USB-C not have a way to indicate that a potential power source is a battery so that the MacBook can charge it if it's plugged in to power, and reverse roles otherwise? Is this a fault how the power bank or macOS implements power negotiation, or is this scenario simply unaddressed in USB-C?
Funny enough, if I plug the USB-C/A dongle on the end of the power bank and the cable into the MacBook, it also won't charge.
I also have a Philips One toothbrush with a USB-C charging input. Similarly, I can't charge it with a USB-C cable directly from my MacBook but have to use A in between (I unsuccessfully tried using either a thinner "lower speed" or a thicker "higher speed" USB-C cable). I'm assuming the toothbrush doesn't support PD, so then why can't it fall back to traditional charging with a C-to-C cable?
It's even simpler, I think: you're forcing it to avoid a PD negotiation, and fall back to the lowest common denominator, "500 mA on the PWR line supplied to the USB device". This goes, I believe, as far back as USB 1.1, as a slow-but-generally-safe power source for things that are barely more than "use USB PWR and GND as a dumb 5V source."
A C-to-C cable, OTOH, doesn't have this requirement, and if there's no PD negotiation, the MacBook is not required to provide power IIRC.
USB 3 bumped non-negotiated current up to 900 mA. You should be getting that on any standard compliant USB-C port with SuperSpeed implemented.
- standard-compliant
- with SuperSpeed implemented
- note that all components need to be compliant (macbook, cable, toothbrush)
That's a lot of ifs just to charge a toothbrush. I would be greatly surprised if someone actually did (yes, it might already be cheaper to source SuperSpeed components at scale; I don't yet find it likely though)
> Does USB-C not have a way to indicate that a potential power source is a battery so that the MacBook can charge it if it's plugged in to power, and reverse roles otherwise? Is this a fault how the power bank or macOS implements power negotiation, or is this scenario simply unaddressed in USB-C?
USB-C does support this. It's known as a DRP (Dual Role Port). USB PD can be used to signal switching between downstream and upstream facing ports depending on state of charge of the battery for instance. The problem is that many devices do not support this, and I strongly suspect your power bank is the issue here. iPhones and Apple stuff in general supports DRP renegotiation quite well. They tend to be USB-C compliant as much as possible, which can lead to issues with interfacing with 'USB-C' devices that are not actually properly compliant.
I'd have thought that iPhones would have sane defaults with USB-C, but it's a real pain when using USB-C to provide tethered internet to a laptop. No, I don't want the phone to charge the laptop, they both have batteries of their own
And there's seemingly no way to get the phone to not try to charge things regardless of what the other side thinks (and when plugging the laptop in, it starts to charge the phone).
The alternative would be using WiFi (in a very RF polluted space) or Bluetooth (horribly slow), versus USB-C where 5g via my phone in Bangkok can get 250mbit easily. Whereas my Android phone has options for 'data only' etc. without charging which seems like it's more of a UX 'Apple' thing than anything else.
PD can certainly do it, but most laptops don’t choose to support high power sourcing, only providing 5V at max 900 mA for devices or taking high power as a sink (charging the laptop).
By converting to USB A you cut out USB-PD completely from the equation. At that point the macbook simply provides 5V as it would to any legacy downstream device.
I have the same issue, but the other way around. I cannot charge my laptop (framework 13, amd) from my power bank. Which sometimes would be super useful.
I don't know nor understand why it doesn't work and if it's a bug in the power bank or the laptop
I have a Framework 13 and I've found that it's fairly finicky about what power sources it will accept. Anything 60W and higher seems to mostly work, but lower wattage chargers are much more dicey.
The one trick I've heard works (but haven't tried) is to "kick start" it by connecting two chargers, one with higher wattage and one with lower, then giving it a minute to begin charging, then disconnecting the higher-powered one. Apparently that's enough to get it past the initial issue and then it will continue charging (more slowly) from the lower wattage charger.
There was a firmware update a while back that was supposed to improve things, but it didn't change the behavior with my 27W charger.
As another data point, the firmware update fixed everything for me and I have no problems charging my Framework 13 from my 18w Pixel charger or 20w iPad charger.
You know what, I went back and checked it and apparently it does work now. Not sure why I thought otherwise.
It's too late to edit my original post :(
> I also have a Philips One toothbrush with a USB-C charging input. Similarly, I can't charge it with a USB-C cable directly from my MacBook but have to use A in between (I unsuccessfully tried using either a thinner "lower speed" or a thicker "higher speed" USB-C cable). I'm assuming the toothbrush doesn't support PD, so then why can't it fall back to traditional charging with a C-to-C cable?
Because USB-C says that a power source cannot provide 5V onto Vbus until negotiation has happened to prevent both endpoints of the link "competing" for power which can have disastrous results - for USB-C devices, that is either two resistors on cc1/2 that is pretty dumb 5V, or it is actual bi-directional communication. Early USB-C devices, most infamously the Raspberry Pi 4, various vapes and likely your toothbrush managed to mess that up [1], although I recently came across a flashlight at Lidl which also has broken resistors.
Using an USB-C male to USB-A female adapter fixes this because the adapter has the two cc1/2 5K resistors correctly in place. The adapter can safely do that because - other than early USB 1 era hubs - 99.999% of USB-A devices with a separate power source have backfeed prevention, and so the source side will just provide 5V at either 100 mA or 500 mA cutoff.
More sophisticated power source devices will also try negotiation over D+/D- after the sink device has started to negotiate higher voltages using various proprietary schemes, there's controller chips available that speak everything from plain 5V@100mA bootstrap over 5V@500mA USB2 and proprietary schemes up to 20V@3A (and probably, given the newest USB-C PD specs, even higher), without even needing an external microcontroller (but of course, muxing the bus for everything up to USB4/TB should there be one). Absolutely wild.
[1] https://hackaday.com/2019/07/16/exploring-the-raspberry-pi-4...
Back in the day when cameras still took better photos than phones, I've always wanted to backup vacation photos without bringing a computer.
I still remember getting so close with the Google Nexus 4 to being able to connect an SD card reader. It supported OTG, but did not have the required charge pump to supply 5V of VBUS. (Supposedly you could hack together something using a 9V battery, some resistors, and a kernel patch, but that was a bit more than I was willing to risk for the convenience.)
Finally, the Nexus 7 and Nexus 5 supported it out of the box, and while Android didn't offer a FAT32 implementation back then, there was (is?) a USB host API which let apps supply that instead, and I think somebody actually ended up implementing FAT32 in userspace to make it all work!
I had a nexus 7 as a kid, much before I had a personal laptop or even a phone. Used to utilize almost all of these features that most people seem to consider pointless. Had one of the little OTG cables so I could plug in flash storage and keyboards. I remember unzipping APKs, finding assets and trying to change them and rezipping. Only to find out they wouldn't install. Presumably failing a signature check.
Was super cool reading the OP article and finally learning how the thing actually worked with the 5th pin.
I went on a long trip with a mirrorless camera and a SanDisk 500GB portable disk. My "computer-less" backup solution was a Pi-esque machine with USB3 (a RockPi), a powerbank, a card reader, and connecting my phone over USB and tethering it. This gave the RockPi an IP I could ssh into, and I'd ssh from the phone and ran rsync to copy the images from the SD card in the reader to the SanDisk portable drive.
I should make a custom Linux image for the Pi4+ (the whole process is probably too slow without USB3) and some automation (Jenkins?) to do this, I'm sure there's photographers who'd find it useful.
That's very neat!
Personally, these days I have less of a need for that kind of thing, given that I can just plug the camera or disk into my phone directly (I suspect a powered USB hub and plugging in both at the same time might even work as well?), but I vaguely recall dedicated "copy everything off this card onto a hard drive" devices being sold, and I don't doubt that some photographers still use these in their workflow.
Ahem. Cameras still take better photos than phones ;)
Somewhat related: For USB C cables, get a CaberQU pin/line checker: https://caberqu.com/
The current model displays active lines, but there's a Kickstarter for one that shows more information: https://www.kickstarter.com/projects/electr/ble-caberqu-a-di...
If you want something today instead of waiting for a Kickstarter, the PowerZ checkers are available on Aliexpress. These will read the e-marker and tell you about supported PD and alt modes https://www.aliexpress.com/item/1005008071270282.html
"screenshots": https://kalleboo.com/microblog/posts/109391700632886806.html
Wow that is some massively overpriced crap right there. Forty dollars for a USB continuity tester with a basic plastic case that only does type-C cables. Meanwhile you can get one, with acrylic case, that does types A, B, C, Micro, and Micro 3.0 for $17 off Amazon or $11 off Aliexpress.
https://www.amazon.com/Treedix-Tester-Checker-Acrylic-Chargi...
It's not just a continuity tester like the one you linked from amazon though. The Kickstarter page is light on details, but it can at the very least communicate with active cables to determine amperage and data speeds.
Add to that a microcontroller, screen and software and the price doesn't look unreasonable to me, especially for a small project like this.
I didn't comment on the kickstarter product. I commented on the forty dollar continuity tester.
That isn't doing a fraction of the same feature set. The one above is able to read the cables emarker tags to tell you the cables described feature set, OEM, version number/etc. And it also tests actually pushing 40Gbit data and 240w power to verify the emarkers are correct.
There are also cases where there can be active electronics in the cable where pins can seem disconnected by a continuity tester but they are actually connected to a chip inside the cable.
Also as an aside, it should be possible to just plug a cable in, and have your OS tell you what kind of cable it is and it's specs. The USB controller has access to this info but there is no standard way to pass it up to the OS like you have with other USB info. Apparently Chromebooks do have controllers which expose this so they can tell you when both the laptop and charger support faster charging but the cable is limited.
Not sure I would highlight that "acrylic case" as a selling point... it's just a flat lid, with plastic standoffs... which you need to assemble yourself. No sides or even bottom.
This is what I was expecting when you said acrylic case: https://www.raspberrypi.com/products/raspberry-pi-4-case/
> [1] My first smartphone was the HTC Thunderbolt. No one, not even me, will speak of that thing with nostalgia. It was pretty cool owning one of the first LTE devices on the market, though. There was no contention at all in areas with LTE service and I was getting 75+Mbps mobile tethering in 2011. Then everyone else had LTE too and the good times ended.
I also had the HTC Thunderbolt and remember getting ~75Mbps initially. My wife's family lived way out in the countryside in Illinois and had something like 2Mbps DSL internet. But on one visit, I realized that if I walked down the road a short distance to the top of a hill where I had line of sight to what turned out to be a Verizon tower, I could still get ~75Mbps! I took advantage of that once or twice to get things downloaded in a more reasonable amount of time.
"this was referred to as a null modem cable"
I remember using one to play Fire Power on the Amiga, my first network game.
Warcraft 1 also supported this!
Null modem is also an excellent name for anything vaguely cyberpunk
USB-C has obfuscated things but I was hoping the following would work:
Buy a Y-cable from Ali Express that has USB-C male to plug into the phone, and both USB-C female and USB-A female sockets. Plug keyboard into the USB-A and the charger into USB-C.
But it doesn't work, and I suspect it's a software limitation at least on my phone (Moto G Play 2023). If the charger is plugged in first, the phone will charge but not use the keyboard. If the keyboard is plugged in first, the phone will use it, but not charge. I think the wires are there to make it all work, but the phone's OS just doesn't support this scenario. Pity.
Needless to say documentation is nonexistent so I don't actually know what's in the cable. For all I know, the two female sockets are just connected in parallel.
USB-C never defined a Y cable and so they never figured out how that would work. If such a cable works anywhere it is either luck, or there is some chip inside that checks for power messages from either end but otherwise looks like a straight through cable. Even then it will be tricky because if the two devices want different voltages from the charger only one can get their way.
I can't blame the USB-C people for not working on this case. It is a lot harder than it seems to make work, and of limited use. Just get a USB-C hub if you need this ability.
Isn't this exactly what USB-C docks are for?
I've seen plenty of those devices, where you have a female USB-C socket to connect a charger to, a range of other female USB-C, USB-A and other ports for peripherals and a short cable with a male USB-C plug to connect to a laptop. If everything works, the dock will act as a power source for both the peripherals and the laptop, but will act like a hub on the data lines, with the laptop being the host.
I wonder if it would work just the same if you connected a phone instead of a laptop to the "host" cable.
That is what a dock is for. OP wants a simple and cheap cable instead which isn't really possible in the generic sense (though it might work in some limited way)
I've connected my phone to the host cable of a dock before and everything worked. (I didn't try the HDMI output, but sound on the dock just worked)
This is known as a USB Accessory Charging Adapter of which a dock is one form but the old Battery Charging standard also anticipated it being in the form of a cabled adapter:
Battery Charging 1.2:
> An Accessory Charger Adaptor (ACA) is an adaptor which allows a single USB port to be attached to both a charger and another device at the same time.
Figure 3-1 shows the various configurations covered. The third one indicates the intent of having an adapter with data pass through to an accessory while powering from a third port fed by an external USB supply.
These exist today as USB-C splitters.
The docks we have around here at work all use Displaylink chips. So it would work if the phone had the (software) Displaylink driver, no Displayport video capability required on the USB-C port. But I'm guessing that's unlikely.
Hmmm, it occurred to me, I'm sitting in front of a laptop connected to a (power delivery) USB-C dock. So unplugged the laptop and plugged the cable into my phone instead (very basic, Moto G Play 2023). What happened? Almost nothing! The phone reported an audio output device, but did not charge, and the keyboard and mouse plugged into the dock did not get recognized either. Not encouraging.
Well, the Kensington dock at work did not work (for delivering power to the phone and letting keyboard and mouse be used) - in fact it did none of those things. But ordered this cheapie from Ali:
https://vi.aliexpress.com/item/1005007015739540.html
which does claim to work with various smartphones. We'll see.
Would be interested to know that as well. Good luck!
Heh, if you want a really atrocious USB power violation... Costco sold some extremely bright flashlights (think car headlight bright, and also usable as a self-defense weapon in the spirit of the old D-cell Maglites) before Christmas, that have an USB charge socket. Needless to say they include a charge cable but no charger.
But this thing wants 1.5A at 5V. And doesn't do any power "negotiation" at all, as far as I can see. It happens to work because modern smartphone chargers can do 5V at 2A by default. But plug it into any older charger and the charger immediately shuts down due to overcurrent.
I have one of those USB passthrough voltage/current meter gadgets. Yes, it draws 1.5A. I guess what it should be doing is slow-charge unless it can negotiate for more power. It's a very decent flashlight otherwise.
Oh, it also has two USB-C sockets. A red one for charging, and a black one for using the flashlight's substantial battery as a power bank. I don't know what would happen if you plugged the charger into the wrong socket and don't have the courage to try.
> Oh, it also has two USB-C sockets. A red one for charging, and a black one for using the flashlight's substantial battery as a power bank. I don't know what would happen if you plugged the charger into the wrong socket and don't have the courage to try.
USB-C does a bit of negation before putting our any significant amount of power. There's a "dumb mode" that just uses a pair of half-cent resistors and is fine for up to 3A at 5V, and then the "smart" PD (Power Delivery) mode that does a digital negotiation and can do much higher wattage.
All that is to say that if you plugged the black USB-C into a charging brick it'd probably just fail the negotiation and nothing bad would happen. Both sides would have to be violating the spec for it to be a real hazard.
Annoyingly, some really cheap devices skip out on even the dumb mode resistors to save a penny, and so even though they have USB-C ports, you have to charge them with USB-A to USB-C cables (because USB-A ports always provide power, no negotiation required.)
Those devices are where the cheap Y-cables come in handy, because they usually include the required resistors + give you a USB-A port.
The flashlight comes with an USB A->C charging cable, as do the (low end) smartphones we have (along with USB-A power adapter for the phones). Thus probably no PD negotiation. Right?
A lot of flashlights and cheap gadgets have USB-C port but can only charge from USB-A port. The reason is that they cheaped out on including the resistors that signal legacy USB mode. The USB-C to USB-A cable has the resistors.
The smartphones should have proper USB-C port, I haven't heard of one with charging problems, and included USB-A cable cause cheap.
Aah, yes, the USB-A side always provides power, no negotiation needed for that aspect. There is still supposed to be some level of negotiation before drawing that much current (often just checking resistance, similar to the USB-C "dumb" mode), but obviously the device skipped that also.
No need for weird racism.
American companies like Skullcandy do this too.
Fair enough, edited.
> extremely bright flashlights (think car headlight bright, and also usable as a self-defense weapon in the spirit of the old D-cell Maglites)
Using a device which is mostly lithium ion batteries as a weapon? Even scarier than you expect, if you puncture a battery
My wild guess would be that, yes, that cable is just a naive splitter. The only real use case I could think of that would work would be taking a USB-C port and making it accept either USB-C or USB-A devices without having to dig around/swap adapters/etc. I say that because as far as I'm aware (though I'm having trouble digging up an authoritative source right now), there's no way for USB devices to share data lines. Even cheap "passive" hubs and things all have ICs to present themselves as a USB device and sit between the host and the downstream devices. With the older USB specs you could still get some power even without the data lines, but with USB-C you need the data lines to negotiate power delivery. I don't think there are any software-level changes would make that setup work.
If you are looking for a solution though (albiet a bit bit bulkier one) it's likely any of a number of "USB C hub" or "USB C dock" products would work there. Most have a USB-C port marked "PD-IN". Plug the hub into your phone, plug your power into the PD-IN, and use the USB-A/other ports to connect your other devices. Run you like $20 from the usual suspects.
Thanks for that. The longer-term goal is to make a "dock" for my elderly mom's phone that lets her use it as a tiny (her eyes are still good) pseudo-desktop setup with keyboard and mouse. She often ends up with her phone as her only communications device when things go wrong (again) on her laptop and this would give a good email experience (she's a skilled touch-typist). Any pointers to a cheap USB-C dock on Ali that does the job?
Sadly, one limitation, at least on the Android device, is that you can't use it in landscape mode with a mouse. Well, you can, but the launcher only operates in portrait mode, as do a lot of apps. I don't want to change the launcher - elderly folks get very fixated on how their device is supposed to work. Anyway as soon as the phone switches to sideways-portrait mode, the mouse also does which is very disorienting.
There is no such thing as a spec compliant USB Y cable. Unless it's got some kind of internal USB hub. There is nothing the spec designers can do to account for non complaint ali express junk.
While not in a Y cable format, there are small USB-C hubs that can do this.
If I plug a NVMe drive into my iPhone, my phone will run out of battery so quickly so I have to use a hub and plug in my charger at the same time.
In my experience not many OTG devices actually used (mini-/micro-)AB ports, instead using just normal (mini-/micro-)B ports. The adapters generally just used a (mini-/micro-)B plug with the id pin wired like an OTG A plug. This does mean you can technically connect these adapters to non OTG products, which the spec writers wanted to avoid, but this simply meant the adapter didn't work.
I also have some peripheral devices with a captive micro-B cable (with ID pin configured like like micro-A) that were specifically intended to be used with OTG compatible phones.
There were also digital cameras that supported OTG in order to print to portable printers (usually just one or two models made by the same manufacturer).
This article, and all comments, have reminded me yet again of my anger at the not so universal USB formats.
I had been designing a device that heavily relied on USB, as its primary goal was to be basically a USB switching station, where you plug your systems and USB into the device and then can swap around which USB is connected to any of the connected systems.
I started during the early USB3x days, and by the time i had a completed design, had to rip out and redo large chunks because the damn USB spec changed with all their 3.x super premium plus ultra speed bullshit. And then... fucking USB c. yes, you dont have to figure out which way the cable goes now, but hardware designers are suffering because of the shenanigans that is USB. My entire project was effectively scrapped because i didnt want to deal with the power draw bullshittery. Before PD it was easy enough for me to manage the power, but now, i need a whole load of supporting circuitry and have to touch datalines which my original goal was to avoid.
In short, i hate USB and its gone the way of the SCSI cable; getting more and more weird every year
> you dont have to figure out which way the cable goes now, but hardware designers are suffering because of the shenanigans that is USB
With all due respect, this is the way it should be. Hardware designers are inconvenienced so that millions of users don't have to be.
>Hardware designers are inconvenienced
So they end up with millions of implementations that do not meet the specifications, and in undocumented, unpredictable ways.
I could look at a SCSI device or a SCSI cable with my eyes and see what I was getting into with good-enough detail to understand the playing field I was dealing with today.
With USB C, my eyes don't help at all with devices nor with cables. Is it a power input? A power output? Both? Does it support a display? Is it USB 2, 3, or none? I have no direct way of telling -- my eyes don't help, and nor do my other senses.
Honestly, SCSI was more straightforward than the quagmire that is current USB standards, especially over Type-C. I can't trust the quality of cables or what they are capable of on the surface. I really need to do my homework to ensure I get the right transfer speeds and power delivery.
Once I was charging my SteamDeck using a cable I thought was quality, and the darn connector bit felt alarmingly hot to the touch. Turns out the cable wasn't certified for PD applications and was better for 5V @ 4.5W...
Just to avoid confusion, there is no such thing as a "PD certified" usb-c cable. All usb-c cables, by any version of the standard, have to safely support at least 3 amps at 20V. And for 5 amps they have to contain an active marker chip that's involved in the PD negotiation.
Any cable not fulfilling these requirements isn't allowed to called a usb-c cable, though I'm sure certain foreign manufacturers don't care.
Duly noted! Thank you kind stranger.
Anyone who likes SCSI didn’t have to deal with a 6 device SCSI chain.
> for most of the '90s RS-232-ish serial and its awkward sibling the parallel port were the norm for external peripheral
The parallel port was a nice way to have GPIOs in a computer back then. A bit like the GPIOs in today's SBCs, but more rudimentary.
Sometimes you read a post somewhere and the thoughts expressed stick with you for years. Decades even.
Once case for me is a post someone wrote in the late 90's that was concerned about parallel ports going away and everything being subsumed by USB et al, cutting off hobbyists and experimenters. It made a lot of sense at the time, and I've thought about this many times since.
Obviously USB has been widely embraced and is highly successful for experimenters, hackers, etc. Whatever friction it causes is so vanishingly small that few people today even suspect that there might be any reason for concern.
But yeah, I get what you're saying: built-in GPIOs on every box by default used to be a thing, and it would be cool to have even now.
Android is a Linux. This means that it can have a keyboard, mouse and other periferials. You could (and probably can) even burn a CD using an Android phone. One of the nice things in OTG was to connect an external screen which is turning the phone to a full blown computer. Or a media player...
HAHAHA! NAÏVE PERSON!
You couldn't watch Netflix on USB OTG. Because... because of... REASONS YOU STUPID PIRATE!!! OR FUTURE PIRATE!!! OR FUTURE WANNA BE PIRATE! YOURETOCLOOSSEETOBEEINGPIRATEYOUPIRATE!
____
disclaimer: I do not want to offend anyone. Above sentences are what I hear in my head when I see that my phone with USB OTG/USB-C is not showing the video on my tv or monitor, or even showing but only subtitles.
disclaimer 2: connecting screen using USB OTG was called MHL, not all devices had (has?) it
Android being based on Linux doesn’t mean it has all of the capabilities of a Linux distribution anymore than iOS being based on BSD or even more relevantly being a fork of MacOS means it can do everything that Macs can do.
As far as connecting an external monitor, that’s a standard USB C alt mode that your phone doesn’t support.
https://www.benq.com/en-us/knowledge-center/knowledge/usb-c-...
My iPhone 16 can send video and power to my USB C portable monitor over one cord. It can only drive the monitor as far as power up to 50% brightness.
If I plug in a separate power supply to the second USB C port on my monitor I can run my monitor at full brightness and the monitor will charge my phone while my phone is sending it video.
Of course my laptop supports powering and video at full brightness over one USB-C port
What I describe is my genuine experience. I had a phone with usb otg with MHL. And netflix app didn't send video to the screen of the TV. It sent only text of subtitles. Because of some stupid limitations.
MHL is different than using the more modern USB-C Alt mode. In the image link I posted above, that was my iPhone connected via USB C watching “Breaking Bad” on Netflix while I was waiting on my flight in a Delta lounge.
This is totally the fault of your hardware for not supporting part of the USB C standard.
Even Google just started supporting it last year.
https://www.androidpolice.com/google-pixel-9-display-output/
I'm honestly a bit confused about what your actual point is. Most people would agree that HDCP is hostile to consumers, but what does any of that have to do with USB or for that matter android? It sounds to me your problem is that your particular MHL implementation just didn't support HDCP. And AFAIK MHL has nothing to do with the USB standard other then reusing the connector to speak their protocol.
You're right, if this MHL implementation didn't have HDCP it would behave exactly like that. Sad.
My thinming is square. I still connect my monitors using SVGA and watch movies on them. Truly this sounds to really complicated that a phone which is indeed a computer cannot do computer things. My first android was closer to my Linux than every each version following. My colleague had SSH server on his Motorola phone. What I moan about is that limiting, strangling list of changes made to browsers and systems that is happening right now
> Truly this sounds to really complicated that a phone which is indeed a computer cannot do computer things.
I agree with that point, but I don't think that's what's happening here.
Go back a couple of years and you'll find tons of posts of people trying to get Netflix working on linux. People did find various workarounds of course, including really stupid things like changing the user agent of your browser, but it really wasn't working out of the box like it should.
So the problem really isn't that your pocket computer can't do computer things, but that HDCP is doing what it's designed to do, restrict people from using video streams in a way not envisioned by the designers. The fact that this is a (legally) legitimate use-case doesn't matter, it's just collateral damage.
> Go back a couple of years and you'll find tons of posts of people trying to get Netflix working on linux
That’s exactly what is happening. The newest Google Pixels phone that support DisplayPort alt-mode over USB C should work with the Netflix app.
You’re over indexing on Android being based on Linux
> That’s exactly what is happening. The newest Google Pixels phone that support DisplayPort alt-mode over USB C should work with the Netflix app.
? I think you misunderstood something, but yes this works now also with usb-c alt modes on newer laptops on linux, hence the "go back a couple of years" part of my post.
> Truly this sounds to really complicated that a phone which is indeed a computer cannot do computer things
An iPhone with USB C supports most of the standard protocols you would expect - video, Ethernet, audio, external storage (USB 2 speeds on non Pro models and 10Gbps on pro models), and wired keyboards and mice.
I suppose you cannot watch Netflix on anything not having a certified DRM-supporting display tract, up to the encrypted HDMI interface. Were it not so, you could PIRATE a movie for free! (Now you need to pay for a $30 HDMI splitter, or something.)
I don't do Netflix, so I don't care. Youtube works fine.
Yeah all I think about when I connect a device to a monitor is PIRATING ARRR!
Does android actually support USB CD drives?
Reading, yes. Writing, I have not tried.
I believe I have seen an external CD drive for android, but not sure. It was quite expensive, but maybe because it was having some middleware
> Android is a Linux.
Can you run unmodified LibreOffice or Wine on it? I can on my Librem 5.
Android can run a full-blown Linux desktop distro in a chroot[0] - so yes, you absolutely can run LibreOffice on stock Android if the mood strikes you. I haven't tried it wine[1], but I don't see why one wouldn't be able to run x86 Wine on x64 Android hardware - it's not an emulator, like it says in the recursive acronym.
0. https://www.reddit.com/r/termux/comments/1e6ahlg/how_do_i_in...
1. Because I don't own x86-64 Android hardware, and it's usually pretty awful (Dell Revue).
> Android can run a full-blown Linux desktop distro in a chroot
By that definition, Windows is a Linux, too (with WSLv1).
If you're playing fast and loose and consider a chroot running under a the devices' kernel (that also handles all syscalls directly) to be the same as a hypervisor, then yeah, Windows is approximately a Linux distro by the same loose considerations. Tomato/tomato: hiring a translator is basically speaking the language, right?
On the other hand, if you're a syscall purists and are particular about the dependency on virtualization microprocessor extensions (or the lack thereof), then the stack requiring a hypervisor to run a guest isn't equivalent to the OS it's hosting.
Bottom line is: if you have a shell access/ a terminal emulator on stock Android, you can configure it to run a desktop Linux using the kernel loaded on the device without installing am emulator or hypervisor. To me, this is materially different to WSL or ChromeOS' crostini.
Man, I hate that name. Why not just call it "host mode," which actually conveys information?
[flagged]
[flagged]