ArcadeItalia.NET

Salve, dopo la recente notizia che anche Ubuntu ha deciso di offrire Wayland di default sulla release 21.04, che arriva dopo tante altre distro come ad esempio Fedora, mi sono un pò documentato ed ho visto che, come c'era da aspettarselo, Wayland sulla carta è un grosso miglioramento, anche per il retrogaming, in particolare per alcune configurazioni.

Ad esempio io uso 2 monitor, come primario un LCD standard 60hz e come secondario un CRT PAL/NTSC; questo per avere un'unica macchina da gaming, retro ed attuale; ho scoperto, grazie ad un malfunzionamento del v-sync sui giochi Amiga e parlando con lo sviluppatore di FS-UAE che c'era un problema nel refresh rate ed infatti, in giro è pieno di post di persone che con una configurazione multi monitor non riescono ad avere 2 frequenze di aggiornamento verticale differenti, una per ciascun monitor, come sarebbe corretto che fosse.
Il problema nella maggior parte dei casi è Xorg.
Wayland risolve questo problema, oltre a tanti altri per cui, dato l'avanzare lento ma inesorabile di questa tecnologia ho deciso di "provare" a spostarmi su Wayland con il retrogaming.

Se ci fosse qualcuno tra voi disposto a fare questo percorso insieme sarebbe fantastico...
Attendo fiducioso

@eldiau è il nostro referente Linux
Anche se latita

Come al solito mi vado ad infilare nei problemi più assurdi....
Partiamo dall'inizio e molto brevemente:
Voglio passare a Wayland perché con xorg non posso avere 2 (o più) monitor ciascuno con un refresh rate differente, per cui ad esempio non posso avere il mio schermo principale LCD a 60Hz o più e lanciare i retro-games sul CRT a refresh rate originale.
Scopro che Xrandr non funziona con Wayland per cui non è possibile cambiare risoluzione al volo e, cosa ancora più grave non è possibile impostare modalità video differente.
Wayland, come pure Xorg, per ora prende le risoluzioni che gli vengono passate dal Kernel, questo le acquisisce facendo delle query in fase di boot ai vari monitor che risultano connessi in quel momento.
Ciascun monitor gli passa un file .bin in cui sono specificate le modalità video possibili, questo file si chiama "EDID" e viene inserito nei device dai produttori, si avranno quindi situazioni in cui:

• un monitor, pur fisicamente potendo supportare caratteristiche maggiori (monitor overclocking) queste non potranno essere impostate

• l'hardware darà degli EDID formattati male o comunque non funzionanti e quindi non sarà utilizzabile a dovere

• nel caso del retrogaming su TV CRT che non restituiscono alcun EDID non saranno utilizzabili

Infatti se non riceve risposta il kernel imposta per quel monitor delle modalità video "safe" che dovrebbero andare bene genericamente ma che ovviamente non vanno bene per noi nostalgici dei pixel.
Cosa fare?
Allo stato attuale bisogna generare un file EDID con le diverse modalità video supportate dal monitor in questione e passarlo come parametro di avvio al kernel, di seguito alcuni link di riferimento:
https://qastack.it/ubuntu/973499/waylan ... resolution
https://wiki.archlinux.org/index.php/ke ... de_setting

Questo processo è valido, come ho detto sopra per Wayland come per Xorg ed ha una sua logica; dal momento che ora i driver video dialogano direttamente con il kernel, non si permette alle applicazioni di impostare risoluzioni non permesse dai produttori dei device, inoltre le modalità video impostate in Kernel Mode Setting funzioneranno anche al di fuori dei Desktop Environment, per cui ad esempio un emulatore (diciamo ad esempio retroarch) potrà funzionare bene lanciandolo semplicemente da TTY senza bisogno di un ambiente Desktop che come sappiamo appesantisce parecchio un sistema; io però voglio un desktop environment perché voglio avere una macchina da gaming unica per vecchi giochi ed attuali, voglio ad esempio lanciare sul mio monitor LCD l'emulatore GameBoy con lo stupendo shader che fa sembrare la modalità video del tutto simile a quella originale ed invece lanciare la GUI di FS-UAE per godermi i dati e gli screenshot di openretro e mandare i suoi giochi sul CRT, e così anche per Dolphin...
Tutto questo come possiamo capire ha dei limiti che dobbiamo in qualche modo superare.

Esiste un progetto: https://github.com/akatrevorjay/edid-generator che permette di trasformare una modeline in un file EDID; certo è ben lontano dal poter creare un EDID completo con tutte le modalità video occorrenti, inoltre ha dei bug ma è un inizio.
Sarebbe fantastico avere già pronto un tale file perché questo funzionerebbe su ogni sistema operativo su ogni emulatore.

Purtroppo le mie conoscenze si fermano qua per cui se ci fosse tra voi qualche Superman cit. (tipo @eldiau come suggerito da @Tox Nox Fox ) gli chiederei di aiutarmi in questo percorso; anche perché credo che il passaggio a Wayland sia inevitabile oramai, perfino Ubuntu da aprile uscirà di default con Wayland...

Nota a margine, credo che si possa ottenere una configurazione dual monitor/dual refresh rate anche in Xorg settando i due monitor con 2 xscreen diversi, senza xinerama, in modo da avere :0.0 e :0.1, questa configurazione dovrebbe chiamarsi "dualhead" o "zaphod" come meglio spiegato qui https://wiki.archlinux.org/index.php/multihead ma non ho provato e se qualcuno avesse la buona volontà di provare sarebbe fantastico

Seconda nota a margine, Groovyarcade mi sembra che già funzioni come descritto sopra e cioè impostando le modalità video a l livello Kernel e senza DE per cui si potrebbe dare uno sguardo per capirne di più...

Groovyarcade è una distro Linux
Può servirti ?

Tox Nox Fox ha scritto: ↑14/02/2021, 15:45 Groovyarcade è una distro Linux
Può servirti ?

Sarebbe bello poter parlare con uno sviluppatore della distro

Lo sviluppatore sta qui http://forum.arcadecontrols.com/index.p ... ,52.0.html , c'è anche un thread dedicato su groovyarcade

Si si ci ho parlato, mi ha tolto un sacco di dubbi che avevo, e non parlo solo di GroovyArcade ma in generale della forzatura 15khz e... cavolo se ne sa....
Devo dire che hanno formato un gruppetto su Discord davvero competente in materia.
Grazie

Si sono tutti molto competenti e disponibili, io non ho mai usato groovy per un monitor crt (pc + uscita per lo meno su Tv consumer crt è un progetto che spero di fare quest'anno), ma il suo groovy è ottimo anche per gli LCD , sempre meglio usare groovy rispetto al mame tradizionale e tutti i problemi che ho sempre avuto con i vari arcade64, mameuifx etc etc con groovy li ho risolti ottenendo la migliore soluzione possibile in termini di input lag e refresh rate.