4 件の脆弱性を修正した X.Org Server 21.1.2、ディスプレイの物理 DPI を報告する機能が廃止に 33
ストーリー by headless
固定 部門より
固定 部門より
15 日に公開された X.Org Server 21.1.2 では最近報告された 4 件の脆弱性が修正されたほか、実際に接続されたディスプレイの物理DPIを報告する機能が廃止になっている (Phoronix の記事、 メーリングリストでのアナウンス)。
リバートされたのは DRM コネクターから得たディスプレイの物理サイズをプログラムへ伝える機能で、X.Org Server 21.1.0 で追加されたものだ。しかし、あまりに破壊的な変更だったことから廃止し、常に 96 DPI と報告する方式へ戻したとのこと。
リバートされたのは DRM コネクターから得たディスプレイの物理サイズをプログラムへ伝える機能で、X.Org Server 21.1.0 で追加されたものだ。しかし、あまりに破壊的な変更だったことから廃止し、常に 96 DPI と報告する方式へ戻したとのこと。
そんなに大変なのか (スコア:2, 興味深い)
俺、画面のスクリーンキャプチャをPNGで保存するとき、そのとき使ってたディスプレイの解像度をピクセル毎メートルでわざわざ計算（小数点以下は四捨五入）して、バイナリエディタでpHYsチャンクをいちいち書き込む変態なんだけど、そんな俺しか得をしないような機能を実装するのって大変なんだな、という感想。そりゃ消されるわ。
# 俺みたいなことをする
変態こだわり派って、他に居るのだろうか? いや開発者の若干名がちょっとこだわってみたくなったから、実装したんだろうけど。それは変態じゃなくて (スコア:2)
偏執狂(へんしゅうきょう) Paranoia [kotobank.jp]なのでは？
でもまだ、病的レベルではないと思う。
uxi
Re:そんなに大変なのか (スコア:1)
何がアレかって、世の中ディスプレイ側が腐ってる可能性も有るって事よ。
ディスプレイ切替機とかIPKVMとか。
Re: (スコア:0)
誰も使っていない機能はろくにテストもされないからね。
Re: (スコア:0)
俺の元コメ#4172619改めて読むと変態って書きすぎたな、って思ったけど、
結局現在のディスプレイ解像度を取得したい動機って例えば、600dpiの画像（書類）を画素ピッチが0.11mmくらいのディスプレイと0.3mmくらいのディスプレイと印刷結果とで、同じ大きさに表示させたい、ってことなのかな?
そう考えると、ディスプレイ切替機使われると確かに詰みそう。
# かくいう私もリモートデスクトップ使いでね。
Re: (スコア:0)
とりあえず途中は読み飛ばして変態ってことは把握した
Re: (スコア:0)
ディスプレイ切替器はディスプレイ側から引っ張って中継してくれる奴もある。
でもディスプレイの電源切れてたら引っ張れないとか起きるし、複数ディスプレイで別解像度(dpi)になるだけで詰む。
Re: そんなに大変なのか (スコア:0)
Re: (スコア:0)
> 昨2000年
A.D. 21 年頃か…
Re: (スコア:0)
DTP（デスクトップパブリッシング）（印刷物制作）の分野だと、ディスプレイに実寸表示（印刷プレビュー）されたものが、そのまま印刷できたら便利ってことですよね。
この分野は、まあ、なんだかんだで大まかには達成できていると思うが、精度はまだまだ足りないだろうね。
私は、電子書籍派ですが、電子書籍等を自家印刷製本して堪能したい派もいるでしょうから、まあ、そういうことですね。
家庭用プリンタの解像度は300dpiから1000dpi以上へと進化したにも関わらず、ディスプレイは96dpiで進化が止まって、今なお、価格面で優位という状況ですからね。つまり、「
Re:そんなに大変なのか (スコア:1)
変態は大変なんだな。
これだったのね (スコア:1)
CLI環境ではdrmエラーが出るだけだったが
GUI環境では起動が激重だったらしい
/etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULTに
video=SVIDEO-1:dを追記で回避してた
# drm:direct rendering manager
Re:これだったのね (スコア:3, 参考になる)
それは関係ない話では？
そのバグは４年くらい前の話で、すでに修正済みだと思います。
物理DPIを自動認識する機能が入ったのは X.Org Server 21.1.0 で、公開されたのは 2021年10月27日、つい最近の話です。
それが今回一時的にリバートにされただけです。
なぜ一時的にリバートされたかと言うと、
今までDPIが96で固定だったのに、21.1.0でDPIが自動認識されるようになって、多くのユーザが混乱したためです。
互換性は保ったほうがいいよねってことで、今回のリリースではとりあえずDPIを96固定に戻しただけです。
ですから「GUI環境では起動が激重だったらしい」の話は無関係だと思います。
なお、Phoronix にも書いてありますが、DPIの自動認識機能は近々復活します。具体的には
デフォルトではDPIは96で固定（従来からの挙動と同じ）で
コマンドラインオプションで -dpi auto みたいな指定をすると物理DPIの自動認識が有効になる
という仕様を考えているそうです。
Re: (スコア:0)
それは関係ない話では？
いえKernel 5.15との組み合わせで再燃してましたね
autoで見失うって状態だったと思われます
Re: (スコア:0)
また微妙な主張を、、、
LTSユーザー向けには正しいが通常向けには間違っています
最新カーネルでは再発してますので次期LTS更新までに整合性が解消されないとLTS民も再度被ります
Re: (スコア:0)
該当するリバートのコミットログをちゃんと読んでください。
https://github.com/freedesktop/xorg-xserver/commit/35af1299e73483eaf93... [github.com]
「互換性は保ったほうがいいよねってことで、今回のリリースではとりあえずDPIを96固定に戻した」という内容が書かれています。
そして「GUI環境では起動が激重だった」という話は全く言及されていません。別の話と考えた方が妥当だと思われます。
破壊的な機能追加？ (スコア:0)
おかしな機能を追加してもそれまでのプログラムはコールしないから影響でないような
元々固定値を戻す仕様が色々な値を戻すようになったらという話かな
だとしてもわざわざ取得・利用しておきながら破壊的な動作（たぶん対応バグ）するってのはどうかと
Re:破壊的な機能追加？ (スコア:1)
WindowsがHigh DPI対応のためにどうして新しい関数やマニフェスト項目や互換モードを追加しまくったんだと思う? 理論的にはGetDeviceCaps(hdc, LOGPIXELSY)の戻り値を変えるだけなのに。
Re: (スコア:0)
WindowsのそのAPIはLOGFONT構造体についてMSDNライブラリから調べると
って式が案内されるからちょいちょい使われてたはずだけど、
他が96dpi決め打ちで書かれる事例、間違いなく大量にあるだろうからなぁ……
Re: (スコア:0)
なぜ正常な値が返ってくると思うのだろうか。
「DRM コネクターから得たディスプレイの物理サイズ」だぞ。
きちんと値を返しているH/Wばかりとは思えん。
0や負数が返ってくる機器が多数だったんだろ。利用側の問題じゃない。
H/Wの自己申告が腐ってたとしても (スコア:2)
機種特定出来れば、DB 用意してパッチすることは出来るだろうし、
ユーザーが個別に H/W からの情報上書きして修正する用の config を手動で食わせて適正値にすることは可能なはずですよね。
これ、現状では 96dpi 返さないと腐るアプリが山のようにあるため、96dpi 以外の値を返すと使い物にならんくらい手間がかかるので一旦(？)元に戻したという話なんじゃないですか？
uxi
Re: (スコア:0)
アプリ側の問題は滅茶苦茶あるだろうけど、ディスプレイ側もあるのは間違いないだろうし、
DBで個別対応は仕組みの整備とDBのメンテ体制も居るから一朝一夕には無理。
他ツリーで言及あるけどKVMやマルチディスプレイ、プロジェクタ類だとサイズが不定で、
その瞬間の正しい値が役に立たない状況は少なくないだろう。
そもそも離れて見るディスプレイ(やプロジェクタ)のdpiと卓上ディスプレイのdpiが単体では区別出来ないけど、
一緒くたに表示サイズ調整したらどう考えても離れたディスプレイでの表示が小さすぎる。
閲覧者から見てどの程度の画角を占めてるのかがGUI上では多分重要だし。
ありがち…… (スコア:0)
実質96dpiで固定だった結果、色々な所(含む仕様)でハードコードされちゃったのね……
Re: (スコア:0)
歴史に倣うなら、まずはSetProcessDPIAware()みたいな宣言で明示すべきだろうね
Re: (スコア:0)
既に動いて使われている物の働きを変えるようなことはせずに、
「シン・DPI」とか新しい名前を作ってそれで返すようにすればよかったのに。
Re: (スコア:0)
こうしてこの世界にまた一つ新たなDPIの定義が生まれた。
# DPI FINAL WARS
Re: (スコア:0)
どいつもこいつも脳みそ空っぽのクソばっかりだな、俺が新しく完璧なDPIの定義を作ってやるぜ！
こうしてまた非互換なクソが一つ増えたのであった…的な
Re: (スコア:0)
XPから使えるようになったHighDPIが、ほぼ標準として使えるようになるのにWin10までかかったという全く同じ先行事例があるのに、なんで全く同じ失敗してんだろうなぁ。
Re:ありがち…… (スコア:1)
ディスプレイの画素数ではなく画面上のサイズで表示を指定できるように最初になったのはXPだがそのご実装が二転三転しているわけで…
なんで全く同じ失敗をするかと言うとあっちを立てるとコッチがたたないみたいな問題が多いからでしょう。
Windowsにもディスプレイ上の表示サイズを指定するAPIが複数ありカオスなことになってる…
Re: (スコア:0)
画面とか音とか文字入力とかホント基本的な部分がままなりませんなぁ…
Re: (スコア:0)
ちなみに複数のAPIがあるのでウィンドウズ側でどのAPIで表示サイズを指定するか選べるようになっている。だが既存の表示サイズ調整関連API全てに対応しているソフトは稀。つまりあるソフトが正常に拡大されるようにすると別のソフトが狂うみたいなことになりがち。ソフト毎に細かく設定できた気もするがそんなリバースエンジニアリングに片足突っ込むようなことを一般人にやらせるのは…
酷いソフトだと世代の異なるAPIの利用が混在してそうだな…
Re: (スコア:0)
同じ失敗ってのは、Winodwsがやって駄目で、遣り直すことになった失敗対応を、あえて真似して、やっぱり失敗しましたってことなんだが。
違うやり方なり、Windowsがまがりなりにも辻褄合わせてきた成果のほうを真似すればいいのに、わざわざ初期に失敗してやりなおすことになった手段を採用して、予想通り同じ結果になってるのが意味わからんって話でしょう。
Re: (スコア:0)
Win95の時代(どころか16bitの時代から？)あるGDIでも論理座標自体は扱えてて、
プリンタへの印刷とかではちゃんと機能して無かったっけか。