Servidor X.Org - X.Org Server
Desenvolvedor (s) | Fundação X.Org |
---|---|
lançamento inicial | 6 de abril de 2004 |
Versão estável | 1.20.13 / 29 de julho de 2021
|
Versão de visualização | 21.0.99.1 / 5 de julho de 2021
|
Repositório | |
Escrito em | C |
Sistema operacional | Plataforma cruzada |
Tamanho | 3,7 MiB |
Disponível em | inglês |
Modelo | Servidor de exibição |
Licença | Licença MIT |
Local na rede Internet | www |
O X.Org Server é a implementação gratuita e de código aberto do servidor de exibição do X Window System administrado pela X.Org Foundation .
As implementações do lado do cliente do protocolo estão disponíveis, por exemplo, na forma de Xlib e XCB .
Os serviços com os quais a Fundação X.Org oferece suporte ao X Server incluem o empacotamento das versões; certificação (mediante pagamento); avaliação de melhorias no código; desenvolver o site e lidar com a distribuição de doações em dinheiro. Os lançamentos são codificados, documentados e empacotados por desenvolvedores globais .
Arquitetura de software
O servidor X.Org implementa o lado do servidor do protocolo central do X Window System versão 11 (X11) e extensões para ele, por exemplo, RandR.
A versão 1.16.0 integra suporte para inicialização e gerenciamento baseados em systemd , o que melhorou o desempenho e a confiabilidade da inicialização.
X independente de dispositivo (DIX)
O Device Independent X (DIX) é a parte do X.Org Server que interage com os clientes e implementa a renderização do software. O loop principal e a entrega do evento fazem parte do DIX.
Um servidor X possui uma quantidade enorme de funcionalidades que devem ser implementadas para suportar o protocolo X core. Isso inclui tabelas de código, rasterização e cache de glifos, XLFDs e a API de renderização principal que desenha primitivos gráficos.
Dependente de dispositivo X (DDX)
O Device Dependent X (DDX) é a parte do servidor x que interage com o hardware. No código-fonte do X.Org Server, cada diretório em "hw" corresponde a um DDX. O hardware inclui placas gráficas, mouse e teclados. Cada driver é específico do hardware e implementado como um módulo carregável separado.
Driver gráfico 2D
Por razões históricas, o servidor X.Org ainda contém drivers de dispositivos gráficos que suportam alguma forma de aceleração de renderização 2D. No passado, a configuração do modo era feita por um driver de dispositivo gráfico do servidor X específico para algum hardware de controlador de vídeo ( por exemplo , uma GPU ). A esta funcionalidade de configuração de modo, foi adicionado suporte adicional para aceleração 2D quando tornou-se disponível com várias GPUs. A funcionalidade de configuração de modo foi movida para o DRM e está sendo exposta por meio de uma interface de configuração de modo DRM, a nova abordagem sendo chamada de "configuração de modo kernel" (KMS). Mas a aceleração de renderização 2D permaneceu.
No Debian, os drivers gráficos 2D para o servidor X.Org são empacotados individualmente e chamados xserver-xorg-video- * . Após a instalação, o arquivo do driver gráfico 2D pode ser encontrado em /usr/lib/xorg/modules/drivers/
. O pacote xserver-xorg-video-nouveau instala nouveau_drv.so
com um tamanho de 215 KiB, o driver proprietário Nvidia GeForce instala um arquivo de 8 MiB chamado nvidia_drv.so
e Radeon Software instala fglrx_drv.so
com um tamanho de cerca de 25 MiB.
Os drivers de dispositivos gráficos de código aberto e gratuitos disponíveis estão sendo desenvolvidos dentro do projeto Mesa 3D . Embora possam ser recompilados conforme necessário, o desenvolvimento dos drivers gráficos DDX 2D proprietários é muito facilitado quando o servidor X.Org mantém uma API / ABI estável em várias de suas versões.
Com a versão 1.17, um método genérico para configuração de modo foi desenvolvido. O xf86-video-modesetting
pacote, o pacote Debian sendo chamado xserver-xorg-video-modesetting
, foi retirado, e o Modosetting genérico DDX que ele continha foi movido para o pacote do servidor para se tornar o DDX padrão habilitado para KMS, suportando a grande maioria das GPUs AMD, Intel e NVidia.
Em 7 de abril de 2016, o funcionário da AMD, Michel Dänzer, lançou a xf86-video-ati
versão 7.7.0 e a xf86-video-amdgpu
versão 1.1.0, a última incluindo suporte para sua microarquitetura Polaris .
Arquiteturas de aceleração
Existem (pelo menos) XAA (XFree86 Acceleration Architecture), EXA , UXA e SNA .
No X Window System , XFree86 Acceleration Architecture ( XAA ) é uma arquitetura de driver para disponibilizar a aceleração de hardware 2D de uma placa de vídeo para o servidor X. Ele foi escrito por Harm Hanemaayer em 1996 e lançado pela primeira vez no XFree86 versão 3.3. Ele foi completamente reescrito para o XFree86 4.0. Ele foi removido novamente do X.Org Server 1.13.
A maioria dos drivers implementa aceleração usando o módulo XAA. O XAA está ativado por padrão, embora a aceleração de funções individuais possa ser desativada conforme necessário no arquivo de configuração do servidor ( XF86Config ou xorg.conf ).
O driver para o chipset ARK foi a plataforma de desenvolvimento original para XAA.
No X.Org Server versão 6.9 / 7.0, EXA foi lançado como um substituto para o XAA, já que o XAA quase não oferece vantagem de velocidade para as placas de vídeo atuais. EXA é considerado uma etapa intermediária para converter todo o servidor X para usar OpenGL .
Glamour
Glamour é um driver de aceleração 2D genérico, independente de hardware para o servidor X que converte os primitivos de renderização X em operações OpenGL , aproveitando qualquer driver OpenGL 3D existente. Desta forma, é funcionalmente semelhante ao Quartz Extreme e QuartzGL (aceleração de desempenho 2D) para o Apple Quartz Compositor .
O objetivo final do GLAMOR é tornar obsoleto e substituir todos os drivers de dispositivos gráficos DDX 2D e arquiteturas de aceleração, evitando assim a necessidade de escrever drivers específicos X 2D para cada chipset gráfico compatível. Glamour requer um driver 3D com suporte para shaders .
O ajuste de desempenho de glamour foi aceito para o Google Summer of Code 2014. Glamour é compatível com Xephyr e DRI3 e pode aumentar algumas operações em 700-800%. Desde sua integração na versão 1.16 do servidor X.Org, o desenvolvimento no Glamour foi continuado e os patches para a versão 1.17 foram publicados.
Virtualização
Existe um DDX distinto e especial para instâncias do X.Org Server que rodam em um sistema convidado dentro de um ambiente virtualizado : xf86-video-qxl, um driver para o "dispositivo de vídeo QXL". O SPICE faz uso desse driver, embora também funcione sem ele.
Nos repositórios Debian, é denominado xserver-xorg-video-qxl, cf. https://packages.debian.org/buster/xserver-xorg-video-qxl
Pilha de entrada
No Debian, os drivers relacionados à entrada são encontrados em /usr/lib/xorg/modules/input/
. Esses drivers são nomeados evdev_drv.so
, por exemplo mouse_drv.so
, synaptics_drv.so
ou wacom_drv.so
.
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 . No XDC 2015 em Toronto, o libratbag foi apresentado como uma biblioteca genérica para oferecer suporte a mouses configuráveis. xserver-xorg-input-joystick
é o módulo de entrada para o servidor X.Org para lidar com joysticks e gamepads clássicos, que não se destina a jogos no X, mas para controlar o cursor com um joystick ou gamepad.
Outros componentes DDX
- XWayland
- XWayland é uma série de patches sobre a base de código do servidor X.Org que implementa um servidor X rodando no protocolo Wayland . Os patches são desenvolvidos e mantidos pelos desenvolvedores do Wayland para compatibilidade com os aplicativos X11 durante a transição para o Wayland, e foram desenvolvidos na versão 1.16 do servidor X.Org em 2014. Quando um usuário executa um aplicativo X de dentro do Weston , ele chama XWayland para atender ao pedido.
- XQuartz
- XQuartz é uma série de patches da Apple Inc. para integrar o suporte para o protocolo X11 em seu Quartz Compositor , de maneira semelhante a como o XWayland integra o X11 aos compositores Wayland .
- Xspice
- Xspice é um driver de dispositivo para o servidor X.Org. Suporta o dispositivo de framebuffer QXL e inclui um script wrapper que possibilita o lançamento de um servidor X.Org cujo display é exportado via protocolo SPICE . Isso permite o uso de SPICE em um ambiente de desktop remoto, sem a necessidade de virtualização KVM .
- Xephyr
- Xephyr é uma implementação X-on-X. Desde a versão 1.16.0, o Xephyr serve como o principal ambiente de desenvolvimento para o novo subsistema de aceleração 2D (Glamour), permitindo um rápido desenvolvimento e teste em uma única máquina.
- RandR
- RandR ( redimensionar e girar ) é um protocolo de comunicação escrito como uma extensão do protocolo X11 . O XRandR oferece a capacidade de redimensionar, girar e refletir a janela raiz de uma tela. RandR é responsável por definir a taxa de atualização da tela. Ele permite o controle de vários monitores.
IPC
O servidor X.Org e qualquer cliente-x são executados como processos distintos. No Unix / Linux, um processo não sabe nada sobre nenhum outro processo. Para se comunicar com outro processo, é total e totalmente dependente do kernel para moderar a comunicação por meio dos mecanismos de comunicação entre processos (IPC) disponíveis. Os soquetes de domínio Unix são usados para se comunicar com processos em execução na mesma máquina. Chamadas de função de soquete especial fazem parte da Interface de chamada do sistema. Embora os soquetes de domínio da Internet possam ser usados localmente, os soquetes de domínio Unix são mais eficientes, uma vez que não têm sobrecarga de protocolo ( somas de verificação , ordens de bytes, etc.).
O servidor X.Org não usa D-Bus .
Os soquetes são o método de comunicação entre processos (IPC) mais comum entre os processos do servidor X e seus vários clientes X. Ele fornece a Interface de Programação de Aplicativo (API) para comunicação no domínio TCP / IP e também localmente apenas no domínio UNIX. Existem várias outras APIs descritas na Interface de Transporte X, por exemplo TLI (Interface de Camada de Transporte). Outras opções de IPC entre para o cliente-servidor X requerem extensões do sistema X Window, por exemplo, a extensão de memória compartilhada do MIT (MIT-SHM) .
Configuração multiterminal
Multi-assento refere-se a uma montagem de um único computador com vários "assentos", permitindo que vários usuários se sentem ao computador, façam login e usem o computador ao mesmo tempo de forma independente. O computador tem vários teclados, mouses e monitores conectados a cada um, cada "assento" tendo um teclado, um mouse e um monitor atribuído a ele. Um "assento" consiste em todos os dispositivos de hardware atribuídos a um local de trabalho específico. Ele consiste em pelo menos um dispositivo gráfico (placa gráfica ou apenas uma saída e o monitor conectado) e um teclado e um mouse. Também pode incluir câmeras de vídeo, placas de som e muito mais.
Devido à limitação do sistema VT no kernel Linux e do protocolo do núcleo X (em particular como o X define a relação entre a janela raiz e uma saída da placa de vídeo), multi-assento não funciona fora do ambiente para a distribuição normal do Linux, mas requer uma configuração especial.
Existem estes métodos para configurar uma montagem multi-assento:
- vários servidores Xephyr em um servidor host xorg
- múltiplas instâncias de um servidor xorg
- uma placa gráfica por assento
- uma única placa gráfica para todos os assentos
As opções de linha de comando utilizadas do xorg-server são:
-
-isolateDevice bus-id
Restringir redefinições de dispositivo (saída) para o dispositivo no bus-id. A string bus-id tem a forma bustype: bus: device: function (por exemplo, 'PCI: 1: 0: 0'). No momento, apenas o isolamento de dispositivos PCI é suportado; isto é, esta opção é ignorada se bustype for diferente de 'PCI'. -
vtXX
o padrão para, por exemplo, Debian 9 Stretch é 7, ou seja, pressionando Ctrl+ Alt+ F7o usuário pode alternar para o VT executando o servidor xorg.
Apenas o usuário no primeiro monitor tem o uso de consoles vt e pode usar Ctrl+ Alt+ Fx para selecioná-los. Os outros usuários têm uma tela de login do GDM e podem usar o xorg-server normalmente, mas não têm vt's.
Mesmo que um único usuário possa utilizar vários monitores conectados a diferentes portas de uma única placa de vídeo (cf. RandR), o método que é baseado em várias instâncias do servidor xorg parece exigir várias placas de vídeo PCI .
É possível configurar multi-assento empregando apenas uma placa gráfica, mas devido às limitações do protocolo X, isso requer o uso do protocolo de controle do X Display Manager XDMCP.
Também existe o Xdmx (Distributed Multihead X).
Adoção
- Unix e Linux
- O servidor X.Org roda em muitos sistemas operacionais de software livre semelhantes ao Unix, inclusive sendo adotado para uso pela maioria das distribuições Linux e variantes do BSD . É também o servidor X do sistema operacional Solaris . O X.Org também está disponível nos repositórios do Minix 3 .
- janelas
- Cygwin / X , a implementação da Cygwin do servidor X para Microsoft Windows , usa o servidor X.Org, assim como o VcXsrv ( Visual C ++ X-server) e o Xming . Os clientes SSH, como o PuTTY, permitem a inicialização de aplicativos X por meio do encaminhamento X11, na condição de que esteja habilitado no servidor e no cliente.
- OS X / macOS
- As versões do OS X anteriores ao Mac OS X Leopard (10.5) foram enviadas com um servidor baseado em XFree86, mas o servidor X do 10.5 adotou a base de código X.Org. A partir do OS X Mountain Lion , (10.8) o X11 não está incluído no OS X; em vez disso, ele deve ser instalado, por exemplo, do projeto XQuartz de software livre . A partir da versão 2.7.4, X11.app/XQuartz não expõe suporte para telas Retina de alta resolução para aplicativos X11, que são executados no modo de pixel duplo em telas de alta resolução.
- OpenVMS
- As versões atuais do servidor DECwindows X11 para OpenVMS são baseadas no servidor X.org.
História
A moderna Fundação X.Org surgiu em 2004 quando o órgão que supervisionou os padrões do X e publicou a implementação de referência oficial juntou forças com os ex- desenvolvedores do XFree86 . X11R6.7.0, a primeira versão do X.Org Server, foi bifurcada do XFree86 4.4 RC2. A razão imediata para o fork foi um desacordo com a nova licença para a versão final de lançamento do XFree86 4.4, mas vários desacordos entre os contribuidores surgiram antes da divisão. Muitos dos desenvolvedores anteriores do XFree86 juntaram-se ao projeto X.Org Server.
Em 2005, um grande esforço foi colocado na modularização do código-fonte do servidor X.Org, resultando em um lançamento duplo até o final do ano. O lançamento do X11R7.0.0 adicionou um novo sistema de construção modular baseado no GNU Autotools , enquanto o X11R6.9.0 manteve o antigo sistema de construção do imake , ambos os lançamentos compartilhando a mesma base de código. Desde então, o branch X11R6.9 é mantido congelado e todo o desenvolvimento contínuo é feito para o branch modular. O novo sistema de compilação também trouxe o uso do vinculador dinâmico padrão dlloader para carregar plug-ins e drivers, substituindo o método antigo. Como conseqüência da modularização, os binários do X11 estavam saindo de sua própria árvore de subdiretórios / usr / X11R6 para a árvore global / usr em muitos sistemas Unix .
Em junho de 2006, outro esforço foi feito para mover o código-fonte do servidor X.Org do CVS para o git . Ambos os esforços tinham o objetivo de longo prazo de trazer novos desenvolvedores para o projeto. Nas palavras de Alan Coopersmith:
Alguns de nossos esforços aqui têm sido tecnológicos - um dos principais esforços das conversões de Imake para automake e de CVS para git foi fazer uso de ferramentas que os desenvolvedores já estariam familiarizados e produtivos em outros projetos. O projeto de Modularização, que dividiu o X.Org de uma árvore gigante em mais de 200 pequenas, tinha o objetivo de tornar possível corrigir um bug em uma única biblioteca ou driver sem ter que baixar e construir muitos megabytes de software e fontes que não estavam sendo alterados.
Na versão 7.1, a estrutura KDrive (uma pequena implementação do X escrita por Keith Packard , que não era baseada no XFree86 que os desenvolvedores do X.Org usaram como campo de teste para novas ideias, como EXA ) foi integrada à base de código principal do Servidor X.Org.
Em 2008, o novo DRI2, baseado no driver kernel mode-setting (KMS), substituiu o DRI. Essa mudança também definiu um marco importante na arquitetura do servidor X.Org, pois os drivers foram movidos do servidor e do espaço do usuário (UMS) para o espaço do kernel .
Em 2013, as versões iniciais das extensões DRI3 e Present foram escritas e codificadas por Keith Packard para fornecer uma renderização 2D mais rápida e sem tearing . No final do ano, a implementação do GLX foi reescrita por Adam Jackson na Red Hat .
Lançamentos
Versão | Encontro | Lançamento X11 | Principais características |
---|---|---|---|
1.0 | 21 de dezembro de 2005 | X11R7.0 (1.0.1) | Servidor X modularizado inicial, arquitetura EXA |
1,1 | 22 de maio de 2006 | X11R7.1 (1.1.0) | Integração KDrive, suporte AIGLX |
1,2 | 22 de janeiro de 2007 | X11R7.2 (1.2.0) | Configuração automática, suporte aprimorado para gerenciadores de composição baseados em GL |
1,3 | 19 de abril de 2007 | RandR 1.2 | |
1,4 | 6 de setembro de 2007 | X11R7.3 (1.4.0) | Suporte a hotplug de entrada |
1,5 | 3 de setembro de 2008 | X11R7.4 (1.5.1) | MPX |
1,6 | 25 de fevereiro de 2009 | RandR 1.3, DRI2 , XInput 1.5 | |
1,7 | 1 de outubro de 2009 | X11R7.5 (1.7.1) | XInput 2.0, multi-ponteiro X |
1,8 | 2 de abril de 2010 | xorg.conf.d , manipulação de entrada udev | |
1,9 | 20 de agosto de 2010 | X11R7.6 (1.9.3) | |
1,10 | 25 de fevereiro de 2011 | X Sincronização Fences | |
1,11 | 26 de agosto de 2011 | ||
1,12 | 4 de março de 2012 | X11R7.7 (1.12.2) | XInput 2.2 (incluindo suporte multi-touch) |
1,13 | 5 de setembro de 2012 | Nova API de driver DDX, DRI2 offload, RandR 1.4, contextos OpenGL 3.x +, remoção de XAA | |
1,14 | 5 de março de 2013 | XInput 2.3 | |
1,15 | 27 de dezembro de 2013 | DRI3 e extensões presentes | |
1,16 | 17 de julho de 2014 | XWayland DDX, aceleração GLAMOR, suporte a dispositivos não PCI, suporte systemd-logind (rootless X), suporte obtido para a biblioteca libinput na forma de um wrapper chamado xf86-input-libinput | |
1,17 | 4 de fevereiro de 2015 | Integração do driver genérico DRM / KMS xf86-video-modesetting anterior , suporte adicionado para DRI2 com GLAMOR | |
1,18 | 9 de novembro de 2015 | RandR 1.5 | |
1,19 | 15 de novembro de 2016 | Entrada encadeada, sincronização PRIME, confinamento e distorção do ponteiro XWayland, suporte a extensão Windows DRI | |
1,20 | 10 de maio de 2018 | Melhorias no sistema de compilação do Meson , o GLXVND permite drivers OpenGL distintos para diferentes telas X, o leasing RandR melhora o suporte ao Steam VR | |
21,1 | TBA | Sistema de compilação Meson agora em par com Autotools, suporte a taxa de atualização variável , gestos de touchpad via XInput 2.4 | |
Lenda:
Versão antiga
Versão mais antiga, ainda mantida
Última versão
Lançamento futuro
|
Veja também
- Implementação de referência - parte de um pacote de lançamento padrão
- Gerenciador de janelas X - um pacote que é deliberadamente mantido separado do pacote do servidor X
- Extensão de vídeo X
- evdev
- xorg.conf
- XQuartz
- Xenocara