In questo articolo Indice dei contenuti 2 sezioni
Chi usa HDMI 2.1 su Linux conosce bene la frustrazione di avere hardware capace sulla carta e un sistema operativo che non riesce a sfruttarlo davvero. Per anni la situazione è rimasta paradossale. Un notebook con GPU Intel recente dichiarava il supporto a HDMI 2.1 con FRL, ovvero il Fixed Rate Link, la modalità di trasmissione ad alta velocità che permette di andare oltre i vecchi limiti di banda. Un televisore 4K accettava tranquillamente i 120 Hz, il cavo era quello giusto. Eppure, collegando tutto sotto Linux, certe configurazioni restavano inchiodate ai limiti del vecchio collegamento TMDS.
Vale la pena capire di cosa si parla. TMDS, sigla che sta per Transition Minimized Differential Signaling, è il metodo usato dalle versioni HDMI fino alla 2.0 per trasportare audio e video digitali. I dati viaggiano su tre canali differenziali mentre un quarto porta il segnale di clock. Con HDMI 2.0 questo sistema arriva a una banda lorda massima di 18 Gbps, abbastanza per il 4K a 60 Hz e poco altro. HDMI 2.1 cambia le carte in tavola introducendo appunto FRL, che manda in pensione il vecchio schema e spinge fino a 48 Gbps. Ecco perché diventa possibile il 4K a 120 Hz con molti meno compromessi.
Ora Intel prova a colmare il divario con una raffica di 44 patch destinate al driver grafico del kernel, pensate per Meteor Lake e le piattaforme successive.
Intel porta FRL dentro il driver grafico Linux
Le modifiche proposte dagli sviluppatori Intel sono in questo momento all’esame dei maintainer del kernel Linux e, con ogni probabilità, servirà tempo prima che entrino in modo stabile. È la prassi dello sviluppo DRM/KMS. Interventi così invasivi sul sottosistema display raramente vengono accettati tutti in un colpo solo senza passare da varie revisioni.
Detto questo, il risultato raggiunto è già notevole. Intel dichiara di aver testato il codice su Panther Lake e Meteor Lake, e sul primo funzionano modalità come 3840 x 2160 a 120 Hz. Non è ancora una garanzia per qualsiasi notebook e qualsiasi monitor, perché contano il PHY effettivamente cablato dal produttore, il firmware, la porta usata, l’EDID del display e ovviamente la qualità del collegamento. L’EDID, per chi non mastica la terminologia, è quel piccolo blocco di informazioni che monitor o TV comunica alla GPU per dichiarare le proprie capacità, dalle risoluzioni alle frequenze di aggiornamento fino a HDR e formati colore.
Usare FRL non significa semplicemente alzare una frequenza. Sorgente e display devono mettersi d’accordo su una modalità comune e verificare che il collegamento regga i dati con un margine di errore accettabile. Il processo si chiama link training.
La grande assente nella prima versione delle patch riguarda il Display Stream Compression, abbreviato DSC. Parliamo di una compressione video pensata apposta per le interfacce display, capace di ridurre parecchio la quantità di dati da trasmettere mantenendo una qualità visiva molto alta. Anche senza DSC, comunque, FRL amplia già di molto le combinazioni disponibili. Una modalità 4K a 120 Hz può rientrare nella capacità del collegamento in diverse configurazioni senza compressione. Salendo verso l’8K o refresh rate elevatissimi il fabbisogno cresce in fretta, e lì DSC diventa spesso indispensabile.
Un progetto nato nel 2022 e poi svanito nel nulla
La parte curiosa riguarda i tempi. Patch Intel dedicate a HDMI 2.1 nativo per Meteor Lake giravano già nel 2022, prima ancora che i processori Core Ultra arrivassero sul mercato. Dopo quelle proposte lo sviluppo pubblico si è praticamente fermato.
La coincidenza con le difficoltà incontrate da altri produttori ha alimentato molte discussioni sul rapporto tra le specifiche HDMI e i driver open source. Il caso più conosciuto riguarda AMD. Nel 2024 gli sviluppatori spiegarono apertamente di non poter pubblicare la propria implementazione HDMI 2.1 rispettando le condizioni imposte dall’HDMI Forum, pur avendo lavorato sul supporto.
Non esiste alcuna dichiarazione Intel che colleghi in modo diretto l’interruzione del progetto del 2022 alle stesse ragioni. Il fatto che prima AMD con AMDGPU e ora Intel abbiano ripreso il lavoro su FRL lascia intendere però che qualcosa, sul piano tecnico oppure su quello delle condizioni che permettono di pubblicare il codice, si è evidentemente sbloccato.
