CachyOS no notebook: troubleshooting de rede, NVIDIA e brilho no XFCE4

Instalei recentemente o CachyOS no meu notebook e documentei todo o processo de validação e ajustes pós-instalação que executei. Meu objetivo com este texto é ajudar quem está montando um ambiente similar nessa distribuição e esbarra em pequenos entraves de hardware ou rede local. Não vou me deter nos passos da instalação em si, pois o foco aqui é o refinamento prático do sistema rodando.

Verificação inicial do sistema#

Logo após o primeiro boot, a primeira coisa que fiz foi rodar comandos essenciais no terminal para checar a saúde geral do ambiente:

uname -r && cat /etc/os-release | head -5
free -h
df -h /
systemctl is-system-running
ping -c 2 archlinux.org

O diagnóstico foi positivo: kernel 7.1.3-2-cachyos ativo (compilado com otimizações para x86_64-v3 e escalonador EEVDF), systemd em estado de execução normal, conectividade de rede respondendo rápido, partição raiz com apenas 4% de espaço ocupado e memória RAM folgada. A base do sistema estava pronta, conforme documentado no wiki oficial do CachyOS.

Configuração de rede local via SMB#

O cenário#

Precisei conectar esse notebook a outro computador que já estava na mesma rede Wi-Fi para transferir arquivos de trabalho. A solução mais prática e interoperável para isso foi recorrer ao protocolo SMB através do Samba, acessando pastas compartilhadas direto pelo gerenciador de arquivos do ambiente gráfico.

Mapeamento da rede local#

O primeiro passo foi identificar as interfaces e o endereço atribuído pelo roteador:

ip link show
ip addr show
nmcli device status

O notebook estava associado ao Wi-Fi com o IP local 192.168.1.17/24. A interface cabeada Ethernet (enp109s0) constava disponível, mas sem cabo conectado no momento.

Para descobrir os outros dispositivos ligados no mesmo segmento de rede, executei uma varredura direta via terminal:

for i in $(seq 1 30); do
  (ping -c 1 -W 1 192.168.1.$i &>/dev/null && echo "192.168.1.$i ativo") &
done; wait

O teste revelou o gateway do roteador (.1) e mais três máquinas ativas (.10, .14, .16). No entanto, nenhuma delas respondia com a porta SMB padrão (TCP 445) aberta.

Ajuste do cliente Samba#

O pacote smbclient já vinha instalado na base do CachyOS, mas o arquivo de configuração /etc/samba/smb.conf não existia por padrão, provocando erros ao listar compartilhamentos remotos:

smbclient -L 192.168.1.16 -N
# Retorno: Can't load /etc/samba/smb.conf - run testparm to debug it

Ao criar o arquivo /etc/samba/smb.conf, há uma decisão importante sobre a diretiva de protocolo, detalhada no guia de Samba da ArchWiki:

sudo bash -c 'cat > /etc/samba/smb.conf << "EOF"
[global]
   workgroup = WORKGROUP
   client min protocol = SMB2_02
   client max protocol = SMB3
EOF'

A armadilha do NT1 (SMB1) vs SMB2/SMB3#

Em tutoriais antigos, é comum encontrar a recomendação client min protocol = NT1. O protocolo NT1 refere-se ao SMBv1, considerado obsoleto e inseguro (vulnerável a ataques como EternalBlue). Desde o Samba 4.11, o padrão mínimo do cliente é SMB2_02. Só utilize NT1 se você estiver se comunicando com roteadores antigos, impressoras legadas ou executando o utilitário smbtree (que depende de NetBIOS broadcasts). Para transferências modernas entre máquinas Linux ou Windows 10/11, mantenha SMB2_02 ou SMB3.

Configurando o servidor Samba na outra máquina#

Como nenhuma máquina da rede tinha o serviço de compartilhamento ativo, precisei configurar o daemon no outro computador (também com distribuição Linux):

# 1. Instalar o pacote do Samba
sudo pacman -S samba

# 2. Criar a pasta que receberá os arquivos
mkdir -p ~/Compartilhado

# 3. Definir a senha do usuário no banco do Samba
sudo smbpasswd -a $USER

# 4. Gravar a configuração do compartilhamento
sudo bash -c 'cat > /etc/samba/smb.conf << EOF
[global]
   workgroup = WORKGROUP
   security = user
   map to guest = never
   server min protocol = SMB2_02

[Compartilhado]
   path = /home/'"$USER"'/Compartilhado
   browsable = yes
   writable = yes
   valid users = '"$USER"'
EOF'

# 5. Ativar e iniciar os daemons smbd e nmbd
sudo systemctl enable --now smbd nmbd

O utilitário smbpasswd solicita uma senha dedicada para conexões de rede SMB. Essa senha fica armazenada na base interna do Samba (passdb.tdb) e não precisa ser idêntica à senha de login do usuário no sistema operacional.

Se a máquina servidora tiver firewall ativo (como ufw ou firewalld), libere as portas necessárias:

# Se utilizar UFW:
sudo ufw allow 445/tcp
sudo ufw allow 139/tcp

Para testar a conexão a partir do CachyOS:

smbclient -L //192.168.1.16 -U meu_usuario

A listagem exibiu a pasta compartilhada e o acesso pelo gerenciador Thunar funcionou imediatamente através da URI smb://192.168.1.16/Compartilhado.

Verificação do driver NVIDIA#

O notebook conta com placa gráfica dedicada NVIDIA GeForce RTX 5050. Para garantir que os drivers oficiais e os módulos de kernel estavam devidamente integrados na compilação otimizada do CachyOS, verifiquei os subsistemas de vídeo:

nvidia-smi
lspci | grep -i vga
pacman -Qs nvidia
lsmod | grep -i nvidia

A saída do nvidia-smi indicou funcionamento estável:

• Versão do driver: 610.43.03 (módulos de kernel em código aberto / open kernel modules, mantidos no repositório NVIDIA open-gpu-kernel-modules).
• Servidor Xorg consumindo cerca de 233 MiB de VRAM.
• Temperatura em repouso na faixa de 51 graus Celsius e consumo contido em 8 W.

Todos os módulos essenciais estavam carregados:

lsmod | grep nvidia
# nvidia
# nvidia_drm
# nvidia_modeset
# nvidia_uvm

O CachyOS já entregou instalados os pacotes nvidia-utils, nvidia-settings, nvidia-open, nvidia-prime, supergfxctl e os módulos correspondentes para o kernel customizado (linux-cachyos-nvidia-open).

Gerenciamento de energia com supergfxctl e PRIME#

Em notebooks com gráficos híbridos (iGPU Intel/AMD + dGPU NVIDIA), manter a placa dedicada acordada em tarefas simples drena a bateria rapidamente. O CachyOS integra o utilitário supergfxctl para alternar perfis:

# Consultar modo gráfico atual
supergfxctl -g
# Resposta: Hybrid

# Alternar para modo integrado (desliga a dGPU para economizar bateria)
supergfxctl -m Integrated

# Verificar se a GPU entrou em suspensão de energia (PCIe D3cold)
cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_status
# Resposta esperada em repouso: suspended

No modo híbrido, tarefas leves rodam na placa integrada e você pode disparar aplicações pesadas sob demanda com aceleração da NVIDIA usando o prefixo prime-run:

prime-run blender
prime-run steam

O problema do controle de brilho no XFCE4#

O sintoma#

O maior obstáculo de usabilidade pós-instalação foi o controle de iluminação da tela. O ícone de brilho na área de notificação do XFCE4 não respondia aos cliques nem aos atalhos de teclado.

Análise da falha#

Investiguei a cadeia de controle em quatro etapas:

1. Identificação da interface no sysfs:

ls /sys/class/backlight/
# nvidia_wmi_ec_backlight

cat /sys/class/backlight/nvidia_wmi_ec_backlight/brightness
# 100

cat /sys/class/backlight/nvidia_wmi_ec_backlight/max_brightness
# 100

A interface exposta pelo hardware era nvidia_wmi_ec_backlight (associada ao tipo firmware), em vez dos controladores convencionais como intel_backlight ou acpi_video0.

2. Verificação de permissões do arquivo:

ls -la /sys/class/backlight/nvidia_wmi_ec_backlight/brightness
# -rw-r--r-- 1 root root brightness

Aqui estava a origem da falha: o arquivo brightness pertencia com exclusividade ao usuário root, com permissões restritas de leitura para terceiros. O grupo video não possuía permissão de escrita, impedindo que o gerenciador de energia do XFCE4 alterasse a intensidade luminosa em tempo de execução.

3. Estado do XFCE Power Manager:

xfconf-query -c xfce4-power-manager -l | grep bright

As variáveis de configuração existiam (brightness-level-on-ac, brightness-step-count), mas o applet não conseguia aplicar os valores no dispositivo.

4. Utilitários auxiliares ausentes: Ferramentas de controle de brilho como brightnessctl ou light não constavam instaladas por padrão.

A solução definitiva#

A resolução exigiu duas ações complementares, baseadas nas diretrizes de configuração de backlight da ArchWiki:

Método A: Regra clássica atribuída ao grupo video#

Criei uma regra no udev para conceder automaticamente permissão de escrita para o grupo video sempre que o subsistema de backlight registrar a interface:

sudo bash -c 'cat > /etc/udev/rules.d/90-backlight.rules << "EOF"
ACTION=="add", SUBSYSTEM=="backlight", RUN+="/bin/chgrp video /sys/class/backlight/%k/brightness", RUN+="/bin/chmod g+w /sys/class/backlight/%k/brightness"
EOF'

sudo udevadm control --reload-rules && sudo udevadm trigger

Certifique-se também de que o seu usuário local faz parte do grupo video:

sudo usermod -aG video $USER

Método B: Alternativa moderna com systemd uaccess (sem grupo manual)#

Se você prefere o gerenciamento dinâmico de assentos do systemd (logind), pode utilizar a tag uaccess, que concede permissão ACL diretamente ao usuário da sessão gráfica ativa:

sudo bash -c 'cat > /etc/udev/rules.d/90-backlight-uaccess.rules << "EOF"
ACTION=="add", SUBSYSTEM=="backlight", TAG+="uaccess"
EOF'
sudo udevadm control --reload-rules && sudo udevadm trigger

Instalação e mapeamento do brightnessctl no XFCE4#

Instalei o pacote leve de controle:

sudo pacman -S brightnessctl

Com ele, o controle de iluminação pode ser operado diretamente pelo terminal:

brightnessctl set 50%    # Ajusta para 50%
brightnessctl set +10%   # Incrementa 10%
brightnessctl set 10%-   # Reduz 10%

Para integrar aos botões de atalho do teclado do notebook no XFCE4 sem depender do applet travado, adicionei atalhos customizados no subsistema xfconf:

# Mapear tecla de aumentar brilho (XF86MonBrightnessUp)
xfconf-query -c xfce4-keyboard-shortcuts -p "/commands/custom/XF86MonBrightnessUp" -n -t string -s "brightnessctl set +5%"

# Mapear tecla de diminuir brilho (XF86MonBrightnessDown)
xfconf-query -c xfce4-keyboard-shortcuts -p "/commands/custom/XF86MonBrightnessDown" -n -t string -s "brightnessctl set 5%-"

Por que essa falha acontece em notebooks com NVIDIA#

No CachyOS em notebooks com essa arquitetura, o módulo nvidia_wmi_ec_backlight instancia o dispositivo sob o subsistema de firmware do Embedded Controller (EC).

O kernel Linux classifica dispositivos de brilho em três níveis de prioridade em /sys/class/backlight/<dispositivo>/type:

1. firmware (prioridade máxima, ex.: nvidia_wmi_ec_backlight)
2. platform
3. raw (prioridade baixa, ex.: intel_backlight, amdgpu_bl0)

Como os compositores e gerenciadores gráficos priorizam o nó de firmware, o XFCE tenta operar o driver da NVIDIA em vez do driver integrado da Intel ou AMD. Como esse nó nasce atribuído a root:root, a interface falha silenciosamente. A regra udev soluciona isso de modo persistente entre reinicializações.

Checklist pós-instalação para notebooks#

Para quem está estruturando um setup semelhante, resumi a sequência que adotei:

1. Validação básica: conferir integridade do kernel, memória RAM e armazenamento.
2. Rede local: criar o arquivo /etc/samba/smb.conf mínimo com protocolo seguro SMB2_02/SMB3 e configurar permissões no servidor.
3. Placa gráfica e economia: auditar módulos via nvidia-smi, configurar o supergfxctl e testar prime-run.
4. Brilho da tela: aplicar regra udev em /etc/udev/rules.d/90-backlight.rules, instalar o brightnessctl e mapear teclas no xfce4-keyboard-shortcuts.
5. Reiniciar a sessão: carregar os novos grupos de usuário e confirmar a operação dos atalhos.

O que fica de experiência pós-instalação#

O CachyOS entrega uma base Arch ágil com otimizações de compilação perceptíveis no uso diário. Como em qualquer distribuição rolling release, notebooks com gráficos dedicados demandam pequenos ajustes após a instalação.

O problema de controle de iluminação no XFCE4 com o driver aberto da NVIDIA é silencioso, pois não emite alertas visíveis de erro, limitando-se a travar os comandos por falta de permissão de escrita. Com a regra udev correta e o brightnessctl, o sistema atinge estabilidade completa de hardware.

Perguntas frequentes sobre CachyOS em notebooks com NVIDIA e XFCE4#

Por que o uso de client min protocol = NT1 no Samba é desaconselhado em redes modernas?#

O protocolo NT1 é a nomenclatura interna do Samba para o SMBv1. Ele foi desativado por padrão desde o Samba 4.11 devido a graves vulnerabilidades de segurança exploradas por ransomwares e ataques man-in-the-middle. Em redes modernas locais com Linux ou Windows contemporâneos, utilize sempre client min protocol = SMB2_02 ou SMB3.

Qual a vantagem da regra udev com TAG+="uaccess" frente ao grupo video?#

A regra clássica com chgrp video exige que o usuário pertença estaticamente ao grupo video e requer logout/login para surtir efeito. A regra com TAG+="uaccess" integra-se ao systemd-logind: o kernel concede permissões ACL dinâmicas diretamente ao usuário ativo no assento físico local (seat0), sendo a abordagem recomendada pelas distribuições Linux modernas.

Como o CachyOS economiza bateria em notebooks com gráficos híbridos NVIDIA?#

O CachyOS fornece o daemon supergfxctl. No modo Integrated, ele desliga eletricamente a GPU dedicada através de estados de economia PCIe D3cold, evitando o consumo ocioso de 8 a 15 watts. No modo Hybrid, a dGPU dorme automaticamente até ser invocada por comandos com o prefixo prime-run.

O que fazer se o valor no sysfs alterar mas o brilho físico da tela não mudar?#

Esse comportamento ocorre quando o hardware possui múltiplos controladores de tela (por exemplo, amdgpu_bl0 e nvidia_wmi_ec_backlight), mas o painel interno está fisicamente conectado à GPU integrada. Se o driver da NVIDIA não controlar fisicamente o barramento PWM, adicione o parâmetro de kernel acpi_backlight=native ou desative o módulo com blacklist nvidia_wmi_ec_backlight em /etc/modprobe.d/blacklist.conf.

Como vincular os atalhos de brilho no XFCE4 sem usar a interface gráfica?#

Utilize a ferramenta de terminal xfconf-query para cadastrar as chaves no canal xfce4-keyboard-shortcuts. Mapeie /commands/custom/XF86MonBrightnessUp para brightnessctl set +5% e /commands/custom/XF86MonBrightnessDown para brightnessctl set 5%-.

Veja também

Inteligência Artificial Do Docker ao bare-metal: a odisseia para rodar modelos de difusão na NVIDIA RTX série 50 (Blackwell) no Arch Linux

Infraestrutura Rodando Android no Linux com Waydroid em notebook híbrido: gráficos integrados e jogos ARM

Infraestrutura Quando a otimização de bateria quebra o display manager: recuperando tela preta no CachyOS com GPU híbrida

Este post está licenciado sob CC BY-NC.