HDMI-CEC (Polski)
HDMI-CEC (Consumer Electronics Control) to magistrala o niskiej prędkości transmisji (50 bajtów na sekundę) na złączu HDMI, która służy do komunikacji pomiędzy urządzeniami HDMI w "sieci". Głównie pozwala urządzeniom HDMI na powiadamianie siebie nawzajem, że powinny się włączyć/wyłączyć, że telewizor zmienił źródło odtwarzania albo, że przycisk na pilocie został wciśnięty poza innymi czynnościami. Na komputerach osobistych HDMI-CEC najbardziej przydaje się w konfiguracji HTPC (PC jako kino domowe).
Z różnych powodów prawie żadna karta graficzna (dla komputerów osobistych) nie wspiera CEC. Konsole gier wideo i dekodery zwykle zawierają zewnętrzny chipset, który obsługuje pin CEC. Podczas gdy istnieją urządzenia posiadające natywne wsparcie dla CEC (takie jak karta GPU VideoCore, która znajduje się w Raspberry Pi), większość konfiguracji potrzebowałyby adaptera USB CEC, aby móc działać.
Funkcje
Głównym celem CEC jest pozwolenie telewizorowi na pozyskiwanie informacji z urządzeń podłączeń do niego i kontrolę nad nimi. W związku z tym jest on podzielony na tuzin "funkcji", z których każda jest ukierunkowana na określone przypadki użycia i które urządzenia mogą zdecydować się na obsługę lub nie w oparciu o ich rolę jako inicjatora / obserwatora, ich możliwości, a także konfigurację użytkownika.
Standardowe funkcje to:
- Odtwarzanie Jednym Dotykiem (One Touch Play)
- Pozwala urządzeniowi zasygnalizować, że chce ono natychmiastowo być aktywnym źródłem odtwarzania, co może automatycznie włączyć telewizor
- Kontrola Trasowania (Routing Control)
- Pozwala telewizorowi na kontrolę przekaźników HDMI oraz pozwala urządzeniom na sprawdzenie, które źródło jest aktualnie aktywne
- Przejście Pilota (Remote Control Passthrough)
- Pozwala urządzeniom na wysyłanie do siebie sygnałów z pilota, zazwyczaj z telewizora do aktywnego źródła
- Kontrola Decku (Deck Control)
- Służy do sterowania odtwarzaczem filmów/muzyki i do sprawdzania statusu odtwarzania
- Czuwanie/Systemowe Czuwanie (Standby/System Standby)
- Pozwala urządzeniowi wysłać żądanie o to, aby inne, specyficzne urządzenie zostało wyłączone, albo rozgłosić, że wszystkie urządzenie w systemie mają zostać wyłączone
- Stan Zasilania (Power Status)
- Pozwala sprawdzić czy dane urządzenie jest w trybie czuwania, jest włączone, albo czy jest w trakcie włączania.
- Systemowe Sterowanie Dźwiękiem (System Audio Control)
- Przyznaje kontrolę nad amplitunerem AV podłączonym przez kanał zwrotny audio telewizora, umożliwiając zmianę głośności oraz włączanie i wyłączanie amplitunera.
- Sterowanie Tunerem (Tuner Control)
- Umożliwia dowolnemu urządzeniu przeglądanie listy kanałów telewizyjnych znanych tunerowi i wyszukiwanie informacji o aktywnym kanale, takich jak numer kanału dla telewizji analogowej lub informacje o strumieniu transportowym DVB/ATSC/ARIB dla telewizji cyfrowej.
- Nagrywanie Jednym Dotknięciem (One Touch Record)
- Umożliwia nagrywarce sprawdzenie, jaki kanał jest aktualnie wyświetlany w telewizorze, dzięki czemu nagrywarka może dostroić się do tego samego kanału i rozpocząć nagrywanie lub dowiedzieć się, że powinna nagrywać siebie lub inne urządzenie, jeśli jest ono już aktualnie aktywnym źródłem HDMI
- Programowanie Timera (Timer Programming)
- Umożliwia telewizorowi skonfigurowanie timera na nagrywarce, aby rozpocząć nagrywanie danego źródła o określonej godzinie.
- Wyświetlacz OSD (OSD display)
- Umożliwia urządzeniu wydrukowanie na telewizorze komunikatu o długości od 1 do 13 znaków ASCII
- Dynamiczny Auto-Lipsync (Dynamic Auto Lipsync)
- Umożliwia telewizorowi transmitowanie zmian w opóźnieniu prezentacji do odbiornika audio, które źródło posiadające własne głośniki (np. komputer) może wykorzystać do kompensacji opóźnienia z obrazem
W przypadku urządzeń takich jak komputery PC, najbardziej użytecznym z nich będzie Przejście Pilota. Systemowe Czuwanie może być przydatne dla komputerów HTPC, ale byłoby wątpliwe w przypadku bardziej uniwersalnych maszyn, które zwykle nie powinny przechodzić w stan uśpienia po wyłączeniu ekranu. Kontrola Trasowania może być używana do wybudzania systemu, gdy telewizor próbuje wyświetlić to wejście, pod warunkiem, że podłączony komputer ma możliwość słuchania ruchu CEC podczas zawieszenia. Systemowe Sterowanie Dźwiękiem byłoby wygodne dla niektórych wyjść dźwiękowych HDMI, ale obecnie nie działa jako środek kontroli głośności z PipeWire lub PulseAudio.
Konfiguracja sprzętowa CEC
Jądro Linux ma już wbudowany podsystem do automatycznego odpowiadania na zapytania i obsługi zdarzeń CEC, ale sprzęt może wymagać wcześniejszej konfiguracji, aby działał.
Natywne CEC
Adapter CEC
Adapter USB PulseEight
Adapter PulseEight USB-CEC działa poprzez pasywne przedłużenie wszystkich pinów złącza HDMI od złącza "po stronie komputera" do złącza "po stronie telewizora", z wyjątkiem pinu CEC, który jest przechwytywany. Dane przechodzące przez ten pin są zamiast tego ujawniane przez interfejs szeregowy USB, aby umożliwić komputerowi kontrolowanie i monitorowanie ruchu CEC. Szeregowe urządzenie wejściowe musi mieć swoją dyscyplinę linii (flagę sygnalizującą jądru, że TTY jest określonego znanego typu i wymaga sterownika do działania) skonfigurowaną ręcznie, zanim jądro przejmie i uzna ją za adapter CEC. Nie można tego zrobić automatycznie z powodu ograniczeń związanych z interfejsami API urządzeń szeregowych, więc obecnie najlepiej jest to osiągnąć za pomocą reguły udev sparowanej z jednostką systemd (ponieważ reguły udev nie mogą uruchamiać długo działających lub rozwidlających się procesów), aby uruchomić inputattach --pulse8-cec ..., gdy urządzenie jest podłączone.
Ten interfejs szeregowy pojawia się jako węzeł urządzenia /dev/ttyACMX, a narzędzie inputattach jest potrzebne do ustawienia dyscypliny linii i umożliwienia sterownikom jądra przejęcia tworzenia urządzenia /dev/cecX, które będzie potrzebne później. Wymaga to pakietu linuxconsole.
@$devnode w poniższej regule, jest to podstawienie ciągu udev./etc/udev/rules.d/pulse8-cec-autoattach.rules
SUBSYSTEM=="tty" ACTION=="add" ATTRS{manufacturer}=="Pulse-Eight" ATTRS{product}=="CEC Adapter" TAG+="systemd" ENV{SYSTEMD_WANTS}="pulse8-cec-attach@$devnode.service"
/etc/systemd/system/pulse8-cec-attach@.service
[Unit] # Powinien być nazwany "pulse8-cec-attach@-dev-ttyACM0.service" lub podobnie Description=Skonfiguruj urządzenie szeregowe USB Pulse-Eight na %I ConditionPathExists=%I [Service] Type=forking # inputattach domyślnie jest budowany bez wsparcia dla daemona systemd, więc systemd będzie musiało zgadywać PID. # https://sourceforge.net/p/linuxconsole/code/ci/a3366c0d5f82485e6aae7b005ec7a2d9a93bf458/tree/utils/inputattach.c#l1233 ExecStart=/usr/bin/inputattach --daemon --pulse8-cec %I
Jednak połączenia urządzeń USB są zwykle resetowane po wybudzeniu systemu ze stanu uśpienia (krok znany jako reset-resume), co oznacza, że połączenie szeregowe zostanie utracone, jeśli komputer zostanie kiedykolwiek zawieszony, oprócz połączeń szeregowych zwykle zawieszających się po wznowieniu. Oznacza to, że powyższa reguła musi zostać w jakiś sposób ponownie uruchomiona.
Niestety, sterownik cdc_acm odpowiedzialny za obiekt ttyACM*, na który reaguje powyższa reguła, nie podnosi żadnego zdarzenia ue o zresetowaniu połączenia i utracie dyscypliny linii, a reguły nie można podłączyć bezpośrednio do urządzenia USB. Zamiast tego najbardziej niezawodnym sposobem na ponowne uruchomienie powyższej reguły we właściwym czasie jest usunięcie i ponowne utworzenie obiektu ttyACM* poprzez wymuszenie rekonfiguracji urządzenia USB po jego zresetowaniu. Aby zareagować na to i zapewnić ponowne otwarcie połączenia, udev może śledzić, kiedy urządzenie USB jest resetowane i wyliczane, o czym świadczy właściwość DEVNUM, która jest zerowana, a następnie przywracana, i dotyka atrybutu bConfigurationValue sysfs.
/etc/udev/rules.d/pulse8-cec-autoattach.rules
SUBSYSTEM=="tty" ACTION=="add" ATTRS{manufacturer}=="Pulse-Eight" ATTRS{product}=="CEC Adapter" TAG+="systemd" ENV{SYSTEMD_WANTS}="pulse8-cec-attach@$devnode.service"
# Wymusza ponowną konfigurację urządzenia podczas resetowania po zawieszeniu, w przeciwnym razie łącze ttyACM zostanie utracone, ale udev tego nie zauważy.
# Zdarzenie usb_dev_uevent z DEVNUM=000 to znak, że urządzenie jest resetowane przed wyliczeniem.
# Ponowna konfiguracja powoduje usunięcie i ponowne dodanie ttyACM.
SUBSYSTEM=="usb" ACTION=="change" ATTR{manufacturer}=="Pulse-Eight" ATTR{product}=="CEC Adapter" ENV{DEVNUM}=="000" ATTR{bConfigurationValue}=="1" ATTR{bConfigurationValue}="1"
Zasadniczo działa to tak, jakby adapter USB został odłączony i ponownie podłączony natychmiast po wyjściu ze stanu uśpienia, zapewniając, że reguła SUBSYSTEM=="tty" ACTION=="add" sprzed uruchomienia zostanie ponownie uruchomiona. Gwarantuje to, że usługa systemd zostanie ponownie uruchomiona, gdy tylko urządzenie powróci do stanu używalności.
Tunelowanie przez DisplayPort
Standard DisplayPort 1.3 umożliwia adapterom DisplayPort-HDMI wykorzystanie kanału pomocniczego do przesyłania sygnałów CEC. Jest to rodzaj funkcji, której adaptery zwykle nie obsługują, chyba że o tym wspomniano, i nie jest powszechnie spotykana, ale wbrew intuicji korzystanie z tunelowania CEC przez DisplayPort może być tańsze i łatwiejsze niż praca z adapterem CEC. Strona dokumentacji jądra dla podmodułu CEC zawiera listę takich adapterów, których działanie zostało potwierdzone.
Konfiguracja podsystemu CEC
Teraz, gdy podsystem CEC ma coś do powiązania i utworzono /dev/cec0, możliwe jest skonfigurowanie komputera tak, aby inne urządzenia CEC wiedziały o nim. Podczas korzystania z wiersza poleceń, urządzenia CEC są zwykle kontrolowane przez cec-ctl, który jest częścią v4l-utils.
Należy pamiętać, że sam pin CEC nie ma wystarczającej ilości informacji, aby wysłać prawidłową wiadomość CEC. Adapter CEC, który monitoruje tylko pin 13 (CEC), nie może znać swojego "adresu fizycznego" (jego pozycji pod względem numerów portów w "drzewie" urządzeń HDMI, takich jak 3.1.0.0), którego musi być świadomy, aby zakończyć procedurę przydzielania adresu logicznego. Bez adresu logicznego urządzenie może jedynie odbierać i wysyłać wiadomości rozgłoszeniowe. Adres fizyczny jest przekazywany przez pin 16 (DDC/EDID), więc konfiguracja podsystemu CEC obejmuje określenie, który port wyjściowy wyświetlacza ma być powiązany z tym obiektem CEC, aby adres fizyczny mógł zostać wyodrębniony z EDID wyświetlacza.
Jednym ze sposobów na znalezienie nazwy aktywnych konektorów jest użycie xrandr --query (które działa również na Waylandzie):
$ xrandr --query
Screen 0: minimum 16 x 16, current 3840 x 2160, maximum 32767 x 32767 DP-1 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 600mm x 340mm 3840x2160 59.98*+ 2048x1536 59.95 ... HDMI-A-1 connected 3840x2160+0+0 (normal left inverted right x axis y axis) 1440mm x 810mm 3840x2160 59.98*+ 2048x1536 59.95 ...
Po zidentyfikowaniu właściwego portu (na przykład HDMI-A-1), nazwę portu sysfs można znaleźć za pomocą ls -1d /sys/class/drm/card*-HDMI-A-1 (np. card1-HDMI-A-1). W takim przypadku dane EDID odpowiedniego wyświetlacza będą przechowywane w /sys/class/drm/card1-HDMI-A-1/edid.
Biorąc pod uwagę, że konfiguracja CEC musi być wykonywana za każdym razem, gdy węzeł urządzenia cec jest ponownie tworzony, najlepiej jest to obsłużyć za pomocą innej reguły udev, która uruchamia się, gdy pojawia się obiekt cec.
card1-HDMI-A-1 w poniższej regule nazwą złącza./etc/udev/rules.d/cec-configure-autostart.rules
SUBSYSTEM=="cec" KERNEL=="cec0" ACTION=="add" TAG+="systemd" ENV{SYSTEMD_WANTS}="cec0-configure@card1-HDMI-A-1.service"
/etc/systemd/system/cec0-configure@.service
[Unit] # Should be called as "cec0-configure@card1-HDMI-A-1.service" or similar Description=Configure CEC adapter cec0 assuming it runs on output %i AssertPathExists=/sys/class/drm/%i/edid BindsTo=dev-cec0.device [Service] Type=exec # --phys-addr-from-edid-poll sprawdza EDID co jedną dziesiątą sekundy # https://git.linuxtv.org/v4l-utils.git/tree/utils/cec-ctl/cec-ctl.cpp?id=0a195181d771090f3c99d4a6ddb8151352509061#n1977 # Użyj `Type=oneshot` jeśli zamiast tego używasz `--phys-addr-from-edid`. ExecStart=/usr/bin/cec-ctl --device=0 "--osd-name=%H" --playback "--phys-addr-from-edid-poll=/sys/class/drm/%i/edid"
Istnieją trzy klasy urządzeń, które źródło HDMI może próbować reklamować jako "urządzenie nagrywające" (maks. 3), "tuner" (maks. 4) i "urządzenie odtwarzające" (maks. 3). Jest to ważne, ponieważ urządzenia HDMI nie używają swojego adresu fizycznego podczas komunikacji między sobą za pośrednictwem CEC, ale 4-bitowego "adresu logicznego", który identyfikuje urządzenia jako "Tuner #3" lub "Urządzenie odtwarzające #1", z określoną liczbą każdego z nich. Jeśli przydzielenie adresu nie powiedzie się z powodu obecności zbyt wielu urządzeń jednego typu, można zamiast tego przypisać rolę "Backup" (maksymalnie 2). Role te mają odnosić się do funkcji CEC wspomnianych wcześniej, a mianowicie:
- "Tuner" powinien obsługiwać "Sterowanie Tunerem".
- "Urządzenie nagrywające" to jedyny typ, który może korzystać z funkcji Nagrywanie Jednym Dotknięciem, ponieważ telewizory mają ignorować powiązane wiadomości pochodzące z innych adresów
- "Urządzenie odtwarzające" dotyczy źródeł wideo ogólnego przeznaczenia. Komputery, podobnie jak konsole do gier wideo, są uważane za "urządzenia odtwarzające".
Powyższa jednostka cec0-configure@.service używa --playback do konfiguracji urządzenia odtwarzającego. Ogólnie rzecz biorąc, dobrze jest jednak ustawić klasę urządzenia na Tuner (--tuner) lub urządzenie nagrywające (--record), czy to dlatego, że nie ma już nieużywanych adresów odtwarzania, czy po prostu dlatego, by komputer wyróżniał się na liście w telewizorach, które wizualnie rozróżniają każdą klasę urządzenia w menu wejściowym.
Zobacz także
- "HDMI CEC: What? Why? How?" autorstwa Hansa Verkuila, który napisał większość podsystemu CEC
- CEC-O-Matic, który umożliwia tworzenie nieprzetworzonych komunikatów CEC i daje przegląd tego, co składa się na prawidłową ramkę CEC
- Dokumentacja podsystemu CEC