Wine と Wayland はさらに多くのコードをマージしてさらに一歩近づいています

Wine と Wayland を Linux 上で完全に連携させるために少しずつ進行中の作業は、さらに一歩前進し、3 番目の大きなマージ リクエストが受け入れられました。 3 月中旬の Wine 8.4 は、Wayland の初期作業の一部を実際に組み込んだ最初の開発リリースでした。

現在受け入れられているマージリクエストから:

この MR では、wl_output イベントをガイド ユース ケースとして使用して、Wayland コンポジターからの動的イベントを処理するドライバー メカニズムを導入します (つまり、ホスト設定が変更されたときに win32u の表示設定を更新したいと考えています)。

この設計では、コンポジターから受信した Wayland イベントを読み取り、ディスパッチする専用のスレッドを作成します。 Wayland イベント ハンドラーが特定の HWND のスレッドのコンテキストでコードを実行する必要がある場合、各 (GUI 対応) スレッド用に用意されているカスタム キューに内部イベントを追加できます。 ProcessEvents ドライバーのコールバックは、そのキューからの内部イベントを処理します。 待機中のスレッドをウェイクアップするために、パイプを使用して新しい内部イベントを通知します。読み取り端はスレッドのホスト キュー fd として機能します。 これは、 winemac.drv の仕組みと似ています。

前述のメカニズムを使用して、win32u ディスプレイ デバイスの更新をデスクトップ ウィンドウ スレッドのキューに入れます。 適切な位置に配置する必要がある要素が多数あるため、この MR は徐々に最終デザインに到達します。

なぜこれが実際に必要なのでしょうか? 現在、Wine は X11 を使用しているため、Wayland を実行している人は XWayland を通じて実行されます。これは、基本的に X が互換性レイヤーのように Wayland の下で実行されることになります。 Collabora が 2020 年の最初の発表でこの問題について述べたように、それは「複雑さと非効率の可能性の原因」であるため、「Wine が Wayland と直接対話して、最新のシステム上でより効率的で無駄のないスタックを実現できれば理想的だ」と述べています。 」

そのため、最終的には、Wayland のユーザー (最終的には全員) が、XWayland レイヤーなしで Wine を動作させ、将来にわたってすべてがうまく動作するようになるはずです。