← 2026-08-31 の一覧へ戻るホーム
オープンソースがなぜ素晴らしいのか——新しいSM750（シリコン・モーションGPU）HDMIドライバの発表

2026/08/31 3:49

オープンソースがなぜ素晴らしいのか——新しいSM750（シリコン・モーションGPU）HDMIドライバの発表

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

本文は、Silicon Motion SM750G10-AC PCIe カード（具体的には SiI9024ACNU トランシーバーと 16 MiB のメモリを備えた SE-DP750A-HDMI モデル）向けの実験的な Linux ディスプレイドライバ (

sm750hdmifb
) について記述している。本ドライバは Ubuntu 24.04（カーネル 6.17）から 7.0 以降の近代カーネルまで DKMS を通じてサポートを提供する。その最も重要な特徴は、物理的に制限されたハードウェア出力（約 2048 ピクセル幅）において EDID の制約を無効化し (
edid_only=0
, 
softscale_wide=1
)、超ワイドデスクトップモード（例：2560x1080）をシミュレーションできる点である。デフォルトでは、ドライバは PCIe 1.1 x1 リンク上の帯域幅への性能最適化を行い、16 ビット RGB565 スキャンアウト形式での順序付きドテリング（オプション: 
rgb565-bbdither
）を用いるほか、94% のグリーンチャネル調整といった特定の色彩補正を適用する。アプリケーションは 32 ビットカラーで描画され、アップロード前に変換される。この構成ではまた、ハードウェアカーソルと DMA アップロードもサポートされている。非デフォルトの設定を検証する際、SSH または他の回復経路を確保しておく必要がある。実験的なモードは無信号、歪み、または不安定さを引き起こす可能性があるため、回復のために実験的な GRUB オプションを削除する必要がある。2560x1080 の超ワイドモニター上で最適な性能を得るには、圧縮アーティファクトを最小限に抑えつつ応答性を最大化するために 2464x1080 の解像度を使用し、シャープ化を有効化 (
sharpen=1
) することが推奨される。インストールには、ローカル DKMS パッケージを構築する（
git clone
、
make check
、および 
./build-package.sh
を使用）ことと、再起動後にレガシーの Linux 
sm750fb
ドライバをブラックリスト化することが含まれる。トラブルシューティングでは、
lspci -nnk -d 126f:0750
を使用し、
journalctl
で関連するメッセージを確認する。厳格な GPL-2.0-only ライセンスの下で動作し、プロプライエタリなファームウェアを含まないこのソフトウェアは、保証に関する強い免責事項を伴っており、ユーザーは設定に伴うリスクと公式技術サポートの完全な欠如を自らの責任で対処する必要がある。

本文

SE-DP750A-HDMI PCIe カード用 Linux ディスプレイドライバー (sm750hdmifb)

このドライバーは、リアルな 2048 ピクセル幅の出力画面や、ソフトウェアスケーリングにより2560x1080 のウルトラワイドデスクトップへ映し出すことを目的としています。帯域幅節約のための色彩変換と更新最適化機能を搭載し、滑らかなパフォーマンスを実現します。

対象製品: 単一 HDMI 端子を持つ SE-DP750A-HDMI PCIe カード向け。

⚠️ 実験的警告

このドライバーは、特定の SM750 ボード向けに開発されています。

  • オプションのモードを使用すると、公表されている GPU またはモニターのクロック制限を超える可能性があります。
  • リスク: 信号が出ない、映像が歪む、不安定な表示を引き起こす可能性があります。
  • 必須対策: 非 EDID モードを試みる際は、必ずSSH 接続または別のリカバリー経路を確保しておいてください。

カードのサポート状況

テストが行われたボードは、SE-DP750A-HDMIとして販売・表記されている必要があります。以下のすべての仕様が満たされていることを確認してください：

  • シリコンモーション (Silicon Motion) チップ: SM750G10-AC（レビジョン A1）
  • PCI ID: 
    126f:0750
  • トランシーバ: シラインジ/ラティス (Silicon Image/Lattice) SiI9024ACNU HDMI
  • ディスプレイメモリ: 16 MiB
  • 出力端子: HDMI 1 つ

注記: PCI ID のみでは不十分です。他の SM750 カードは、VGA 端子を使用したり、異なるトランシーバを搭載していたり、異なる GPIO 配線を行っていたりする可能性があり、現状ではサポートされていません。

インストール手順

Ubuntu 24.04 または Linux Mint 22 のユーザー向けに、ローカルで DKMS パッケージをビルドする手順です。

1. 依存関係のインストールとソースコード取得

sudo apt update
sudo apt install build-essential dkms linux-headers-$(uname -r) libdrm-dev git
git clone https://github.com/KodeMunkie/sm750hdmifb.git
cd sm750hdmifb
make check
./build-package.sh

2. パッケージのインストールと再起動

sudo apt install ./dist/sm750hdmifb_0.5.5_all.deb
sudo reboot

重要: リブート（再起動）は必須です。パッケージがカーネルの古い 

sm750fb
ドライバを無効化（ブラックリスト化）する前に、そのドライバーがカードを占有してしまうのを防ぐためです。

3. 注意点

  • パッケージ名: 
    sm750hdmifb
  • カーネルモジュール名: 
    sm750hdmidrm.ko
    （
    sm750fb.ko
    と混同しないようにご注意ください）

カーネル互換性

  • 想定環境: Linux 6.17 およびそれ以降を前提としています。
  • ビルド制限: DKMS は意図的に古いカーネルのビルドを拒否しています（必要な DRM インターフェースがサポートされていないため）。
  • ソースコード: Linux 6.x シリーズ（6.17 から）および Linux 7.0 以降への互換性パスが含まれています。
  • テスト結果: Ubuntu 24.04 の 6.17 カーネルおよび 7.0 カーネルに対してフルテストスイートが通過しています。

ビルドに関する推奨事項

  • プリビルトパッケージは GitHub Releases で公開されていますが、ローカルでのビルドをお勧めします。
  • 理由: DKMS はインストールされたカーネルヘッダーに対してコンパイルされるため、将来のカーネルで内部 DRM API が変更された場合にソースコードを自動的に更新できます。

通常の使用

デフォルトでは、ドライバーは以下の動作を行います：

  • モニターの EDID モードを使用
  • ディザリング付き16 ビット RGB565 のスキャンアウト（画面描画）を使用
  • ハードウェアカーソルを使用
  • ワーカープロセス上で更新を統合（coalesce）
  • DMA（直接メモリ転送）を使用して 8 行ごとのバッチアップロードを実行
  • DMA が失敗した場合は安全にフォールバック動作を行う

色彩変換の仕組み

アプリケーション側では依然として32 ビットカラーでレンダリングされます。アップロード直前に、ドライバーは以下の変換を行います：

  1. 変更された画面領域を RGB565 に変換
  2. 順序付きディザリング (Ordered dither) を適用（KodeMunkie 開発）
  3. 緑チャネル補正を実施（94%）

理由: SM750 のフレームバッファは PCIe 1.1 x1 リンク経由でアクセスされるため、フルスクリーンの 32 ビット更新に追従することが高解像度において困難です。

  • XRGB8888: 出力ピクセル 1 つあたり 4 バイト
  • RGB565: 出力ピクセル 1 つあたり 2 バイト

ディザリング付きの RGB565 は、デバイス側に送られるピクセルトラフィックを約半分に減らす同時にも、大部分の色再現性を維持します。

グルブ (GRUB) オプション設定

以下のカーネルオプションを追加することで動作を変更できます。

/etc/default/grub
の 
GRUB_CMDLINE_LINUX_DEFAULT
に追加し、後で 
sudo update-grub
を実行してください。

共通プレフィックスオプション名デフォルト値指定すべき場合効果とトレードオフ
scanout_format
rgb565-bbdither
xrgb8888
特に不要。推奨されるデフォルトです。32 ビットスキャンアウトが必要な場合のみ。
⚠️ 注意: アップロードトラフィックが倍増し、高解像度ではラグが生じる可能性があります。		RGB565、ディザリング、緑チャネル補正を無効化します。
scanout_format
rgb565-bbdither
rgb565
特に不要。デフォルトです。単なる RGB565 のみが必要な場合のみ。
⚠️ 注意: 色彩品質が低下します。		ディザリングと緑チャネル補正を無効化します。
dither_green_gain
94
100
特に不要。デフォルトで補正は有効です。緑チャネル補正をオフにする場合。ディザリングは維持されますが、色バランスが緑寄りになる可能性があります。
enable_dma
1
0
特に不要。DMA はデフォルトで有効です。DMA を無効にする場合。CPU がアップロードを担当するため、通常は更新パフォーマンスが低下します。
disable_hardware_cursor
1
0
ソフトウェアカーソルフォールバックが必要な場合。ハードウェアカーソルを無効化し、カーソルの反応速度が低下する可能性があります。
edid_only
1
0
ドライバーカタログモードおよびウルトラワイドモードでのみ必要。
⚠️ 危険: EDID の制限を受けません。		モニターがサポートしていないクロックを適用したり、信号が出ないリスクがあります。
softscale_wide
1
0
2464x1080 および 2560x1080 で必要です。
また 
edid_only=0
も設定してください。
⚠️ 危険 / 実験的: ワイドコンプレッションを有効にし、モニターのストレッチ処理が必要です。
sharpen
1
0
ウルトラワイドモードで使用した方が推奨されます。コンプレッション後、固定の 8% のコントラストシャープニングを追加します。
double_shadow
1
0
不要なアップロードを回避するために推奨されます。ソースと出力の比較スナップショットを追加し、変更されていないピクセルをスキップしますが、システムメモリ使用量が増えます。

設定完了後、以下を実行してください：

sudo update-grub
sudo reboot

ウルトラワイドスケーリングモード

このデバイスは通常、横方向に最大 1920 ピクセルをサポートしていますが、

edid_only=0
を設定すると、より高い解像度を提供します。

デスクトップおよび HDMI モード (EDID 制限なし)

リフレッシュレート出力とリスク
2048x864
59.94, 60, 70, 72, 75 Hz		ネイティブまたはモニタースケーリング。
⚠️ 実験的: EDID の制限を受けません。
2048x1024
59.94, 60, 70, 72 Hz		ネイティブまたはモニタースケーリング。
⚠️ 実験的: EDID の制限を受けません。
2048x1080
50, 59.94, 60, 70, 72, 75 Hz		ネイティブまたはモニタースケーリング。
⚠️ 実験的: HIGH REFRESH は仕様の上限を超える可能性があります。
2048x1152
59.94, 60 Hz		ネイティブまたはモニタースケーリング。
⚠️ 実験的: EDID の制限を受けません。

論理的デスクトップ (ソフトスケーリングモード)

softscale_wide=1
を設定すると、さらに広い論理的デスクトップが利用可能です。 必須条件: 「フルワイドスクリーンストレッチ（FULL WIDESCREEN STRETCH）」を有効にしている 2560x1080 のウルトラワイドモニターが必要です。

論理デスクトップ物理モニター幅の比率HDMI とモニターのパス
2464x10802560x108077:64
（コンプレッション率 16.9%）		2048x1080 -> 2560x1080 ストレッチ
2560x10802560x10805:4
（コンプレッション率 20%）		2048x1080 -> 2560x1080 ストレッチ

ソフトスケーリングモードのガイダンス

モードリフレッシュレートガイダンス
2464x108050, 59.94, 60, 70, 72, 75 Hz✅ 推奨: より詳細で反応性が良いモードです。
sharpen=1
を有効にしてください。
2560x108050, 59.94, 60, 70, 72, 75 Hz⚠️ より多くの幅が圧縮されるため、詳細さやパフォーマンスが低下します。

技術的な仕組み:

  • 2048 ピクセルは、SM750 がハードウェアで生成できる最大の実質的な幅です（プライマリーグラフィックプレーンの 11 ビット右エッジフィールドによる制約）。
  • カード自体は依然として 2048 ピクセル幅のシグナルのみを出力します。
  • 完全なパス: 
    論理的デスクトップ -> ドライバーによる圧縮 -> 2048x1080 HDMI -> モニターによる 2560x1080 物理ピクセルへストレッチ

なぜ 2464x1080 が推奨されるのか？

  • 2560x1080 モード: ドライバーが横方向に 20% の圧縮（最適化された 5:4 の削減）を行い、モニターが 25% 拡大表示します。結果として微細な横方向の詳細が必然的に結合され、処理負荷が高くなります。
  • 2464x1080 モード: デスクトップピクセル数はわずかに少なく（約 3.75%）、信号を伝える前に幅を 16.9% のみ圧縮します。モニターがそれを展開するため、最終画像は論理 géométrie よりも約 3.9% 広くなりますが、パフォーマンスが高く、シャープなモードとなります。

推奨設定: 

sm750hdmidrm.sharpen=1
の有効化が推奨されます。コンプレッション後に適用される固定の 8% コントラストシャープニングにより、フィルタリングによって失われたエッジ定義を部分的に回復できます。

推奨される実験的プロファイル

以下の設定は、EDID モード制限を無効にし、カタログとワイドスケーリングを有効にしたテスト済みプロフィールです。

⚠️ 危険: このプロフィールは EDID モード制限を無効にし、実験的または仕様超過のクロックを公開します。リストされたモードは、画面を白くしたり、表示を不安定にさせたりする可能性があります。

sm750hdmidrm.edid_only=0 \
sm750hdmidrm.softscale_wide=1 \
sm750hdmidrm.sharpen=1 \
sm750hdmidrm.scanout_format=rgb565-bbdither \
sm750hdmidrm.double_shadow=1 \
sm750hdmidrm.enable_dma=1

スクリーンショットの解説

以下のプロセスはウルトラワイド変換全体を可視化しています（論理的デスクトップと物理的な写真はページの 50% 幅で表示され、圧縮されたプレビューは 41.56% の縮小で表示されています）。

  1. 論理的デスクトップ: ドライバーが受け取る元の 2464x1080（推奨）または 2560x1080 のイメージ。
  2. 圧縮された HDMI スキャンアウト: SM750 のハードウェア幅制限（2048x1080）まで圧縮されたイメージ。横方向に潰れたように見えるのは、物理的な制約のためです。
  3. 物理モニターの結果: ドライバーの 16 ビットスキャンアウトを使用して、モニターが「フルワイドスクリーンストレッチ」処理を施して、75 Hz で 2560x1080 の物理ピクセルを埋めた状態。

トラブルシューティング

バインディングと最新のドライバーメッセージを確認してください：

# PCI バインディング確認
lspci -nnk -d 126f:0750

# ドライバーメッセージの確認
journalctl -k -b | grep -iE 'sm750|sii902'
  • 実験的モードで信号が出ない場合:
    • 古いカーネルエントリをブートするか、
    • リカバリーアクセスから追加された 
      sm750hdmidrm.*
      GRUB オプションを削除してください。

開発者・法的事項

ライセンスと開示

  • プロジェクトは GPL-2.0-only です。DDK 派生ファイルは Linux の GPL-2.0 ステージング 
    sm750fb
    ドライバから取得されました。
  • 独占的な Silicon Motion ドライバー、バイナリオブジェクト、ファームウェア、閉鎖ライブラリは一切含まれておらず、リンクされていません。
  • 広範な AI 支援によるコーディングや「vibe coding」によって作成されましたが、Linux DRM/KMS/カーネルフレームワークの専門知識が不足する部分があります。ソースコードはアップストリームのカーネル品質を主張するものではありません。

免責事項

⚠️ 自己責任での利用:

  • この実験的ドライバーと、EDID 以外のモード、または仕様を超えるモードの使用は、完全に自己責任で行ってください。
  • リカバリーアクセス、バックアップ、モード選択、およびハードウェア互換性に対する責任は使用者にあります。
  • 著者やコントリビューターは、表示の喪失、データの破損、時間の損失、ハードウェア故障、収入の損失、またはその他の直接的・間接的な損失に対して一切責任を負いません。

本ソフトウェアは無保証です。詳しくは 

LICENSE
を参照してください。

同じ日のほかのニュース

一覧に戻る →

2026/08/30 2:49

おどろおどろしい虫たち

## Japanese Translation: Linux カーネルの公式サイトは、AI モデルの学習に使用する自動スクレーパーから多大な負荷をかけています。これらのボットはプロキシ SDK を利用し、数百万件の住宅 IP やモバイル IP を悪用しています。これらのボットは日間のトラフィックのおよそ 33% を消費し、利用可能な CPU コアを約半数（5 つの地理的に分散されたノードを通じて 90 のコアのうち 14〜16 コア）に占有しており、主にレポジトリをクローンするのではなく git コミットを HTML としてレンダリングすることによってこれを行っています。この手法はプロジェクトの著者が「スクレーパーがデータを使用する最も愚かな方法」と呼んでいます。Anubis がアクセス前に SHA256 パズルを要求しているにもかかわらず、ボットが低い難易度を解いた後に難易度がレベル 4 から 5 に引き上げられましたが、これはモバイルユーザーにとってデバイスを温めるという点で依然として不満を生み出しており、人間の行動を模倣する高度な戦術を完全に阻止していません。推定される正当な人間によるトラフィックはわずか約 2% です。スクレーパーは Linux カーネルの履歴が LLM の学習データの豊富な源泉であるためこれを標的としています。また、浅いクローンを使用している脆弱な CI システムは、さらなる即時的過負荷リスクをもたらします。緩和策としては特定の機能を無効化し、匿名ユーザーのアクションをゲートリングするなどの措置が講じられていますが、すべてのデータは引き続きダウンロード可能です。簡単な解決策はありません：新しい AI モデル企業は引き続き無料の学習データを求めており、アプリ開発者は家庭用デバイスを攻撃ベクトルに変え続けており、その結果、サイトはスクレーパーによる負荷から「背景放射線」のような状態に常時置かれています。

2026/08/31 5:00

宇宙のコア：1980年のスペースシャトル搭載のSpacelabコンピュータから復元されたコアメモリモジュール

## Japanese Translation: Spacelab は、スペースシャトルの貨物コンパートメントに搭載された再利用可能な欧州製実験室であり、標準的な IBM AP-101 システムではなく、フランス製 Mitra 125 MS ミニコンピュータを 3 台採用していた。これら 3 台のうち 1 台は実験室を、もう 1 台は実験を担当し、残りの 1 台が予備として機能した。各コンピュータのメモリシステムは 1980 年頃製作され、シリコンではなくフェライトリングを使用した磁性コアメモリを採用しており、「2½D」アーキテクチャにより抑制線を廃止するため、各ビットに独立した X ドライバ回路を設け、位相反転技術を用いることで垂直ドライバの数を半減させていた（U 字形の配線ループを使用）。メモリスタックは 7 ボードで構成され、ドライバボード、4 つのコアプレーンボード、第 2 のドライバボード、およびインターフェースボードからなっていた。各コアプレーンは 1024 本の垂直 Y ワイヤーと 288 本の水平 X ワイヤーで支えられ、16K の 18 ビット語（32 KB）を保持し、総計で 294,912 個のリチウムフェライトコアを有していた。ノイズキャンセレーションにはねじれペアセンスワイヤと「蝶結び」状のクロス構成が用いられ、ダイオードマトリクスはプリント基板間にコードウッド構造を採用しており、各ダイオードチップには 8 コアラインに対応する 16 個のダイオードが含まれていた。1991 年、IBM AP-101S のアップグレードにより、AP-101SL モディフィケーションを通じて磁性コアを半導体メモリに置き換えられながら、フェライトコアメモリが廃棄される直前まで Spacelab システムとの互換性を維持した。 ## Text to translate: Spacelab was a reusable European laboratory carried in the Space Shuttle's cargo bay that employed three French-built Mitra 125 MS minicomputers—rather than standard IBM AP-101 systems—with one managing the laboratory, one managing experiments, and one as a backup. Each computer's memory system, built around 1980, used magnetic core memory with ferrite rings (not silicon) in a "2½D" architecture that eliminated inhibit lines by using separate X driver circuitry for each bit; phase reversal techniques halved the number of vertical drivers via U-shaped wiring loops. The memory stack comprised seven boards: a driver board, four core plane boards, a second driver board, and an interface board. Each core plane held 16K of 18-bit words (32 KB) supported by 1024 vertical Y wires and 288 horizontal X wires, totaling 294,912 lithium ferrite cores. Noise cancellation was achieved through twisted pair sense wires and a "bow tie" crossing configuration, while diode matrices used cordwood construction between printed circuit boards (each diode chip containing 16 diodes for 8 core lines). In 1991, IBM AP-101S upgrades replaced the original magnetic cores with semiconductor memory via the AP-101SL modification, maintaining compatibility with the Spacelab system before ferrite core memory became obsolete.

2026/08/31 1:01

Haiku R1/beta6 がリリースされました

## Japanese Translation: 2026 年 8 月 26 日（水曜日）に、R1/beta6 のリリースをもって Haiku は創業 25 周年を迎えます。これは記念日から約 1 ヶ月後、そして前回から約 2 年後の発表です。この大きなアップデートは開発の一時停止を経て実現され、ユーザーに待ち望まれていた機能向上を提供します。ファンは提供されたダウンロードポータルを通じてすぐにアップグレードを行うか、詳細なリリースノートを確認するか、またはお問い合わせにはプレスコンタクトまでご連絡ください。この発売は Haiku の遺産を称えつつ、オープンソース OS が専用コミュニティと共に進化し続ける中、個々のユーザーならびにテクノロジー企業双方がアクセス可能な導入と継続的なフィードバックへと導く重要な瞬間を象徴します。

オープンソースがなぜ素晴らしいのか——新しいSM750（シリコン・モーションGPU）HDMIドライバの発表 | そっか～ニュース