Proposta de TCC

Introdução

Historicamente, o X11 forneceu a base para a interface gráfica de sistemas UNIX, e, ao longo da existência do X11, inúmeros gerenciadores de janelas foram criados para fornecer diferentes maneiras de organizar janelas.

Com o advento do Wayland, o papel antes cumprido pelos gerenciadores de janelas X agora pertence aos compositores Wayland, de modo que se poderia esperar a mesma variedade de compositores que há nos gerenciadores de janelas. Porém, na prática, isso não se verifica.

Esse fenômeno pode ser explicado, em parte, pelo fato de que os compositores Wayland também devem realizar uma série de funções que antes pertenciam ao servidor X — o que aumenta a complexidade de criar um compositor novo. Muitas dessas funções não dependem da maneira como o compositor gerencia suas janelas; é possível, portanto, fornecer tais funcionalidades em bibliotecas, de modo que possam ser reaproveitadas, o que facilita o desenvolvimento de compositores novos.

Entre as tentativas de fornecer tais funcionalidades de maneira reaproveitável a qualquer compositor Wayland, destaca-se a biblioteca wlroots, que foi criada pelo mesmo desenvolvedor do compositor Wayland sway — e foi criada precisamente para ser usada nesse compositor. Porém, nem todas as funcionalidades reaproveitáveis se encontram na biblioteca wlroots; algumas se encontram no próprio sway.

Neste trabalho de conclusão de curso, pretendemos modificar o sway de maneira que boa parte das funcionalidades reaproveitáveis desse compositor passem a estar em uma biblioteca nova, que não esteja contida no sway. Espera-se que essa nova biblioteca, juntamente com o wlroots, facilitará ainda mais a criação de novos compositores Wayland.

Contexto

Sistema de janelas X (X11)

O Sistema de janelas X (X Window System), mais conhecido como X11 ou apenas X, é um sistema gráfico de janelas [1] que abarca uma série de especificações incluindo o protocolo central, X Window System Protocol, e uma série de extensões. [2], O Xorg é um software livre que implementa o X11 [3] e é, na prática, a mais usada entre usuários de Linux [4].

O X11 tem uma arquitetura cliente-servidor, em que os programas gráficos são clientes de um servidor denominado servidor X. [5]

Embora o X11 forneça o ambiente necessário para a criação de janelas gráficas, há uma série de tarefas necessárias ao funcionamento de uma interface gráfica que não são realizadas pelo X, e ficam a cargo do gerenciador de janelas (window manager). [6] Entre as atribuições de um gerenciador de janelas, estão:

• Definir a posição e tamanho incial de uma janela na tela — e em qual tela, caso haja mais de uma;
• Definir qual janela tem foco, ou seja, qual janela deve receber o input do teclado, mouse, touchscreen etc;
• Definir os mecanismos pelos quais os usuários podem realizar ações sobre as janelas — fechar, mover, alterar o tamanho, minimizar, maximizar, colocar em tela cheia, entre outras;
• Decidir se devem ser desenhadas bordas ou decorações na janela — e, caso essas decorações tenham botões para realizar ações sobre a janela (fechar, minimizar etc.), definir suas posições.

Wayland e weston

O Wayland foi criado com o objetivo de substituir o X, a fim de ser uma alternativa mais simples e mais fácil de manter, [8] que não tem uma série de funcionalides já obsoletas do X11. [9] De maneira similar ao X11, o Wayland define um protocolo de comunicação entre um servidor, denominado compositor Wayland, e seus clientes — protocolo cuja implementação é também chamada de Wayland. [8] Adicionalmente, foi criado um compositor Wayland denominado weston, que serve como implementação de referência para outros compositores. [10]

Entre as bibliotecas que possibilitam a criação de janelas de maneira independente de dispositivo, boa parte das que têm suporte a Linux já permitem a criação de clientes Wayland — entre elas o Gtk+ [11], o Qt [12], e o SDL [13].

Diferentemente do X11, sob a arquitetura Wayland, não há um cliente especial que lida com o gerenciamento de janelas — essa responsabilidade também recai sobre o compositor. [14]

libweston, wlroots e sway

Há algumas iniciativas no sentido de desenvolver bibliotecas que possam oferecer parte da funcionalidade esperada de um compositor Wayland.

Paralelamente, um desenvolvedor criou o sway, um compositor Wayland compatível com o gerenciador de janelas i3. [16] Por decorrência do desenvolvimento do sway, foi criada a biblioteca wlroots, que se apresenta hoje como "cerca de 50 000 linhas de código que você iria escrever de qualquer jeito" para criar um compositor Wayland. [17] O wlroots foi criado para suprir deficiências de outra biblioteca, usada anteriormente pelo sway. [18]

Motivação e objetivos

A biblioteca wlroots implementa uma boa parte das funcionalidades antes implementadas no servidor X, de modo que compositores que usem essa biblioteca não precisam reimplementá-las. Porém, o sway também possui algumas funcionalidades reaproveitáveis — ou seja, que não dependem da forma esse compositor realiza seu gerenciamento de janelas, e que outros compositores provavelmente também teriam a necessidade de implementar.

• Inserção e remoção de dispositivos de output (como monitores e TVs conectados por cabo HDMI ou VGA); [19]
• Damage tracking, ou seja, cálculo das regiões efetivamente alteradas desde a útlima renderização, que precisam ser renderizadas novamente; [20]
• Clientes X11. [21]

O objetivo deste TCC é, portanto, modificar o código do sway de maneira a extrair dele uma biblioteca, que não esteja incorporada ao sway — ou seja, que pode ser compilada e ligada de forma independente — e que tenha o máximo de funcionalidades reaproveitáveis do sway que se possa extrair, dado o tempo disponível.

Essa nova biblioteca, que será chamada wlstem (link para o repositório), complementará o wlroots, no sentido de fornecer funcionalidades que a maior parte dos compositores Wayland, se não usassem essas bibliotecas, provavelmente teriam que implementar manualmente — independentemente de qual seja a lógica de gerenciamento de janelas do compositor. Desse modo, a wlstem, assim como o wlroots, presta-se a auxiliar a criação de novos compositores Wayland.

O restante do código simplificado do sway, que não for incorporado na biblioteca, será modificado para que se obtenha um programa que sirva como implementação de referência da wlstem.

Estratégia e cronograma

1. Simplificar o sway, removendo dele funcionalidades muito específicas a esse programa, que certamente não poderão ser reaproveitadas;
2. Alterar o sistema de build, a fim de que:
   • Uma biblioteca seja gerada a partir de um dos arquivos de código do sway,
   • O programa usual seja gerado a partir dos demais arquivos, e
   • O programa gerado seja ligado à biblioteca gerada;
3. Escolher uma funcionalidade reaproveitável do sway, extraí-la para um arquivo a parte (caso necessário) e incorporar esse arquivo à biblioteca;
4. Repetir o passo anterior tantas vezes quanto forem necessárias (e possíveis, dado o prazo).

• Passo 2: até 21/06;
• Passo 3: 1 mês por iteração, totalizando 5 iterações até 21/11.
• O último mês (até 21/12) será reservado para finalizar a monografia.

Referências

[1]: Página de manual do sistema de janelas X. Acesso em: 23 mai 2021.

[2]: Standards do sistema de janelas X. Acesso em: 23 mai 2021.

[3]: Página principal do Xorg. Acesso em: 23 mai 2021.

[4]: "Xorg (commonly referred as simply X) is the most popular display server among Linux users. Its ubiquity has led to making it an ever-present requisite for GUI applications, resulting in massive adoption from most distributions."
Página da wiki do Archlinux sobre o Xorg. Acesso em: 23 mai 2021.

[5]: Overview da arquitetura do sistema de janelas X. Acesso em: 23 mai 2021.

[6]: TLDP: Window managers. Acesso em: 23 mai 2021.

[7]: Lista (não-exaustiva) de gerenciadores de janelas X. Acesso em: 23 mai 2021.

[8]: Página principal do Wayland. Acesso em: 23 mai 2021.

[9]: "When you're an X server there's a tremendous amount of functionality that you must support to claim to speak the X protocol, yet nobody will ever use this. [...] With Wayland we can move the X server and all its legacy technology to an optional code path. " Wayland FAQ, seção "What is wrong with X?"

[10]: Documentação do Weston. Acesso em: 23 mai 2021.

[11]: Status do suporte a Wayland no Gtk+. Acesso em: 23 mai 2021.

[12]: Página do QtWayland. Acesso em: 23 mai 2021.

[13]: SDL Now Supports Wayland's XDG-Shell. Acesso em: 23 mai 2021.

[14]: "The Wayland architecture integrates the display server, window manager and compositor into one process."
Wayland FAQ, seção "How can I replace Wayland's Window Manager?"
Acesso em: 23 mai 2021.

[15a]: "Libweston is an effort to separate the re-usable parts of Weston into a library. Libweston provides most of the boring and tedious bits of correctly implementing core Wayland protocols and interfacing with input and output systems"
[15b]: "In current form, libweston is an amalgam of various APIs mashed together and currently it needs a large clean-up and re-organization and possibly, a split into class-specific files."
Documentação do libweston. Acesso em: 23 mai 2021.

[16]: README do sway. Acesso em: 23 mai 2021.

[17]: "Pluggable, composable, unopinionated modules for building a Wayland compositor; or about 50,000 lines of code you were going to write anyway."
README do wlroots. Acesso em: 23 mai 2021.

[18]: The future of Wayland, and sway's role in it. Acesso em: 25 mai 2021.

[19]: Vide as funções output_enable, output_disable, output_evacuate, e restore_workspace: tree/output.c. Acesso em: 23 mai 2021.

[20]: Vide a função render_texture e as funções que a chamam: desktop/render.c. Acesso em: 23 mai 2021.

[21]: Todo o código do arquivo desktop/xwayland.c. Acesso em: 23 mai 2021.