「HDMI-CEC」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(序文を翻訳)
 
(同じ利用者による、間の11版が非表示)
2行目: 2行目:
 
[[en:HDMI-CEC]]
  
[[en:HDMI-CEC]]
 
[[pl:HDMI-CEC]]
  
[[pl:HDMI-CEC]]
−
[[Wikipedia:Consumer Electronics Control|High-Definition Multimedia Interface - Consumer Electronics Control]] (HDMI-CEC) は、HDMI 接続内の追加の低速（50 B/s）バスであり、HDMI デバイスの「ネットワーク」が互いに通信するために使用できます。これにより、HDMI デバイスはお互いにオンまたはオフにすることを通知したり、テレビが入力を切り替えたり、リモコンのボタンが押されたりするなどの操作が可能になります。PC セットアップでは、通常、HTPC（ホームシアターPC）セットアップで遭遇します。
 +
[[Wikipedia:Consumer Electronics Control|High-Definition Multimedia Interface - Consumer Electronics Control]] は、HDMI 接続内の追加の低速（50 B/s）バスであり、HDMI デバイスの「ネットワーク」が互いに通信するために使用できます。これにより、HDMI デバイスはお互いにオンまたはオフにすることを通知したり、テレビが入力を切り替えたり、リモコンのボタンが押されたりするなどの操作が可能になります。PC セットアップでは、通常、HTPC（ホームシアターPC）セットアップで遭遇します。
   
 
様々な理由から、ほとんどの PC GPU は CEC のハードウェアサポートを持っていません。ビデオゲームコンソールやセットトップボックスは通常、CEC ピンを駆動するために外部チップセットを含める必要があります。Raspberry Pi で見られる VideoCore GPU のようにネイティブ CEC サポートを持つデバイスもありますが、ほとんどのハードウェア構成では追加のハードウェアが必要です。
  
様々な理由から、ほとんどの PC GPU は CEC のハードウェアサポートを持っていません。ビデオゲームコンソールやセットトップボックスは通常、CEC ピンを駆動するために外部チップセットを含める必要があります。Raspberry Pi で見られる VideoCore GPU のようにネイティブ CEC サポートを持つデバイスもありますが、ほとんどのハードウェア構成では追加のハードウェアが必要です。
   
−
== Features ==
 +
== 機能 ==
   
  +
CEC (Consumer Electronics Control) の主な目的は、テレビがそれに接続されているデバイスの状態を把握し、制御することを可能にすることです。そのため、特定の使用例に対応する「機能」のいくつかに分けられており、デバイスは発信者/フォロワーとしての役割、能力、ユーザー設定に基づいて、これらの機能をサポートするかどうかを選択できます。
−
The main purpose of CEC is to grant a television insight and control over the state of the devices plugged into it. As such, it is split into a dozen of "features" that each target specific use cases, and which devices can opt to support or not based on their role as initiator/follower, their capabilities, as well as user configuration.
  
   
  +
標準化された機能は以下の通りです：
−
The standardized features are:
  
   
  +
;ワンタッチプレイ: デバイスが直ちにアクティブソースになることを希望していることを示し、自動的にテレビをオンにすることができます
−
;One Touch Play: Lets a device signal that it wishes to immediately become the active source, which can automatically turn on the TV
  
  +
;ルーティング制御: テレビがHDMIスイッチを制御できるようにし、デバイスが現在アクティブなソースを確認できるようにします
−
;Routing Control: Allows the TV to control HDMI switches and lets devices check what source is currently active
  
  +
;リモートコントロールパススルー: デバイスが互いにリモコン信号を送信できるようにします。通常はテレビからアクティブソースへ送信されます
−
;Remote Control Passthrough: Lets devices send remote control signals to each other, usually from the TV to the active source
  
  +
;デッキコントロール: 映画/音楽プレイヤーを制御し、その再生状態を照会する
−
;Deck Control: To control a movie/music player and query its playback status
  
  +
;スタンバイ/システムスタンバイ: デバイスが別の特定のデバイスの電源を切ることを要求したり、システム上のすべてのデバイスが今電源を切るべきだと放送することができます
−
;Standby/System Standby: Lets a device request that another specific device be turned off, or broadcast that all devices on the system should now turn off.
  
  +
;電源状態: デバイスがスタンバイモードにあるか、オンになっているか、またはオンになるプロセス中にあるかを調べることができます
−
;Power Status: Lets devices be probed to see if they are in standby mode or turned on, or if they are in the process of turning on.
  
  +
;システムオーディオコントロール: テレビのオーディオリターンチャネルを介して接続されたAVレシーバーを制御できるようにし、音量を変更したりレシーバーの電源を入れたり切ったりできます
−
;System Audio Control: Grants control of an AV receiver connected over the TV's Audio Return Channel, allowing the volume to be changed and the receiver to be turned on or off.
  
  +
;チューナーコントロール: 任意のデバイスがチューナーデバイスに知られているテレビチャンネルのリストを通過し、アクティブなチャンネルの情報（アナログテレビのチャンネル番号やデジタルテレビのDVB/ATSC/ARIBトランスポートストリーム情報など）を照会できます
−
;Tuner Control: Lets any device step through the list of TV channels known to a tuner device and query information on the active channel, like the channel number for analog TV or DVB/ATSC/ARIB transport stream information for digital TV
  
  +
;ワンタッチレコード: レコーダーがテレビが現在表示しているチャンネルを照会できるようにし、そのレコーダーが同じチャンネルにチューニングして録画を開始するか、既に現在アクティブなHDMIソースであれば自身や下流デバイスを録画すべきかを知ることができます
−
;One Touch Record: Enables a recorder to query what channel the TV is currently showing so that said recorder can tune to the same channel and begin recording, or know that it should record itself or a downstream device if it already is the currently active HDMI source
  
  +
;タイマープログラミング: テレビが特定の時間に特定のソースの録画を開始するためにレコーダー上のタイマーを設定できるようにします
−
;Timer Programming: Allows a TV to configure a timer on a recorder to start recording a given source at a specific time
  
  +
;OSD表示: デバイスがテレビ上にメッセージを表示できるようにします。1から13文字のASCII文字で
−
;OSD display: Allows a device to print a message on the TV, between 1 and 13 ASCII characters long
  
  +
;ダイナミックオートリップシンク: テレビがオーディオシンクへのプレゼンテーション遅延の変更を放送できるようにします。これは、独自のスピーカーを持つソース（PCなど）が画像との遅延補償に使用できます。
−
;Dynamic Auto Lipsync: Allows a TV to broadcast changes in presentation latency to the the audio sink, which a source that has its own speakers (like a PC) can use for latency compensation with the image
  
   
  +
{{Tip|リストにないもの：デバイスメニューコントロール（CEC 2.0で廃止）、OSD名転送（cec-ctlによって処理）、システム情報、ベンダー固有のコマンド（標準化されたメッセージなし）、オーディオレートコントロール（TV-AVのみ）、オーディオリターンチャネルコントロール（TV-AVのみ）}}
−
{{Tip|Not listed: Device Menu Control (deprecated in CEC 2.0), OSD name transfer (handled by cec-ctl), System information, Vendor-specific command (no standardized messages), Audio Rate Control (TV-AV only), Audio Return Channel Control (TV-AV only)}}
  
   
  +
PC のようなデバイスにとって、これらの中で最も有用なのは「リモートコントロールパススルー」でしょう。HTPC にとっては「システムスタンバイ」が有用かもしれませんが、スクリーンがオフになったときに通常スリープ状態に入ることが期待されないより一般的な用途のマシンでは疑問の余地があります。「ルーティングコントロール」は、テレビがその入力を表示しようとするときにシステムを起動させるために使用できますが、接続されたPCがサスペンド中にCECトラフィックをリッスンする方法を持っている場合に限ります。「システムオーディオコントロール」は、一部の HDMI サウンド出力にとって便利ですが、現在、[[PipeWire]]や [[PulseAudio]] といったもので音量制御の手段としては機能していません。
−
For a device like a PC, the most useful one among these is going to be '''Remote Control Passthrough'''. '''System Standby''' may be useful for HTPCs, but would be of questionable use on more general-purpose machines, which are not usually expected to go to sleep when the screen turns off. '''Routing Control''' could be used to wake up the system when the the TV attempts to display that input, provided the connected PC has a way to listen to CEC traffic while suspended. '''System Audio Control''' would be convenient for some HDMI sound outputs, but does not currently work as a mean of volume control with either [[PipeWire]] or [[PulseAudio]].
  
   
  +
== ハードウェアセットアップ ==
−
== Hardware setup ==
  
   
  +
Linux の[[カーネル]]には既に CEC イベントに自動的に応答し、処理するための組み込みのサブシステムがありますが、ハードウェアが正しく機能するためには最初に設定が必要になる場合があります。
−
The Linux [[Kernel]] already has a built-in subsystem to automatically respond to queries and handle CEC events, but the hardware may need to be configured first in order to work.
  
   
 
=== Native CEC ===
  
=== Native CEC ===
   
−
Native CEC is [https://docs.kernel.org/admin-guide/media/cec.html#supported-hardware-in-mainline mostly encountered] in ARM devices. In x86 world the easiest option is [[#Tunneling over DisplayPort|tunneling over DisplayPort]], otherwise only some [[Chrome OS devices|Chrome OS]] devices and [https://www.seco.com SECO] [https://www.udoo.org UDOO] single-board computers offer CEC.
 +
Native CEC は主に ARM デバイスで[https://docs.kernel.org/admin-guide/media/cec.html#supported-hardware-in-mainline 見られます]。x86 世界では、[[#Tunneling over DisplayPort|DisplayPort経由のトンネリング]]が最も簡単なオプションです。それ以外では、一部の [[Chrome OS デバイス|Chrome OS]] デバイスと [https://www.seco.com SECO] [https://www.udoo.org UDOO] のシングルボードコンピューターのみが CEC を提供しています。
   
  +
=== DisplayPort 経由のトンネリング ===
−
=== Tunneling over DisplayPort ===
  
   
−
This works with [[i915]], [[nouveau]] and [[AMDGPU|amdgpu]] drivers. The DisplayPort 1.3 standard (introduced in 2014) allows DisplayPort-to-HDMI adapters to use the auxiliary channel to forward CEC signals both ways. This is the sort of feature that adapters do not usually support unless mentioned, and is not commonly found, but it can counter-intuitively be cheaper and easier to use CEC tunneling over DisplayPort than a USB-CEC adapter. The kernel documentation page for the CEC submodule has [https://docs.kernel.org/admin-guide/media/cec.html#displayport-to-hdmi-adapters-with-working-cec a list of adapters] which have been confirmed to work.
 +
これは [[i915]]、[[nouveau]]、[[AMDGPU|amdgpu]] ドライバーで機能します。2014 年に導入された DisplayPort 1.3 標準では、DisplayPort から HDMI アダプターを使用して補助チャネルを介して CEC 信号を双方向に転送することができます。これはアダプターが通常サポートしていない種類の機能であり、一般的ではありませんが、USB-CEC アダプターよりも直感に反して CEC のトンネリングを DisplayPort 経由で使用する方が安価で簡単な場合があります。CEC サブモジュールのカーネルドキュメントページには、動作が確認された[https://docs.kernel.org/admin-guide/media/cec.html#displayport-to-hdmi-adapters-with-working-cec アダプターのリスト]があります。
   
−
=== CEC adapter ===
 +
=== CEC アダプター ===
   
−
{{Note|If you are looking to use HDMI-CEC with [[Kodi]], know that it has [[Kodi#HDMI-CEC|built-in support for both Pulse-Eight and Raspberry Pi modes of CEC control]] and is incompatible with the following configuration.}}
 +
{{Note|[[Kodi]] で HDMI-CEC を使用しようとしている場合、それは [[Kodi#HDMI-CEC|Pulse-Eight および Raspberry Pi の CEC 制御モードの両方の組み込みサポート]]を持っており、以下の設定と互換性がありません。}}
   
−
==== PulseEight USB adapter ====
 +
==== PulseEight USB アダプター ====
   
  +
[https://www.pulse-eight.com/p/104/usb-hdmi-cec-adapter PulseEight USB-CEC アダプター]は、「PC 側」コネクタから「TV 側」コネクタへ HDMI コネクタのすべてのピンを受動的に延長しますが、CEC ピンを除きます。そのピンを通るデータは、PC が CEC トラフィックを制御し監視できるように USB シリアルインターフェース上で公開されます。[[Serial input device to kernel input|シリアルデバイス]]は、カーネルがそれを CEC アダプターとして認識し、引き継ぐ前に手動でそのラインディスプリン（TTY が特定の既知のタイプであり、動作にドライバーが必要であることをカーネルに信号を送るフラグ）を設定する必要があります。[https://lwn.net/Articles/700489/ シリアルデバイス API の制限]のためにこれを自動的に行うことはできないため、現在はデバイスが接続されたときに{{ic|inputattach --pulse8-cec ...}}を実行する [[udev ルール]]と [[systemd|systemd ユニット]]（udev ルールでは長時間実行またはフォークするプロセスを起動できないため）を組み合わせて実現するのが最善の方法です。
−
The [https://www.pulse-eight.com/p/104/usb-hdmi-cec-adapter PulseEight USB-CEC adapter] works by passively extending all the pins of the HDMI connector on from the "PC side" connector to the "TV side" connector, save for the CEC pin, which is intercepted. The data going through that pin is instead exposed over a USB serial interface to let a PC control and monitor CEC traffic. The [[Serial input device to kernel input|serial device]] needs to have its line discipline (a flag to signal to the kernel that a TTY is of a specific known type and requires a driver to work) configured manually before the kernel takes over and acknowledges it as a CEC adapter. This cannot be done automatically [https://lwn.net/Articles/700489/ due to limitations around serial device APIs], so it is currently best achieved with a [[udev rule]] paired with a [[systemd|systemd unit]] (as udev rules cannot launch long-running or forking processes) to run {{ic|inputattach --pulse8-cec ...}} when the device is plugged.
  
   
  +
このシリアルインターフェイスはデバイスノード {{ic|/dev/ttyACM''X''}} として現れ、カーネルドライバーが引き継いで後で必要になる {{ic|/dev/cec''X''}} デバイスを作成するために、ラインディスプリンを設定して ''inputattach'' ユーティリティが必要です。これには {{Pkg|linuxconsole}} パッケージが必要です。
−
This serial interface appears as device node {{ic|/dev/ttyACM''X''}}, and the ''inputattach'' utility is needed to set the line discipline and let the kernel drivers take over to create the {{ic|/dev/cec''X''}} device that will be needed later. This requires the {{Pkg|linuxconsole}} package.
  
   
−
{{Note|Do not modify {{ic|@$devnode}} in the following rule, it is a udev string substitution.}}
 +
{{Note|以下のルールで {{ic|@$devnode}} を変更しないでください。これは udev の文字列置換です。}}
   
 
{{hc|/etc/udev/rules.d/pulse8-cec-autoattach.rules|2=
  
{{hc|/etc/udev/rules.d/pulse8-cec-autoattach.rules|2=
71行目: 71行目:
 
}}
  
}}
   
  +
しかし、USB デバイス接続は、システムがスリープから復帰するときに通常リセットされます（これは「reset-resume」として知られています）。これは、コンピュータがサスペンドされた場合、シリアル接続が失われることを意味します。さらに、通常、シリアル接続は復帰時に切断されがちです。このため、上記のルールを何らかの方法で再度トリガーする必要があります。
−
However, USB device connections [https://docs.kernel.org/driver-api/usb/persist.html are usually reset when the system wakes up from sleep] ([https://docs.kernel.org/driver-api/usb/power-management.html a step known as reset-resume]) , meaning the serial connection will be lost if the computer is ever suspended, on top of serial connections usually hanging up on resume anyway. This means the above rule has to be triggered again somehow.
  
   
  +
残念ながら、上記のルールが反応する {{ic|ttyACM*}} オブジェクトを担当する{{ic|cdc_acm}}ドライバは、接続がリセットされてラインディスプリンが失われたことについての uevent を発生させず、USB デバイス直接にルールをフックすることはできません。代わりに、正しいタイミングで上記の使用されたルールを再度トリガーする最も確実な方法は、リセット時に USB デバイスを再設定することを強制して {{ic|ttyACM*}} オブジェクトを削除して再作成することです。これにより、udev は USB デバイスがリセットされて列挙されるときを追跡でき、{{ic|DEVNUM}} プロパティがゼロになり後で復元されること、{{ic|bConfigurationValue}} sysfs 属性を触ることにより、接続が再開されることを確実にします。
−
Unfortunately, the {{ic|cdc_acm}} driver in charge of the {{ic|ttyACM*}} object that the above rule reacts to does not raise any uevent about the connection being reset and the line discipline being lost, and the rule cannot be hooked on the USB device directly. Instead, the most reliable way to get the used rule above to trigger again at the right time is to delete and recreate the {{ic|ttyACM*}} object [https://docs.kernel.org/admin-guide/abi-stable.html#abi-sys-bus-usb-devices-bconfigurationvalue by forcing the USB device to be reconfigured] when it resets. In order to react to this and ensure the the connection is reopened, udev can keep track of when the USB device is reset and enumerated, as evidenced by the {{ic|DEVNUM}} property being zeroed and later restored, and touching the {{ic|bConfigurationValue}} sysfs attribute.
  
   
 
{{hc|/etc/udev/rules.d/pulse8-cec-autoattach.rules|2=
  
{{hc|/etc/udev/rules.d/pulse8-cec-autoattach.rules|2=
84行目: 84行目:
 
}}
  
}}
   
  +
これは基本的に、USB アダプタがスリープから出た直後に抜き差しされたかのように機能し、以前の {{ic|1=SUBSYSTEM=="tty" ACTION=="add"}} ルールが再び実行されることを保証します。これにより、デバイスが使用可能な状態に戻るとすぐに systemd サービスが再起動されることが保証されます。
−
This essentially acts as if the USB adapter had been unplugged and re-plugged immediately upon coming out of sleep, ensuring the {{ic|1=SUBSYSTEM=="tty" ACTION=="add"}} rule from before gets to run again. This ensures that the systemd service will be restarted as soon as the device is back to a usable state.
  
   
  +
== ソフトウェアセットアップ ==
−
== Software setup ==
  
   
−
=== CEC subsystem configuration ===
 +
=== CECサブシステム設定 ===
   
  +
CECサブシステムの設定が完了し、{{ic|/dev/cec0}} が作成されたので、他の CEC デバイスが PC について知るように PC を設定することが可能になりました。コマンドラインを使用している場合、CEC デバイスは通常 {{Pkg|v4l-utils}} の一部である {{ic|cec-ctl}} を介して制御されます。
−
Now that the CEC subsystem has something to bind on and that {{ic|/dev/cec0}} has been created, it is now possible to configure the PC so other CEC devices know about it. When using the command-line, CEC devices are normally controlled via {{ic|cec-ctl}}, which is part of {{Pkg|v4l-utils}}.
  
   
  +
一つ注意すべき点は、CEC ピンだけでは、有効な CEC メッセージを送信するために必要な情報が十分ではないということです。ピン13（CEC）のみを監視する CEC アダプターは、「物理アドレス」（HDMI デバイスの「ツリー」内のポート番号による位置、例えば {{ic|3.1.0.0}} など）を知ることができず、論理アドレス割り当て手続きを完了するためにこれを把握する必要があります。論理アドレスがなければ、デバイスはブロードキャストメッセージのみを受信および送信できます。物理アドレスはピン 16（DDC/EDID）を介して伝えられるため、CEC サブシステムの設定には、物理アドレスをディスプレイの EDID から抽出できるように、どのディスプレイ出力ポートがその CEC オブジェクトに関連付けられるべきかを指定することが含まれます。
−
One thing to be aware of is that the CEC pin alone does not have enough information on its own to send a valid CEC message. A CEC adapter that only monitors pin 13 (CEC) cannot know its "physical address" (its position in terms of port numbers in the "tree" of HDMI devices, such as {{ic|3.1.0.0}}), which it needs to be aware of in order to complete the logical address allocation procedure. Without a logical address, a device can only receive and send broadcast messages. The physical address is communicated over pin 16 (DDC/EDID), so configuring the CEC subsystem includes specifying which display output port is supposed to be associated with with that CEC object, in order for the physical address to be extracted from the display's EDID.
  
   
  +
アクティブなコネクターの名前を見つける一つの方法は、{{ic|xrandr --query}} を使用することです（これは Wayland でも機能します）：
−
One way to find the name of the active connectors is to use {{ic|xrandr --query}} (which also works on Wayland):
  
   
 
{{hc|$ xrandr --query |
  
{{hc|$ xrandr --query |
108行目: 108行目:
 
}}
  
}}
   
−
Once the correct port has been identified (for example {{ic|HDMI-A-1}}), then the sysfs port name can be found by using {{ic|ls -1d /sys/class/drm/card*-HDMI-A-1}} (such as {{ic|card1-HDMI-A-1}}). In this case, the corresponding display's EDID data would be kept at {{ic|/sys/class/drm/card1-HDMI-A-1/edid}}.
 +
正しいポートが識別されたら（例えば{{ic|HDMI-A-1}}）、sysfs ポート名は {{ic|ls -1d /sys/class/drm/card*-HDMI-A-1}} を使用して見つけることができます（例えば {{ic|card1-HDMI-A-1}}）。この場合、対応するディスプレイの EDID データは {{ic|/sys/class/drm/card1-HDMI-A-1/edid}} に保持されます。
   
  +
物理アドレスはこのようにプレビューできます：
−
The physical address can be previewed like this:
  
   
 
{{hc|$ edid-decode --physical-address /sys/class/drm/card1-DP-3/edid|2=
  
{{hc|$ edid-decode --physical-address /sys/class/drm/card1-DP-3/edid|2=
116行目: 116行目:
 
}}
  
}}
   
  +
{{ic|cec}} デバイスノードが再作成されるたびに CEC 設定を行う必要があるため、これは {{ic|cec}} オブジェクトが表示されたときに発火する別の udev ルールで最もよく処理されます。
−
Given how CEC configuration must be performed every time the {{ic|cec}} device node is re-created, this is best handled with another udev rule that fires when the {{ic|cec}} object appears.
  
   
−
{{Note|Be sure to replace {{ic|card1-HDMI-A-1}} in the following rule by your connector name.}}
 +
{{Note|以下のルールで {{ic|card1-HDMI-A-1}} をあなたのコネクタ名に必ず置き換えてください。}}
   
 
{{hc|/etc/udev/rules.d/cec-configure-autostart.rules|2=
  
{{hc|/etc/udev/rules.d/cec-configure-autostart.rules|2=
139行目: 139行目:
 
}}
  
}}
   
  +
HDMI ソースが自己を宣伝できるデバイスクラスには、「録画装置」（最大 3 台）、「チューナー」（最大 4 台）、「再生装置」（最大 3 台）の 3 種類があります。これは重要です。なぜなら、HDMI デバイスは CEC を介して互いに通信する際に物理アドレスを使用せず、代わりに 4 ビットの「論理アドレス」を使用して「チューナー＃3」や「再生装置＃1」などのデバイスを識別し、それぞれの数には限りがあるからです。一つのタイプのデバイスが多すぎるためにアドレス割り当てに失敗した場合、代わりに「バックアップ」（最大 2 台）の役割が割り当てられるかもしれません。これらの役割は、以前に述べた [[#Features|CEC の機能]]に関連して意図されています。すなわち：
−
There are three device classes that an HDMI source can try to advertise itself as, which are "Recording device" (3 max), "Tuner" (4 max) and "Playback device" (3 max). This is important because HDMI devices do not use their physical address when communicating with each other over CEC, but a 4 bit "logical address", which identify devices as "Tuner #3" or "Playback Device #1", with a finite number of each. If address allocation fails because too many devices of one type are present, it may be assigned the "Backup" (2 max) role instead. These roles are intended to relate to the [[#Features|CEC features]] mentioned earlier, namely:
  
   
  +
* 「チューナー」は「チューナーコントロール」をサポートすることが意図されています
−
* "Tuner" is supposed to support "Tuner Control"
  
  +
* 「録画装置」は、テレビが他のアドレスからの関連メッセージを無視するとされているため、ワンタッチレコードを使用できる唯一のタイプです
−
* "Recording device" is the only type that can use One Touch Record, as TVs are supposed to ignore related messages coming from other addresses
  
  +
* 「再生装置」は、一般的なビデオソース用です。コンピュータやビデオゲームコンソールなどは、「再生装置」とみなされます。
−
* "Playback device" is for general purpose video sources. Computers, like video game consoles, are considered "Playback devices".
  
   
  +
上記の {{ic|cec0-configure@.service}} ユニットは {{ic|--playback}} を使用して再生装置を設定しています。ただし、再生アドレスが使用済みでない場合、またはテレビの入力メニューで各デバイスクラスを視覚的に区別するために PC を目立たせたい場合は、デバイスクラスをチューナー（{{ic|--tuner}}）またはレコーダー（{{ic|--record}}）に設定しても一般的に問題ありません。
−
The above {{ic|cec0-configure@.service}} unit uses {{ic|--playback}} to configure a Playback device. It is, however, generally OK to set the device class to Tuner ({{ic|--tuner}}) or Recorder ({{ic|--record}}), whether because there are no more unused playback addresses, or simply to have the PC stand out in the list on TVs that visually set apart each device class in their input menus.
  
   
−
=== Input-handling daemons ===
 +
=== 入力処理デーモン ===
   
 
* {{AUR|cecdaemon-git}}
  
* {{AUR|cecdaemon-git}}
 
* {{AUR|libcec-daemon-git}}
  
* {{AUR|libcec-daemon-git}}
   
−
=== Userspace tools ===
 +
=== ユーザー空間ツール ===
   
−
User access to {{ic|/dev/cec*}} devices can be granted by enrolling users into the {{ic|video}} [[user group]]. The basic tool for controlling CEC devices is {{ic|cec-ctl}} from {{Pkg|v4l-utils}}. A similar one is {{ic|cec-client}} from {{Pkg|libcec}}, for which there are also Python bindings available in {{AUR|python-cec}}.
 +
{{ic|/dev/cec*}} デバイスへのユーザーアクセスは、ユーザーを {{ic|video}} [[ユーザーグループ]]に登録することで許可されます。CEC デバイスを制御する基本ツールは {{Pkg|v4l-utils}} からの {{ic|cec-ctl}} です。同様のものに {{Pkg|libcec}} からの {{ic|cec-client}} があり、{{AUR|python-cec}} で利用可能な Python バインディングもあります。
   
−
== See also ==
 +
== 参照 ==
   
−
* [https://docs.kernel.org/admin-guide/media/cec.html Kernel documentation for the CEC subsystem]
 +
* [https://docs.kernel.org/admin-guide/media/cec.html CEC サブシステムに関するカーネルドキュメント]
−
* [https://elinux.org/CEC_(Consumer_Electronics_Control)_over_HDMI CEC (Consumer Electronics Control) over HDMI], in Embedded Linux Wiki (eLinux.org)
 +
* [https://elinux.org/CEC_(Consumer_Electronics_Control)_over_HDMI HDMI 上の CEC (Consumer Electronics Control)]、Embedded Linux Wiki (eLinux.org)内
−
* [https://www.youtube.com/watch?v=Q6S2FabX2WA HDMI CEC: What? Why? How?], by Hans Verkuil, who wrote most of the CEC subsystem
 +
* [https://www.youtube.com/watch?v=Q6S2FabX2WA HDMI CEC: 何？ なぜ？ どうやって？]、CEC サブシステムの大部分を書いた Hans Verkuil による
−
* [https://www.cec-o-matic.com/ CEC-O-Matic], which allows to create raw CEC messages and gives an overview of what makes up a valid CEC frame
 +
* [https://www.cec-o-matic.com/ CEC-O-Matic]、生の CEC メッセージを作成し、有効な CEC フレームを構成するものの概要を提供するツール

2024年4月5日 (金) 22:02時点における最新版

High-Definition Multimedia Interface - Consumer Electronics Control は、HDMI 接続内の追加の低速（50 B/s）バスであり、HDMI デバイスの「ネットワーク」が互いに通信するために使用できます。これにより、HDMI デバイスはお互いにオンまたはオフにすることを通知したり、テレビが入力を切り替えたり、リモコンのボタンが押されたりするなどの操作が可能になります。PC セットアップでは、通常、HTPC（ホームシアターPC）セットアップで遭遇します。

様々な理由から、ほとんどの PC GPU は CEC のハードウェアサポートを持っていません。ビデオゲームコンソールやセットトップボックスは通常、CEC ピンを駆動するために外部チップセットを含める必要があります。Raspberry Pi で見られる VideoCore GPU のようにネイティブ CEC サポートを持つデバイスもありますが、ほとんどのハードウェア構成では追加のハードウェアが必要です。

機能

CEC (Consumer Electronics Control) の主な目的は、テレビがそれに接続されているデバイスの状態を把握し、制御することを可能にすることです。そのため、特定の使用例に対応する「機能」のいくつかに分けられており、デバイスは発信者/フォロワーとしての役割、能力、ユーザー設定に基づいて、これらの機能をサポートするかどうかを選択できます。

標準化された機能は以下の通りです：

ワンタッチプレイ
デバイスが直ちにアクティブソースになることを希望していることを示し、自動的にテレビをオンにすることができます
ルーティング制御
テレビがHDMIスイッチを制御できるようにし、デバイスが現在アクティブなソースを確認できるようにします
リモートコントロールパススルー
デバイスが互いにリモコン信号を送信できるようにします。通常はテレビからアクティブソースへ送信されます
デッキコントロール
映画/音楽プレイヤーを制御し、その再生状態を照会する
スタンバイ/システムスタンバイ
デバイスが別の特定のデバイスの電源を切ることを要求したり、システム上のすべてのデバイスが今電源を切るべきだと放送することができます
電源状態
デバイスがスタンバイモードにあるか、オンになっているか、またはオンになるプロセス中にあるかを調べることができます
システムオーディオコントロール
テレビのオーディオリターンチャネルを介して接続されたAVレシーバーを制御できるようにし、音量を変更したりレシーバーの電源を入れたり切ったりできます
チューナーコントロール
任意のデバイスがチューナーデバイスに知られているテレビチャンネルのリストを通過し、アクティブなチャンネルの情報（アナログテレビのチャンネル番号やデジタルテレビのDVB/ATSC/ARIBトランスポートストリーム情報など）を照会できます
ワンタッチレコード
レコーダーがテレビが現在表示しているチャンネルを照会できるようにし、そのレコーダーが同じチャンネルにチューニングして録画を開始するか、既に現在アクティブなHDMIソースであれば自身や下流デバイスを録画すべきかを知ることができます
タイマープログラミング
テレビが特定の時間に特定のソースの録画を開始するためにレコーダー上のタイマーを設定できるようにします
OSD表示
デバイスがテレビ上にメッセージを表示できるようにします。1から13文字のASCII文字で
ダイナミックオートリップシンク
テレビがオーディオシンクへのプレゼンテーション遅延の変更を放送できるようにします。これは、独自のスピーカーを持つソース（PCなど）が画像との遅延補償に使用できます。
ヒント: リストにないもの：デバイスメニューコントロール（CEC 2.0で廃止）、OSD名転送（cec-ctlによって処理）、システム情報、ベンダー固有のコマンド（標準化されたメッセージなし）、オーディオレートコントロール（TV-AVのみ）、オーディオリターンチャネルコントロール（TV-AVのみ）

PC のようなデバイスにとって、これらの中で最も有用なのは「リモートコントロールパススルー」でしょう。HTPC にとっては「システムスタンバイ」が有用かもしれませんが、スクリーンがオフになったときに通常スリープ状態に入ることが期待されないより一般的な用途のマシンでは疑問の余地があります。「ルーティングコントロール」は、テレビがその入力を表示しようとするときにシステムを起動させるために使用できますが、接続されたPCがサスペンド中にCECトラフィックをリッスンする方法を持っている場合に限ります。「システムオーディオコントロール」は、一部の HDMI サウンド出力にとって便利ですが、現在、PipeWireや PulseAudio といったもので音量制御の手段としては機能していません。

ハードウェアセットアップ

Linux のカーネルには既に CEC イベントに自動的に応答し、処理するための組み込みのサブシステムがありますが、ハードウェアが正しく機能するためには最初に設定が必要になる場合があります。

Native CEC

Native CEC は主に ARM デバイスで見られます。x86 世界では、DisplayPort経由のトンネリングが最も簡単なオプションです。それ以外では、一部の Chrome OS デバイスと SECO UDOO のシングルボードコンピューターのみが CEC を提供しています。

DisplayPort 経由のトンネリング

これは i915、nouveau、amdgpu ドライバーで機能します。2014 年に導入された DisplayPort 1.3 標準では、DisplayPort から HDMI アダプターを使用して補助チャネルを介して CEC 信号を双方向に転送することができます。これはアダプターが通常サポートしていない種類の機能であり、一般的ではありませんが、USB-CEC アダプターよりも直感に反して CEC のトンネリングを DisplayPort 経由で使用する方が安価で簡単な場合があります。CEC サブモジュールのカーネルドキュメントページには、動作が確認されたアダプターのリストがあります。

CEC アダプター

ノート: Kodi で HDMI-CEC を使用しようとしている場合、それは Pulse-Eight および Raspberry Pi の CEC 制御モードの両方の組み込みサポートを持っており、以下の設定と互換性がありません。

PulseEight USB アダプター

PulseEight USB-CEC アダプターは、「PC 側」コネクタから「TV 側」コネクタへ HDMI コネクタのすべてのピンを受動的に延長しますが、CEC ピンを除きます。そのピンを通るデータは、PC が CEC トラフィックを制御し監視できるように USB シリアルインターフェース上で公開されます。シリアルデバイスは、カーネルがそれを CEC アダプターとして認識し、引き継ぐ前に手動でそのラインディスプリン（TTY が特定の既知のタイプであり、動作にドライバーが必要であることをカーネルに信号を送るフラグ）を設定する必要があります。シリアルデバイス API の制限のためにこれを自動的に行うことはできないため、現在はデバイスが接続されたときにinputattach --pulse8-cec ...を実行する udev ルールと systemd ユニット（udev ルールでは長時間実行またはフォークするプロセスを起動できないため）を組み合わせて実現するのが最善の方法です。

このシリアルインターフェイスはデバイスノード /dev/ttyACMX として現れ、カーネルドライバーが引き継いで後で必要になる /dev/cecX デバイスを作成するために、ラインディスプリンを設定して inputattach ユーティリティが必要です。これには linuxconsole パッケージが必要です。

ノート: 以下のルールで @$devnode を変更しないでください。これは 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]
# Should be called as "pulse8-cec-attach@-dev-ttyACM0.service" or similar
Description=Configure USB Pulse-Eight serial device at %I
ConditionPathExists=%I

[Service]
Type=forking
# inputattach is built without systemd daemon support by default, so systemd will have to guess the PID.
# https://sourceforge.net/p/linuxconsole/code/ci/a3366c0d5f82485e6aae7b005ec7a2d9a93bf458/tree/utils/inputattach.c#l1233

ExecStart=/usr/bin/inputattach --daemon --pulse8-cec %I

しかし、USB デバイス接続は、システムがスリープから復帰するときに通常リセットされます（これは「reset-resume」として知られています）。これは、コンピュータがサスペンドされた場合、シリアル接続が失われることを意味します。さらに、通常、シリアル接続は復帰時に切断されがちです。このため、上記のルールを何らかの方法で再度トリガーする必要があります。

残念ながら、上記のルールが反応する ttyACM* オブジェクトを担当するcdc_acmドライバは、接続がリセットされてラインディスプリンが失われたことについての uevent を発生させず、USB デバイス直接にルールをフックすることはできません。代わりに、正しいタイミングで上記の使用されたルールを再度トリガーする最も確実な方法は、リセット時に USB デバイスを再設定することを強制して ttyACM* オブジェクトを削除して再作成することです。これにより、udev は USB デバイスがリセットされて列挙されるときを追跡でき、DEVNUM プロパティがゼロになり後で復元されること、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"

# Force device to be reconfigured when reset after suspend, otherwise the ttyACM link is lost but udev will not notice.
# A usb_dev_uevent with DEVNUM=000 is a sign that the device is being reset before enumeration.
# Re-configuring causes ttyACM to be removed and re-added instead.
SUBSYSTEM=="usb" ACTION=="change" ATTR{manufacturer}=="Pulse-Eight" ATTR{product}=="CEC Adapter" ENV{DEVNUM}=="000" ATTR{bConfigurationValue}=="1" ATTR{bConfigurationValue}="1"

これは基本的に、USB アダプタがスリープから出た直後に抜き差しされたかのように機能し、以前の SUBSYSTEM=="tty" ACTION=="add" ルールが再び実行されることを保証します。これにより、デバイスが使用可能な状態に戻るとすぐに systemd サービスが再起動されることが保証されます。

ソフトウェアセットアップ

CECサブシステム設定

CECサブシステムの設定が完了し、/dev/cec0 が作成されたので、他の CEC デバイスが PC について知るように PC を設定することが可能になりました。コマンドラインを使用している場合、CEC デバイスは通常 v4l-utils の一部である cec-ctl を介して制御されます。

一つ注意すべき点は、CEC ピンだけでは、有効な CEC メッセージを送信するために必要な情報が十分ではないということです。ピン13（CEC）のみを監視する CEC アダプターは、「物理アドレス」（HDMI デバイスの「ツリー」内のポート番号による位置、例えば 3.1.0.0 など）を知ることができず、論理アドレス割り当て手続きを完了するためにこれを把握する必要があります。論理アドレスがなければ、デバイスはブロードキャストメッセージのみを受信および送信できます。物理アドレスはピン 16（DDC/EDID）を介して伝えられるため、CEC サブシステムの設定には、物理アドレスをディスプレイの EDID から抽出できるように、どのディスプレイ出力ポートがその CEC オブジェクトに関連付けられるべきかを指定することが含まれます。

アクティブなコネクターの名前を見つける一つの方法は、xrandr --query を使用することです（これは Wayland でも機能します）： 

$ 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  
   ...

正しいポートが識別されたら（例えばHDMI-A-1）、sysfs ポート名は ls -1d /sys/class/drm/card*-HDMI-A-1 を使用して見つけることができます（例えば card1-HDMI-A-1）。この場合、対応するディスプレイの EDID データは /sys/class/drm/card1-HDMI-A-1/edid に保持されます。

物理アドレスはこのようにプレビューできます： 

$ edid-decode --physical-address /sys/class/drm/card1-DP-3/edid
4.0.0.0

cec デバイスノードが再作成されるたびに CEC 設定を行う必要があるため、これは cec オブジェクトが表示されたときに発火する別の udev ルールで最もよく処理されます。

ノート: 以下のルールで card1-HDMI-A-1 をあなたのコネクタ名に必ず置き換えてください。
/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 checks EDID every tenth of a second
# https://git.linuxtv.org/v4l-utils.git/tree/utils/cec-ctl/cec-ctl.cpp?id=0a195181d771090f3c99d4a6ddb8151352509061#n1977
# Use `Type=oneshot` if using `--phys-addr-from-edid` instead
ExecStart=/usr/bin/cec-ctl --device=0 "--osd-name=%H" --playback "--phys-addr-from-edid-poll=/sys/class/drm/%i/edid"

HDMI ソースが自己を宣伝できるデバイスクラスには、「録画装置」（最大 3 台）、「チューナー」（最大 4 台）、「再生装置」（最大 3 台）の 3 種類があります。これは重要です。なぜなら、HDMI デバイスは CEC を介して互いに通信する際に物理アドレスを使用せず、代わりに 4 ビットの「論理アドレス」を使用して「チューナー＃3」や「再生装置＃1」などのデバイスを識別し、それぞれの数には限りがあるからです。一つのタイプのデバイスが多すぎるためにアドレス割り当てに失敗した場合、代わりに「バックアップ」（最大 2 台）の役割が割り当てられるかもしれません。これらの役割は、以前に述べた CEC の機能に関連して意図されています。すなわち：

  • 「チューナー」は「チューナーコントロール」をサポートすることが意図されています
  • 「録画装置」は、テレビが他のアドレスからの関連メッセージを無視するとされているため、ワンタッチレコードを使用できる唯一のタイプです
  • 「再生装置」は、一般的なビデオソース用です。コンピュータやビデオゲームコンソールなどは、「再生装置」とみなされます。

上記の cec0-configure@.service ユニットは --playback を使用して再生装置を設定しています。ただし、再生アドレスが使用済みでない場合、またはテレビの入力メニューで各デバイスクラスを視覚的に区別するために PC を目立たせたい場合は、デバイスクラスをチューナー（--tuner）またはレコーダー（--record）に設定しても一般的に問題ありません。

入力処理デーモン

ユーザー空間ツール

/dev/cec* デバイスへのユーザーアクセスは、ユーザーを video ユーザーグループに登録することで許可されます。CEC デバイスを制御する基本ツールは v4l-utils からの cec-ctl です。同様のものに libcec からの cec-client があり、python-cecAUR で利用可能な Python バインディングもあります。

参照

「https://wiki.archlinux.jp/index.php?title=HDMI-CEC&oldid=36836」から取得