Un poco de trabajo en curso para lograr que Wine y Wayland funcionen completamente juntos en Linux lo ha llevado un paso más allá y se ha aceptado una tercera gran solicitud de extracción. Wine 8.4, lanzado a mediados de marzo, fue el primer lanzamiento en desarrollo que en realidad tenía parte del trabajo original de Wayland.
De la solicitud de extracción aceptada:
Este MR presenta mecanismos de controlador para manejar eventos dinámicos desde el enlazador de Wayland, usando eventos wl_output como el caso de uso guía (es decir, queremos actualizar la configuración de visualización de win32u cuando cambia la configuración del host).
En este diseño, creamos un hilo dedicado para leer y enviar eventos de Wayland recibidos del compositor. Si el controlador de eventos de Wayland quiere que se ejecute algún código en el contexto de un subproceso HWND en particular, puede agregar un evento interno a la cola personalizada que tenemos para cada subproceso (con la GUI habilitada). La devolución de llamada ProcessEvents del controlador procesa los eventos internos de esta cola. Para activar los subprocesos en espera, usamos una canalización para notificar nuevos eventos internos, con el final de la lectura actuando como el fd de la cola del host del subproceso. Esto es similar a cómo funciona winemac.drv.
Usamos los mecanismos anteriores para poner en cola las actualizaciones del dispositivo de visualización win32u en el subproceso de la ventana del escritorio. Dado que hay muchas piezas que deben encajar en su lugar, este MR está llegando gradualmente a su diseño final:
- Primero presentamos un subproceso de lectura/envío dedicado y manejamos eventos (y también mostramos actualizaciones de dispositivos si se trata de un proceso de escritorio) en ese subproceso.
- Nos aseguramos de que el acceso a la salida de Wayland sea seguro para subprocesos y consistente (porque necesitaremos acceder desde otro subproceso en el paso 3).
- Finalmente, presentamos colas de eventos internas por subproceso y, si estamos en un proceso de escritorio, ponemos en cola la actualización del dispositivo de visualización en la cola de eventos interna del subproceso de la ventana del escritorio. Tenga en cuenta que la mayor parte del código del evento wl_output aún se maneja en un subproceso de lectura/envío dedicado.
¿Por qué es esto necesario? Bueno, Wine actualmente usa X11, por lo que para cualquiera que use Wayland, se ejecutará a través de XWayland, que básicamente es X que se ejecuta bajo Wayland, como una capa de compatibilidad. Como afirmó Collabora en su anuncio original en 2020, al hablar de esto, dijeron que era «una fuente de complejidad y posible ineficiencia» y que sería «ideal si Wine pudiera comunicarse directamente con Wayland para proporcionar una solución más compacta y eficiente». pila en los sistemas modernos. «
Entonces, el resultado final debería ser que los usuarios de Wayland, en lo que todos eventualmente se convertirán, deberían tener Wine ejecutándose sin la capa XWayland, y todo funcionará bien en el futuro.
Artículo tomado de MuyLinux.xyz.
