Slashdot Mirror
Apple's Lightning-to-HDMI Dongle Secretly Packed With ARM, Airplay
New submitter joelville writes "After noticing artifacts and a 1600 × 900 image in the output from Apple's new Lightning Digital AV Adapter, the Panic Blog sawed it open and found an ARM chip inside. They suspect that video bypasses the cable entirely and instead uses Airplay to stream three inches to make up for the Lightning connector's shortcomings."
Can someone please explain this with a car analogy?
So I guess it may be possible to reprogram the ARM chip to maliciously invade the users computer.
Might it even be possible to turn the adapter into a minion of evil by just connecting it to your computer assuming you have the right software running?
So borrowing someones AV adapter can now be a security risk?
Doubtful. More likely that it's streaming encoded digital video via the cable itself, and the components on the connector just decode the stream.
Perhaps this is a slight step forward, as far as technology is concerned, but it's a big leap back, as far as consumers are concerned...
My sig can beat up your sig.
That seems a bit of a sad method ... selling it as a cable, anyway. It's deceptive.
Remember when Apple was known (at least by the general public) as being the company with simple, elegant engineering?
How the mighty have fallen. Really, needing a computerized cable is just silly.
Was the change really worth it?
With its limited pin count, it's not a surprise that the Lightning connector does not have the bandwidth to transfer uncompressed video. But it's disappointing for it to be so bad at compression, with the MPEG artifacts shown in the article, plus latency issues with encoding/decoding. On that point, the old connector was better, and micro-USB3 would have had enough bandwidth to avoid the issue completely.
What happens if you just turn on airplane mode on the phone and try to use the adapter? If it's really creating an ad-hoc network to do this, the output shouldn't work. Disappointing to hear about the quality of the image, regardless of how it gets there. Apple, you can and have done better.
The main advantage I could see is video editing but adding artifacts makes me want to stick to my firewire machine.
With its limited pin count, it's not a surprise that the Lightning connector does not have the bandwidth to transfer uncompressed video.
Good grief. How many pins, exactly, would you say are needed for a serial connection?
Now look at the end of any USB cable and the end of a Lightning connector. What is the pin count between the two?
micro-USB3 would have had enough bandwidth
Also look at how many pins are in a USB 3 connector (HINT: ITS THE SAME).
This issue has nothing to do with bandwidth from Lightning.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Of course it has a CPU in it. Something has to do the protocol conversion.
It's not clear that Apple's AirPlay protocol, which has HTTP connections in both directions, is involved. But the pictures indicate compression artifacts. The original article doesn't go into enough detail to determine whether image compression (like JPEG) or motion compression (like MPEG) is being used. An MPEG compressor would introduce visible lag between the master and slave screens.
It's not a lie, it says "UP TO" 1080p. Mathematically speaking that's "less than or equal to (<=)". If it had then supplied something with a resolution greater than 1080p, well, then it would have been a lie. 1600x900 is less than 1080p, so it's correct! ;-) (All cynicism provided free of charge!)
Too bad there was basically nothing in the article demonstrating they'd attempted to test the hypothesis. They cut it open, found an SoC, and started speculating.
Any of this is certainly testable.
#DeleteChrome
would be interesting to know if the chip can be reprogrammed,.. to do other stuff you or the ?Apple? wants,....
Whoa. Are you saying this is applying HDCP to everything it plays?
That would be very interesting, since if I made a video of my own and played it through this device, the television would be descrambling a technological measure which limits access, without my authorization. That's circumvention. This device from Apple, would cause the manufacture and sale of all HDMI compliant TVs to become illegal.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
What a waste of psilocybin....
Remember "News for Nerds, Stuff that Matters"? Help make it a reality again! http://soylentnews.org
I think we are missing the point a little here, They released a tiny computer for 50 bucks, now we just need a port of cyanogen for it.
ultra hdmi
The serial/parallel distinction is completely useless in here. But you're right on the pin count.
There are 9 pins in a full size USB3 connector, and 8 pins in a Lightning connector. But when the lightning connector has two data pairs, USB3 has a bidirectional pair for legacy, and two single-direction pairs for high-speed traffic. HDMI, and Displayport respectively have 3 pairs (+ 1 differential clock) and 4 pairs.
The real question is the nature of the signal on those pairs. USB2 is 480Mb/s with a lot of protocol overhead, HDMI has 3.40 Gb/s with only error correction, and USB3 is 5 Gb/s, but still has (parts of) its inefficient protocol. Depending from what Apple is doing, it could route only the high-speed signaling of USB3 on the Lightning connector's two pairs, and provide the same performance as a standard USB3 cable.
However, since Apple keeps all information about Lightning under wraps, only insiders can tell. And until now, all we've seen is quite underwhelming, with USB2 data cables, and now this adapter.
You're such a giant wanker, Kendall.
Fact: Apple has an ARM processor in the cable. It is fair to assume the video is processed by the chip in the cable.
The rest of the facts in this case are just speculation:
* Is design a 'limitation', or a design choice?
* Is the 1600x900 output seen by Panic a Panic problem or an Apple one? Is it a bug or a limitation of the hardware? File a bug and find out
* Is the connector providing Airplay over the 6cm cable? Pure speculation. Sounds plausible, even clever, but that is just a guess.
It seems to me that there is certainly an interesting story in this adapter, but I don't think we know what that story is yet.
See I can give people who use micro-USB a bit of a pass. You are using a standard that doesn't have enough pins/BW/whatever for HDMI. Fine, that is the price you pay for using a standard (though as you noted it can be extended as Samsung did). However Apple's is fully custom. They made their own connector. So why the issue? Why was it not designed properly in the first place? They could have, they just didn't.
It's like having a 300HP engine in your fancy new sportscar, but all it does is turn an electric generator that delivers 50HP to the electric drive motor.
In other words, a poorly scaled series hybrid. Car buyers would eat up Apple Motor Company's excuse: "This oversized engine charges the car's battery pack more quickly so that you're not carrying so much fuel around all the time."
Wow, not only did you not read the article, you didn't even look at the pictures, did you?
Stop the presses! The are scaling 1024x768 content to 1600x900,
The cable is advertised as doing "up to 1080". It does not.
and there are MPEG artifacts happening as a result?!?! The deuce you say! There's never artifacts when you scale things! Never, I say!
Did you look at the picture? Those are not scaling artifacts: there is noise around edges. Those look like artifacts from MPEG or a similar compression algorithm. If it was just scaling, it would introduce aliasing patterns, which is not what they are talking about.
Next thing I know, you'll be claiming that Apple didn't replace all the already transcoded content on the Inktomi CDN with new, higher resolution content over night!
What does that have to do with this discussion?
It's almost already too scandalous that they used a CPU and software to avoid having to design and spin silicon for a Lightning-to-HDMI converter ASIC.
In fact, it looks like they did create an ARM-based ASIC, which on the face of it is bizarre to find in something sold as "an adapter cable". It's obviously doing something much more than or quite different from your standard adapter cable.
I can only echo some of the sentiments expressed in the bad ratings they received in several reviews from owners of Samsung Televisions which improperly negotiate EDID information by failing to negotiate on input sources which are not selected at the time the device comes online. One would almost think this might be an issue for Linux systems when trying to use HDMI to output to Samsung equipment, or that Dish Network DVRs might have similar problems (with the fix being to plug the device into the input channel which is selected by default when the television is powered on).
EDID? Linux? What? The article doesn't mention those topics at all. It's talking about an ARM-based chip that was unexpectedly found in a new model of a supposed "adapter cable" from Apple that is providing results that are substantially inferior to what was available on older models of Apple's similar products. As a result, if you use this cable to attach your iWhatever to a TV, you get laggy, downsampled, artifact-laden video, where Apples previous products and products from their competitors deliver sharp, un-transcoded 1080p video.
Consider this hypothetical: Movie studios license their works to cable and satellite networks. The studios and networks want to measure to what extent HDMI playback from iDevices competes with cable and satellite TV. (In this case, playback on the internal display of a mobile device is considered complement, not competition.) So they get Apple to add something buried in the protocol between the iDevice and the adapter to measure this. The ARM microcontroller in the adapter measures the screen size of the device on the other end of the HDMI cable and reports it to the iDevice, which sends it to Apple the next time the device connects to iCloud.
[Proprietary] firmware blobs have been the curse of linux driver developers for years. RAM is cheaper than custom-masked ROM.
But RAM is also more expensive per bit than flash memory. Ideally, SoC firmware blobs would be stored in flash on the device.
Very few people will ever wire their iDevice to a display when AirPlay works so well over wireless. This is a non-issue.
The Lightning connector appears not to have the signal integrity necessary to support the serial bit rate needed for 1080p video.
There is no problem with data transfer rates across Lighting being any slower than the older cables, and I have never had an issue with 1080p content across USB2.0 (which has a lot of overhead).
The number of pins has nothing to do with it.
Which was one of my points. You can't just look at something and say "my, that doesn't have a lot of pins, the bandwidth must be terrible".
Micro USB 2.0 connectors support 1080p video via MHI. I don't know why Apple were unable to match that relatively mature
Wow, I don't get why Apple would drop an ancient technology used by very few people any more. No idea at all why they wouldn't support every standard back to bird-calls used by tribes in Africa.
Apple did what they always do. Drop a technology a bit ahead of the point it's obvious the need for it is gone, and provide a legacy compatible bridge.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Sending video through Airplay is WAY easier than keeping cables around to hook up an iPad to a display
As opposed to keeping cables around to hook up a $99 AirPlay receiver to a display?
and having to know how to switch video inputs (still an unfathomable mystery to many)
If it's unfathomable to switch inputs to the iPad, it's just as unfathomable to switch inputs to the Apple TV.
I've fallen and am only outselling everyone else in the market by a huge margin!
Do you want me to go dig up the story about Nexus tablets outselling the iPad? I will if you want.
The electronics involved have nothing to do with AirPlay, and this is not "news" in any way. Sorry to ruin excitement and conspiracy theories... :-)
I am willing to bet serious money that all these chips do is decode whatever proprietary protocol Apple uses for transmitting video over the Lightning port to a standard HDCP protected HDMI signal. This is needed because the Lightning port has no other way of transmitting the video - and this has been clear from the day Apple revealed the Lightning port to the world. It is really just a high-speed 8-pin serial connector. Nothing else.
In addition the chips probably try to introduce a classic vendor lock-in factor, making it hard for 3rd party vendors to provide similar cables and accessories for the Lightning port without paying royalties to Apple (read: legal tech-extortion).
Also, the scaling-problems mentioned are without a doubt due to the screen-mirror scheme involved. If they streamed an actual 1080p video file directly, the result would likely be very different.
The speculation in the article is so far from reality it almost hurts... They get points for taking it apart and all, but they could have reached the correct conclusion merely by reading up on the existing specs of the Lightning port (if they had bothered to add a bit of digital-video knowledge from Wikipedia that is).
- Jesper
My security clearance is so high I have to kill myself if I remember I have it...
does it run linux?
...except my Apple ethernet cable needed a firmware update.
found this nice gem this week: https://www.reflectorapp.com/
the entire office was tripping on it once I unleashed it to the sale guys!
Hey!, It's an Apple product, what did you expect?
My karma is bad. Don't get too close!!!
Fry's had the latest phones up on one of their ads, and they're claiming the Nexus 4 is a 650 dollar phone with 500 dollar instant rebate on 2 year contract.
My friend currently has one on order from google, but given that kind of scamming from the carriers, who here thinks these phone prices are even close to the actual cost/potential retail price of the items?
Airplay is not involved in the operation of this adapter.
It is true that the kernel the adapter SoC boots is based off of XNU, but that's where the similarities between iOS and the adapter firmware end. The firmware environment doesn't even run launchd. There's no shell in the image, there's no utilities (analogous to what we used to call the "BSD Subsystem" in Mac OS X). It boots straight into a daemon designed to accept incoming data from the host device, decode that data stream, and output it through the A/V connectors. There's a set of kernel modules that handle the low level data transfer and HDMI output, but that's about it. I wish I could offer more details then this but I'm posting as AC for a damned good reason.
The reason why this adapter exists is because Lightning is simply not capable of streaming a "raw" HDMI signal across the cable. Lightning is a serial bus. There is no clever wire multiplexing involved. Contrary to the opinions presented in this thread, we didn't do this to screw the customer. We did this to specifically shift the complexity of the "adapter" bit into the adapter itself, leaving the host hardware free of any concerns in regards to what was hanging off the other end of the Lightning cable. If you wanted to produce a Lightning adapter that offered something like a GPIB port (don't laugh, I know some guys doing exactly this) on the other end, then the only support you need to implement on the iDevice is in software- not hardware. The GPIB adapter contains all the relevant Lightning -> GPIB circuitry.
It's vastly the same thing with the HDMI adapter. Lightning doesn't have anything to do with HDMI at all. Again, it's just a high speed serial interface. Airplay uses a bunch of hardware h264 encoding technology that we've already got access to, so what happens here is that we use the same hardware to encode an output stream on the fly and fire it down the Lightning cable straight into the ARM SoC the guys at Panic discovered. Airplay itself (the network protocol) is NOT involved in this process. The encoded data is transferred as packetized data across the Lightning bus, where it is decoded by the ARM SoC and pushed out over HDMI.
This system essentially allows us to output to any device on the planet, irregardless of the endpoint bus (HDMI, DisplayPort, and any future inventions) by simply producing the relevant adapter that plugs into the Lightning port. Since the iOS device doesn't care about the hardware hanging off the other end, you don't need a new iPad or iPhone when a new A/V connector hits the market.
Certain people are aware that the quality could be better and others are working on it. For the time being, the quality was deemed to be suitably acceptable. Given the dynamic nature of the system (and the fact that the firmware is stored in RAM rather then ROM), updates **will** be made available as a part of future iOS updates. When this will happen I can't say for anonymous reasons, but these concerns haven't gone unnoticed.
"Based on a [December] survey of 2,400 consumer electronics stores in Japan, Google's Nexus 7 tablet had 44.4 percent of the market versus the iPad's 40.1 percent, according to Nikkei, Japan's largest business daily."[1]
[1] Brooke Crothers. "Google Nexus 7 tops iPad in Japan: Is this a trend?" CNET, January 16, 2013.
So how did I fail?
I was under the impression that adding a micro-HDMI output to a device that can play videos rented from Google Play required an HDCP license, and those weren't exactly free.
Stop the presses! The are scaling 1024x768 content to 1600x900, and there are MPEG artifacts happening as a result?!?! The deuce you say! There's never artifacts when you scale things! Never, I say!
Ahh I see. You must be from marketing. How clever of you to put a positive spin on the story that the result is they now must scale 1080p down to 1600x900, a notable step backwards from their previous design which could do native 1080p uncompressed.
Maybe it's not marketing, maybe it's just reality distortion.
To reply to myself.. The harddrives were quantum's. Here is an article in infoworld from 89 about it. Titled "Mac IICX, SE/30 users report drive failures"
http://books.google.com/books?id=wDAEAAAAMBAJ&pg=PT32&lpg=PT32&dq=mac+SE30+hard+drive+failures&source=bl&ots=O-OI7Qd-Z2&sig=Wd2zMHjgAu5Afr0NhURcAoRqwUc&hl=en&sa=X&ei=6L4yUYfaAo2LrQH32oC4AQ&ved=0CHEQ6AEwCQ
Baaaaaa baaaaaaaa...
Steeeve Steeeve
This is so extremely disappointing. The most informative post here describing exactly what's going on gets modded as Overrated. On the other hand, a whole SLEW of misinformation and "Apple hate" gets modded +5 Informative.
Really, sometimes I feel that the majority of Slashdot's posters are high school students who haven't learnt the basics of research and verifying information before shooting off a comment.
P.S. I'm neither pro nor anti Apple. I disagree with their consumer lock-ins but appreciate that they sparked off the smartphone revolution and development.
I'm still waiting for the uber hdmi.
-- This space for lease, low setup fee, inquire within!
Yes, one should never buy a product that others do not like.
-- This space for lease, low setup fee, inquire within!
"Not only that, but they can shift faster than 95% of people can shift a manual transmission"
I suspect from this you don't drive a manual car. When I see a *potential* problem ahead that will cause me to accelerate or decelerate, I drop it down into 3 or 4 BEFORE I make the actual maneuver so the engine has time to get its revs up. If I need to react the car is already in gear and revved to match. Likewise if I see an overtaking opportunity, I'll drop it down to be ready to accelerate.
So automatic drivers think its about the time to switch gears and its really not. The gear change is done long before it's needed, and sometimes JUST IN CASE it's needed. The delay is the engine adjusting its revs, not the gear change.
There's other things I miss about my manual car too. If I want to steadily slow the car without the brake lights (to prevent a que of cars behind me panic braking), I drop it down a gear and steadily slow it down. They don't see a brake light and panic, and I get to slow the car and drop into the slower lane smoothly. On an automatic, the lights come on, they don't know if I'm sharp braking or smooth braking and it's panic time behind me.
Then there's the clutch. You think its just to smooth the power on and power off. But it isn't, if the road is slippy easing the clutch on lets me test the grip. In slow speed traffic coasting in neutral with occasional partial lift of the clutch to keep it going is an easy way to drive. It's as much a driving control as any other.
I've tried quite a few automatics here, the VVTs truely suck, the shifters have the engine lag, none comes close, but people don't want to learn stick these days, so it's difficult to get the model I want with stick.
HDCP (the drm stuff) is essentially licenced from Intel. Intel only basically agreed to allow HDCP to be used on DVI and HDMI (originally) and only reluctantly allowed it for DisplayPort only after Intel's competing technolgy went bust (and vesa basically threatened to use another drm scheme which intel would then have to license).
Since it's unlikely that intel would have licenced HDCP to Apple for this purpose, it's likely that Apple was forced to use their own drm scheme between the lightning port to the hdmi dongle to comply with the licencing requirement for external monitor connections and the only way they could deploy it was to have a chip made to implement it or put it in software on an ARM chip.
if you need for some reason real 1080p streaming physically from an iPad you can always buy an iPad 2 or 3
You are an incurable retard. It looks like you've been sucking Apple's cock for so long, and taking it so deep, that its pressure has forced your brain out of your ears.
Nuff said
Wow, not only did you not read the article, you didn't even look at the pictures, did you?
I looked at the pictures. I saw artifacts from scaling 1024x768 4:3 aspect ratio content to 1600x900 16:9 aspect ratio content from source material encoded at 1024x768, with intentional watermarking to identify the iTunes account that the data was pulled down from. Do you often watch your television with a microscope?
The cable is advertised as doing "up to 1080". It does not.
I'm not sure I buy the information in the blog post. Specifically, the thing that drives the EDID negotiation is the display device; it states what resolutions it supports, and the device driving the display picks from that list and advertises it back to the display. If the EDID negotiation in the display device isn't working correctly (many don't), or the information communicated over the input port is just plain incorrect, then it's going to negotiate down using the set of defaults that the device providing the input signal uses when the display device fails to adhere to the standard.
I've already pointed out that there are a large number of Samsung Televisions which will not negotiate EDID on inactive channels. This causes problems with Samsung Chromebooks when used with these televisions, unless you hook them up to the default HDMI input so that the input channel is active at the time. Ideally, the Linux video stack would workaround this problem by reattempting to negotiate an EDID periodically until it was either successful, or hell froze over, whichever came first. When Google was working on the Chromebooks and first encountered the problem, Samsung was able to supply beta firmware updates for the Television to allow the negotiation to happen on unselected but electrically active channels.
So those numbers in that blog post are for the EDID information being advertised by the display, and it's no wonder that the display is only offering 1600x900 (I would not be surprised if instead of a Samsung TV, the problem device was a DELL monitor instead).
Here's another TV that has the same problem as some of the Samsung TV's; it's a Kogan KGN1080P32VAA, and it actually fails to advertise the correct EDID information at all. You can work around the problem by stuffing fake EDID information into the nVidia card driver, but it's not at all surprising that Apple doesn't provide you with the ability to do this with their cable: https://forums.geforce.com/default/topic/478250/working-around-tvs-with-defective-edids-useedid-works-but-kills-hdmi-audio/
Alternately, you can continue to buy crappy displays with busted firmware, and workaround the handshake issue by buying a box like this one: http://www.vidabox.com/products_dr_doctor_hdmi.php to let you set the handshake see by the Apple cable to be correct.
Did you look at the picture? Those are not scaling artifacts: there is noise around edges. Those look like artifacts from MPEG or a similar compression algorithm. If it was just scaling, it would introduce aliasing patterns, which is not what they are talking about.
Unless they ripped the content themselves from a DVD to load onto the iPad Mini, I'm going to go with them having either downloaded a torrent (notoriously bad compression artifacts), or having downloaded it from the iTunes store (720P, always scaled, 1024x768, different aspect ratio from what was being displayed).
Next thing I know, you'll be claiming that Apple didn't replace all the already transcoded content on the Inktomi CDN with new, higher resolution content over night!
What does that have to do with this discussion?
It's all encoded at 1024x768 4:3 aspect ratio; that's what it has
that's just what they call ultra hdmi in sweden
Really, I wonder if I'm missing the point of this outcry. I think putting a chip on the dongle to offload the decoding of video streams to HDMI to be a really elegant and scalable solution; possibly even scalable to the point of doing 4K video with a more powerful ARM chip.
The bandwidth of the Lightning connector itself is easily in the same range as USB 3 (10Gbbps) and the limiting factor is the hardware in the iPad/iPhone which is limited to USB 2.0 spec type speeds across that connector. There's no technical reason that future devices won't up that to USB 3 speeds, but the chipsets just aren't there yet. Once upped into that range, there's no reason that uncompressed 1080p video can't be pushed through that interface (approximately 3Gbps at max throughput, FYI). Again, the limit isn't the Lightning connector but rather the chipsets in the current range of devices. I don't have all the specs off-hand, but it's quite likely that the Lightning connector is actually capable of faster speeds, but the standards for that don't exist yet.
Besides, this is where I think I'm missing the point: Why the hoopla? This is a consumer-grade device (iPad/iPhone) and we have some guy who's got his ass chapped by the fact that it can't output uncompressed 1080p video through it's current connector? Uhm... OK. The 30-pin adapter got around this by having discrete video output on its own pins... the Lightning connector is purely a data connection. Yes, this change to only being able to get compressed video out at USB 2 speeds does seem to be a bit of a step backward, but again this is a consumer-grade device and should be treated as such. If you're using it for playback of video that must be 1080p in all it's uncompressed and perfect glory then you're really missing the point and probably need... Oh I don't know... a laptop with HDMI out? Or Thunderbolt if you're really an Apple fan?
I'm not an Apple apologist; I am typing this on an Alienware laptop running Ubuntu and my phone is a Galaxy Nexus... yes I have a Macbook Pro as well and it's a great laptop, but I in no way a fanboy. I just realize that this is a pretty elegant solution that's really scalable and interesting... but you have to remember this is for a consumer-grade device, not professional. This is for displaying your holiday pictures on a big screen, or playing back your holiday videos to the great chagrin of your friends... this isn't for reviewing takes between shots of the latest movie blockbuster... Apple sells better hardware for that. So do many other manufacturers.
All that being said; there's no technical reason that future generations of the iPad/iPhone won't be able to output 1080p uncompressed through Lightning... the limit is not the new connector but rather what the device itself can output. This dongle design is actually a really good idea... faster ARM CPU in there and you've got massive scalability.
The only person it doesn't suck for is someone who doesn't use it, and therefore has no dog in the fight.
I actually do use video from an iPad at times. That's how I know it's too fiddly a proposition for most people.
For me it doesn't matter though because I have an iPad 3 that still includes the original dock connector. There are millions of these to be had, cheaper now even if you buy used or refurb. Any of the dwindling number of people who NEED 1080p from a tablet can simply get one of these instead of a newer tablet with a Lightning connector.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
An anonymous coward on Panic's blog posted this. They elude to that fact they work for Apple and have knowledge about this technology.
Airplay is not involved in the operation of this adapter.
It is true that the kernel the adapter SoC boots is based off of XNU, but that’s where the similarities between iOS and the adapter firmware end. The firmware environment doesn’t even run launchd. There’s no shell in the image, there’s no utilities (analogous to what we used to call the “BSD Subsystem” in Mac OS X). It boots straight into a daemon designed to accept incoming data from the host device, decode that data stream, and output it through the A/V connectors. There’s a set of kernel modules that handle the low level data transfer and HDMI output, but that’s about it. I wish I could offer more details then this but I’m posting as AC for a damned good reason.
The reason why this adapter exists is because Lightning is simply not capable of streaming a “raw” HDMI signal across the cable. Lightning is a serial bus. There is no clever wire multiplexing involved. Contrary to the opinions presented in this thread, we didn’t do this to screw the customer. We did this to specifically shift the complexity of the “adapter” bit into the adapter itself, leaving the host hardware free of any concerns in regards to what was hanging off the other end of the Lightning cable. If you wanted to produce a Lightning adapter that offered something like a GPIB port (don’t laugh, I know some guys doing exactly this) on the other end, then the only support you need to implement on the iDevice is in software- not hardware. The GPIB adapter contains all the relevant Lightning -> GPIB circuitry.
It’s vastly the same thing with the HDMI adapter. Lightning doesn’t have anything to do with HDMI at all. Again, it’s just a high speed serial interface. Airplay uses a bunch of hardware h264 encoding technology that we’ve already got access to, so what happens here is that we use the same hardware to encode an output stream on the fly and fire it down the Lightning cable straight into the ARM SoC the guys at Panic discovered. Airplay itself (the network protocol) is NOT involved in this process. The encoded data is transferred as packetized data across the Lightning bus, where it is decoded by the ARM SoC and pushed out over HDMI.
This system essentially allows us to output to any device on the planet, irregardless of the endpoint bus (HDMI, DisplayPort, and any future inventions) by simply producing the relevant adapter that plugs into the Lightning port. Since the iOS device doesn’t care about the hardware hanging off the other end, you don’t need a new iPad or iPhone when a new A/V connector hits the market.
Certain people are aware that the quality could be better and others are working on it. For the time being, the quality was deemed to be suitably acceptable. Given the dynamic nature of the system (and the fact that the firmware is stored in RAM rather then ROM), updates **will** be made available as a part of future iOS updates. When this will happen I can’t say for anonymous reasons, but these concerns haven’t gone unnoticed.
Bummer, I was wrong. 1201(a)(3)(2). If DRM is applied without the authority of the copyright holder, then it is not circumvention to defeat it.
Everybody, please send along a statement whenever you share your home movies: "I grant authorization to all parties, to apply technological measures which limit access to this work. I do not grant authorization to any party, to bypass or descramble any such measures."
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
The new connector isn't technically a connector. It's just a bus.
It doesn't have any pin for any function (no audio, no video, no nothing), it only has data lines which speak to the electronics inside.
The actually I/O isn't handled by the connector. It's handled by a chip embed in the things you are connecting.
Want a (micro-) USB connector ? But a USB chip in the cable.
Want a video out port ? Put a chip generating video inside the AV adapter (exactly as in TFA).
Want compatibility with old iPhones ? Put a large chip which output audio, video, usb, and tons of other things like the original iPod connector - you can actually use the same output component as the original ipod, except they are not soldered on the phone's mainboard, they are piloted by an embed chip which talks to the phone over the serial line. (That's also how they can justify the expensive price on the lightning-to-apple-dock adapter: it's not a dumb cable it has all the signal generator chip inside)
This is similar to they way a ISA/PCI/PCIe bus works in a desktop PC or PCCard in a laptop. Want more USB or Firewire ? Just put a PCI card with more ports. Want video out? Add extra graphic card. And so on.
After they made such a big deal of the new dock connector
Apple has 2 massive adantages :
1. Electronics is moved out of the device.
Imagine that suddenly USB is phased out of market and replace by a new and incompatible "Magic Bus Plus".
- With Apple Dock connector: oops, sorry we don't have MBP lines on the connector. we can't do it now. (The only solution would be to deprecate some older unused lines and put MBP lines on it in newer phones. Older phones don't support MBP, but newer support it, at the loss of some other functionality. Example: over time FireWire was removed, and Video capability was added).
- With Lightning connector: well, put a chip supporting MBP inside the MBP cable, duh...
2. Apple control.
Of course everything is authenticated, signed, etc.
- With Apple Dock: any device can tap the useful signals in the dock (audio, control, etc.) to build whatever device they want. Apple can still try to sue them if they didn't license their stuff, but good luck suing asian no-name brands
- if any device want to talk to any apple iGadget, it needs to obtain the necessary keys. Apple sells them for a price and if they don't like a gadget, they can revoke its keys. After the next iTunes sync, the device won't work anymore.
Now this has a massive PROBLEM for Apple:
iGadget are portable device. They are slow.
Whereas in my example PCIe is a rather fast bus and you can power lot of useful electronics (even graphic cards), the lightning connector is slow (that's actually pretty normal for a phone. in the embed world where I2C is still used a lot).
It might be a lot faster than other typical phone connection, but it still pales in comparison to Thunderbold (which packs a display-port stream in addition to 2 PCIe channels).
It can't tansmit high quality digital video. The only possibility is for the iPhone to compress it and for the chip inside the adapter to decompress. Hence the limited resolution (1600x900) and mpeg artifacts.
For better video, the only possible solution is to wait for future versions of both the phone and the adapter speaking a much faster version of the protocol.
It's exactly the same situation as USB flash sticks: Yup in theory you could already use a USB bus to access mass storage back in the USB 1.x days. But it was fucking slow and useless for anything more than emergency access to some files.
You needed to wait until USB 2.0 to have decent speed at which point attaching mass storage device was practical, and now USB 3.0 even made it interestingly competitive.
Samsung's modified micro USB connector does uncompressed full 1080p HDMI
That's because said connector can also speak MHL.
MHL is a specially designed standard protocol to handle multimedia in
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]