Às vezes, a GUI responde lentamente - ou não responde - ou parece travar - mas o cursor ainda responde rapidamente. Como funciona o ponteiro do mouse?

Há pelo menos dois detalhes separados aqui:

1. Cursor de hardware
2. As atualizações do cursor são deliberadamente priorizadas

1. Cursor de hardware

O primeiro detalhe é mais conhecido. Você pode encontrá-lo mencionado na documentação: a HWCursoropção no Xorg.

Seus gráficos provavelmente usam um cursor de hardware. À medida que o hardware varre os pixels para a tela, ele sobrepõe o cursor do mouse sobre o framebuffer principal.

• Um bug no driver gráfico pode configurar incorretamente o framebuffer, sem quebrar o cursor do hardware.
• Ou um cursor de hardware mal configurado pode parecer corrompido. Mas você ainda pode ver o cursor corrompido se mover e responder, enquanto o restante da tela parece quebrado.
• Ou o cursor pode ser configurado incorretamente enquanto o framebuffer está OK. Como no caso do " desaparecimento do mouse ".

1.1 Cursor de software

Observe que, embora os cursores de hardware sejam muito úteis, também existem técnicas para fazer com que os cursores de software funcionem melhor.

https://www.x.org/wiki/Development/Documentation/InputEventProcessing/

Se for feito em software, o cursor deve ser armazenado em buffer. Toda vez que ele se move, restauramos a imagem anterior, salvamos a janela na posição de destino e renderizamos o cursor no fluxo.

xorg-server-1.20.5/mi/midispcur.c - miDCSaveUnderCursor() / miDCRestoreUnderCursor()

2. As atualizações do cursor são deliberadamente priorizadas

Para ser justo, o cursor é relativamente simples. Além disso, está em uso constante. Isso significa que é improvável que a memória específica do cursor seja trocada quando você começa a ficar sem memória. Mas há também outro detalhe:

https://who-t.blogspot.com/2016/09/input-threads-in-x-server.html

Anteriormente, havia duas opções de como um driver de entrada passaria eventos para o servidor X: polling ou de dentro do manipulador de sinal. O polling simplesmente adiciona os descritores de arquivo de todos os dispositivos de entrada a um loop select(2) que é processado no mainloop do servidor. A desvantagem aqui é que, se o servidor estiver ocupado renderizando algo, sua entrada será atrasada até que a renderização seja concluída. Historicamente, o polling era usado principalmente pelo driver do teclado porque não importa muito quando as teclas são atrasadas. Tanto porque você precisa que o cliente os renderize de qualquer maneira (o que não pode quando está ocupado) e possivelmente também porque estamos tão acostumados a atrasos de digitação.

A abordagem do manipulador de sinal contornou os atrasos instalando um manipulador SIGIO para cada dispositivo de entrada fd e chamando-o quando ocorresse qualquer entrada. Isso interrompe efetivamente o processo até que o manipulador de sinal seja concluído, independentemente do que o servidor está ocupado no momento. Uma ótima solução para fornecer movimento visível imediato do cursor (portanto, é usado por evdev, synaptics, wacom e a maioria dos drivers legados agora aposentados)

[...]

Os drivers enviam eventos para a fila durante o manipulador de sinais, no loop principal o servidor os lê e os processa. Em um servidor ocupado, isso pode levar vários segundos após o movimento do ponteiro ter sido executado na tela, mas, ei, ele ainda parece responsivo.

[...]

Nós ainda estávamos "felizes" com isso até que o libinput apareceu. libinput é uma pilha de entrada completa e esperar que funcione dentro de um manipulador de sinal é algo entre otimista, masoquista e sádico. O driver xf86-input-libinput não usa o manipulador de sinal e o efeito colateral disso é que um desktop com libinput não parecia tão responsivo quando o servidor estava ocupado renderizando.

Keith Packard interveio e mudou o servidor do manipulador de sinal para o uso de threads de entrada. Ou mais especificamente: um thread de entrada no topo do thread principal. Esse thread controla todos os descritores de arquivo do dispositivo de entrada e lê continuamente os eventos deles. Caso contrário, ele fornece a mesma funcionalidade que o manipulador de sinais fazia antes: movimento de ponteiro visível e envio de eventos na fila de eventos para o thread principal processá-los posteriormente. Mas é claro que, uma vez que você muda para tópicos, os problemas têm 2 agora. [...] algumas condições de corrida interessantes continuaram acontecendo. Mas a partir de hoje, achamos que a maioria deles está resolvida.