Consumer Electronics Control
computer.rip
computer.rip
CEC on the flip side is wired only, only works with certain devices, and its success is dependent on manufacturers coming to some sort of agreement. CEC is missing some sort of bridge, something where other non-CEC devices can control everything on the bus. Something that can remap buttons for specific devices.
CEC has also led to a lot of devices outright not adding IR remotes to their setup anymore, which makes any sort of external control 100x harder and prone to failure. I have an LG OLED TV, Pioneer AV receiver, and an Nvidia Shield. My choices for remotes are either the Shield's terrible Bluetooth-based remote that eats 2xAAA's every week, or the LG's magic wand where anything other than the TV doesn't support the pointer and tons of buttons can accidentally be pressed resulting in webOS rearing its ugly head on my display (with ads as a bonus!).
With IR in the mid 2000's I could get a Harmony that would control every single device in my cabinet. If their database didn't have a remote's profile, you would have to learn the extra buttons and program it, but you could do it. There were certainly downsides, like activities were poorly planned and the lack of a bidirectional communication meant that the remote was often out of sync for what devices were actually on.
Honestly, as much as the post trashes on USB, I would almost want CEC's capabilities to be a part of USB. Let me route my USB keyboard, mouse, remote, gamepad, whatever to whatever device in the chain. Let me remap any of those buttons to talk to a specific device in the chain. Basically, let me have a KVM that relays inputs based on configuration.
Add to that the fact that 1. Some devices have separate "turn on" and "turn off" signals and some only hav a "power toggle" 2. My receiver had buttons that did not exist in Logitech's database. My attempts to have the remote learn them was only partially successful (like, it learned some of them properly and others never worked) 3. My screen was a projector that refused to turn on again until a 1-2 minute cooldown after it had been turned off (I assume to avoid heat stress on the bulb)
It was a right mess. When it worked it was great. The 5% of time it failed hard I had to dig out the individual remotes because the projector's cooldown made Harmony's attempt to fix things not work at all.
this was exactly what I found.
IR is fundamentally flawed because it is one-way. It is like UDP across a modem.
I went with Panasonic and don’t regret it for a second. The TV turns on in 10 seconds flat from standby to picture, there are no ads anywhere (it’s just not a thing Panasonic does), the OS is invisible, and the picture is amazing. For other readers: don’t buy LG garbage.
I bought it for what it was not (ie vizio, samsung, sony, tcl) I don't hook it to the internet and I have disabled the nonsense anyway.
Only really (really) annoying thing is the soundbar MUST be wifi, and it creates its own access point.
Can you even get a Panasonic OLED tv?
(also, I have found that unless you have a very dark room, the benefits of oled are lost, especially with dark movie scenes)
OLED is nice, I don’t regret my choice. But yes indeed if you only ever watch in a very bright room, you might not get most of the benefit from an OLED screen. I still find the colors more vibrant in any context compared to LCD and I love that the black is black (instead of greyish) but I can understand the premium isn’t worth it for everyone.
In any case, I understand what you mean by not Samsung or Vizio… These are dumpster fires when it comes to build quality, privacy, software quality, and after sales service/“repairs”
For those who don’t know the term, look up “automated content recognition” and see how Samsung sells absolutely all the data it can gather from your TV, your LAN, your watching habits, what you actually watch… creepy.
I should add on the Panasonic, most of the turning on time is spent switching refresh rate to whatever source it's showing.
It does make receiver-based setups more complicated; I feed my receiver through eARC and live with the slight downgrade in sound quality.
As a tiny example, by default when I turn off my AV receiver, my TV notices and turns itself off too. (Or maybe it's the reverse, or both. Don't remember.) This behavior is controlled by a poorly-named item deep in the TV's menu, and by enabling/disabling CEC on the receiver. (The latter is what I chose because it still passes CEC signals through source<->TV and has a better-defined automation protocol of its own.) Who knows if some other TV has the same default or has any way to control it, much less a way I can describe without getting into the specifics of each model.
To make it really useful for a well-controlled HA setup, I think at least I'd have to have some sort of device has a bunch of HDMI in and out ports and intercepts all the HDMI-CEC signals so the devices no longer talk with each other but instead with something I control. That takes it from an O(devices^2) interop problem to an O(devices) problem. Even then I'm not sure it's really tractable. There needs to be more standardization.
A bonus was that my TV didn't support CEC; it had one of those mini-audio-jack-looking RS232 connectors, and there happened to also be a Rust crate which spoke the protocol.
3 CEC breakout boxes = 1 for the PS3 + 1 for the receiver + 1 for what, given that the TV didn't support CEC? Did the receiver and PS3 have other automation options? In theory I'd like the idea of "just implement CEC and you're done". If that were really viable, I would have released my home theater controller in a form useful to people who don't happen to have the exact same media components I do. But my experience is the proprietary APIs are generally better. Some exceptions. My (ancient by now) Bluray player's REST interface has something like 200 ms latency. As a hint to why: the URLs contain `.cgi`. It's awful.
Such periods of unity must be savored, knowing the fleeting peace will vanish with the next device upgrade.
I hit cast from my phone and a couple seconds later everything is powered on and connected. Then the LG remote (RF not IR) does volume. Audio routes correctly between TV and receiver when I play back files on a USB SSD connected to the TV
If I turn on the PS5 or Apple TV, within a couple seconds the receiver and TV are powered up and working. If I turn on the other device, the receiver switches to its input. When I turn the active device off, the TV and receiver turn themselves off.
That is, until one of my kids goes out of their way to find the TV remote and turn it off manually. Then everything goes out of sync until I cut power to all those devices and turn them on again. At least it's an easy fix that doesn't require any manual configuration.
It's just enough of a pain point that I will look to see if I can stream a movie I already own on Blu-ray just to avoid the hassle of getting off the couch to load a disc and fiddle with remotes.
Yes, that is a very first world problem.
I have no idea what the status is, but there has been work on driver support for AMDGPU and Nvidia-supporting Noveau drivers dating back to 2018. https://www.phoronix.com/news/AMDGPU-Nouveau-CEC-Tunnel . The official kernel docs link forward to a pretty helpful https://linuxtv.org/downloads/v4l-dvb-apis-new/admin-guide/c...
It's notably CEC over DisplayPort AUX, not HDMI. It'd be super interesting to know if this would tend to work with HDMi adapter or not?
I did have a battle a couple years back, where my dad said the main thing keeping him from using the mini-pc & monitor and instead sitting at the desk with an old janky laptop was that there were keyboard shortcuts for adjusting the brightness. I tried like 6 programs and one (and only one) actually did let me adjust the monitor's brightness (via the Intel integrated graphics)! (And then wrote some gnome keyboard shortcuts to wire that up). I remember it being brutal, a slog, trying all sorts of stuff, but it was so rewarding to see (and made me so much happier than software dimming).
(Epilogue: dad still doesn't use that nice ass computer or screen.)
For many a years, CEV was something seemingly only available on raspberry pi & other sbc. It seems like CEC is still sort of an afterthought for most desktop environments. A pity! Ideally computers should be a nexus of control, but so often we accept the limited personas we are handed, don't delve deeper.
Interesting write-up! I'd only known abstractly about CEC, known there's some mind of toolbox of options in it & that most PCs don't really use that.
Universal: https://www.pulse-eight.com/p/104/usb-hdmi-cec-adapter
NUC specific: https://www.pulse-eight.com/p/154/intel-nuc-hdmi-cec-adapter
Raspberry Pis (at least the 2 and 4, so I'd guess the 3 and 5 too) also have CEC support built in. Same libcec/cec-client software as the pulse-eight adapter, but no dongle needed.
I have two TVs with a Roku soundbar connected to each. Sometimes when I wake each TV, the soundbar no longer connects so I get no audio. One TV is capable of displaying the volume level, but the other can't. My Playstation can accept directional and OK button presses over CEC, but my Roku can't despite that being much more useful. And if CEC is enabled on both, all hell breaks loose.
To be fair, in this case, the issue not "CEC doesn't work", but rather, "Roku broke compatibility".
You can control directional/OK on a Roku STB built into a Roku TV via CEC, the hardware supports everything just fine. But in software, Roku (intentionally?) implemented unusual (arguably proprietary) control codes to do it, instead of the normal ones everyone else uses. Roku will, however, happily pass along regular codes to a connected Playstation or Google TV stick or whatever other 'lesser' device you connect.
(assuming HDMI-CEC) You can work around this by injecting Roku-specific codes into your CEC stream. But like, no one should have to do that...
Though, does DP have something like ARC?
No, but it does have Multi Stream Transport (MST), which allows you to daisy-chain DisplayPort sinks to a source. It even supports sending only audio to a sink (see softcopy page 10 of [0]).
NB: that document was written in 2013. Capabilities in terms of available bandwidth have probably grown since then.
<https://www.vesa.org/wp-content/uploads/2013/05/Understandin...>