Sugestões para otimização da configuração do multiterminal


#1

@dpasqualin @sbamerico, eu estou experimentando o LE6.1 multiterminal em uma máquina aqui e acho que dá pra otimizar um pouco o processo:

  1. No script /usr/sbin/multiseat-controller, não deveria ser necessário executar explicitamente o “Xorg fake-seat :90”, pois ele já executado automaticamente pelo systemd, desde que a unidade xorg-daemon.socket esteja devidamente ativada e iniciada. Na pior das hipóteses, eu substituiria o comando de execução explícita do Xorg :90 pelo comando systemctl restart xorg-daemon.socket.

  2. Uma vez que o Xorg :90 não é mais executado explicitamente pelo script multiseat-controller, ele também não é terminado ao final da sua execução, o que permite uma segunda otimização: não deveria ser mais necessário reiniciar o computador no final do script /usr/sbin/multiterminal. Uma vez que o udevadm já atribuiu as devidas tags aos hubs configurados e que os mesmos já estão devidamente listados no loginctl list-seats, basta deixar o sistema seguir o seu curso, executando o lightdm ao final da configuração do multiterminal.

Eu realizei estas duas alterações aqui e refiz a configuração do multiterminal. Nos meus testes, tudo funcionou como esperado, e a tela de login é carregada tão logo eu conclua a associação dos terminais, sem necessidade de reiniciar o computador.


#2

Muito obrigada pelo feedback e toda parceria, @lbssousa! Vamos fazer os testes e incluir as alterações cabíveis!


#3

Mais uma sugestão, desta vez para otimizar o processo de reconfiguração do multiterminal:

@sbamerico Em vez de instalar explicitamente o serviço le-multiterminal.service e forçar sua execução antes do serviço lightdm.service, talvez seja melhor simplesmente declará-lo como uma dependência deste. Por exemplo, o pacote le-multiterminal poderia instalar um arquivo /lib/systemd/system/lightdm.service.d/le-multiterminal.conf com o seguinte conteúdo:

[Unit]
Wants=le-multiterminal.service
After=le-multiterminal.service

Com isto, é possível remover as linhas Before=lightdm.service e toda a seção [Install] do arquivo le-multiterminal.service, bem como o comando deb-systemd-helper enable le-multiterminal.service do script pós-instalação do pacote le-multiterminal.

Com esta otimização, não é necessário reiniciar o computador para reconfigurar o multiterminal: basta reiniciar o serviço do lightdm. Vocês podem fazer o teste com os seguintes comandos:

sudo rm /etc/le-multiterminal/configurado
sudo systemctl restart lightdm

#4

Atualmente, o script seat-attach-assistant do pacote le-multiterminal cria um terminal novo incondicionalmente sempre que um hub é conectado ao computador. É possível simplificar a configuração, eliminando este script junto com o arquivo 73-seat-attach-assistant.rules, se vocês acrescentarem a diretiva ENV{ID_AUTOSEAT}="1" ao arquivo 71-seat-usb.rules. Por outro lado, uma outra abordagem para o multiterminal é possível.

Quando eu comecei a pesquisar a solução para o multiterminal, parecia-me bastante razoável eliminar o hub do terminal primário e conectar o seu teclado e mouse diretamente ao computador. No entanto, logo nos primeiros feedbacks que eu recebi quando publiquei a solução, perguntaram-me sobre a possibilidade de se usar um hub também com o terminal primário, seja porque desejavam manter o dual-boot com o LE4 ou LE5, seja porque o laboratório foi montado de tal forma que os computadores ficam afastados demais dos terminais para permitir a conexão direta do teclado ou mouse.

Se for desejável para vocês flexibilizar a configuração do multiterminal para permitir o uso do hub também com o terminal primário, uma forma possível de viabilizá-la é substituir a regra do udev que marca os hubs como master-of-seat por outra que faz o mesmo com a própria placa TN-502. O kernel do Ubuntu inclui, por padrão, o módulo sm501.ko, que permite expor alguns dispositivos relacionados à placa TN-502 que podemos marcar como master-of-seat. Exemplo:

# Convenção: associar arquivos de dispositivo desta regra à saída LVDS da placa TN-502
KERNEL=="sm501-fb.[0-9]*", SUBSYSTEM=="platform", TAG+="seat", TAG+="master-of-seat", 

# Convenção: associar arquivos de dispositivo desta regra à saída VGA da placa TN-502
KERNEL=="sm501-usb.[0-9]*", SUBSYSTEM=="platform", TAG+="seat", TAG+="master-of-seat"

Além da possibilidade de se usar um hub com o terminal primário, esta solução alternativa para o multiterminal oferece outras “vantagens”:

  • conceitualmente, oferece um resultado mais próximo do propósito original do systemd-logind no que tange ao suporte a multiterminais, em que são sempre as placas de vídeo que recebem a marca master-of-seat por padrão.
  • permite uma configuração fixa do LightDM, não sendo mais necessário gerar dinamicamente o arquivo de configuração 98-xephyr-multi-seat.conf.
  • a configuração do multiterminal fica mais robusta, deixando o sistema menos propenso a instabilidades devido ao mau contato dos hubs USB, por exemplo.

Com esta nova regra, vocês poderiam alterar o script multiseat-controller, modificando a linha

N_SEATS_LISTED=$(($(loginctl list-seats | grep -c "seat-")+$ONBOARD))

para listar, por exemplo, as saídas de vídeo disponíveis. Então, na rotina que detecta o pressionamento da tecla Fn, vocês poderiam executar o loginctl attach sob demanda. Por exemplo, se for detectado o pressionamento da tecla no terminal associado à saída de vídeo LVDS da primeira placa TN-502, o script poderia invocar os seguintes comandos:

loginctl attach seat-sm501-0-lvds /syspath/do/dispositivo/sm501-fb.0
loginctl attach seat-sm501-0-lvds /syspath/do/hub/detectado

O único cuidado necessário para esta abordagem é o tratamento adequado das condições de saída do script multiseat-controller:

  • se houver menos teclados conectados do que saídas de vídeo disponíveis, pode acontecer que, após a configuração de todos os teclados conectados, não haja teclados disponíveis para associar a uma determinada saída de vídeo; neste caso, o script encerra a configuração, deixando aquela saída de vídeo desconfigurada (não se executa loginctl attach seat-... /sys/devices/... para aquela saída de vídeo).
  • se houver mais teclados conectados do que saídas de vídeo disponíveis, pode acontecer que haja um excesso de teclados não associados após a configuração dos terminais em todas as saídas de vídeo disponíveis; neste caso, o script encerra a configuração, deixando o excesso de teclados desconfigurado (por padrão, eles vão para o terminal primário).

#5

Eu consegui implementar estas otimizações, entre outras, no nosso projeto oi-lab. Eu publiquei um descritivo das diferenças neste link: https://github.com/oiteam/oi-lab/wiki/Diferenças-entre-a-implementação-do-multiterminal-no-oi-lab-e-no-le-multiterminal