Resolvendo Aceleração de Hardware no Chrome com Nvidia no Linux (Artix/Arch)
Prologo - Por que Artix
A parte 1 - Inicio da odisseia
A parte 2 - Tentando se manter no terminal
A parte 3 - Deixando mais palatável
A parte 4 - Algumas explicações de alguns problemas
A parte 5 - Saindo do Nautilus entrando no Thunar
A NVIDIA GeForce GT 730 pertence à família Kepler (chipset NVC1), cujo suporte pelo driver proprietário da NVIDIA foi encerrado na versão 390.157, lançada em 2022. Em kernels modernos (6.x), esse driver legado apresenta incompatibilidades crescentes com o subsistema DRM e com compositores gráficos contemporâneos.
Fica a pergunta "Mas Demostenes não é mais facil simplesmente trocar a placa de video?" .
Sim mas que pessoa merda seria eu se não resolvesse isso antes de trocar a placa de video.
Fica a pergunta "Mas Demostenes não é mais facil simplesmente trocar a placa de video?" .
Sim mas que pessoa merda seria eu se não resolvesse isso antes de trocar a placa de video.
Este artigo documenta dois episódios distintos de diagnóstico nesse hardware: primeiro, travamentos esporádicos do ambiente gráfico atribuídos inicialmente ao compositor, e segundo, falha de aceleração de hardware em navegadores Chromium. Ambos revelaram um problema de raiz comum: o driver gráfico efetivamente em uso pelo Xorg não era o esperado.
Parte 1 - Travamentos Esporádicos do Ambiente Gráfico
Sintoma
O ambiente gráfico travava periodicamente, com intervalo aproximado de 16 horas entre ocorrências. Durante o travamento, o ponteiro do mouse permanecia responsivo, mas todas as janelas ficavam congeladas. Esse comportamento é característico de falha no compositor, o servidor X e o kernel continuam operando normalmente, mas o processo responsável pela composição das janelas para em um estado inconsistente.
Metodologia de Diagnóstico
A investigação seguiu uma ordem de eliminação: hardware, kernel, driver e compositor.
Verificação de hardware e temperatura:
bash
sudo dmesg | grep -iE "error|hang|freeze|nvidia|gpu" | tail -50 sensors nvidia-smi -q -d TEMPERATURE sudo smartctl -a /dev/sda
CPU entre 31–37°C e GPU a 55°C, dentro dos limites normais de operação. O disco SSD PNY 1TB reportou 18 erros de escrita e 3 de leitura no BTRFS, investigados a seguir.
Verificação do sistema de arquivos BTRFS:
bash
sudo btrfs device stats /dev/sda2 sudo btrfs scrub start /dev/sda2 sudo btrfs scrub status /dev/sda2
O scrub não encontrou erros de corrupção. Os erros de I/O registrados eram antigos e não apresentavam progressão, descartando o disco como causa dos travamentos. Recomenda-se agendar scrubs periódicos via cron:
bash
# Executar todo domingo às 3h 0 3 * * 0 /usr/bin/btrfs scrub start /dev/sda2
Análise do log do Xorg:
bash
cat /var/log/Xorg.0.log | grep -iE "nvidia|nouveau|driver" | head -20
Aqui foi encontrada a primeira anomalia significativa:
(==) Matched nouveau as autoconfigured driver 0 (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so (II) NOUVEAU driver for NVIDIA chipset families
O Xorg estava carregando o driver nouveau (código aberto) por autoconfiguração, ignorando completamente o driver proprietário nvidia-390xx instalado no sistema. A causa: o pacote nvidia-390xx-utils adiciona automaticamente um blacklist do nouveau em /usr/lib/modprobe.d/, impedindo seu carregamento no kernel, mas não configura o Xorg para usar o driver proprietário de forma explícita. Sem um xorg.conf com a diretiva correta no local lido pelo Xorg (/usr/share/X11/xorg.conf.d/), o servidor X simplesmente escolhia o primeiro driver disponível na autodetecção.
Identificação do compositor:
bash
ps aux | grep picom
O sistema utilizava o picom-ftlabs-git, um fork experimental do picom com suporte a animações de janela. Rodando sobre nouveau sem firmware de aceleração 3D, o backend GLX desse compositor operava sobre llvmpipe, renderização por software, acumulando estado ao longo de horas até atingir um deadlock.
Causa Raiz
A falha resultou da combinação de três fatores independentes que se agravavam mutuamente:
- Xorg usando nouveau por autoconfiguração em vez do driver proprietário
- Nouveau sem firmware NVC1, forçando o GLX a operar via llvmpipe (CPU)
- picom-ftlabs com animações experimentais acumulando recursos sob carga GLX degradada
O YouTube atuava como gatilho: ao abrir um contexto GL pesado no processo de GPU do Brave, esgotava os recursos que o picom já consumia de forma ineficiente, precipitando o travamento.
Solução
A decisão foi migrar definitivamente para o driver nouveau com suporte completo a aceleração 3D, removendo o driver proprietário legado.
Passo 1, Remover o driver nvidia-390xx:
bash
sudo pacman -Rns nvidia-390xx-dkms nvidia-390xx-utils nvidia-390xx-settings sudo mkinitcpio -P sudo reboot
A remoção do nvidia-390xx-utils nao elimina o blacklist automático do nouveau, permitindo que o kernel o carregue normalmente.
Atenção: Após a remoção, apagar qualquer xorg.conf gerado pelo nvidia-xconfig, pois ele contém diretivas incompatíveis com o nouveau:
bashsudo rm /etc/X11/xorg.conf
Passo 2 - Instalar o firmware de aceleração 3D:
bash
sudo pacman -S linux-firmware-nvidia
Este passo é crítico e frequentemente negligenciado. Sem o firmware NVC1, o nouveau opera em modo degradado e delega toda renderização OpenGL ao llvmpipe, um backend de software que não utiliza a GPU. A consequência é desempenho muito inferior e instabilidade em compositores com backend GLX.
Verificação:
bash
glxinfo | grep "OpenGL renderer" # Resultado esperado: OpenGL renderer string: NVC1
Passo 3 - Restaurar o compositor:
Com o nouveau e o firmware funcionando corretamente, o picom-ftlabs pode ser utilizado normalmente. A causa dos travamentos não era o fork em si, mas a base GLX instável sobre a qual ele operava. Com NVC1 provendo aceleração real, as animações rodam sobre GPU de verdade.
bash
yay -S picom-ftlabs-git picom -b
Configuração recomendada para o ambiente (manter use-damage = false com nouveau):
backend = "glx"; vsync = true; use-damage = false;
Parte 2 - Falha de Aceleração de Hardware em Navegadores Chromium
Esta seção documenta um episódio anterior, quando o setup utilizava o driver proprietário nvidia-390xx.
Sintoma
O Google Meet exibia mensagem solicitando ativação de aceleração de hardware, embora a opção já estivesse habilitada nas configurações do navegador. Fundos virtuais não funcionavam.
Diagnóstico
Verificar status da GPU no navegador:
Acessar chrome://gpu (ou brave://gpu). O resultado indicou:
Canvas: Software only, hardware acceleration unavailable WebGL: Software only, hardware acceleration unavailable Compositing: Software only. Hardware acceleration disabled
E na linha de comando do processo do navegador:
--disable-gpu
A flag --disable-gpu havia sido adicionada manualmente em sessão anterior como workaround para um crash, desativando toda aceleração de hardware de forma persistente.
Após remoção da flag , novo diagnóstico:
GPU0: ANGLE (Google, Vulkan 1.3.0 (SwiftShader Device (Subzero)))
O navegador passou a usar SwiftShader (renderização por CPU via Vulkan emulado), ainda sem acesso à GPU real. O log do Xorg revelou:
(EE) NVIDIA(0): Failed to initialize the GLX module dri3 extension not supported
Verificação do GLX no sistema:
bash
glxinfo | grep renderer # OpenGL renderer string: llvmpipe (LLVM 22.1.2, 256 bits)
O sistema operava com llvmpipe mesmo com o driver nvidia carregado no kernel:
bash
lsmod | grep nvidia # nvidia, nvidia_drm, nvidia_modeset, nvidia_uvm — todos presentes
Identificação do problema raiz:
O Xorg carregava a biblioteca GLX da Mesa em vez da NVIDIA:
/usr/lib/xorg/modules/extensions/libglx.so ← Mesa (incorreto) /usr/lib/nvidia/xorg/libglx.so ← NVIDIA (correto)
A causa: o xorg.conf existente continha uma seção Files vazia, que sobrescreve qualquer configuração presente em xorg.conf.d/. Sem os ModulePath corretos declarados, o Xorg carregava o GLX da Mesa por padrão.
Section "Files" EndSection ← seção vazia sobrescreve xorg.conf.d/
Solução
Declarar explicitamente os caminhos de módulo no xorg.conf:
Section "Files"
ModulePath "/usr/lib/nvidia/xorg"
ModulePath "/usr/lib/xorg/modules"
EndSectionVerificação após reiniciar o Xorg:
bash
grep -i "modulepath" /var/log/Xorg.0.log # ModulePath set to "/usr/lib/nvidia/xorg,/usr/lib/xorg/modules" glxinfo | grep renderer # OpenGL renderer string: GeForce GT 730/PCIe/SSE2
Com o GLX da NVIDIA funcionando, o navegador passou a utilizar aceleração de hardware real e o Google Meet voltou a exibir a opção de fundos virtuais.
Nota: Após essa correção, o picom com backend = "glx" passou a apresentar tela branca no i3, sintoma de conflito entre o compositor e o driver proprietário. Esse comportamento foi um dos motivadores para a migração posterior ao nouveau descrita na Parte 1.
Monitoramento da GPU com Conky (nouveau)
Com o nouveau, o nvidia-smi não está disponível. Os dados de hardware são acessíveis via sysfs:
Temperatura:
${execi 5 cat /sys/class/drm/card0/device/hwmon/hwmon0/temp1_input | awk '{printf "%.0f", $1/1000}'}°CLimitação conhecida: O nouveau não expõe informações de uso de VRAM via sysfs na GT 730 com kernel 6.19. Não há substituto direto para nvidia-smi --query-gpu=memory.used nessa configuração.
Considerações Finais
Por que abandonar o nvidia-390xx?
O driver proprietário 390.157 encerrou seu ciclo de desenvolvimento em 2022. Em kernels 6.x, ele apresenta incompatibilidades crescentes com o subsistema DRM, falhas na inicialização do GLX e conflitos com compositores modernos. Para a GT 730, o nouveau com firmware NVC1 oferece maior estabilidade no ecossistema atual, ainda que com funcionalidades reduzidas (sem suporte a CUDA, NVENC ou monitoramento via nvidia-smi).
Por que não migrar para Wayland?
O i3wm é um gerenciador de janelas X11 e não tem equivalente nativo em Wayland. A migração exigiria adotar o Sway ou o Hyprland. O suporte da GT 730 via nouveau em Wayland existe, mas a estabilidade nessa combinação específica não foi validada neste ambiente.
Diagnóstico rápido para travamentos futuros
Em caso de novo travamento com mouse livre, acessar via SSH e executar imediatamente:
bash
sudo dmesg | tail -30 cat /var/log/Xorg.0.log | grep -iE "EE|error" | tail -20 ps aux --sort=-%mem | head -10 sudo btrfs device stats /dev/sda2
Resumo do Ambiente Final
Componente | Detalhe Distribuição | Artix Linux Kernel | 6.19.11-artix1-1 Sistema de init | OpenRC Gerenciador de janelas | i3wm Compositor | picom-ftlabs-git (backend glx) GPU | NVIDIA GeForce GT 730 (NVC1 / Kepler) Driver | nouveau (nativo do kernel) + linux-firmware-nvidia Navegador | Brave (ozone-platform=x11) Servidor de display | X11 (Xorg 1.21) Sistema de arquivos | BTRFS
