ハードウェアカテゴリ: グラッフィックボード
ハードウェア名: RX６４００／RX５５０
ハードウェア型式: MSI Radeon RX 6400 AERO ITX 4G
MSI Radeon RX 550 AERO ITX 4G OC
Linuxディストリビューション: ubuntu 22.04 LTS
RX6400 / RX550 を使用するとモニターがブランクになってもモニターが省エネモードにならず、バックライトが点灯したまま。
Intel のiGPUを使用しているマシン(uhd770他)は画面ブランク時にはモニターもバックライトが消灯するのを確認済み。
夜中にPCをつけっぱなしにするとバックライトが消えないので電気がもったいないなぁと思って、色々調べたんですが、結局わからずメインマシンを intel に変更です。
linux で性能の良いグラボを選択する場合は Radeon を選択するのが良いと思いますが、何か設定はあるんでしょうかね。
xset dpms force off
したらどうなりますか？
私も類似の症状の経験がありますが、基本的に「たまにそういうことがある」程度にあきらめています。同一機種でも特定のモニターだけで発生しますので。
どっちがどっちだったか忘れてしまいましたが、DP接続かHDMI接続かを変更すれば解消したりするかもしれません。 (多分、DPだと発生しないだと思う)
返信ありがとうございます。
Chienomi 読んでます！
返信を読んでなんとなく原因がわかりました。
私の環境はマルチモニタです。
RX6400 はモニタ出力が DP と HDMI の２ポートしか無く、
DP と HDMI を使用して２モニタ構成でした。
DP １モニタで確認すると画面ブランク時にバックライトが消えます。
HDMI １モニタで確認するとバックライトは消えませんでした。
２モニタだと、どうもHDMI接続に引きずられているようです。
intel uhd770 だとトリプルモニタ DP DP HDMI の場合でも正常にバックライトが消えるし、Radeon の linux ドライバーが対応していないのかもしれません。
DPが２ポート以上あるRX６６００を使えばバックライトは消えるのかもしれませんね。（linux でゲームをしない私には高価すぎて・・・）
ACPI切ってたりします？
(CPUがRyzenの場合、切らないとエラーが出るため切ってるケースが結構ある)
うちだとRX580, RX5700XT, RX7950XTXがあって、いずれでも基本的にはDPでもHDMIでも問題はないのですが、Systemdで落とすと(つまり systemctl poweroff あるいは poweroff すると)2台あるS2817Qのうちかたっぽだけ落ちない、ということが時折ありました。
DP接続になってから同様の問題は発生していないので多分HDMI固有じゃないかなと思うのですが、HDMIでつないでいる別のディスプレイで問題が生じているわけでもないので、話は割と複雑です。Cinnamonから落とすと発生しませんし。
いずれにせよ、 xset dpms force off して切れるのであれば根本的な問題があるわけではないので、考えられるのはACPIを切っていてシャットダウン時にうまく動作しないのではないかということ、またシャットダウンシーケンスがうまくいってないのではないかということ(それでも本来は問題は生じないはずですが)のどちらかかと推察されます。
ACPIを切ってるわけでないのなら、シャットダウン方法を変えたり、あるいはデスクトップ環境を変えたり、ディストリビューションを変えたり(構成の問題なのでエディションを変えるだけでも違うでしょう)することで解決する可能性もあります。
はじめに問題を切り分けるのに HDMI １モニタだけにしました。
まず acpi ですが、/etc/defalut/grub に acpi=off の設定は追加していません。
$ cat /proc/acpi/wakeup
Device S-state Status Sysfs node
GP12 S4 *enabled pci:0000:00:07.1
GP13 S4 *enabled pci:0000:00:08.1
XHC0 S4 *enabled pci:0000:0a:00.3
GP30 S4 *disabled
GP31 S4 *disabled
PS2K S3 *disabled
PS2M S3 *disabled
GPP0 S4 *enabled pci:0000:00:01.1
GPP8 S4 *enabled pci:0000:00:03.1
SWUS S4 *enabled pci:0000:06:00.0
SWDS S4 *enabled pci:0000:07:00.0
GPP1 S4 *enabled pci:0000:00:01.2
PTXH S4 *enabled pci:0000:02:00.0
PT20 S4 *disabled
PT24 S4 *disabled
PT26 S4 *disabled
PT27 S4 *disabled
PT28 S4 *enabled pci:0000:03:08.0
PT29 S4 *enabled pci:0000:03:09.0
次に xset dpms force off ですが、
xset dpms force off
xset dpms force suspend
xset dpms force standby
いずれも一瞬バックライトは消えますが、１〜２秒後に元に復帰します。
poweroff などで電源落とす場合はPCの電源が完全に切れ、モニターへの信号が無くなりモニターは省エネモードになります。
今回調べているのは無操作時の画面ブランク時にHDMI接続モニターが省エネモードにならないという事で、シャットダウン時は問題ありません。
ディストリビューションを変更して確認するというのは有りだと思いますが、いつも常用しているPCなのでインストールし直しはハードルが高いです。環境が変わるのはそれなりに大変なので。
ちなみに使用しているモニターは DELL S2721DS と P2417H です。
この手の問題はしばらくすると kernel のアップデートなどで fix されたりするかもしれないので気長に考えようと思います。
（HDMIを使わずDP接続にするというのが一番手っ取り早そうです。）
いずれも一瞬バックライトは消えますが、１〜２秒後に元に復帰します。
これはおそらく入力があるからなので、マウスなどを切った上でやればオフのままだと思います。
ただし、それでもなお一瞬で復帰するのなら、後述の問題が考えられます。
ちなみに使用しているモニターは DELL S2721DS と P2417H です。
DELLのディスプレイは信号検出周りが微妙で、私が同様の問題に遭遇しているのもDELLのディスプレイだけですし、最近は逆に信号が入ったときにディスプレイがかたっぽwakeしないという問題に悩まされています。
設定によって軽減される可能性はありますが、まぁDELLのディスプレイはそういうものだとおもったほうがいいかも
この手の問題はしばらくすると kernel のアップデートなどで fix されたりするかもしれないので気長に考えようと思います。
カーネル周りに由来する問題には見えない(もしそうなら信号が残っているはずなので、どのディスプレイだろうが常に発生する)ですから、これは期待薄でしょう。
もしDPを含むマルチディスプレイにおいてのみ問題が発生するなら別の可能性もあります。
ディスプレイ側にもよりますが、DPで信号を失うとディスプレイは接続を切ります。これはLinux側から見るとディスプレイがなくなったように見えます。
Linuxはディスプレイを失うと現在のディスプレイで再構築を行います。このときディスプレイは復帰するため、「一瞬切れてもとに戻る」という挙動になりますが、ディスプレイを切る操作と排他で行われているわけではないため、ディスプレイを再構築している間に他のディスプレイが切れて変なことになる場合もあります。
この問題は信号が切れるタイミングや順番にも依存するため複雑な問題です。基本的にはDPを含むマルチディスプレイではディスプレイが切れないようにするほうが安全です。
この問題はLinux固有というわけではなく、Windowsも同様の問題でアイコンがぐちゃぐちゃになるという問題があったりしました。
というのは私もインターネットで見た事があり、DELL のモニター固有の問題ではとも考えていますが、BIOS でブートドライブを切り替えて Windows 11 で起動すると Windows では画面ブランク時に問題なくモニター（HDMI と DPのマルチモニタ構成でも）が省エネモードになるので linux のカーネルに含まれるであろう Radeon のドライバと DELL のモニタを組み合わせた時の問題ではないかとも思っています。
linux のカーネルに含まれるであろう Radeon のドライバと
Linuxにおけるビデオドライバというものについてどのような認識を走る持っているのかわかりませんが、 amdgpu はカーネルモジュールではありますが、信号制御のような低レベルな処理は含んでいませんよ？
あれはMesaやVulkanのようなライブラリに対するアダプタでしかありませんので。
(プロプライエタリのNvidiaドライバは別です。そちらは自前で制御しています)
マルチディスプレイの挙動の違いは、そもそもWindowsはディスプレイを切っているときにディスプレイ構成が変化してもその場で描画することはしないので、Windowsで同じ状況にならないのは当然のことです。
そうだったんですね。
現状の認識としては本現象は
・モニターがDELL製でHDMI接続の場合は発生する可能性がある。
本現象の回避策としては
・モニターがDELL製の場合はDP接続のみとする。（HDMI接続を使用しない。）
DELL以外のディスプレイについては所有していないので不明です。
というところでだと思います。
いろいろお付き合いいただきありがとうございました。
いろいろ漁っていたら
に、情報を見つけました。
HDMI connected monitors fail to sleep and instead turn back on when amdgpu.dc=1
4年前からいまだに直ってない問題のようでした。