Abonnement aux commentaires

S'abonner pour recevoir les commentaires suivants par email

まこと の ブログ

MaKoTo no burogu — Journal de bord…

Aller au contenu | Aller au menu | Aller à la recherche

Mame en vrai 15 kHz, le retour !

Près de 7 ans plus tard, est-il toujours possible de modifier Linux afin qu'on puisse brancher un écran cathodique, comme une TV ou un écran d'arcade, autrement appelé moniteur 15 kHz, sur un ordinateur muni d'une carte graphique ATI ?
La démarche décrite dans mon billet de l'époque pour patcher 15 kHz, puis compiler un noyaux Linux est-elle toujours valable ?

  • C'est ce que j'ai eu besoin de valider afin de pouvoir mettre à jour l'OS de ma borne et utiliser les dernières versions de mame.

Le temps passe à une vitesse folle. À peine a-t'on un système jouable en place qu'il est déjà sur la sellette du remplacement, et fatigué par ce manège, j'avais fini par laisser courir… Après tout, ma borne fonctionne, pas besoin d'y toucher !
Jusqu'au moment où l'on voudrait bien pouvoir profiter des dernières innovations de mame.
Problème, l'OS (debian8) est trop vieux pour supporter SDL2 requis maintenant par mame, et une fois debian10 réinstallé, impossible de faire fonctionner le noyaux Linux 3.2 patché 15 kHz compilé à l'époque.
Malheureusement une recherche rapide sur les forums d'alors me fit comprendre que les patches Linux n'étaient plus publié et disponible pour les versions récentes…
Occupé ailleurs j'avais un peu mis ça de côté, et puis un jour, au détour de la consultation des statistiques du blog, j'ai découvert qu'on « linkait » gentiment mon billet sur github.
Le dénommé Doozer proposait donc des patches pour le noyaux v5, et dés la première lecture du document, je compris que pas mal de choses avaient changé, dans la façon de faire fonctionner ce noyau patché, et plus tard dans la manière de le compiler.
Avant de continuer à raconter ma vie, on va déjà faire ça !

Compilation de Linux patché @15kHz :

Voici donc la nouvelle routine de compilation au goût du jour !

  • 1 — Prérequis :

Installer debian 10 Buster, puis les paquets nécessaires à la compilation :

apt update
apt upgrade
apt install build-essential bc kmod cpio flex libncurses5-dev dpkg-dev debconf-utils debhelper fakeroot zlib1g-dev rsync


  • 2 — Préparatifs :

Récupérer les sources et les extraire dans un dossier de travail : /home/user/kernel5.5

mkdir /home/user/kernel5.5
cd /home/user/kernel5.5
wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.5.tar.gz
tar xvf linux-5.5.tar.gz

Se rendre dans le dossier crée :

cd linux-5.0.1

Configurer le kernel :

make olddefconfig

Cette commande va chercher la configuration du kernel actuel (booté) et met toutes les nouvelles options en « par défaut ».
Il faut donc s'assurer que le debian actuel est démarré sur un noyaux 5.4 au moins.

Éditer le fichier .config, afin de vérifier que cette ligne ne contient rien entre les guillemets (sinon la compilation plantera dés les premières minutes) :

CONFIG_SYSTEM_TRUSTED_KEYS = ""

Exécuter ce script permet de ne pas compiler un noyau de debug, et donc de gagner du temps :

./scripts/config -d CONFIG_DEBUG_INFO


  • 3 — Patcher :

Récupérer les patchs 15kHz[1] :

cd /home/user/
wget https://github.com/D0023R/linux_kernel_15khz/archive/master.zip

Les extraires :

unzip master.zip

Tester les patchs :

cd /home/user/kernel5.5/linux-5.5/
patch -p1 --dry-run < ../../linux_kernel_15khz-master/linux-5.5/01_ati_9200_pllfix.diff
patch -p1 --dry-run < ../../linux_kernel_15khz-master/linux-5.5/02_arcadevga_3000.diff
patch -p1 --dry-run < ../../linux_kernel_15khz-master/linux-5.5/03_linux_15khz.diff
patch -p1 --dry-run < ../../linux_kernel_15khz-master/linux-5.5/04_linux_15khz_interlaced_mode_fix.diff
patch -p1 --dry-run < ../../linux_kernel_15khz-master/linux-5.5/05_linux_15khz_scanoutpos.diff
patch -p1 --dry-run < ../../linux_kernel_15khz-master/linux-5.5/06_linux_15khz_640x240_resolution.diff

Patcher les sources :

patch -p1 < ../../linux_kernel_15khz-master/linux-5.5/01_ati_9200_pllfix.diff
patch -p1 < ../../linux_kernel_15khz-master/linux-5.5/02_arcadevga_3000.diff
patch -p1 < ../../linux_kernel_15khz-master/linux-5.5/03_linux_15khz.diff
patch -p1 < ../../linux_kernel_15khz-master/linux-5.5/04_linux_15khz_interlaced_mode_fix.diff
patch -p1 < ../../linux_kernel_15khz-master/linux-5.5/05_linux_15khz_scanoutpos.diff
patch -p1 < ../../linux_kernel_15khz-master/linux-5.5/06_linux_15khz_640x240_resolution.diff


  • 4 - Compilation du kernel :
make -j$(nproc) bindeb-pkg LOCALVERSION=-"$(dpkg --print-architecture)"-patched15khz

Après plusieurs minutes/heures, on obtiens alors une liste de packets, dont notre linux-image tant attendu :

linux-5.5.0-amd64-patched15khz_5.5.0-amd64-patched15khz-1_amd64.buildinfo
linux-5.5.0-amd64-patched15khz_5.5.0-amd64-patched15khz-1_amd64.changes
linux-headers-5.5.0-amd64-patched15khz_5.5.0-amd64-patched15khz-1_amd64.deb
linux-image-5.5.0-amd64-patched15khz_5.5.0-amd64-patched15khz-1_amd64.deb
linux-image-5.5.0-amd64-patched15khz-dbg_5.5.0-amd64-patched15khz-1_amd64.deb
linux-libc-dev_5.5.0-amd64-patched15khz-1_amd64.deb

(Sauf le packet « -dbg_ » si la compilation du noyau débug a été désactivée)

  • 5 - Installation du kernel :

Voici le fichier résultant de la compilation, prêt à être installé en quelques secondes sur Debian 10. Il est possible qu'il fonctionnent sous Ubuntu également, à tester…

linux-image-5.5.0-patched15khz_amd64.deb

Pour l'installer, suffit d'utiliser dpkg avec les droits root ou via un sudo :

dpkg -i linux-image-5.5.0-amd64-patched15khz_5.5.0-amd64-patched15khz-1_amd64.deb

Et pour le faire fonctionner il faut éditer le fichier grub :

nano /etc/default/grub

Repérer la ligne GRUB_CMDLINE_LINUX_DEFAULT="quiet" et ajouter cette ligne en dessous :

GRUB_CMDLINE_LINUX="video=DVI-I-1:320x240eS"

Puis impérativement appliquer la configuration avec :

update-grub

Rq : l'argument DVI-I-1 dépend de la sortie utilisée sur la carte vidéo. Pour obtenir le nom exact, utiliser cette commande :

ls /sys/class/drm/



Premiers essais :

  • Au démarrage donc, on devrait voir la console Linux s'afficher directement sur l'écran cathodique !

Ça c'est nouveau, car anciennement, il fallait attendre que Xorg soit démarré pour espérer afficher une image sur l'écran.

Maintenant on va pouvoir démarre X dans la résolution de son choix, en utilisant xorg.conf ou xrandr

Voici le fichier que j'utilise :

Section "Device"
    Identifier  "ATI"
    Driver      "radeon"
EndSection

Section "Monitor"
        Identifier   "TV"
        HorizSync    15.0 - 20.0
        VertRefresh  50.0 - 60.0
## modelines TV @15kHz
# identique à celle de la console
    ModeLine "320x240x60.00" 6.639840 320 336 368 424 240 242 245 261 -HSync -VSync
# autres versions
    Modeline "320x240" 6.452 320 338 368 412 240 242 245 264  -HSync -VSync
    Modeline "320x240@60Hz" 6.463 320 344 376 408 240 242 245 264 -hsync -vsync
    Modeline "320x240@57.55Hz" 6.199 320 344 376 408 240 242 245 264  -HSync -VSync
    Modeline "640x480i" 12.209786 640 664 720 776 480 490 496 525  -HSync -VSync interlace
EndSection

Section "Screen"
    Identifier "Default Screen"
    Device     "ATI"
    Monitor    "TV"
    DefaultDepth     24
    SubSection "Display"
    Depth     24
    Modes    "320x240x60.00"
#    Modes    "320x240"
#    Modes    "320x240@60Hz"
#    Modes    "320x240@57.55Hz"
#    Modes    "640x480i"
    EndSubSection
EndSection



Problème majeur rencontré :

Voilà, donc la belle histoire contée ci-dessus, c'est quand tout le monde est beau… En vrai il arrive toujours des trucs pas prévu…

  • Car au premier démarrage, rien, pas d'image… j'ai donc ouvert un ticket afin de peut-être d'alerter d'un problème potentiel, ou tout du moins de comprendre ce qu'il se passait.

En définitive, ma carte graphique ATI FireGL3550 était incompatible aux pixel clock trop lent. Ce qui aura été difficile à comprendre, car elle fonctionnait bien avec l'ancien noyau 3.2.

C'est avec l'aide de Substring et des heures passées à tester diverses solutions qu'on a conclu que la carte fonctionnait par chance en 3.2, et que le noyau v5 n'aura fait que révéler le problème.
Certaines résolutions passaient bien avec le noyau v5, comme 384x288, et d'autres comme 320x240 pas du tout.

Et effectivement, en passant sur une carte Radeon HD7540D, tout à fonctionné parfaitement.

Cependant ces investigations et « béta tests » auront permises à Substring de perfectionner le patch et d'intégrer de nouvelles fonctionnalités pour la version 5.5 du noyau.

  • Et aussi de me remettre à jour sur l'actualité des systèmes arcades Linux. En effet il y a 7 ans, alors que j'avais pas mal bidouillé avec le projet AdvanceMame (au point mort à l'époque et remis en marche depuis l’avènement du RaspberryPi), j'évoquais l’existence des débuts de GroovyMame, et avait pu tester un peu le soft avec son SwitchRes capable comme AdvanceMame de basculer l'affichage dans la résolution spécifique de chaque jeux (mais sous X cette fois-ci, et non sous FrameBuffer, alors impossible à faire fonctionner… relire mon billet de l'époque). J'avais aussi rapidement essayé la distribution GroovyArcade qui embarquait tout cela, mais sans aller plus loin, étant enfin moi-même arrivé à faire mon propre système, je n'ai plu eu la patience de voir comment évoluerait le projet…
  • Et donc de découvrir ici que j'avais en fait affaire aux valeureux développeurs de GroovyArcade, ou plutôt à celui qui tentait de le ressusciter, épaulé par une petite équipe de dév improvisée, avec chacun sa spécialité, comme par exemple Doozer pour la partie DRM du kernel, et Substring donc pour l'empaquetage et la génération de l'image iso de GroovyArcade.

Les non-développeurs s'imaginent souvent, en les désignant par « ils » ou « les mec de » (pour évoquer un soft), une équipe de développement nombreuse et inaccessible, mais la réalité est souvent tout autre, et on se rend alors compte qu'ils ou elles sont peut-être deux ou trois, mais souvent seul·e, et qu'ils parlent peut-être même ta langue.

  • GroovyArcade que j'ai donc testé (qui tourne sous Arch Linux) est vraiment très bien faite pour qui voudrait monter une borne rapidement sans partir de zero. J'ai été impressionné par l'interactivité du système et la facilité à le personnaliser, à tel point qu'elle nous aura servis de référence au « débug » de mon problème de carte, et plus tard pour résoudre des points de réglages que je rencontrais avec mon système perso.
  • GroovyMame, s'est révélé très intéressant, mais je conserve aussi mame classique sur ma borne pour deux raisons. Parfois GroovyMame, bascule certains jeux dans une résolution inadéquate, mais surtout, mon écran étant à commande numérique, tous les réglages de la géométrie de l'image se font via des menus cachés avec la télécommande, et à moins de jouer toujours au même jeu, c'est juste inadaptée à l'instantanéité de la situation. En effet, le fait de changer de résolution déforme l'image en l'étirant verticalement ou horizontalement, faisant apparaître des bandes noires sur les bords, etc. L'idéal serait donc d'avoir un écran avec ces réglages accessibles depuis des potentiomètres en façade, afin de pouvoir très rapidement remettre l'image en plein écran.

Bon, voilà pour l'essentiel, j'avais en tête de raconter plus précisément l'histoire, mais j'ai trop tarder à écrire et ces détails se sont estompé de ma mémoire.

  • Je suis en tous cas heureux de voir ce type de projet continuer de vivre et tiens ici à remercier chaleureusement toute l'équipe et contributeurs qui permettent aux joueurs de retrouver et partager les sensations de l'Arcade !

Ressources :
- https://github.com/D0023R/linux_kernel_15khz
- https://github.com/substring
- https://github.com/TiBeN/15khz-arcade-pkg
- https://github.com/Ansa89/linux-15khz-patch
GroovyMame :
- https://drive.google.com/drive/folders/0B5iMjDor3P__aEFpcVNkVW5jbEE Via http://forum.arcadecontrols.com/index.php/topic,151459.0.html
GroovyArcade :
- https://drive.google.com/drive/folders/0B0NB2HYUHHktUFZXTWJfbHpzUlE

Note

[1] Dispo en annexe ci--dessous si le lien se retrouvait brisé

Commentaires

1. Le lundi, 9 mars 2020, 15:40 par Cdrik

Bonjour MaKoTo,
Merci pour ton billet, je suis plus où moins dans le même cas, j'ai installé Lubuntu 18.04 LTS hier pour sa légèreté en ayant la facilité d'Ubuntu étant pas un pro Linux. Je vais utilisé ce PC sur TV CRT. J'ai pour l'instant installé Retroarch, Attract Mode, il me reste à installer Groovymame et enfin de patcher mon kernel en 15kHz et je pense que ton billet va beaucoup m'aider. Apparemment le kernel utilisé de Lubuntu n'est pas le 5.5 mais ça ne doit pas changer grand chose dans la manipulation à effectuer.
Par contre pour ton soucis d'écran avec GroovyMame y a t'il pas possibilité d'utilisé l'arcade OSD de Calamity comme sur Windows, je ne sais pas si ça existe sous Linux ça me permettait de recalibrer l'écran selon les modelines pour avoir un meilleur affichage sur ma TV CRT.
J'avais essayé les drivers de Calamity CRT emudriver 2.0 sur Windows 10 mais je trouve Windows 10 trop long à démarrer... d'où mon passage à une distribution Linux.
Cordialement

2. Le mercredi, 11 mars 2020, 14:06 par makoto

Élo !
C'est un plaisir si mon compte-rendu t'es utile :)
Ça se passera de la même manière si tu patches un noyau 5.0, et ça ne devrait pas poser de problème pour le mettre sur Lubuntu 18.04.
Cependant, pense au fait que la version 20.04 sort en avril donc, ça ira !
Je n'ai pas connaissance de « l'arcade OSD de Calamity » mais je n'imagine pas qu'un logiciel puisse résoudre ici un problème purement matériel et qui concerne l'écran CRT. (si on parle bien des soucis de réglages de la géométrie de l'image, décrit dans l'avant dernier paragraphe).
Outre le fait que je suis allergique à Windose, la rapidité, la légéreté et la customisabilité (un nouveau mot :p) ont aussi été pour moi une évidence à l'usage de GNU/Linux.

Bon amusement !

3. Le mercredi, 11 mars 2020, 16:08 par Cdrik

Salut!

Je viens de voir ça pour la 20.04, j'ai pas encore patché mon noyau par manque de temps :( d'ici là je pense que j'aurai installé la 20.04 avant d'avoir eu le temps de patcher :D

Oui je parle bien du fait de pouvoir régler notre géométrie de l'image
Il y a le tutoriel si tu veux jeter un oeil pour info:
http://geedorah.com/eiusdemmodi/for...

Merci à toi aussi MaKoTo ;)

4. Le vendredi, 24 juillet 2020, 02:12 par TiBeN

Salut MaKoTo,

Je suis TiBeN, le bidouilleur à la base du projet "15khz-arcade-pkg" que tu cites dans les ressources de ton billet. Tout d'abord, je te remercie de me citer, ca fait vraiment plaisir, d'autant plus que tes premiers billets m'ont servi entre autre comme base à la création de ce projet à l'époque. Ayant quitté Ubuntu depuis (étant ingénieur passionné de Linux, je change de distro comme de chemise), ce projet est un peu obsolète maintenant, bien que je pense que la doc puisse toujours servir.

J'ai cependant continué à explorer le sujet depuis et ai réussi à reproduire la config au moins sur Fedora et plus récemment sur ArchLinux et je confirme ca marche toujours.

J'en profite ainsi pour apporter quelques éclairages, fruit de mes expériences dans le domaine:

Patcher le noyau est au final vraiment optionnel, il sert juste à avoir le bon modeline au niveau "KMS", pour voir affiché les logs de boot du kernel. Une fois que la main est passée au serveur X, ce patch est inutile, X gère les modelines comme un grand.

J'ai testé de créer un binaire EDID custom sans succès.

Pour avoir testé avec des cartes de différentes marques, je dois dire que les Radeon "old-school" sont de loin les plus flexibles pour ca. J'ai une radeon HD 5000 que j'ai dédié à ca. J'ai fait pas mal d'expériences avec les nvidia.

J'avais réussi fut un temps à les faire marcher correctement mais aux dernières itérations des composants kernel/xorg/nouveau, impossible sans me défaire de frustrant tearing. Seul le driver (xorg) radeon permet de s'en defaire avec l'option:

   Option "ShadowPrimary"  "on"

Je déconseille ainsi le driver plus récent "modesetting" pour ca (ou alors j'ai pas trouvé comment le configurer).

J'ai noté aussi des comportements vraiment très divers concernant l'activation de l'output VGA par le kernel sans EDID. Pour la radeon, elle est activée les doigts dans le nez, tandis qu'avec les nvidia il faut forcer l'activation au niveau du kernel (par exemple).

Pour les carte Intel (puce graphique intégrée), j'ai obtenu des bons résultats en utilisant les "super résolutions". Ce type de résolution est supporté par Groovymame et Retroarch. Cela permet de multiplier par X la résolution native du système émulé, et donc de pouvoir être supporté par des cartes/drivers qui supportent pas les basses résolutions, tout en ayant un rendu identique aux résolutions natives sur le CRT. Pratique pour recycler un PC portable un peu obsolète.

Une config que j'aime bien c'est le multiseat, c-a-d utiliser son PC de bureau avec deux écrans et deux "sièges" bien séparés. J'ai refait aujourd'hui, pour le fun, ce genre de config sur ma distro actuelle ArchLinux. J'ai fait quelques vidéos Youtube pour illustrer cela:

https://www.youtube.com/watch?v=doE...
https://www.youtube.com/watch?v=P6I...
https://www.youtube.com/watch?v=c-0...

Pour résumer, ce genre de config dépends beaucoup du hardware qu'on utilise et des évolutions de la stack kernel/drivers/xorg/distri et il est difficile de faire un tuto générique. Du temps, de l'investigation sur Linux et du suivi des évolutions de ces composants sont clairement nécessaires.

Mais c'est passionnant .

5. Le vendredi, 24 juillet 2020, 02:41 par TiBeN

En ce qui concerne les problèmes d'affichage avec groovymame, il est possible d'ajuster la position avec les options "crt_range".

De plus, il est possible de créer des fichiers "ini" spécifiques à un driver mame, donc de bidouiller l'affichage par système émulé. (il faut créer un fichier ini avec le nom du system, par exemple "genesis.ini", qui écrasera les options mame par défaut).

Enfin, l'usage des super résolutions, que j'ai évoqué dans mon précédant commentaire, résout en grande partie ce problème.

6. Le samedi, 1 août 2020, 09:58 par Makoto

Salut TiBeN !

Merci pour ta contribution au schmilblick et content d'avoir pu te mettre le pied à l'étrier fût un temps.
C'est amusant de se croiser et recroiser entre contributeurs, même si je fais en fait seulement partie de ceux qui testent et archivent l'information.
Je n'ai pas parlé de ta partie, cependant les recherches pour mettre en œuvre ce long billet de mise à jour m'auront permises de tester ta version de patch sur le vieil Ubuntu, car au début j'ai tenté de compiler tout ce que j'ai pu trouver sur le sujet avant de comprendre (avec l'aide de Substring) que ce qui ne fonctionnait pas c'était en fait ma carte graphique.

Ajouter un commentaire

Les commentaires peuvent être formatés en utilisant une syntaxe wiki simplifiée.

Fil des commentaires de ce billet