ThinkPad X13 Gen 2i com Arch Linux + Niri + DankMaterialShell — relato da instalação e configuração
Há algum tempo eu estava procurando um notebook usado para substituir, pelo menos em boa parte do uso diário, o meu desktop. Acabei comprando um ThinkPad X13 Gen 2i, e a máquina acabou vindo melhor do que eu esperava em alguns aspectos. Inspirado no @frc_kde escrevi um relato sobre o que foi feito. 
A configuração atual é esta:
- ThinkPad X13 Gen 2i, plataforma Intel de 11ª geração;
- 16 GB de RAM;
- SSD NVMe ADATA de 256 GB;
- tela interna de 13,3" com resolução 2560×1600;
- leitor de digitais Synaptics;
- câmera com infravermelho;
- Wi-Fi Intel AX210;
- teclado físico dinamarquês, configurado no sistema como ABNT2;
- dock Lenovo USB-C 40AY0090BR;
- dois monitores externos 1440×900: um AOC 912Vwa e um Dell E1913;
- impressora Brother HL-L5102DW.
Inicialmente usei Windows e BigLinux no notebook. O BigLinux funcionava bem e inclusive me serviu para testar praticamente todo o hardware, mas eu já vinha pensando em montar uma instalação mais enxuta e mais próxima do que eu realmente queria usar. Depois de vários testes com outras combinações, inclusive CachyOS, Noctalia e diferentes ambientes, acabei decidindo por Arch Linux + Niri + DankMaterialShell.
Instalação do Arch
A instalação foi feita pelo archinstall, em UEFI, com LUKS2 + Btrfs.
Deixei uma partição EFI de aproximadamente 1 GiB em /boot e o restante do SSD criptografado. No Btrfs criei subvolumes separados para raiz, /home, /var/log e cache do Pacman. Também usei compressão zstd:3.
Não configurei swap em disco; estou usando ZRAM. Também não configurei hibernação.
Para boot escolhi Limine, e instalei apenas dois kernels: linux-zen, como principal, e linux-lts, como alternativa de emergência. Não mantive o kernel linux padrão.
O sistema ficou em português do Brasil, timezone America/Sao_Paulo e teclado br-abnt2.
Snapshots e recuperação
Uma das coisas que eu queria era manter um sistema rolling release sem abrir mão de uma forma simples de recuperação.
Configurei o Snapper, com snapshots da raiz e do /home, além do snap-pac, que cria automaticamente snapshots antes e depois de operações do Pacman.
Depois instalei o limine-snapper-sync, que adiciona os snapshots diretamente ao menu do Limine.
O menu de boot ficou basicamente com:
Arch Linux
├── Linux LTS
├── Linux Zen
└── Snapshots
E não fiquei apenas na teoria. Fizemos um teste real de recuperação: criei um arquivo em /etc, fiz um snapshot, alterei o arquivo e depois inicializei pelo snapshot através do Limine. Ao entrar no snapshot, o arquivo voltou ao conteúdo anterior, provando que o sistema realmente estava rodando a raiz histórica.
Durante esse boot apareceram alguns erros de serviços tentando escrever em um snapshot somente leitura, especialmente Bluetooth, GnuPG e alguns arquivos de /var, mas isso era esperado. Reiniciei normalmente pelo Zen e o sistema voltou sem nenhuma unidade com falha.
Então hoje eu sei que, se uma atualização realmente quebrar o sistema, não dependo apenas de “esperar que os snapshots estejam funcionando”: eu já testei o processo de boot por snapshot.
Niri + DankMaterialShell
Para o ambiente gráfico escolhi o Niri, com o DankMaterialShell (DMS).
Não estou usando KDE Plasma nem GNOME como desktop completo. Também não estou usando SDDM. O login é feito pelo greetd com DMS Greeter.
Depois da última atualização, estou com DMS 1.6.2 e o pacote específico dms-shell-niri.
O terminal principal ficou sendo o Ghostty, embora eu tenha mantido vários aplicativos KDE, porque gosto deles e funcionam perfeitamente fora do Plasma: Dolphin, Kate, Spectacle, Gwenview, Okular, Ark, KDE Partition Manager, KDE Connect etc.
Tive um pequeno problema com teclas mortas no Ghostty usando ABNT2. A solução foi adicionar:
GTK_IM_MODULE=simple
ao ambiente da sessão.
Também instalei o qtengine e configurei o Qt para seguir melhor o tema do DMS. Hoje o dms doctor dá 37 verificações OK e apenas um aviso referente ao plugin Qt5 do qtengine, que não está causando nenhum problema real.
Atalhos
Criei um arquivo separado para meus atalhos pessoais no Niri, em vez de misturá-los com os arquivos gerenciados pelo DMS.
Alguns que uso:
Mod+F1 painel de atalhos
Mod+B Firefox
Mod+E Dolphin
Mod+Alt+E Kate
O painel padrão do Niri em Mod+Shift+/ também foi mantido.
Dock e três monitores
Depois de terminar a instalação retirei o OptiPlex da mesa e coloquei a Lenovo USB-C Dock 40AY no lugar.
A dock foi reconhecida completamente pelo Linux: hubs USB 2 e 3, áudio, Ethernet Realtek RTL8153 e os dois monitores.
A disposição normal ficou com o AOC e o Dell lado a lado na parte superior, ambos em 1440×900, e a tela do X13 abaixo, em 2560×1600 com escala 1,75.
Tentei inicialmente usar os perfis de monitor do DMS para alternar entre duas e três telas, mas não gostei do resultado. Em vez de simplesmente desligar a tela interna, ele reorganizava tudo.
A solução acabou sendo muito mais simples: modo clamshell nativo do Niri.
Com o X13 aberto uso três telas. Fecho a tampa e a tela interna é desligada automaticamente, permanecendo apenas AOC + Dell. Reabro a tampa e a tela do notebook volta.
Na primeira tentativa de clamshell houve um problema: a troca de topologia derrubou a barra do DMS e tive que reiniciar pelo console. Depois do reboot, no entanto, passei a fechar e abrir a tampa várias vezes e o problema não voltou.
No fim, não precisei de Kanshi, perfis especiais nem plugins de terceiros.
Bateria
Como o notebook agora passa bastante tempo ligado à dock, também configurei limites de carga.
Os valores efetivamente aplicados pelo kernel são:
início da carga: 50%
fim da carga: 80%
Estou usando power-profiles-daemon no perfil balanced.
A bateria atualmente tem cerca de 229 ciclos e aproximadamente 80% da capacidade original. Para um notebook usado, considero perfeitamente aceitável, e manter 50/80 deve ajudar bastante agora que ele passou a trabalhar boa parte do tempo conectado à energia.
Leitor de digitais
O leitor de digitais funciona muito bem.
Estou usando para:
- login pelo DMS Greeter;
- desbloqueio da sessão.
Preferi não habilitar a digital para sudo. O sudo continua exigindo senha.
Também percebi que, inicialmente, ao suspender pelo menu do DMS, o computador acordava sem pedir autenticação. Descobri que loginctlLockIntegration já estava ativado, mas lockBeforeSuspend não.
Depois de ativar essa opção, o comportamento ficou correto:
bloqueia a sessão → suspende → acorda na tela de bloqueio → digital ou senha.
MEGAsync
O MEGAsync deu um pouco mais de trabalho no Niri.
Primeiro, o autostart tradicional fazia o programa aparecer de maneira estranha e eventualmente criava instâncias duplicadas. Passei a iniciar o MEGAsync através de um serviço systemd --user, alguns segundos depois do DMS.
Depois veio outro problema: ao clicar no ícone do tray, o painel do MEGA aparecia como uma enorme janela tiled.
Criamos então uma regra do Niri para fazê-lo abrir como floating, em tamanho 400×560 e no canto superior direito.
Curiosamente, descobri que o MEGAsync pode expor dois App IDs diferentes dependendo da inicialização:
MEGAsync
ou:
nz.co.mega.megasync
Então a regra final ficou preparada para os dois casos.
Depois disso, o MEGA passou a se comportar como eu esperava: inicia no tray e o painel aparece como uma pequena janela flutuante.
A integração do MEGA com o Dolphin também está funcionando.
KDE Connect e firewall
Estou usando firewalld, não UFW.
Criei uma zona chamada kdeconnect para as redes domésticas. Tanto o Wi-Fi quanto a Ethernet da dock ficam nessa zona.
Redes desconhecidas continuam usando public.
Isso permite que KDE Connect e descoberta mDNS funcionem em casa sem simplesmente abrir esses serviços em qualquer rede.
O KDE Connect está funcionando inclusive para troca de arquivos e área de transferência com o Galaxy S24+.
Impressora Brother HL-L5102DW
A Brother foi instalada sem driver proprietário.
Usei IPP Everywhere, CUPS, Avahi e mDNS.
Foi necessário habilitar o avahi-daemon e instalar nss-mdns, porque inicialmente o sistema descobria a impressora via Avahi, mas não conseguia resolver o hostname .local.
Hoje ela é encontrada como:
Brother5A141448.local
192.168.1.125
IPP / porta 631
Criei a fila Brother_HL_L5102DW com -m everywhere.
A página de teste saiu normalmente.
Também configurei duplex por borda longa como meu padrão, porque praticamente sempre uso impressão frente e verso.
Aplicativos do BigLinux no Arch
Uma coisa que eu gostava no BigLinux eram alguns dos programas próprios do projeto. Descobri que vários deles estão disponíveis separadamente no GitHub, então instalei alguns no Arch sem adicionar repositórios do BigLinux.
Hoje tenho funcionando:
- Big Audio Converter;
- Big Video Converter;
- AshyTerm;
- BigTube;
- Big Network Info;
- BigCam.
O Big Audio Converter precisou do python-numpy, que não estava declarado corretamente no PKGBUILD.
O BigCam também exigiu uma adaptação: o pacote listava uxplay como dependência, mas como uso Android e não precisava do suporte AirPlay, retirei essa dependência e mantive scrcpy e android-tools.
O v4l2loopback-dkms compilou corretamente tanto para o Zen quanto para o LTS.
Outros programas
Além dos aplicativos KDE, instalei ou mantive:
Firefox
LibreOffice Fresh
Calibre
Telegram
Bitwarden
Tuta
Joplin
Strawberry
KTeaTime
Resources
VueScan
MEGAsync
MEGA VPN
htop
micro
mc
O Tuta AppImage precisou do fuse2. Depois instalei também gnome-keyring e libsecret para o armazenamento seguro das credenciais.
Tenho Flatpak/Flathub disponíveis, mas prefiro instalar cada programa pelo método que considero mais apropriado, sem transformar tudo em Flatpak por padrão.
Estado atual do sistema
Depois de terminar toda a configuração fiz uma revisão geral.
O resultado atual é:
systemctl --failed
→ 0 falhas
systemctl --user --failed
→ 0 falhas
pacman -Qdtq
→ nenhum pacote órfão
Também removi alguns pacotes -debug que haviam sido instalados junto com pacotes AUR e não tinham utilidade para mim.
O SSD ainda tem aproximadamente 220 GiB livres.
A ESP de 1 GiB está com menos de 40% de uso, mesmo armazenando os arquivos necessários para os snapshots inicializáveis.
O firmware está totalmente atualizado segundo o fwupd, incluindo BIOS, Embedded Controller, Intel Management Engine, SSD e demais dispositivos suportados.
Uma exceção temporária: libcupsfilters
No momento estou mantendo o:
libcupsfilters 2.1.1-4
e bloqueando a atualização para 2.2.1-2 através de:
IgnorePkg = libcupsfilters
no /etc/pacman.conf.
Isso é deliberado e temporário. Pretendo liberar novamente quando sair uma versão posterior que resolva o problema que encontramos.
Resultado
Depois de alguns dias mexendo bastante no sistema, cheguei a uma configuração que considero praticamente final.
O X13 hoje funciona tanto como notebook quanto como desktop. Quando está na mesa, conecto uma única USB-C e tenho energia, Ethernet, dois monitores, USB e áudio pela dock. Posso usar as três telas com o notebook aberto ou simplesmente fechar a tampa e trabalhar com os dois monitores externos.
Ao tirar da dock, continuo com um Arch leve e totalmente funcional como notebook.
O sistema tem criptografia LUKS, snapshots Btrfs inicializáveis, dois kernels, biometria, suspensão com bloqueio, impressora driverless, dock completamente funcional e praticamente todo o software que eu usava anteriormente.
A única pendência que ainda pretendo resolver é colocar um HDD de 500 GB em um case USB e configurá-lo com LUKS2 para armazenamento externo criptografado. Em algum momento também pretendo trocar o SSD interno de 256 GB por um maior, mas no uso atual o espaço ainda está bastante folgado.
Foi uma instalação que exigiu bastante ajuste fino, principalmente em pontos como MEGAsync, clamshell, firewall/mDNS e integração dos programas do BigLinux, mas o resultado ficou exatamente no espírito que eu procurava: Arch relativamente enxuto, Niri muito rápido, DMS agradável de usar e sem depender de um desktop tradicional completo.
Até agora, estou bastante satisfeito com a combinação.
Algumas imagens do sistema e do setup final:
O X13 em uso aberto e depois em modo clamshell:
