1 28/10/2026 12 min

Su Ubuntu la luminosità dello schermo si può cambiare da terminale in più modi, ma non tutti sono equivalenti. La scelta dipende da come il sistema espone il pannello, dal tipo di sessione grafica in uso e da quanto vuoi che la modifica sia temporanea o persistente. In pratica, il punto non è solo “abbassare la luminosità”, ma farlo nel modo giusto per evitare di ritrovarsi con un comando che funziona oggi e domani no, oppure che altera solo la sessione corrente senza toccare il controllo reale del display.

Su molti portatili Ubuntu gestisce la luminosità tramite i classici controlli del kernel esposti in /sys/class/backlight/. In altri casi, soprattutto con certe GPU o configurazioni ibride, conviene agire a livello X11 con xrandr. In ambienti Wayland le possibilità cambiano, perché alcuni strumenti storici non hanno lo stesso effetto. Per questo vale la pena distinguere subito tra i metodi disponibili, così eviti tentativi casuali e scegli la strada più affidabile per il tuo sistema.

Capire quale controllo di luminosità hai davvero disponibile

Prima di toccare qualcosa, conviene verificare quali interfacce espone il sistema. Questo ti dice se la luminosità è gestibile a livello hardware, se stai lavorando in una sessione X11, oppure se il pannello non compare affatto tra i dispositivi backlight. È il passaggio più utile per evitare di scegliere uno strumento che poi non ha effetto.

Il controllo più rapido è guardare i dispositivi disponibili in /sys/class/backlight/:

ls /sys/class/backlight/

Se il comando restituisce uno o più nomi, ad esempio intel_backlight, amdgpu_bl0 o simili, sei nella situazione migliore: il kernel espone un canale diretto per regolare la luminosità. Se la directory è vuota, non significa per forza che non puoi cambiare la luminosità, ma che dovrai probabilmente passare da un altro livello, spesso xrandr o un controllo specifico del desktop environment.

Puoi anche leggere i valori attuali e massimi per capire la scala usata dal sistema:

cat /sys/class/backlight/*/brightness
cat /sys/class/backlight/*/max_brightness

Se vedi numeri, il driver sta già esponendo un controllo reale. Il valore di brightness va confrontato con max_brightness: in genere non si ragiona in percentuale, ma in valori assoluti della scala del driver. Questo è importante perché alcuni tool lavorano in percentuale, altri in valori grezzi.

Metodo più affidabile su molti portatili: brightnessctl

Se il dispositivo compare in /sys/class/backlight/, brightnessctl è spesso la scelta più pulita. Non dipende dall’interfaccia grafica e usa il meccanismo standard del kernel. È comodo sia per un abbassamento temporaneo sia per legarlo a scorciatoie o script.

Su Ubuntu puoi installarlo così:

sudo apt update
sudo apt install brightnessctl

Per vedere i dispositivi rilevati e il livello corrente:

brightnessctl info

Un output tipico mostra il device, il valore corrente e la percentuale. Se invece compare un errore tipo “No suitable device found”, significa che il tool non vede un backlight utilizzabile o che l’utente non ha i permessi necessari.

Per diminuire la luminosità del 10%:

brightnessctl set 10%-

Per aumentarla del 10%:

brightnessctl set +10%

Se vuoi impostare un valore preciso, ad esempio il 40%:

brightnessctl set 40%

Questo metodo è quello che in genere consiglio per primo sui notebook, perché agisce sul controllo nativo del sistema e tende a comportarsi bene anche dopo riavvio della sessione grafica. Non è però universale: su alcuni sistemi il dispositivo giusto non è quello predefinito e va specificato esplicitamente.

Per elencare i dispositivi disponibili e scegliere quello corretto:

brightnessctl --list

Se ce ne sono più di uno, puoi indicare il device con -d. Ad esempio:

brightnessctl -d intel_backlight set 30%

Qui il punto non è tanto il nome preciso del dispositivo, quanto il fatto che il tool stia parlando con il driver corretto. Se sbagli device, il comando può apparire riuscito ma non cambiare nulla di visibile.

Regolare la luminosità con xrandr in sessione X11

Se stai usando X11 e il controllo backlight non è disponibile o non funziona come previsto, xrandr può essere una soluzione pratica. Attenzione però: in questo caso non sempre stai modificando la luminosità reale del pannello, ma spesso stai applicando una correzione gamma o un fattore di resa visiva. Il risultato può sembrare simile, ma il comportamento non è identico al controllo hardware.

Per prima cosa individua il nome dell’output collegato, ad esempio eDP-1, HDMI-1 o simili:

xrandr --query

Cerca la riga con lo schermo interno attivo. L’output con una risoluzione e la dicitura connected è quello su cui puoi intervenire. Per abbassare la luminosità percepita, puoi usare il parametro --brightness:

xrandr --output eDP-1 --brightness 0.8

Il valore di default è 1.0. Scendere a 0.8 riduce la luminosità, mentre 1.2 la aumenta leggermente. In pratica è un moltiplicatore, non una percentuale nativa del pannello. Se abbassi troppo, il contenuto può perdere contrasto; se alzi troppo, puoi introdurre un’immagine slavata. È utile per correzioni rapide, meno per una gestione “pulita” del display.

Se vuoi verificare subito l’effetto, esegui il comando e osserva il cambiamento sullo schermo. Se non succede nulla, le cause più comuni sono due: sei in Wayland, oppure l’output indicato non è quello giusto. In quel caso riparti da xrandr --query e controlla il nome esatto del display.

Un aspetto importante: xrandr --brightness di norma vale per la sessione corrente. Se chiudi la sessione o riavvii, il valore torna al comportamento standard. Questo è comodo per test, meno per una configurazione persistente.

Wayland: perché alcuni comandi non fanno effetto

Su Ubuntu moderno è frequente trovarsi in Wayland, soprattutto con GNOME. Qui molti strumenti storici pensati per X11 non si comportano allo stesso modo. Se xrandr non cambia nulla, non è per forza un bug: può semplicemente essere il limite del protocollo o della sessione in uso.

Per capire se sei in Wayland o X11, puoi controllare la variabile di sessione:

echo $XDG_SESSION_TYPE

Se ottieni wayland, orientati preferibilmente su strumenti che lavorano con il backlight del kernel, quindi brightnessctl o l’equivalente via /sys/class/backlight/. Se ottieni x11, hai più libertà con xrandr. In entrambi i casi, però, il metodo più robusto resta quello che usa il controllo nativo del pannello quando disponibile.

Modificare la luminosità scrivendo in /sys/class/backlight

Quando il device è esposto in /sys/class/backlight/, puoi intervenire direttamente sui file brightness e max_brightness. Questo è utile per capire il funzionamento interno o per uno script minimale. Va però usato con più attenzione, perché scrivere direttamente lì richiede privilegi adeguati e non hai la comodità di un wrapper che gestisce percentuali e limiti.

Prima leggi il valore massimo:

cat /sys/class/backlight/intel_backlight/max_brightness

Poi imposta un valore intermedio. Per esempio, se il massimo è 1000 e vuoi stare circa al 30%, puoi scrivere 300:

echo 300 | sudo tee /sys/class/backlight/intel_backlight/brightness

Qui il comando usa sudo tee perché la shell non può scrivere direttamente nel file con privilegi elevati usando il solo redirect. Se sbagli il numero, non rompi il sistema, ma puoi ottenere uno schermo troppo scuro o troppo chiaro. Il rollback è semplice: riscrivi il valore corretto o usa brightnessctl per tornare a un livello confortevole.

Questo approccio è utile anche per capire se il driver accetta davvero la modifica. Se il file cambia ma lo schermo no, il problema è più a valle: può esserci un layer grafico che sovrascrive il valore, oppure un driver che espone un controllo non pienamente efficace sul pannello.

Rendere la luminosità persistente al login

Se vuoi che il livello venga applicato a ogni accesso, hai varie strade. La più semplice è usare gli strumenti del desktop environment, ma se vuoi restare su terminale puoi creare uno script di avvio. La scelta migliore dipende da quanto vuoi che la soluzione sia leggera e indipendente dal desktop.

Un approccio pratico è creare uno script nella tua home, ad esempio ~/bin/set-brightness.sh, con un contenuto simile:

#!/bin/sh
brightnessctl set 35%

Rendi eseguibile lo script:

chmod +x ~/bin/set-brightness.sh

Poi collegalo all’avvio della sessione grafica, ad esempio tramite “Applicazioni d’avvio” se usi GNOME, oppure con il meccanismo equivalente del tuo ambiente desktop. In alternativa puoi usare un servizio utente systemd, ma ha senso solo se sai già come vuoi orchestrare l’avvio e la sessione. Il vantaggio dello script è che puoi modificarlo rapidamente senza toccare il sistema.

Se preferisci un servizio utente, il file potrebbe essere qualcosa come ~/.config/systemd/user/brightness.service. La logica però resta la stessa: eseguire un comando semplice dopo il login. Il vantaggio è la ripetibilità; il limite è che devi verificare bene il momento in cui il display è effettivamente disponibile. Se parti troppo presto, il comando può fallire perché il device non è ancora pronto.

Permessi, gruppi e casi in cui il comando fallisce

Se brightnessctl o la scrittura diretta in /sys/class/backlight/ falliscono con errori di permesso, il problema non è la luminosità in sé ma l’accesso al dispositivo. In genere il sistema usa regole udev o gruppi specifici per consentire agli utenti di modificare il backlight senza diventare root a ogni comando. Se non funziona, vale la pena controllare i log e le regole installate dal sistema.

Un primo controllo utile è verificare la presenza di regole relative al backlight in /usr/lib/udev/rules.d/ o /etc/udev/rules.d/. Non è sempre necessario toccarle, ma sapere che esistono ti aiuta a capire perché un utente normale può o non può operare sul device. Se stai intervenendo su un laptop aziendale o su una macchina con policy particolari, è anche possibile che la gestione sia volutamente limitata.

Se vuoi un controllo rapido del contesto, puoi guardare i messaggi del kernel relativi al backlight:

dmesg | grep -i backlight

Non sempre il log è risolutivo, ma può dirti quale driver è stato caricato e se ci sono anomalie nel rilevamento del pannello. Se il sistema vede un device ma il controllo non è coerente, il log è spesso il primo posto da interrogare.

Quale metodo scegliere in pratica

Se il tuo obiettivo è cambiare la luminosità in modo affidabile su Ubuntu, la priorità è questa: prima brightnessctl o il controllo diretto in /sys/class/backlight/, poi xrandr se sei in X11 e ti basta una regolazione visiva. Il metodo via sysfs è quello più vicino all’hardware e di solito è quello da preferire su portatili moderni. xrandr resta utile quando il controllo nativo non è disponibile o quando ti serve una soluzione immediata senza toccare il sottosistema backlight.

In termini operativi, il criterio è semplice: se vuoi una variazione reale del pannello, vai sul backlight; se vuoi un aggiustamento rapido della resa visiva, usa xrandr. Se il tuo ambiente è Wayland e xrandr non produce effetti, non perdere tempo a insistere su quel ramo: torna al controllo del kernel o agli strumenti supportati dal desktop.

Una buona abitudine è annotare il dispositivo usato e il valore applicato, soprattutto se lavori su più macchine. Sapere che un certo laptop usa intel_backlight e che un certo livello corrisponde a un comfort visivo preciso ti evita di rifare ogni volta il lavoro di taratura. È un dettaglio semplice, ma in pratica fa risparmiare tempo e riduce gli errori quando devi replicare la configurazione su altri sistemi.

Checklist rapida per il debug

Se il comando non funziona come previsto, questa sequenza copre i casi più comuni:

  1. Controlla la sessione con echo $XDG_SESSION_TYPE: se sei su wayland, non aspettarti che xrandr si comporti come in X11.
  2. Verifica i device con ls /sys/class/backlight/: se la directory è vuota, il controllo nativo non è esposto nel modo atteso.
  3. Leggi i valori correnti con cat /sys/class/backlight/*/brightness e cat /sys/class/backlight/*/max_brightness: se i numeri esistono, hai un canale reale.
  4. Usa brightnessctl info per capire se il tool vede il device giusto.
  5. Se resti su xrandr, conferma l’output corretto con xrandr --query e applica un valore moderato, ad esempio 0.8, per testare l’effetto senza estremi.

Questa sequenza evita il classico errore di cambiare parametro nel posto sbagliato. Il primo obiettivo non è “provare tutto”, ma identificare il layer su cui il sistema sta davvero accettando la modifica.

Un esempio pratico completo

Supponiamo di avere un notebook Ubuntu con device intel_backlight. Il controllo iniziale mostra che il massimo è 9375 e il valore corrente è 5000. Se vuoi abbassare la luminosità a circa un terzo, puoi impostare un valore vicino a 3100:

cat /sys/class/backlight/intel_backlight/max_brightness
cat /sys/class/backlight/intel_backlight/brightness
echo 3100 | sudo tee /sys/class/backlight/intel_backlight/brightness

Dopo il comando, rileggi brightness per confermare che il valore sia cambiato. Se lo schermo si è effettivamente abbassato, hai una prova che il controllo è funzionante. Se invece il valore cambia ma la luminosità percepita resta uguale, c’è probabilmente un altro livello che sovrascrive il pannello o una gestione specifica del firmware.

Se stessi lavorando in X11 e volessi solo una regolazione visiva temporanea, il test equivalente sarebbe qualcosa come:

xrandr --query
xrandr --output eDP-1 --brightness 0.75

Anche qui l’effetto dovrebbe essere immediato. Se non lo è, torna alla diagnosi di sessione e al nome dell’output. La differenza tra un intervento che funziona e uno che sembra casuale sta quasi sempre in questi due dettagli.

Quando conviene evitare soluzioni “creative”

Ci sono contesti in cui è meglio non improvvisare con script strani o hack che scrivono valori a caso. Per esempio, su macchine condivise, ambienti con policy di sicurezza o notebook con driver particolari, la strada più solida resta quella standard: tool supportati, device espliciti, valori controllati. Se devi integrare la regolazione in un flusso più ampio, meglio partire da un comando semplice e osservabile piuttosto che da una catena complessa difficile da diagnosticare.

In sintesi operativa: usa brightnessctl quando vuoi un controllo pulito e vicino all’hardware, usa xrandr quando ti basta un aggiustamento visivo in X11, e verifica sempre quale sessione e quale device stai realmente toccando. È la differenza tra un workaround che sembra funzionare e una configurazione che sai riprodurre e mantenere nel tempo.