Wayland (protocolo do servidor de exibição) - Wayland (display server protocol)

Wayland
Wayland Logo.svg
Wayland-weston 8.0.0-2-2020-08-04.png
Weston , a implementação de referência de um servidor Wayland.
Autor (es) original (is) Kristian Høgsberg
Desenvolvedor (s) freedesktop.org et al.
lançamento inicial 30 de setembro de 2008 ; 13 anos atrás ( 30/09/2008 )
Versão estável
Wayland: 1,19, Weston: 8,0 / 27 de janeiro de 2021 ; 8 meses atrás ( 2021-01-27 )
Repositório
Escrito em C
Sistema operacional oficial: Linux
não oficial: NetBSD , FreeBSD , DragonFly BSD
Modelo
Licença Licença MIT
Local na rede Internet wayland .freedesktop .org

Wayland é um protocolo de comunicação que especifica a comunicação entre um servidor de exibição e seus clientes, bem como uma implementação de biblioteca C desse protocolo. Um servidor de exibição usando o protocolo Wayland é chamado de compositor Wayland , porque adicionalmente executa a tarefa de um gerenciador de janela de composição .

O Wayland é desenvolvido por um grupo de voluntários inicialmente liderado por Kristian Høgsberg como um projeto gratuito e de código aberto dirigido pela comunidade com o objetivo de substituir o X Window System por um sistema de janelas mais simples e seguro no Linux e outros sistemas operacionais semelhantes ao Unix . O código-fonte do projeto é publicado sob os termos da Licença MIT , uma licença permissiva de software livre .

Como parte de seus esforços, o projeto Wayland também desenvolve uma implementação de referência de um compositor Wayland chamado Weston .

Visão geral

  1. O módulo evdev do kernel Linux obtém um evento e o envia para o compositor Wayland .
  2. O compositor do Wayland examina seu gráfico de cenário para determinar qual janela deve receber o evento. O cenógrafo corresponde ao que está na tela e o compositor do Wayland entende as transformações que ele pode ter aplicado aos elementos do cenário. Assim, o compositor do Wayland pode escolher a janela certa e transformar as coordenadas da tela em coordenadas locais da janela, aplicando as transformações inversas. Os tipos de transformação que podem ser aplicados a uma janela são restritos apenas ao que o compositor pode fazer, contanto que ele possa calcular a transformação inversa para os eventos de entrada.
  3. Como no caso do X, quando o cliente recebe o evento, ele atualiza a IU em resposta. Porém, no caso do Wayland, a renderização acontece pelo cliente via EGL , e o cliente apenas envia uma solicitação ao compositor para indicar a região que foi atualizada.
  4. O compositor do Wayland coleta solicitações de danos de seus clientes e, em seguida, recompõe a tela. O compositor pode então emitir diretamente um ioctl para agendar um pageflip com KMS .

O projeto Wayland Display Server foi iniciado pelo desenvolvedor da Red Hat Kristian Høgsberg em 2008.

Começando por volta de 2010, os gráficos de desktop Linux deixaram de ter "uma pilha de interfaces de renderização ... todas falando com o servidor X , que está no centro do universo" para colocar o kernel do Linux e seus componentes (ou seja, Direct Rendering Infrastructure ( ou seja, Direct Rendering Infrastructure DRI) , Direct Rendering Manager (DRM) ) "no meio", com "sistemas de janela como X e Wayland ... no canto". Este será "um sistema gráfico muito simplificado que oferece mais flexibilidade e melhor desempenho".

Høgsberg poderia ter adicionado uma extensão ao X como muitos projetos recentes fizeram, mas preferiu "[empurrar] o X para fora do caminho de acesso entre os clientes e o hardware" pelos motivos explicados no FAQ do projeto:

A diferença agora é que muita infraestrutura foi movida do servidor X para o kernel (gerenciamento de memória, agendamento de comando, configuração de modo ) ou bibliotecas ( cairo , pixman, freetype , fontconfig , pango , etc.), e há muito pouco esquerda isso tem que acontecer em um processo de servidor central. ... [Um servidor X tem] uma quantidade enorme de funcionalidades que você deve suportar para afirmar que fala o protocolo X, mas ninguém jamais usará isso. ... Isso inclui tabelas de código, glifo rasterização e cache, XLFDs (sério, XLFDs!), E toda a API de renderização principal que permite desenhar linhas pontilhadas, polígonos, arcos largos e muitos outros gráficos no estilo dos anos 1980 primitivos. Para muitas coisas, conseguimos manter o servidor X.org moderno adicionando extensões como XRandR , XRender e COMPOSITE ... Com o Wayland, podemos mover o servidor X e toda a sua tecnologia legada para um caminho de código opcional. Chegar a um ponto em que o servidor X é uma opção de compatibilidade em vez do sistema de renderização central vai demorar um pouco, mas nunca chegaremos lá se [nós] não planejarmos.

Wayland consiste em um protocolo e uma implementação de referência chamada Weston . O projeto também está desenvolvendo versões do GTK e Qt que renderizam para o Wayland em vez de para o X. Espera-se que a maioria dos aplicativos obtenha suporte para o Wayland por meio de uma dessas bibliotecas sem modificação no aplicativo.

As versões iniciais do Wayland não forneceram transparência de rede , embora Høgsberg tenha notado em 2010 que a transparência de rede é possível. Ele foi tentado como um projeto do Google Summer of Code em 2011, mas não teve sucesso. Adam Jackson imaginou fornecer acesso remoto a um aplicativo Wayland por "pixel-scraping" (como VNC ) ou enviando um "stream de comando de renderização" pela rede (como em RDP , SPICE ou X11 ). No início de 2013, Høgsberg está experimentando com transparência de rede usando um servidor proxy Wayland que envia imagens compactadas para o compositor real. Em agosto de 2017, o GNOME viu a primeira implementação de servidor VNC de pixel scraping sob o Wayland.

Arquitetura de software

Arquitetura de protocolo

Na arquitetura do protocolo Wayland, um cliente e um compositor se comunicam por meio do protocolo Wayland usando as bibliotecas de implementação de referência.

O protocolo Wayland segue um modelo cliente-servidor no qual os clientes são os aplicativos gráficos que solicitam a exibição de buffers de pixel na tela, e o servidor (compositor) é o provedor de serviços que controla a exibição desses buffers.

A implementação de referência do Wayland foi projetada como um protocolo de duas camadas:

  • Uma camada de baixo nível ou protocolo de conexão que lida com a comunicação entre processos entre os dois processos envolvidos - “cliente e compositor” - e o empacotamento dos dados que eles trocam. Essa camada é baseada em mensagens e geralmente implementada usando os serviços IPC do kernel, especificamente soquetes de domínio Unix no caso de Linux e sistemas operacionais semelhantes ao Unix.
  • Uma camada de alto nível construída sobre ela, que lida com as informações que o cliente e o compositor precisam trocar para implementar os recursos básicos de um sistema de janelas . Esta camada é implementada como "um protocolo assíncrono orientado a objetos".

Enquanto a camada de baixo nível foi escrita manualmente em C , a camada de alto nível é gerada automaticamente a partir de uma descrição dos elementos do protocolo armazenados no formato XML . Cada vez que a descrição do protocolo deste arquivo XML muda, o código-fonte C que implementa tal protocolo pode ser regenerado para incluir as novas mudanças, permitindo um protocolo muito flexível, extensível e à prova de erros.

A implementação de referência do protocolo Wayland é dividida em duas bibliotecas : uma biblioteca para ser usada por clientes Wayland chamados libwayland-cliente uma biblioteca para ser usada por compositores Wayland chamados libwayland-server.

Visão geral do protocolo

O protocolo Wayland é descrito como um " protocolo assíncrono orientado a objetos ". Orientado a objetos significa que os serviços oferecidos pelo compositor são apresentados como uma série de objetos que vivem no mesmo compositor. Cada objeto implementa uma interface que possui um nome, vários métodos (chamados de solicitações ), bem como vários eventos associados . Cada solicitação e evento tem zero ou mais argumentos, cada um com um nome e um tipo de dados . O protocolo é assíncrono no sentido de que as solicitações não precisam esperar por respostas sincronizadas ou ACKs , evitando o tempo de retardo de ida e volta e melhorando o desempenho.

Os clientes Wayland podem fazer uma solicitação (uma invocação de método) em algum objeto se a interface do objeto suportar essa solicitação. O cliente também deve fornecer os dados necessários para os argumentos de tal pedido. É assim que os clientes solicitam serviços do compositor. O compositor, por sua vez, envia informações de volta ao cliente, fazendo com que o objeto emita eventos (provavelmente com argumentos também). Esses eventos podem ser emitidos pelo compositor como uma resposta a uma determinada solicitação, ou de forma assíncrona, sujeito à ocorrência de eventos internos (como um de um dispositivo de entrada) ou mudanças de estado. As condições de erro também são sinalizadas como eventos pelo compositor.

Para que um cliente possa fazer uma solicitação a um objeto, ele primeiro precisa informar ao servidor o número de ID que usará para identificar esse objeto. Existem dois tipos de objetos no compositor: objetos globais e objetos não globais. Objetos globais são anunciados pelo compositor aos clientes quando são criados (e também quando são destruídos), enquanto objetos não globais geralmente são criados por outros objetos que já existem como parte de sua funcionalidade.

As interfaces e suas solicitações e eventos são os elementos centrais que definem o protocolo Wayland. Cada versão do protocolo inclui um conjunto de interfaces, junto com suas solicitações e eventos, que devem estar em qualquer compositor Wayland. Opcionalmente, um compositor Wayland pode definir e implementar suas próprias interfaces que suportam novas solicitações e eventos, estendendo assim a funcionalidade além do protocolo central. Para facilitar as mudanças no protocolo, cada interface contém um atributo "número da versão" além de seu nome; este atributo permite distinguir variantes da mesma interface. Cada compositor Wayland expõe não apenas quais interfaces estão disponíveis, mas também as versões suportadas dessas interfaces.

Interfaces principais do Wayland

As interfaces da versão atual do protocolo do Wayland são definidas no arquivo protocol / wayland.xml do código-fonte do Wayland. Este é um arquivo XML que lista as interfaces existentes na versão atual, junto com suas solicitações, eventos e outros atributos. Este conjunto de interfaces é o mínimo necessário para ser implementado por qualquer compositor Wayland.

Algumas das interfaces mais básicas do protocolo Wayland são:

  • wl_display  - o objeto global central, um objeto especial para encapsular o próprio protocolo Wayland
  • wl_registry  - o objeto de registro global, no qual o compositor registra todos os objetos globais que deseja disponibilizar para todos os clientes
  • wl_compositor  - um objeto que representa o compositor e é responsável por combinar as diferentes superfícies em uma saída
  • wl_surface  - um objeto que representa uma área retangular na tela, definida por um local, tamanho e conteúdo de pixel
  • wl_buffer  - um objeto que, quando anexado a um objeto wl_surface , fornece seu conteúdo exibível
  • wl_output  - um objeto que representa a área de exibição de uma tela
  • wl_pointer , wl_keyboard , wl_touch  - objetos que representam diferentes dispositivos de entrada, como ponteiros ou teclados
  • wl_seat  - um objeto que representa um assento (um conjunto de dispositivos de entrada / saída) em configurações multiterminais

Uma sessão cliente típica do Wayland começa abrindo uma conexão com o compositor usando o objeto wl_display . Este é um objeto local especial que representa a conexão e não reside no servidor. Usando sua interface, o cliente pode solicitar o objeto global wl_registry do compositor, onde todos os nomes de objetos globais residem, e vincular aqueles nos quais o cliente está interessado. Normalmente o cliente vincula pelo menos um objeto wl_compositor de onde solicitará um ou mais objetos wl_surface para mostrar a saída do aplicativo na tela.

Interfaces de extensão Wayland

Um compositor Wayland pode definir e exportar suas próprias interfaces adicionais. Este recurso é usado para estender o protocolo além da funcionalidade básica fornecida pelas interfaces principais e se tornou a maneira padrão de implementar extensões de protocolo Wayland. Certos compositores podem escolher adicionar interfaces personalizadas para fornecer recursos especializados ou exclusivos. O compositor de referência do Wayland, Weston, os usou para implementar novas interfaces experimentais como um teste para novos conceitos e ideias, alguns dos quais mais tarde se tornaram parte do protocolo central (como a interface wl_subsurface adicionada no Wayland 1.4).

Protocolos de extensão para o protocolo principal

Protocolo XDG-Shell

O protocolo XDG-Shell (consulte freedesktop.org para XDG) é uma maneira estendida de gerenciar superfícies sob compositores Wayland (não apenas Weston). A maneira tradicional de manipular (maximizar, minimizar, tela cheia, etc.) superfícies é usar as funções wl_shell _ * (), que são parte do protocolo central do Wayland e residem no libwayland-client . Uma implementação do protocolo xdg-shell, ao contrário, deve ser fornecida pelo compositor Wayland. Portanto, você encontrará o cabeçalho xdg-shell-client-protocol.h na árvore de origem Weston. Cada compositor Wayland deve fornecer sua própria implementação.

Em junho de 2014, o protocolo XDG-Shell não tinha versão e ainda estava sujeito a alterações.

xdg_shell é um protocolo que visa substituir wl_shell a longo prazo, mas não fará parte do protocolo principal do Wayland. Ele começa como uma API não estável, destinada inicialmente a ser usada como um local de desenvolvimento, e uma vez que os recursos são definidos conforme exigido por vários shells de desktop, ele pode finalmente ser tornado estável. Ele fornece principalmente duas novas interfaces: xdg_surface e xdg_popup. A interface xdg_surface implementa uma janela estilo desktop que pode ser movida, redimensionada, maximizada, etc .; fornece uma solicitação para a criação de relacionamento filho / pai. A interface xdg_popup implementa um pop-up / menu no estilo desktop; um xdg_popup é sempre transitório para outra superfície e também possui captura implícita.

Protocolo IVI-Shell

IVI-Shell é uma extensão do protocolo principal do Wayland, voltado para dispositivos de infotainment (IVI) em veículos .

Modelo de renderização

O compositor Wayland e seus clientes usam EGL para desenhar diretamente no framebuffer ; Servidor X.Org com XWayland e Glamour .

O protocolo Wayland não inclui uma API de renderização. Em vez disso, o Wayland segue um modelo de renderização direta , no qual o cliente deve renderizar o conteúdo da janela em um buffer compartilhável com o compositor. Para isso, o cliente pode escolher fazer toda a renderização por si mesmo, usar uma biblioteca de renderização como Cairo ou OpenGL , ou contar com o motor de renderização de bibliotecas de widgets de alto nível com suporte a Wayland, como Qt ou GTK . O cliente também pode usar opcionalmente outras bibliotecas especializadas para realizar tarefas específicas, como Freetype para renderização de fontes .

O buffer resultante com o conteúdo da janela renderizado é armazenado em um objeto wl_buffer . O tipo interno deste objeto depende da implementação. O único requisito é que os dados de conteúdo devem ser compartilháveis ​​entre o cliente e o compositor. Se o cliente usa um renderizador de software (CPU) e o resultado é armazenado na memória do sistema , então o cliente e o compositor podem usar a memória compartilhada para implementar a comunicação do buffer sem cópias extras. O protocolo Wayland já nativamente fornece este tipo de buffer de memória compartilhada através das wl_shm e wl_shm_pool interfaces. A desvantagem desse método é que o compositor pode precisar fazer um trabalho adicional (geralmente para copiar os dados compartilhados para a GPU) para exibi-los, o que leva a um desempenho gráfico mais lento.

O caso mais típico é o cliente renderizar diretamente em um buffer de memória de vídeo usando uma API acelerada por hardware (GPU), como OpenGL , OpenGL ES ou Vulkan . O cliente e o compositor podem compartilhar esse buffer de espaço da GPU usando um manipulador especial para referenciá-lo. Este método permite que o compositor evite a cópia extra de dados através dele mesmo do método cliente-para-compositor-para-GPU do buffer de memória principal, resultando em desempenho gráfico mais rápido e, portanto, é o preferido. O compositor pode otimizar ainda mais a composição da cena final a ser mostrada na tela usando a mesma API de aceleração de hardware como um cliente API.

Quando a renderização é concluída em um buffer compartilhado, o cliente Wayland deve instruir o compositor a apresentar o conteúdo renderizado do buffer na tela. Para este propósito, o cliente vincula o objeto buffer que armazena o conteúdo renderizado ao objeto de superfície e envia uma solicitação de "confirmação" para a superfície, transferindo o controle efetivo do buffer para o compositor. Em seguida, o cliente espera que o compositor libere o buffer (sinalizado por um evento) se quiser reutilizar o buffer para renderizar outro quadro, ou pode usar outro buffer para renderizar o novo quadro e, quando a renderização for concluída, vincular esse novo buffer à superfície e comprometa seu conteúdo. O procedimento utilizado para a renderização, incluindo o número de buffers envolvidos e seu gerenciamento, está inteiramente sob o controle do cliente.

Comparação com outros sistemas de janela

Diferenças entre Wayland e X

Existem várias diferenças entre o Wayland e o X em relação ao desempenho, capacidade de manutenção do código e segurança:

Arquitetura
O gerenciador de composição é um recurso adicional separado no X, enquanto o Wayland mescla o servidor de exibição e o compositor como uma única função. Além disso, ele incorpora algumas das tarefas do gerenciador de janelas , que no X é um processo separado do lado do cliente.
Composição
A composição é opcional no X, mas obrigatória no Wayland. A composição em X é "ativa"; ou seja, o compositor deve buscar todos os dados de pixel, o que introduz latência. No Wayland, a composição é "passiva", o que significa que o compositor recebe dados de pixel diretamente dos clientes.
Renderização
O próprio servidor X é capaz de realizar a renderização, embora também possa ser instruído a exibir uma janela renderizada enviada por um cliente. Em contraste, o Wayland não expõe nenhuma API para renderização, mas delega aos clientes tais tarefas (incluindo a renderização de fontes, widgets, etc.). As decorações das janelas podem ser renderizadas no lado do cliente (por exemplo, por um kit de ferramentas gráficas) ou no lado do servidor (pelo compositor).
Segurança
Wayland isola a entrada e a saída de cada janela, alcançando confidencialidade, integridade e disponibilidade em ambos os casos; o design original do X carece desses importantes recursos de segurança, embora algumas extensões tenham sido desenvolvidas para tentar mitigá-los. Além disso, com a grande maioria do código em execução no cliente, menos código precisa ser executado com privilégios de root , melhorando a segurança, embora várias distribuições populares do Linux agora permitam que o X seja executado sem privilégios de root.
Comunicação entre processos
O servidor X fornece um método básico de comunicação entre clientes X, posteriormente estendido pelas convenções ICCCM . Esta comunicação cliente-cliente X é usada por gerenciadores de janela e também para implementar sessões X , seleções e arrastar e soltar e outros recursos. O protocolo central do Wayland não oferece suporte à comunicação entre os clientes wayland, e a funcionalidade correspondente (se necessário) deve ser implementada pelos ambientes de desktop (como KDE ou GNOME), ou por um terceiro (por exemplo, usando IPC nativo de o sistema operacional subjacente).
Networking
O X Window System é uma arquitetura que foi projetada em seu núcleo para funcionar em uma rede. Wayland não oferece transparência de rede por si só; entretanto, um compositor pode implementar qualquer protocolo de área de trabalho remota para obter a exibição remota. Além disso, há pesquisas sobre o streaming e a compactação de imagens do Wayland que forneceriam acesso remoto ao buffer de quadros semelhante ao do VNC .

Compatibilidade com X

O XWayland é um servidor X rodando como cliente Wayland e, portanto, é capaz de exibir aplicativos cliente X11 nativos em um ambiente de compositor Wayland. Isso é semelhante à maneira como o XQuartz executa aplicativos X no sistema de janelas nativo do macOS . O objetivo do XWayland é facilitar a transição dos ambientes X Window System para Wayland, fornecendo uma maneira de executar aplicativos não portados nesse meio tempo. O XWayland foi integrado ao servidor X.Org versão 1.16.

Kits de ferramentas de widget como Qt 5 e GTK 3 podem alternar seu back-end gráfico em tempo de execução, permitindo que os usuários escolham no momento do carregamento se desejam executar o aplicativo no X ou no Wayland. O Qt 5 fornece a -platformopção de linha de comando para esse efeito, enquanto o GTK 3 permite que os usuários selecionem o back-end GDK desejado definindo a GDK_BACKEND variável de ambiente Unix .

Compositores Wayland

Elementos típicos de uma janela . Nem o Wayland nem o X11 especificam qual software é responsável por renderizar a decoração da janela . Weston requer que eles sejam desenhados pelo cliente, mas o KWin implementará a decoração do lado do servidor.

Os servidores de exibição que implementam o protocolo de servidor de exibição Wayland também são chamados de compositores de Wayland porque, adicionalmente, executam a tarefa de um gerenciador de janela de composição .

  • Weston  - a implementação de referência de um compositor Wayland; Weston implementa decorações do lado do cliente
  • Batom - estrutura de shell gráfica móvel que implementa o Wayland compositor; é usado em Sailfish OS , Nemo Mobile e AsteroidOS
  • O Enlightenment reivindicou suporte total ao Wayland desde a versão 0.20, mas o trabalho está em andamento para conseguir um compositor completo do Wayland
  • KWin tem suporte Wayland quase completo em 2021
  • Mutter mantém uma filial separada para a integração do Wayland para GNOME 3.9 (em setembro de 2013)
  • Clayland - um exemplo simples de compositor Wayland usando Clutter
  • Westeros - uma biblioteca de compositor do Wayland que permite que os aplicativos criem seus próprios monitores do Wayland, o que permite aninhamento e incorporação de aplicativos de terceiros
  • wlroots - uma implementação modular do Wayland que funciona como base para outros compositores, principalmente Sway
  • Sway - um compositor de Wayland e um substituto para o gerenciador de janelas i3 para X11
  • gamescope - parte do SteamOS, substituindo o steamcompmgr anterior

Weston

Weston é a implementação de referência de um compositor Wayland também desenvolvido pelo projeto Wayland. Ele foi escrito em C e publicado sob a licença do MIT . Weston tem suporte oficial apenas para o sistema operacional Linux devido à dependência de Weston de certos recursos do kernel Linux , como configuração de modo do kernel , Graphics Execution Manager (GEM) e udev , que não foram implementados em outro sistema operacional semelhante ao Unix sistemas. Ao executar no Linux, a manipulação do hardware de entrada depende do evdev , enquanto a manipulação dos buffers depende do Gerenciamento de Buffer Genérico (GBM). No entanto, em 2013, um protótipo de porta de Weston para FreeBSD foi anunciado.

Weston oferece suporte para HDCP ( High-bandwidth Digital Content Protection ).

Weston conta com o GEM para compartilhar buffers de aplicativos entre o compositor e os aplicativos. Ele contém um sistema de plug-in de "shells" para recursos comuns de desktop, como docas e painéis. Os clientes são responsáveis ​​pelo desenho das bordas das suas janelas e pela sua decoração. Para renderização, Weston pode usar OpenGL ES ou a biblioteca pixman para fazer renderização de software . A implementação completa do OpenGL não é usada, porque na maioria dos sistemas atuais, instalar as bibliotecas OpenGL completas também instalaria o GLX e outras bibliotecas de suporte do X Window System como dependências.

Uma interface de acesso remoto para Weston foi proposta em outubro de 2013 por um funcionário da RealVNC .

Maynard

Maynard (em janeiro de 2017)

Maynard é um shell gráfico e foi escrito como um plug-in para Weston, assim como o GNOME Shell foi escrito como um plug-in para Mutter .

A Raspberry Pi Foundation em colaboração com a Collabora lançou Maynard e trabalha para melhorar o desempenho e o consumo de memória.

libinput

libinput foi criado para consolidar a pilha de entrada em vários compositores Wayland.

O código Weston para lidar com dispositivos de entrada (teclados, ponteiros, telas sensíveis ao toque, etc.) foi dividido em sua própria biblioteca separada, chamada libinput , para a qual o suporte foi incorporado pela primeira vez no Weston 1.5.

Libinput lida com dispositivos de entrada para vários compositores Wayland e também fornece um driver de entrada X.Org Server genérico . Seu objetivo é fornecer uma implementação para vários compositores de Wayland com uma maneira comum de lidar com eventos de entrada enquanto minimiza a quantidade de compositores de código de entrada customizados que precisam incluir. libinput fornece detecção de dispositivo (via udev ), manipulação de dispositivo, processamento de evento de dispositivo de entrada e abstração.

A versão 1.0 do libinput seguiu a versão 0.21 e incluiu suporte para tablets, conjuntos de botões e gestos de touchpad. Esta versão manterá API / ABI estável.

Como GNOME / GTK e KDE Frameworks 5 destacaram as mudanças necessárias, o Fedora 22 substituirá os drivers evdev e Synaptics do X.Org por libinput.

Com a versão 1.16, o servidor X.Org obteve suporte para a biblioteca libinput na forma de um wrapper chamado xf86-input-libinput .

Módulo de Segurança Wayland

Wayland Security Module é uma proposta que se assemelha à interface do Linux Security Module encontrada no kernel do Linux .

Alguns aplicativos (especialmente aqueles relacionados à acessibilidade ) requerem recursos privilegiados que devem funcionar em diferentes compositores Wayland. Atualmente, os aplicativos no Wayland geralmente são incapazes de realizar qualquer tarefa sensível, como fazer capturas de tela ou inserir eventos de entrada. Os desenvolvedores do Wayland estão procurando ativamente maneiras viáveis ​​de lidar com clientes privilegiados com segurança e, em seguida, projetando interfaces privilegiadas para eles.

O Módulo de Segurança Wayland é uma forma de delegar decisões de segurança dentro do compositor para um mecanismo de decisão de segurança centralizado.

Adoção

O protocolo Wayland foi projetado para ser simples, de modo que protocolos e interfaces adicionais precisam ser definidos e implementados para obter um sistema holístico de janelas. Em julho de 2014, essas interfaces adicionais estavam sendo trabalhadas. Assim, embora os kits de ferramentas já suportem totalmente o Wayland, os desenvolvedores dos shells gráficos estão cooperando com os desenvolvedores do Wayland na criação das interfaces adicionais necessárias.

Distribuições de desktop Linux

A partir de 2020, a maioria das distribuições Linux suportam Wayland fora da caixa, alguns exemplos notáveis ​​são:

  • O Fedora a partir da versão 25 (lançado em 22 de novembro de 2016) usa o Wayland para a sessão de desktop GNOME 3.22 padrão, com o X.Org como fallback se o driver gráfico não suportar o Wayland. O Fedora usa o Wayland como padrão para a sessão da área de trabalho do KDE a partir da versão 34 (lançada em 27 de abril de 2021)
  • O Ubuntu fornece o Wayland como padrão no Ubuntu 17.10 (Artful Aardvark). O Ubuntu reverteu para o X.Org para o Ubuntu 18.04 LTS, já que o Wayland ainda tem problemas com compartilhamento de tela e aplicativos de área de trabalho remota, e não se recupera tão bem de travamentos do gerenciador de janelas. O Ubuntu envia o Wayland por padrão em 21.04.
  • O Red Hat Enterprise Linux fornece o Wayland como a sessão padrão na versão 8, lançada em 7 de maio de 2019.
  • O Debian distribui o Wayland como a sessão padrão para o GNOME desde a versão 10, lançada em 6 de julho de 2019.
  • O Slackware Linux incluiu o Wayland em 20 de fevereiro de 2020 para a versão de desenvolvimento, -current, que eventualmente se tornará a versão 15.0.
  • Manjaro envia Wayland como padrão na edição Gnome de Manjaro 20.2 (Nibia) (lançado em 22 de novembro de 2020).

Adotante inicial notável:

  • RebeccaBlackOS é uma distribuição Linux baseada em Debian baseada em USB que permite uma maneira conveniente de experimentar um desktop Wayland real sem ter que fazer nenhuma modificação no sistema operacional principal do computador. Ele tem sido usado desde o início de 2012 para mostrar o Wayland.

Suporte para kit de ferramentas

Os kits de ferramentas que suportam o Wayland incluem o seguinte:

  • Clutter tem suporte completo para Wayland.
  • EFL tem suporte completo para Wayland, exceto para seleção.
  • GTK 3.20 tem suporte completo para Wayland.
  • O Qt 5 tem suporte completo para Wayland e pode ser usado para escrever compositores Wayland e clientes Wayland.
  • O suporte SDL para Wayland estreou com a versão 2.0.2 e foi habilitado por padrão desde a versão 2.0.4.
  • GLFW 3.2 tem suporte Wayland.
  • FreeGLUT tem suporte inicial para Wayland.

Ambientes de desktop

Os ambientes de desktop em processo de portabilidade do X para o Wayland incluem GNOME , KDE Plasma 5 e Enlightenment .

Em novembro de 2015, o Enlightenment e20 foi anunciado com suporte total do Wayland. GNOME 3.20 foi a primeira versão a ter uma sessão completa do Wayland. GNOME 3.22 incluiu suporte Wayland muito melhorado em GTK, Mutter e GNOME Shell. GNOME 3.24 distribuído suporte para os drivers proprietários NVidia sob o Wayland.

O suporte do Wayland para o KDE Plasma foi adiado até o lançamento do Plasma 5, embora anteriormente o KWin 4.11 tivesse um suporte experimental para o Wayland. A versão 5.4 do Plasma foi a primeira com uma sessão de Wayland. Durante 2020, o Klipper foi portado para Wayland e o próximo lançamento 5.20 em outubro de 2020 tem o objetivo de melhorar a transmissão de tela e gravação.

Outro software

Outro software compatível com o Wayland inclui o seguinte:

  • O Intelligent Input Bus está trabalhando no suporte ao Wayland, ele pode estar pronto para o Fedora 22.
  • O RealVNC publicou uma prévia do desenvolvedor do Wayland em julho de 2014.
  • Maliit é um framework de método de entrada executado no Wayland.
  • kmscon suporta Wayland com wlterm.
  • Mesa tem suporte Wayland integrado.
  • O Eclipse foi feito para rodar no Wayland durante um GSoC -Project em 2014.
  • O Vulkan WSI (Window System Interface) é um conjunto de chamadas de API que tem uma finalidade semelhante à do EGL para OpenGL ES ou GLX para OpenGL. Vulkan WSI inclui suporte para Wayland desde o primeiro dia: VK_USE_PLATFORM_WAYLAND_KHR. Os clientes Vulkan podem ser executados em servidores Wayland não modificados, incluindo Weston, GENIVI LayerManager, Mutter / GNOME Shell, Enlightenment e mais. O WSI permite que os aplicativos descubram as diferentes GPUs no sistema e exibam os resultados da renderização da GPU em um sistema de janela.
  • SPURV , uma camada de compatibilidade para aplicativos Android para rodar em distribuições Linux usando Wayland

Hardware móvel e integrado

Weston em execução no postmarketOS

O hardware móvel e integrado que suporta o Wayland inclui o seguinte:

História

Wayland usa renderização direta sobre EGL .

Kristian Høgsberg, um desenvolvedor gráfico do Linux e X.Org que trabalhou anteriormente em AIGLX e DRI2 , iniciou o Wayland como um projeto de tempo livre em 2008, enquanto trabalhava para a Red Hat . Seu objetivo declarado era um sistema no qual "cada quadro é perfeito, com o que quero dizer que os aplicativos serão capazes de controlar a renderização o suficiente para que nunca vejamos tearing, lag, redesenhado ou tremulação." Høgsberg estava dirigindo pela cidade de Wayland, Massachusetts, quando os conceitos subjacentes "se cristalizaram", daí o nome.

Em outubro de 2010, Wayland se tornou um projeto freedesktop.org . Como parte da migração, o Grupo Google anterior foi substituído pela lista de e - mails wayland-devel como o ponto central de discussão e desenvolvimento do projeto.

As bibliotecas de cliente e servidor Wayland foram inicialmente lançadas sob a licença MIT , enquanto o compositor de referência Weston e alguns clientes de exemplo usaram a GNU General Public License versão 2 . Posteriormente, todo o código GPL foi licenciado novamente sob a licença MIT "para tornar mais fácil mover o código entre a implementação de referência e as bibliotecas reais". Em 2015, foi descoberto que o texto da licença usado por Wayland era uma versão ligeiramente diferente e mais antiga da licença do MIT, e o texto da licença foi atualizado para a versão atual usada pelo projeto X.Org (conhecido como MIT Expat License ).

Wayland funciona com todos os drivers compatíveis com Mesa com suporte DRI2 , bem como drivers Android através do projeto Hybris .

Lançamentos

Lançamentos importantes de Wayland e Weston
Versão Encontro Principais características
Wayland Weston
Versão antiga, não mais mantida: 0,85 9 de fevereiro de 2012 Primeiro lançamento.
Versão antiga, não mais mantida: 0,95 24 de julho de 2012 Começou a estabilização da API.
Versão antiga, não mais mantida: 1.0 22 de outubro de 2012 API estável do cliente wayland.
Versão antiga, não mais mantida: 1,1 15 de abril de 2013 Renderização de software. Back-ends FBDEV, RDP.
Versão antiga, não mais mantida: 1,2 12 de julho de 2013 API de servidor de wayland estável. Gerenciamento de cor. Subsurfaces. Back- end do Raspberry Pi .
Versão antiga, não mais mantida: 1,3 11 de outubro de 2013 Mais formatos de pixel. Suporte para ligações de linguagem. Suporte ao driver Android via libhybris .
Versão antiga, não mais mantida: 1,4 23 de janeiro de 2014 Novas interfaces wl_subcompositor e wl_subsurface. Vários formatos de framebuffer. suporte de logind para Weston sem raiz.
Versão antiga, não mais mantida: 1,5 20 de maio de 2014 libinput. Shell em tela cheia.
Versão antiga, não mais mantida: 1,6 19 de setembro de 2014 libinput por padrão.
Versão antiga, não mais mantida: 1,7 14 de fevereiro de 2015 Suporte para a extensão de apresentação do Wayland e para papéis de superfície. Protocolo de shell IVI .
Versão antiga, não mais mantida: 1,8 2 de junho de 2015 Cabeçalhos separados para protocolo central e gerado. Agendamento de redesenho. Saídas nomeadas. Transformações de saída. API de disparo de superfície.
Versão antiga, não mais mantida: 1,9 21 de setembro de 2015 Licença atualizada. Licença atualizada. Nova estrutura de teste. Compositor DRM de cabeça tripla. extensão linux_dmabuf.
Versão antiga, não mais mantida: 1,10 17 de fevereiro de 2016 Funcionalidade de arrastar e soltar, eventos de ponteiro agrupados. Vídeo 4 Linux 2, entrada de toque, melhorias de depuração.
Versão antiga, não mais mantida: 1,11 1 de junho de 2016 Nova rotina de carregamento de backup, nova lógica de configuração. Wrappers de proxy, alterações de memória compartilhada, documentos HTML gerados pelo Doxygen.
Versão antiga, não mais mantida: 1,12 21 de setembro de 2016 Suporte de depuração melhorado. libweston e libweston-desktop. Bloqueio e confinamento do ponteiro. Suporte para ponteiro relativo.
Versão antiga, não mais mantida: 1,13 24 de fevereiro de 2017 A ABI de Weston foi alterada, portanto, a nova versão foi nomeada 2.0.0 em vez de 1.13.0.
Versão antiga, não mais mantida: 1,14 8 de agosto de 2017 Weston 3.0.0 foi lançado ao mesmo tempo.
Versão antiga, não mais mantida: 1,15 9 de abril de 2018 Weston 4.0.0 foi lançado ao mesmo tempo.
Versão antiga, não mais mantida: 1,16 24 de agosto de 2018 Weston 5.0.0 foi lançado ao mesmo tempo.
Versão antiga, não mais mantida: 1,17 20 de março de 2019 Weston 6.0.0 foi lançado ao mesmo tempo.
Versão antiga, não mais mantida: 1,18 2 de agosto de 2019 Weston 7.0.0 foi lançado um mês depois.
Versão estável atual: 1,19 27 de janeiro de 2021
Weston 8 24 de janeiro de 2020
Weston 9 4 de setembro de 2020
Lenda:
Versão antiga
Versão mais antiga, ainda mantida
Última versão
Versão de visualização mais recente
Lançamento futuro

Veja também

Referências

links externos