なにをしたか

あらまし

私はディスプレイは「随時買い足す」スタイルできた。 それも、主にリサイクルショップで買い集める形だ。

台数が多く、並行作業も多いので、接続数の関係上どうしてもディスプレイが増えざるをえない。

そうした中、ずっとメイン環境を支えてきたのがLGの22EN33及び22EN43である。 支えてきた、と言うと良さそうに聞こえるが、私にとっては最悪なディスプレイである。 輝度調節がおかしいし、色味も最初からぶっとんでいて調整の意味がない。挙げ句、ドット抜けはあるし、ちょっと触れただけでも傷はつくし、アダプタは激しくコイル鳴きするし、一度は液晶抜けするし、LGのサポートは「何も問題はない」と突っぱねるし、もう二度とLGのディスプレイは買わないと心に決めるくらいはひどかった。 似たようなサムスンのS22B300は非常に素晴らしいディスプレイなので、サムスンがPCディスプレイをやめたのが残念でならない。

基本的に輝度や色味などのぶっとび度合いは22EN33のほうが悪いが、傷がついたりドット抜けしたり壊れたりとトラブルが多いのは圧倒的に22EN43である。そして、その22EN43が、ついに画面全体に乳白色の何かを浮かべるようになってしまった。

困ったものだと思っていたところ、なんだかちょうどよくアウトレット品の4kディスプレイ、AcerのET322QKがえらい安くで出ていたので即決してきた。

解説

これは、もうちょっと説明がいるだろう。

私のディスプレイは圧倒的に21.5インチFHDが多いが、これはFHDディスプレイとしては安いためである。叩き売られることも多いし、中古も潤沢だ。

基本的にはやや小さいが、DPIとしては101ないし102程度であるため、これ以上大きいと96を下回ってしまう。解像度的には無難な線だ。

4kに変更したい、というのはずーーーっと前から思っていたこと(10万円くらいの4kディスプレイが出始めた頃から)なのだけど、その場合27インチを本命としていた。 これは、視線移動量と視点距離を考えたときにこれ以上大きくなってほしくないからだ。 一方、21.5インチや24インチの場合、4kになることで密度が上がり、必然的に多くの情報を表示できることから、より色々と表示できるし、ウィンドウのクォータータイリングも現実的になる…はずなのだが、24インチや21.5インチの4kではあまりにも表示サイズが物理的に小さいため、結局左右タイルが限界であり、あまり情報量が増えない。 27インチもまぁまぁきついが並べるには限界サイズである。

私のディスプレイは基本的にメイン2+サブ1という使い方なのだが、今回は事情が事情だし、2枚は買えない。 そこで1枚だけ置き換えるのだが、そうするとメインディスプレイ同士で表示サイズが著しく違うという事態が生じる。

32インチはちょっと大きすぎるが、おけないこともない(32インチ2枚は机のサイズを考えても現実的でないくらいは厳しい)し、DPI差が小さく、妥協できるセッティングが出しやすい――このことはこの記事のこのあとの話で延々触れる。

ちなみに、アウトレット(展示品)というといまいち感があるが、ディスプレイの場合保証があったところで対応されづらいのが現実である上、対応されることのないドット抜けや表面の擦り傷というのがあって賭けみたいなところもあるので、動いている実物をチェックした上で買えるのはむしろメリットだと思っている。

今回は、これまで理解はしていたが、実際に混ぜてみたことで改めて実感したことを述べていこう。 もちろん、Linux前提である。

小さい? 大きい?

実測値としてはLG 22EN43は幅47.7cmで1920px (102dpi)、 ET322QKは幅69.3cmで3840px (140dpi) である。

102 / 140 = 0.728571427571… であるため、ドットは72.857%(約3/4)に小さくなったことになる。

逆に、ET322QKをFHD表示にした場合は145.71%に拡大されることになる。これは、単純に21.5インチディスプレイから同一解像度(FHD)のまま32インチディスプレイに変更した場合と同様のことである。

これは一辺を見た数字だし、基本的にコンピュータ上で表示されるものというのはボックス状なので、面積で言うと53.08%まで小さくなっているのでだいたい「半分になった」という感覚だし、FHDのままだと212.31%と「倍になった」感じがする。もちろん、ディスプレイの表示面の面積自体倍以上に大きくなっている。

これをまぜたとき、FHDで統一するともちろん4kディスプレイのほうが物理的に大きいぶん大きく表示される(倍以上に!!)のだが、実はこちらはあまり気にならない。 「大きいテレビで引き伸ばされた画面を見る」というようなことに慣れているからだろうか。実際、その画面を見ると「ギザギザでぼんやりしているなぁ」と私は思うのだが、でもそこまでみづらいということもない不思議だ。

ところが、FHDで適性なサイズにしている状態で4kに表示させると表示サイズが半分になっていながら表示する空間は4倍ある(表示可能な量は4倍にしかなっていないのだが、「半分のサイズで表示されている」「空間は4倍になった」というそれぞれ別の感覚が相乗効果を発揮する)のでやたらがらんとして見えるし、やはり適正サイズの半分というのは小さすぎる。 高密度になっているので意外と文字も読めるは読めるのだが、しかしながら非常にきつい。4kを4kとして運用する以上、元のままのスケールではちょっとやっていられない。

ちなみに、32インチのディスプレイは問答無用で大きい。一枚だけ使うにしてもかなり距離がないと大きすぎるくらいで、マルチディスプレイするサイズではないな、と感じる。

混ぜる場合どうスケールさせる?

4kのほうがいいディスプレイだし、物理的にも大きいので4kをメインに考えるべきだろうと思うのだけど、 72.857%ということは、元の状態でスケールしていなかったとしたらだいたい1.4倍にするとFHD側の元の状態と同じ物理サイズになる。1.5倍だとちょっと大きい。

ところが、1.4倍にスケールさせてしまうと、FHDの論理ピクセル数は1370となるため、HD(FWXGA)と同等になる。縦は771ピクセルである。 21.5インチのHDディスプレイというのは実在したが、ちょっと狭い。ウィンドウをタイルして並べるとやたら文字も大きく表示領域がまるで足りない感覚になる。

だから、間をとって1.2倍(あるいは1.25倍)というのがよさそうではある。フォントサイズは少し大きめにしたほうがいいかもしれない。4k側で文字が小さく感じるかもしれないし、部品が多少小さくなるのに比べて文字が小さくなる影響は大きいからだ。

1.2倍スケールの場合FHDの論理ピクセル数は横1600ピクセル、1.25倍スケールの場合1536ピクセルになる。1.25倍だとちょっと狭いが、1.2倍ピクセルなら「なんか表示が大きい」程度で済ませることもできそうな感じである。 MacなんかはUIが大きくぎっしり表示されるので、それが気にならない人は普通にいるだろうし、悪くないかもしれない。

試した結果は結局「間をとる」という無難な結論になってしまった。

ちなみに、今回の場合21.5インチFHDが2枚で32インチ4kが1枚という構成であるためにあまりFHD側を無視するわけにもいかなかったが、これが4k2枚でFHDが補助ディスプレイであるという話であれば1.4倍スケールでも別に構わないだろう。1370ピクセルあればウィンドウを常に最大化してしまえばそんなに気にならない、というか、そもそもラップトップが実DPIに合わせてスケールするとそれよりも小さくなるのが普通なので(私のThinkPad X1 Carbon(14インチ FHD)は148DPIでスケールされているため論理ピクセル数は1228である)表示スペースが足りずにはみだすようなことはあまりない。

それぞれスケールできない?

できない、らしい。

Windowsだとディスプレイごとに「拡大率」という値を設定できるようになっている。 この拡大というのはまんまスケーリングを意味しているので、ここで175%を設定すると論理1ピクセルに対して1.75ピクセルをカウントするようになる。

だが、この設定が今のところLinuxでは上手くできない。 最もスケーリングが細かくできるのはKDE Plasmaだが、それでもディスプレイごとに独立した設定はできないようになっているようだ。

xrandrを使うことで設定自体は可能だが、少数の値を設定してしまうとフォントがすごく汚く表示されることになる。

だから、現時点ではディスプレイごとのDPI差を適切に埋める完璧な方法はない、ということになるだろう。

フォントだけ合わせるという方法

今回の場合、51.6%に縮小されるもののUIのサイズとしてたいていの場合は51.6%というのは私にとっては許容できるサイズに収まった。

そこで、私がとった方法がこれだ。

実DPIによる影響が最も大きいのは「文字サイズ」であるため、LinuxでもUIスケーリングとは別にフォントはスケーリングできるようになっている。

そして、フォントのスケーリングの構造はちょっとめんどくさい。

フォントの場合96を1として、設定されたDPIの倍率にスケールされる。 つまり、144DPIを設定した場合、144 / 96 = 1.5 なので、1.5倍にスケールされる。

フォントにおける1は1ピクセルであり、1ポイントでもあるのだが、両者は同時にスケールされることになり、基本的には同一視できる。 FontConfigは144DPIを設定した場合、16pxを求めても、16ptを求めても、24実ピクセルで描画する。 問題はビットマップフォントを使う場合だが、その話は割愛する。

基本的に115.2DPIにすれば1.2倍スケールとなる。120DPIで1.25倍スケールだ。 UIと比べ柔軟に設定できるので、このあたりを参考にバランス良い設定になりそうなDPIを設定すると文字側は調整できる。

私は今のところ120-136DPIの範囲で様子を見ている感じだ。 KDE Plasmaの場合、ほとんどのアプリケーションはPlasma Workspace側で設定されたDPIに従うが、ConkyはFontConfig設定ファイルを尊重するため、Conkyのサイズ調整を目的に異なった値を設定する方法もある。

あとは、積極的にフォント側DPIを設定してからUIスケーリングでバランスをとる、という方法もある。 この方法はもっと実DPIに差がある場合の解消方法として使える。 また、フォントのみで解決する場合は細かなUIスケーリングがいらないため、「Hi-DPIのためにKDE Plasmaを使わなくてはならない」という状況を避けられる。 (KDE Plasmaは0.1倍単位でUIスケールできる)

もはや、DPIとかピクセルとかポイントとかいう、定義が明確であるはずの言葉が相対的なものになってしまっていて意味がわからないが。

なお、フォント設定でスケールする場合に特に重要なこととして、「普段GTKデスクトップを使っていて、スケーリングのためにKDE Plasmaにスイッチした人」は、.xprofileなどでexport QT_QPA_PLATFORMTHEME=qt5ctとかしているのであれば、それをやめないとKDEの設定がちゃんと反映されず、GTK2アプリケーションにも反映されない。

また、この方法を取る場合、パネルだけはCinnamonもPlasma Workspaceも高さがピクセル単位になっているため大幅に小さくなってしまう。このため、パネルの高さは再調整が必要だ。 私の場合、サブディスプレイ上にパネルを置いているため問題はなかった。

ブラウザのスケーリング

ウェブブラウザはちょっと特殊な事情を持っているようだ。

Chromium系(ChromeもVivaldiも)ブラウザはフォントのDPI値が約110%以上(103以上?)であるとき、そのDPI値に合わせて10%単位でスケールするようだ。 これはブラウザをズームしたときと同じ挙動だが、困る場合がある。

これによってパーツがはみ出してみづらい場合があるが、これについてはまだズームを落とせばいいので許せる。 問題はフラゲ(フラッシュゲーム)である。 見た目が汚くなる上に動作が遅くなって非常に辛い。

なお、Firefoxはまた事情が違うのだが、layout.css.devPixelsPerPxを1にすれば自動スケールは行われなく成り、-1にすると自動的にスケールされる(多分、UIスケールによるのだが、DPIによるのかもしれない)。この機能に関してはlayout.css.dpiも絡む。

実際、メイン/大きな4k * 1 + サブ/小さなFHD * 2 ってどう

だめ。 どうしたってみんな4kを取り合ってしまう。

なにをするにも大概大きい4kっていうのは便利で、できればそこに置きたいという気持ちが強い。 みっちり書かれている文章だとそうでもない(FHDの全画面表示でもテキスト量が多すぎる)けれども、なにかしら情報が付属していたりマルチペインだったりするのが現代なので、たいていのアプリケーション及びコンテンツが4kを奪い合う。

サブは私の場合メール, Discord, Twitterなんかになるのだけど、これらは基本的にリアルタイムで見続けるようなものでもないからそれぞれ全画面化してサブに置いているものの、4kだったらモニタリング機能とか作ってタイルして色々表示させてもいい。

だから特に必要ないものも含めてたいていのアプリケーションは大きな4k(もちろん、適切な大きさの)を欲しがる。 21.5 FHDを回転させて縦にするとバランスはいいが、表示できるものはさらに少なくなる。

32インチを複数置くのは難しいので、やはり27インチ4k*2 + 21.5もしくは24インチFHDというのがバランスがいいと思う。 逆にサブを32インチ4kにして少し離してモニタリングに使う手もあるけど。

Acer ET322QKってどう (2018-12-03 追記)

基本的には悪くないと思う。 少なくとも22EN43/22EN33のように色味がおかしくて輝度もおかしくて視野角も異様に狭いといった問題はない。 特別良いということもないけれど、かといって目立った問題があるわけでもない。

特別良いというわけではなく、色味も標準(というフラット設定)ではフラットではないため、アートワークの作業をするクリエイターにはとても耐えないし、ゲーマーにも無理だろうけれど、 動画視聴程度であれば遅延が気になるということはないし(ただビデオカードのほうは4kなのでちょっと重いけど)。

色味も、特に優れたところはないけれど、別に使えないことはない。一応sRGB 100%らしいので、カラーキャリブレーションすれば結構使えるのかもしれない。

目立った問題としては入力端子が3系統(HDMI 2.0x2, DP 1.2x1)であることだろう。 台数が多いとなるべく集約したいので、端子はなるべく欲しい。 私の環境だとDVI-Iが多いけど、別にDVI-ItoHDMIは可能なのでHDMIで良しとして…

JAPANNEXTがIPSで消費電力も最大35Wと低いのに安くてなんか強い。 それはともかくとして、以前のように端子数5を越えるものは減っている感じだけど、3というのは結構少なめ。 端子数4は普通に狙えるので、そこは残念ポイントな感じがする。

最大の難点は、起動が遅いということだろう。 EIZOとかも遅いので、品質の問題ではないけれど、結構遅い。そして、切り替えも遅い。信号がなくなってから再び信号を捉えるまでが長い。

「待てばいいじゃん」と思うかもしれないが、実は KDE Plasmaでは深刻な問題になる。

KDE Plasmaで思わぬ問題 (2018-12-03 追記)

KDE Plasmaの場合、ディスプレイに対してディスプレイの接続方法ではなく、「ディスプレイの認識上の番号で」識別する。 KDE Plasmaはディスプレイを中途半端に重ねることも可能で柔軟なのはいいのだが、応答の早いLG及びサムスンのディスプレイはすぐつくのだが、このときKDE Plasmaは「ディスプレイが2台しか接続されていないように見間違う」。

つまり、左から

• LG HD
• ET332QK
• サムスン HD

と並んでいて、パネルはサムスンの上にあるのだが、 このときこの並び順に最初にKDEにログインした時点では認識されている。 だから、パネルは3番ディスプレイにある。

ところが、一時ブランクスクリーンになって復帰すると、ET332QKの認識が遅れるためにサムスンが2番になり、ET332QKが3番になる。 結果としてサムスンとET332QKの壁紙が入れ替わり、パネルはET332QK上に移動してしまう。 さらに、なぜか中心座標を見失ってしまって、Conkyが1920pxずれる。

3台であれば右にあるディスプレイをプライマリディスプレイにすることで1番を固定すればET332QKが最後にくるように固定できるから問題は軽減される。 だが、アンバランスな配置のせいかPlasmashellがバグることが多い。さらに、どうしても左側のディスプレイをy:1081に固定するのが難しい。y:0になってしまう。

また、マルチディスプレイではKDEはフルスクリーンにしたときにパネルの表示がおかしくなる。 パネルの表示の上に古いパネルの表示がかさねられたようになる。つまり、以前同アプリケーションでフルスクリーンにしたときと同じ状態になる。 確実になるわけではないが、一度発生するとフルスクリーンにするたびに再現しつづける。

結局、私はCinnamonに戻した。 フォントのスケーリングを中心としてUIスケーリングしないことにしたため、これでも問題はない。

CinnamonのフォントスケーリングはDPIではなく倍率になっている。 0.1倍単位だが、1.25倍で120DPI, 0.1倍あたり9.6DPIというのを基準に考えれば良いだろう。 今の状況を考えるとこちらのほうが素直だろう。

このままではQTアプリケーションが小さいので、.xprofileでQT_SCALE_FACTORを設定しておくと良いだろう。 1.2とか1.25あたりが無難な値になるだろうか。

ところがCinnamonでも… 原因はDP (2018-12-05 追記)

Cinnamonなら大丈夫と油断していたところ、Cinnamonでもブランクスクリーンに落ちるとおかしなことになってしまった。 パネルがおかしくなるといったことはないのでKDE Plasmaよりはマシではあるものの、好ましい状態ではない。

どうも他のディスプレイでは発生しない症状として、「電源がオフになると切断される」らしく、問題はディスプレイの電源を切っても発生する。 そして調べていくと、「DPの仕様」らしいとわかった。なるほど、確かに他の2台はminiDP→DVI-Iで接続しているのでDPではささっていない。

WindowsだろうがLinuxだろうが、ディスプレイのホットプラグで問題が生じないなんてことはないので、これは大迷惑である。ディスプレイを共有して作業していることなんて普通にあるのだし… 実際、この挙動は相当強く嫌われているようだ。

なんとかしようとがんばって/etc/X11/xorg.conf.d/90-mhwd.confに

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
        Option "NoLogo" "1"
        Option "UseHotplugEvents" "false"
        Option "AllowEmptyInitialConfiguration" "true"
EndSection

などと書いてみたものの残念ながら効果はなし。

ただ、この場合問題ははっきりしているので、本気になればやりようはある話だと思う。 とりあえずは私の場合ディスプレイの電源を切らないように設定してしのいでいるが、困るのは「通し作業のときにディスプレイを切って節電する」という方法がとれないことだと思う。

そのうち何か考えて対応したい。

がんばって解決した人がいるようです (2018-12-16追記)

Twitterでのやりとりを経てエヌユルさんがxrandrを使う方法で解決した旨ブログにかかれていました。

実はこの方法、私にとっては既知で、以前のスケールとDPIのアーティクルを含めて「あんまよくないので言及を避けていた」方法だったりする。 しかし、参考にしてもらえるなら、もっとちゃんと説明すればよかったな、この方法でよかったなら悩ませずに済んだのに…と割と後悔している。

手順、及び結果はどうブログの記事の通りである。 ちなみに、ディスプレイ位置が上限に合わせられてしまうのは「0,0にディスプレイを欲しがる」からで、左のディスプレイが4kなら問題ないのだが、そうでないとFHDディスプレイを上にあげたがる。 Plasma Workspaceだと勝手に修正されてしまったりする。

私が言及を避けたいと思う理由は次の通り

• ディスプレイをネイティブ解像度以外にしたときのようなもやっと感がある
• xrandrのスケーリングはFTより後段にあるため、字の描画が大変汚い
• Plasma Workspaceはひょんなことでこの設定をリセットしてしまうのでえらいことになる(パネルが吹っ飛んだりする)。 これは、ワークスペース切替時、アクティビティ切替時、ロック時などに発生しがち
• DPのホットプラグ切断による問題がより深刻化する
• 私としてはUIサイズはそれほど気にしないがフォントサイズの落差が辛い、ということを問題にしているので、FHD側を1/4角にするというのはフォントサイズの設定において事情が変わらない(単に元はFHDが4倍角だっただけの話なので、DPIをだいたい中間に設定するという話から動かない)

UIスケーリングに関しては、現代においては「ブラウザ(特にBlink系)がフォントDPIに従って勝手にスケールしやがるので、中間DPIを設定しておけばだいたい許せる結果になる」というのが私の感想である。 画像を見たり、VSCodeとかAtomを使う分には割とどうとでもなるので(ディスプレイを4k/FHD間で動かすのは大変だけど)、「フォントサイズさえ妥協できるサイズにしとけばいいや」が私の現状の結論。 もちろん、言うまでもなく「ディスプレイごとに適切スケールさせろ」と言いたいところだけど、未だにNvidiaがLinuxでマルチヘッドディスプレイに対して雑な対応を続けているあたりを考えると、多分無駄な主張になるだろう。 世の中マルチヘッドディスプレイが当たり前になっていっているわけでもないし。

あと、本題とは関係ないが

世の中のwebサイト巨大ディスプレイに最適化されてなさすぎですね.

これについてはDPIと画面サイズとスケーリングとピクセルの話で書いているけど、基本的に現代においては「1ピクセルが物理的1ピクセルを意味しない」というスケーリングの方向であり、 14インチのThinkPad X1 Carbonですら横の論理ピクセルは1288pxである。12.5インチのThinkPad X280では1047pxしかない。 この方法は、そもそも「物理的にピクセル数が増えても論理ピクセル数は増えない」というものなので、XPS13の4kを使ったところで、論理ピクセル数は1200pxに満たないのだ。

私はFCとしては120dpiに設定しているので、ブラウザは1.2倍にスケールするのだが、それでも4k側だと3200pxも幅があることになる。 さすがにこれを「想定しろ」というのは無理な注文だと思っている。 4kを使うならウィンドウをタイルする、で良いのではないだろうか。大きな4kディスプレイを持っている人はある程度知識がある人のほうが多いし、安全側に倒すならそちらを優先した設計はできない。

どちらかといえば私が考慮すべきなのではないかと考えるのはChromium及びFirefoxのテーマだ。 あれらは全くスケールしないため、4kで最大化すると画像サイズが足りずすっかすかになる。