Mac Mini 2012 video blinking out

I think the issue probably just boils down to the fact that Intel has never been known as the maker of decent graphics chips, and it seems that reputation is well deserved. When I bought my first ever Mac (Mini) a few weeks ago I thought to myself that surely by now an Intel GPU would be OK for what I'm going to do with it (no games or high-end graphics) but even the ordinary, run-of-the-mill activities still are a bit much to ask of an Intel GPU [yes, maybe this is pessimism/alarmism, I don't care anymore].

My brother has just hit the "Place Order" button on a 15" Retina MBP and is expecting it in about a week, so I might even be able to get his Late 2011 Mac Mini by Sunday. Once I'm settled in, my ill-fated Late 2012 is going back for a refund. I think Apple probably need to go back to playing off ATI and NVidia against each other for a good deal, because it's looking more and more like the Intel GPU experiment being a spectacular flop.

As a new convert to Apple, this experience hasn't quite made me want to go back to Linux (and certainly not to Windows, I'm not that crazy!), so I don't want my comments to be taken as an attempt to continue the tit-for-tat arguments of recent days. But this Mac Mini is going to fetch much less on the second hand market down the track no matter what pans out, and my need to get onto a stable machine is paramount at this point.

Could it be that the firmware on Apple's HDMI to DVI adapter requires an update to avoid the problem? The following links demonstrate that if an adapter's firmware is outdated then video output problems occur:

http://support.apple.com/kb/ts3232

http://support.apple.com/kb/HT3492

Perhaps the solution lies in updating the firmware on the HDMI to DVI adapter...

No. The problem is clearly the Intel GPU. It occurs with straight HDMI out>HDMI cable>Monitor/TV too, no adapters involved. This is clear throughout the thread.

But it's another illustration of the difficulties involved in implementing the HDMI specs properly.

In listing the possible sources of the problem I didn't make any effort to assign probabilities. I agree that the most likely source is a problem with the mini, but it not the only possibility. I'm not an expert in HDMI by any means, so I can only give a hypothetical answer to your question about how the specification might be the source of the problem.

Video signals use some sort of sync pulse, often embedded in the video data. It is used by the display to synchronize a circuit called a phase locked loop (PLL), which depends on the sync pulse to remain locked. The PLL provides the internal clock for the display. That much is fact. Here's the speculation. It could be that the specification states that the display is to retain frequency lock even if some small number of sync pulses are missing, maybe as few as one. This could be done to prevent frequent loss of sync. Further speculation is that maybe the Intel chip changes its GPU clock speed when the chip is at idle. This would be done to reduce power consumption. Maybe during the changeover in clock speed a single sync pulse is missed. This might be allowable according to the spec. But it might be that few, if any, GPUs have ever taken advantage of that feature of the spec, so it really hasn't been tested. Along comes the Intel chip and when it skips a sync pulse, many monitors lose sync. Understand that this is just one hypothetical way that the spec might not have been followed.

No one tests every display design that claims to meet the HDMI spec. Compliance is usually derived from the component parts. If you use certified parts in your design, then the design is certified. (An exception is Military Spec where each design has to be tested and certified. This makes military grade hardware prohibitively expensive.) Some displays, even those from the same manufacturer, might use one HDMI decoder chip, some another. One chip might work with the mini, the other might not.

I presented this not to try to solve the problem. That's up to Intel and Apple. But rather to indicate how complex a problem this might be. Anecdote to follow in a subsequent post.

Computer system debugging anecdote:

In the 1990s a group of EE senior design students designed and built a computer under my direction. It was based on a passive (no motherboard attached) IBM-PC AT bus. It used the Motorola 68020 processor and could interface to custom PC boards or standard boards meant to work in IBM PCs. One senior designed the CPU board and attempted to interface it to a PC memory board through the bus. It had a glitch that happened only rarely.

We hooked the system up to a logic analyzer connected across the bidirectional bus tranceiver ICs. These were mil-spec 54HCTxxx parts, chosen because their pinouts were convenient. The logic analyzer looked at the inputs and outputs to the transceiver and was to trigger if they ever differed. Its triggering would also trigger a digital storage oscilloscope that would capture the actual waveforms. The system would run for over 24 hours straight without an error, so we didn't get many events to analyze.

We expected to find an error in our design. When the analyzer triggered, what we found instead was the the inputs and outputs of the transceiver were indeed different, but all of the timing was within spec. The oscilloscope showed that the voltage waveforms (levels and rise and fall times) were also within spec. The noise on the power and ground pins was within spec. We were left to conclude that the mil-spec bus tranceivers were faulty. We replaced the parts with 74HCTxxx parts, which required re-wiring of the CPU board, and all was well.

This goes to show you that the solution to a problem may not be in the most probable location. It took us days to solve this, and we didn't have to deal with meetings, lawyers, other departments, or other companies. We didn't have to run our "fix" through suites of tests. What may seem like an easy problem to end users can be a nightmare for engineers. We have to let them do their job and that can take time. That was really my only point in all of this.

dsmith, thanks for the effort of replying!

I'm aware of the difficulties of troubleshooting, especially problems that only appear briefly, non-frequent, randomly and non-reproducable. It's part of my daily job although in a different domain. I can confirm the solution to a technical problem is often found where it is least expected. I've had it multiple times we replaced all but one component in the chain, and the last one turns out to be the culprit.

The part about syncing the signal with PLL I understand, although I have difficulty imagining the problems we're seeing would arise from that. I've had the blackout's many times using VLC-player, I don't think the GPU clocks down or idles with VLC playing in a dual monitor setup (continuous video stream), with a bunch of other apps open at the same time. Okay, I know - there are thousands of other possibilities, you just mentioned that to illustrate the complexity, which I don't doubt, and it is indeed up to Apple & Intel to investigate, not us... agreed.

You lost me a bit with your anecdote about analysing transceivers with an oscilloscope, but hey, I get the picture ;-)

Thanks for the constructive thinking along.

No wonder my Mini DisplayPort to Dual-Link DVI Adapter cost $120! It takes firmware. I never knew what I thought should be a simple cable was firmware upgradable. You learn something new every day. In any event, I only started using HDMI to DVI because my Thunderbolt port died (probably in its sleep). I normally don't care for HDMI with my Dell U2711 27" display but am currently slumming for now it because that's the only way I can see my Mac Mini.

Hello all,

I would like to buy a mm, so I called apple in the Netherlands, and asked about the hdmi problems of mm. they were not aware of the hdmi problems ........

they had no complaints .....

I told them about this forum, and I wait to buy until I read here that the problem is resolved.

strength for all owners mm.

Greetings from Holland

Greetings! 🙂

Hi nnllkk,

that's weird. Apple NL should be aware of the issue. It has been mentioned earlier in this discussion. Also, I returned my mm which I bought in the Netherlands and received a new one, which has exactly the same problems. So I think it is a smart choice to wait with buying until the issue is resolved.

Cheers,

Iohanna

Recent article from yesterday. I don't know where Karen Haslem got her info, or how soon "soon" is......

http://news.idg.no/cw/art.cfm?id=FF34F221-CF49-368C-C4EDE5788409EA56

http://www.maclife.com/article/news/intel_aware_hdmi_flickering_issue_mac_mini_f ix_future

There's a ton of articles now when before there wasn't so that's good news. I'll save most of you the trouble......haha they all say the sameeeeee thing.

Laxman25 wrote:

Recent article from yesterday. I don't know where Karen Haslem got her info

If it's the same Karen Haslem that I'm thinking of then it's credible information. She used to work for Apple (helped launch the iPod) and now works for MacWorld. A firmware update would be good considering 10.8.3 probably won't be released until Jan/Feb. Hopefully everyone can put this matter behind them and start enjoying their mini's soon. Thank you for the link.

Whomever Ms Haskem is, she simply regurgitated the posting from the Intel forum - she didn't provide any further insight beyond a copy and paste. All those other reports on CNET, Maclife, etc about this issue were equally useless.

Does anyone know if this problem is present in mac minis with an Intel HD3000 graphics system?