Ffmpeg n'a pas de module d'enregistrement natif PipeWire.
J'aurais dû lire ton comm' avant mon propre commentaire ci-dessous… bon à savoir, même si ça arrivera forcément un jour (tu peux ignorer cette partie du coup !).
Passionnant, merci ! J'ignorais l'usage du module PulseAudio ; PipeWire en direct ce serait intéressant, si la couche de compat' avec PA fait défaut un jour (mais là j'en suis encore à m'habituer…).
Je réagis sur :
À noter qu'on peut très facilement lancer de façon semblable un compositeur Wayland dans une fenêtre, mais que l'enregistrement d'un affichage Wayland est moins bien supporté : je m'en tiendrai donc à Xephyr.
Normalement la partie vidéo c'est couvert par cette section du billet (l'outil utilise aussi FFmpeg en interne).
Après il resterait à réunir les 2 flux.
Ah je vois ! Tu te connectes par SSH, avec la redirection X11 pour disposer de son socket (ou au pire ça se fait bien à la main).
Par Wayland "seul", avec les compositeurs wlroots et la commande wlr-randr, ça se fait bien aussi en définissant WAYLAND_DISPLAY (l'équivalent de la variable DISPLAY sous X11).
Mais je vois le problème potentiel avec GNOME : il s'attend à du D-Bus. Quand tu te logges en interactif sur la machine, systemd démarre un démon D-Bus personnel… mais pas forcément en SSH, où c'est paramétré via PAM, typiquement dans /etc/pam.d/sshd. Et la config par défaut SSH/PAM considère que tu n'as pas besoin de D-Bus car ce n'est pas un usage "desktop".
Maintenant ça se rajoute sans problème dans la config. D'ailleurs, le wrapper que j'évoque plus haut en aurait aussi besoin, vu qu'il fait du D-Bus… est-ce que ça résoudrait ton souci, ou tu trouves que ça vaut pas le coup (parce que tu as une config hétérogène = GNOME pas partout)?
Le protocole Wayland n'a pas voulu définir ces aspects côté serveur, alors chacun a fait à sa sauce.
L'encapsulation ne va objectivement pas dans wlr-randr, éventuellement dans GNOME… mais ils l'accepteront pas tel quel ; pour ça je suggérais un module indépendant. À la fin le protocole le plus utilisé "gagnera" logiquement.
Sinon, l'interface wlr-output-management-unstable-v1 est encore expérimentale, ce qui peut expliquer la non implémentation par Gnome et d'autres.
Ils ne l'implémenteront probablement pas eux-mêmes : ce n'est pas "dans la famille", pour ainsi dire.
Si on voulait le faire léger et hors de Mutter (leur compositeur), on pourrait imaginer un petit processus indépendant qui expose le protocole et lance les commandes D-Bus qu'il attend. Ce serait un chouette projet pas trop gros !
$ wlr-randr
compositor doesn't support wlr-output-management-unstable-v1
C'est attendu, et tristement prévisible : comme son nom l'indique un petit peu, wlr-randr ne supporte que les compositeurs exposant la famille de protocoles wlr
(c'est-à-dire ceux basé sur la lib wlroots ; dont labwc de cet article… et COSMIC apparemment, tu me l'apprends !).
Comme ça à vue de nez, je peux prédire que ça ne marchera pas non plus sous KDE Plasma ni Weston.
Ceux-ci gèrent eux-mêmes leurs réglages vidéos, avec ou sans protocole externe pour interagir avec. Techniquement, ils pourraient le supporter (via un module ?) mais ne le font pas de base, et personne n'a jugé bon d'écrire un tel module on dirait…
Rien à voir mais : GNOME ne propose pas un truc par D-Bus ?
Hello, quand tu dis que ça ne "lit plus", parles-tu plutôt de :
- l'affichage "brut" du contenu du DVD dans l'explorateur de fichiers ;
- la lecture DVD-Vidéo (effectuée avec un logiciel dédié, p.ex. VLC) ?
Pour moi, après l'établissement du duopole actuel, c'est le meilleur possible. Un "ordiphone" ayant d'autres formats d'applis, un autre SDK… ça a été tenté plein de fois, et c'est voué à l'échec : sauf dans le cas d'un marché contrôlé, ou s'il fournit lui-même un bon émulateur Android (ce sur quoi j'avoue pas être très au jus).
Parmi les compositeurs minimaux, Weston est le plus simple puisqu'il arrive prêt à l'emploi (un terminal, un lanceur, un lock screen, un enregistreur d'écran, RDP…).
L'inconvénient est qu'il n'est pas très modulaire : on peut retirer ces choses, mais pas en ajouter ; et les modules externes pour lui sont rares (j'étais justement l'un des rares).
Les mini-compositeurs basés sur wlroots suivent en général l'optique inverse : ils arrivent avec quasi-rien (typiquement un menu-clic-droit à la TWM) mais s'appuient sur un écosystème de clients dont les privilégiés utilisent leur protocole "wlr" : n'importe quel terminal compatible, lanceur avec waybar / Cairo-Dock, lock screen avec swaylock, capture d'écran avec wf-recorder…
Je trouve que tu as là une bonne alternative décrite ; et comme les autres, ne pourrai te renseigner davantage avant d'en savoir plus ;).
Merci ; moi pareil, je me fais avoir à chaque fois ;).
Je viens de regarder la prog. Quoique définitivement orientée "corporate", y a des sujets intéressants : alternatives OSS à Jira, Confluence, Exchange…oh tiens, une conf Cryptpad…
… mais la surprise : y a un "lightning talk" LinuxFR (sans déc' : "LinuxFr.org giveaway: random draw"!).
C'est peut-être simple mais quali ; merci bien !
(on m'en avait déjà parlé du couple astral, mais ça m'était sorti de l'esprit)
Question : je vois que le dépôt COPR "beta" est mis à jour en gros chaque mois. Y a jamais rien qui pète ? Pas de version à privilégier à part "la dernière" ?
Mais y en a plein dans l'écosystème Rust. Egui est top aussi, mais c'est un autre paradigme. Et si jamais tu veux donner une chance à mon DSL ça me ferait hyper plaisir, je pourrais même trouver du temps pour implémenter des trucs dont t'aurais besoin en terme d'UI ^
In fine, il me faudra définitivement des widgets avec des trucs de haut niveau genre menu, boîte de dialogue "Ouverture de fichiers", etc.
Je sait d'avance que Macroquad n'a pas tout ça de base, et donc ce serait "injuste" de faire peser ça sur toi… cela dit, il est certain que je vais essayer ton DSL ; et je te ferai des retours assurés 😀 !
au début je voulais rester au maximum agnostique du moteur de rendu […] mais entre les type font et texture et les events systèmes de macroquad, plus les appels de rendu ça devient de plus en plus lié.
Tu m'étonnes ; vu comment Rust est fait… et de toute façon plus tu feras des trucs évolués, plus ce sera le cas.
ML déclaratif pour Macroquad ça colle. Ça ferait Macroquad Markup Language, MML
Pourquoi pas : MLM -> "A Markup Language for Macroquad" ? 😉
Ou sinon, tu gardes MLM -> "My Markup Language" et un jour éventuellement…. (car s'ils acquiescent chez Macroquad, pas impossible que ça s'accompagne d'une respo de maintenance !)
Je suis assez intéressé car je compte écrire un tool GUI en pur Rust.
Il ne tournera -et pour de bonnes raisons- que sur Linux, donc le cross-platform m'indiffère…
Je comptais poser des questions sur le moteur de rendu, mais je vois que t'appuies sur Macroquad (que j'avais repéré à l'époque)… serait-ce trahir ton framework que le décrire comme "un ML déclaratif pour Macroquad" 😃 ?
J'ai lu ton comm' vaaaaaachement trop tard ; quand je suis revenu pour y re-piquer des infos 🤭 !
Les screenshots m'ont mis une grosse claque dans la gueule (notamment la config graphique de Half Life/Counter Strike).
J'ai passé des centaines heures sur ce jeu et ses mods (HL, j'avais un peu lâché à l'arrivée de CS …). Y a notamment 2 maps multi de ma création qui ont été entièrement perdues : le premier dur apprentissage du devoir de sauvegarde 😶.
Et Glide était magnifique et super fluide. OpenGL était moins véloce et moins beau, et Direct3D c'était une blague.
Ayant eu une Voodoo 2 et 3, j'ai eu 100% la même expérience.
Mais faut être honnête : même si les dévs du jeu peuvent pas se plier en 3, le support Direct3D des cartes 3dfx était aussi tout pété. Déjà qu'ils préféraient qu'on utilise leur Glide qu'OpenGL (auquel ils avaient juste consenti sur demande), alors Direct3D… c'était la concurrence, et d'ailleurs ça marchait un cran mieux sur les NVIDIA - même si les drivers sont restés bancals jusqu'à DirectX 6.
Mouais.
Je dis "mouais" en parlant spécifiquement de WINUX et ses 3-4 autres pseudos, car il s'agit en gros de la même distro à des intervalles de temps, sites, styles graphiques et accroches marketing différentes (avec la fameuse promo de la version payante).
J'avais testé rapidement sa version "Linuxfx" en live DVD, sans voir de problème évident…
…il n'en reste pas c'est plus des pratiques de studio de poudre verte que de développeurs OSS sérieux. Ça incite à la prudence.
Ça a l'air simple si on a l'habitude, mais ça va concrètement repousser 90% des utilisateurs -au pire ils vont le confier à un atelier, et encore faut-il qu'ils aient l'expérience des Chromebooks…
Xorg n'est pas censé crasher comme ça, juste parce qu'un processus random est abattu par l'OOM.
Par contre, j'ai déjà vu des interactions pourries d'applications accélérées par GPU (Chrome, Firefox) avec le pilote graphique, qui est du coup le soutien de Xorg.
Qu'est-ce que ça donne en désactivant l'Accelération matérielle dans les params FF (quitte à ce que ça soit + lent, mais pour tester) ?
un meilleur support fenêtrage de Wayland, visible en comparant le nombre de protocoles supportés par SDL2 contre SDL3 ;
Ah zut, je ne peux plus éditer, mais je comparais aussi avec le support Wayland de GLFW : au doigt mouillé, c'est entre les 2.
En vrai c'est loin d'être si important, la plupart n'utiliseront jamais tous ces protocoles, et nous alors… mais il y en a un dont je voulais être 100% sûr (même si GLFW a aussi l'air de le supporter) c'est le "pointer lock" pour verrouiller la souris dans une fenêtre ; et hors bas niveau je ne l'avais testé que là 😓.
Aaah Glut… le vieil exemple que j'ai retrouvé l'utilisait encore. Et bien que je ne l'aie jamais utilisé, j'ai effectivement vu énormément de GLFW sur les codes Vulkan récents !
Tu n'as pas entièrement tort sur SDL. Il fait beaucoup de choses, et d'ailleurs on pourrait juste dessiner avec son API haut niveau en lui laissant sélectionner le moteur (OpenGL ou autre)… si ce n'était pas le sujet principal du tuto ;-).
Ce qui a motivé mon choix :
- (le point perso dont tout le monde se fiche) je fais un portage avec en ce moment ;
- un meilleur support fenêtrage de Wayland, visible en comparant le nombre de protocoles supportés par SDL2 contre SDL3 ;
- le code Vulkan à venir sera très long, je pense que tu vois ce que je veux dire… une fois démontré la première fois, je projette d'utiliser les nouvelles fonctions de SDL_GPU pour le raccourcir et se concentrer sur la boucle de rendu.
Qu'en penses-tu ?
[^] # Re: Enregistement PipeWire avec Ffmpeg
Posté par Tarnyko (site web personnel) . En réponse au journal Enregistrement de vidéo à la demande avec Xephyr et PulseAudio. Évalué à 2 (+0/-0).
J'aurais dû lire ton comm' avant mon propre commentaire ci-dessous… bon à savoir, même si ça arrivera forcément un jour (tu peux ignorer cette partie du coup !).
# PulseAudio & enregistrement Wayland
Posté par Tarnyko (site web personnel) . En réponse au journal Enregistrement de vidéo à la demande avec Xephyr et PulseAudio. Évalué à 3 (+1/-0).
Passionnant, merci ! J'ignorais l'usage du module PulseAudio ; PipeWire en direct ce serait intéressant, si la couche de compat' avec PA fait défaut un jour (mais là j'en suis encore à m'habituer…).
Je réagis sur :
Normalement la partie vidéo c'est couvert par cette section du billet (l'outil utilise aussi FFmpeg en interne).
Après il resterait à réunir les 2 flux.
[^] # Re: wlr-randr
Posté par Tarnyko (site web personnel) . En réponse au journal Un bureau Wayland minimal et modulaire. Évalué à 4 (+2/-0). Dernière modification le 15 décembre 2025 à 10:19.
Ah je vois ! Tu te connectes par SSH, avec la redirection X11 pour disposer de son socket (ou au pire ça se fait bien à la main).
Par Wayland "seul", avec les compositeurs wlroots et la commande
wlr-randr, ça se fait bien aussi en définissantWAYLAND_DISPLAY(l'équivalent de la variableDISPLAYsous X11).Mais je vois le problème potentiel avec GNOME : il s'attend à du D-Bus. Quand tu te logges en interactif sur la machine,
systemddémarre un démon D-Bus personnel… mais pas forcément en SSH, où c'est paramétré via PAM, typiquement dans/etc/pam.d/sshd. Et la config par défaut SSH/PAM considère que tu n'as pas besoin de D-Bus car ce n'est pas un usage "desktop".Maintenant ça se rajoute sans problème dans la config. D'ailleurs, le wrapper que j'évoque plus haut en aurait aussi besoin, vu qu'il fait du D-Bus… est-ce que ça résoudrait ton souci, ou tu trouves que ça vaut pas le coup (parce que tu as une config hétérogène = GNOME pas partout)?
[^] # Re: wlr-randr
Posté par Tarnyko (site web personnel) . En réponse au journal Un bureau Wayland minimal et modulaire. Évalué à 2 (+0/-0).
Ce n'est donc un problème que si tu utilises des compositeurs qui ne le supportent pas 😶.
Plus sérieusement, quel est donc le dit flux de travail ? Testage de distributions à la chaîne, bureau mobile…. ?
[^] # Re: wlr-randr
Posté par Tarnyko (site web personnel) . En réponse au journal Un bureau Wayland minimal et modulaire. Évalué à 2 (+0/-0).
C'est l'idée (enfin normalement) !
Le protocole Wayland n'a pas voulu définir ces aspects côté serveur, alors chacun a fait à sa sauce.
L'encapsulation ne va objectivement pas dans wlr-randr, éventuellement dans GNOME… mais ils l'accepteront pas tel quel ; pour ça je suggérais un module indépendant. À la fin le protocole le plus utilisé "gagnera" logiquement.
[^] # Re: wlr-randr
Posté par Tarnyko (site web personnel) . En réponse au journal Un bureau Wayland minimal et modulaire. Évalué à 2 (+0/-0).
Ils ne l'implémenteront probablement pas eux-mêmes : ce n'est pas "dans la famille", pour ainsi dire.
Si on voulait le faire léger et hors de Mutter (leur compositeur), on pourrait imaginer un petit processus indépendant qui expose le protocole et lance les commandes D-Bus qu'il attend. Ce serait un chouette projet pas trop gros !
[^] # Re: wlr-randr
Posté par Tarnyko (site web personnel) . En réponse au journal Un bureau Wayland minimal et modulaire. Évalué à 5 (+3/-0). Dernière modification le 14 décembre 2025 à 18:23.
Hello Meku ; alors :
C'est attendu, et tristement prévisible : comme son nom l'indique un petit peu, wlr-randr ne supporte que les compositeurs exposant la famille de protocoles wlr
(c'est-à-dire ceux basé sur la lib wlroots ; dont labwc de cet article… et COSMIC apparemment, tu me l'apprends !).
Comme ça à vue de nez, je peux prédire que ça ne marchera pas non plus sous KDE Plasma ni Weston.
Ceux-ci gèrent eux-mêmes leurs réglages vidéos, avec ou sans protocole externe pour interagir avec. Techniquement, ils pourraient le supporter (via un module ?) mais ne le font pas de base, et personne n'a jugé bon d'écrire un tel module on dirait…
Rien à voir mais : GNOME ne propose pas un truc par D-Bus ?
# Rha, coquille !
Posté par Tarnyko (site web personnel) . En réponse au journal Un bureau Wayland minimal et modulaire. Évalué à 2 (+0/-0).
Aux modérateurs, cette section:
Fedora 42 (mise à jour)
Vérifiez que vous avez bien wlroots 0.19 :
devrait en fait être :
Fedora 42 (mise à jour)
Vérifiez que vous avez bien wlroots 0.19 :
Merki 😀
# Vidéo ou données
Posté par Tarnyko (site web personnel) . En réponse au message cherche pilote pour lecteur DVD LG compatible linux Mint. Évalué à 6 (+4/-0).
Hello, quand tu dis que ça ne "lit plus", parles-tu plutôt de :
- l'affichage "brut" du contenu du DVD dans l'explorateur de fichiers ;
- la lecture DVD-Vidéo (effectuée avec un logiciel dédié, p.ex. VLC) ?
# /e/OS
Posté par Tarnyko (site web personnel) . En réponse au message [Ordiphone] : PostMarket OS, Sailfish OS, Murena. Évalué à 6 (+4/-0). Dernière modification le 10 décembre 2025 à 13:25.
/e/OS donc ; c'est ce que j'utilise.
Pour moi, après l'établissement du duopole actuel, c'est le meilleur possible. Un "ordiphone" ayant d'autres formats d'applis, un autre SDK… ça a été tenté plein de fois, et c'est voué à l'échec : sauf dans le cas d'un marché contrôlé, ou s'il fournit lui-même un bon émulateur Android (ce sur quoi j'avoue pas être très au jus).
# Weston est le plus simple
Posté par Tarnyko (site web personnel) . En réponse au message waydroid : weston, ou autre chose?. Évalué à 3 (+1/-0). Dernière modification le 10 décembre 2025 à 12:07.
Parmi les compositeurs minimaux, Weston est le plus simple puisqu'il arrive prêt à l'emploi (un terminal, un lanceur, un lock screen, un enregistreur d'écran, RDP…).
L'inconvénient est qu'il n'est pas très modulaire : on peut retirer ces choses, mais pas en ajouter ; et les modules externes pour lui sont rares (j'étais justement l'un des rares).
Les mini-compositeurs basés sur wlroots suivent en général l'optique inverse : ils arrivent avec quasi-rien (typiquement un menu-clic-droit à la TWM) mais s'appuient sur un écosystème de clients dont les privilégiés utilisent leur protocole "wlr" : n'importe quel terminal compatible, lanceur avec waybar / Cairo-Dock, lock screen avec swaylock, capture d'écran avec wf-recorder…
Je trouve que tu as là une bonne alternative décrite ; et comme les autres, ne pourrai te renseigner davantage avant d'en savoir plus ;).
# Merki
Posté par Tarnyko (site web personnel) . En réponse au journal Petit rappel : Salon Opensource Experience 2025 : 10-11 décembre. Évalué à 6 (+4/-0).
Merci ; moi pareil, je me fais avoir à chaque fois ;).
Je viens de regarder la prog. Quoique définitivement orientée "corporate", y a des sujets intéressants : alternatives OSS à Jira, Confluence, Exchange…oh tiens, une conf Cryptpad…
… mais la surprise : y a un "lightning talk" LinuxFR (sans déc' : "LinuxFr.org giveaway: random draw"!).
# Simple mais quali (version ?)
Posté par Tarnyko (site web personnel) . En réponse au journal Cloud Gaming at home 2, le retour. Évalué à 2 (+0/-0).
C'est peut-être simple mais quali ; merci bien !
(on m'en avait déjà parlé du couple astral, mais ça m'était sorti de l'esprit)
Question : je vois que le dépôt COPR "beta" est mis à jour en gros chaque mois. Y a jamais rien qui pète ? Pas de version à privilégier à part "la dernière" ?
# Liens
Posté par Tarnyko (site web personnel) . En réponse au journal coquillage inversé légitime. Évalué à 2 (+0/-0).
Solution un peu complexe mais laissant le sentiment du travail accompli !
De mon côté, j'ai adoré suivre tes liens 😉.
[^] # Re: Intéressant, moteur?
Posté par Tarnyko (site web personnel) . En réponse au journal Rustic Markup Language 0.1.3. Évalué à 4 (+2/-0).
In fine, il me faudra définitivement des widgets avec des trucs de haut niveau genre menu, boîte de dialogue "Ouverture de fichiers", etc.
Je sait d'avance que Macroquad n'a pas tout ça de base, et donc ce serait "injuste" de faire peser ça sur toi… cela dit, il est certain que je vais essayer ton DSL ; et je te ferai des retours assurés 😀 !
Tu m'étonnes ; vu comment Rust est fait… et de toute façon plus tu feras des trucs évolués, plus ce sera le cas.
Pourquoi pas : MLM -> "A Markup Language for Macroquad" ? 😉
Ou sinon, tu gardes MLM -> "My Markup Language" et un jour éventuellement…. (car s'ils acquiescent chez Macroquad, pas impossible que ça s'accompagne d'une respo de maintenance !)
# Intéressant, moteur?
Posté par Tarnyko (site web personnel) . En réponse au journal Rustic Markup Language 0.1.3. Évalué à 4 (+2/-0). Dernière modification le 20 novembre 2025 à 17:20.
Je suis assez intéressé car je compte écrire un tool GUI en pur Rust.
Il ne tournera -et pour de bonnes raisons- que sur Linux, donc le cross-platform m'indiffère…
Je comptais poser des questions sur le moteur de rendu, mais je vois que t'appuies sur Macroquad (que j'avais repéré à l'époque)… serait-ce trahir ton framework que le décrire comme "un ML déclaratif pour Macroquad" 😃 ?
[^] # Re: Back to the future
Posté par Tarnyko (site web personnel) . En réponse au journal Programmation 3D à travers les âges : les débuts (1992-1999). Évalué à 2.
J'ai lu ton comm' vaaaaaachement trop tard ; quand je suis revenu pour y re-piquer des infos 🤭 !
J'ai passé des centaines heures sur ce jeu et ses mods (HL, j'avais un peu lâché à l'arrivée de CS …). Y a notamment 2 maps multi de ma création qui ont été entièrement perdues : le premier dur apprentissage du devoir de sauvegarde 😶.
Ayant eu une Voodoo 2 et 3, j'ai eu 100% la même expérience.
Mais faut être honnête : même si les dévs du jeu peuvent pas se plier en 3, le support Direct3D des cartes 3dfx était aussi tout pété. Déjà qu'ils préféraient qu'on utilise leur Glide qu'OpenGL (auquel ils avaient juste consenti sur demande), alors Direct3D… c'était la concurrence, et d'ailleurs ça marchait un cran mieux sur les NVIDIA - même si les drivers sont restés bancals jusqu'à DirectX 6.
Je t'en prie ! Moi j'y retourne :).
[^] # Re: Arnaque
Posté par Tarnyko (site web personnel) . En réponse au message recherche renseignements sur WINUX. Évalué à 5 (+3/-0).
Mouais.
Je dis "mouais" en parlant spécifiquement de WINUX et ses 3-4 autres pseudos, car il s'agit en gros de la même distro à des intervalles de temps, sites, styles graphiques et accroches marketing différentes (avec la fameuse promo de la version payante).
J'avais testé rapidement sa version "Linuxfx" en live DVD, sans voir de problème évident…
…il n'en reste pas c'est plus des pratiques de studio de poudre verte que de développeurs OSS sérieux. Ça incite à la prudence.
[^] # Re: Retrait, pour mieux revenir ?
Posté par Tarnyko (site web personnel) . En réponse au journal Les conservateurs allemands bloquent Chat Control. Évalué à 3 (+1/-0).
Yes !
[^] # Re: Arnaque
Posté par Tarnyko (site web personnel) . En réponse au message recherche renseignements sur WINUX. Évalué à 7 (+5/-0).
Effectivement.
J'étais tombé dessus une fois : j'avais remarqué que toutes ces distros ont des pages web faites sur le même modèle.
Concrètement elles marchotent, mais sont mal maintenues ET contiennent potentiellement des trucs pas clairs.
[^] # Re: Antivol/antialteration
Posté par Tarnyko (site web personnel) . En réponse au journal Déverrouillage d'un Chromebook. Évalué à 4 (+2/-0).
Je me suis fait la même remarque.
Ça a l'air simple si on a l'habitude, mais ça va concrètement repousser 90% des utilisateurs -au pire ils vont le confier à un atelier, et encore faut-il qu'ils aient l'expérience des Chromebooks…
[^] # Re: SDL 3
Posté par Tarnyko (site web personnel) . En réponse au journal Programmation 3D à travers les âges : OpenGL 1.1 (1997-2003). Évalué à 2.
Oui voilà ! C'est beaucoup une question d'habitude, et là on ne les utilise pas (encore) de manière assez poussée pour voir la différence.
On se comprend 😄.
# Accélération matérielle
Posté par Tarnyko (site web personnel) . En réponse au message Drôle de crash de Xorg. Évalué à 3.
Xorg n'est pas censé crasher comme ça, juste parce qu'un processus random est abattu par l'OOM.
Par contre, j'ai déjà vu des interactions pourries d'applications accélérées par GPU (Chrome, Firefox) avec le pilote graphique, qui est du coup le soutien de Xorg.
Qu'est-ce que ça donne en désactivant l'Accelération matérielle dans les params FF (quitte à ce que ça soit + lent, mais pour tester) ?
[^] # Re: SDL 3
Posté par Tarnyko (site web personnel) . En réponse au journal Programmation 3D à travers les âges : OpenGL 1.1 (1997-2003). Évalué à 2.
Ah zut, je ne peux plus éditer, mais je comparais aussi avec le support Wayland de GLFW : au doigt mouillé, c'est entre les 2.
En vrai c'est loin d'être si important, la plupart n'utiliseront jamais tous ces protocoles, et nous alors… mais il y en a un dont je voulais être 100% sûr (même si GLFW a aussi l'air de le supporter) c'est le "pointer lock" pour verrouiller la souris dans une fenêtre ; et hors bas niveau je ne l'avais testé que là 😓.
[^] # Re: SDL 3
Posté par Tarnyko (site web personnel) . En réponse au journal Programmation 3D à travers les âges : OpenGL 1.1 (1997-2003). Évalué à 2. Dernière modification le 19 septembre 2025 à 12:14.
Hello et cool que ça te plaise !
Aaah Glut… le vieil exemple que j'ai retrouvé l'utilisait encore. Et bien que je ne l'aie jamais utilisé, j'ai effectivement vu énormément de GLFW sur les codes Vulkan récents !
Tu n'as pas entièrement tort sur SDL. Il fait beaucoup de choses, et d'ailleurs on pourrait juste dessiner avec son API haut niveau en lui laissant sélectionner le moteur (OpenGL ou autre)… si ce n'était pas le sujet principal du tuto ;-).
Ce qui a motivé mon choix :
- (le point perso dont tout le monde se fiche) je fais un portage avec en ce moment ;
- un meilleur support fenêtrage de Wayland, visible en comparant le nombre de protocoles supportés par SDL2 contre SDL3 ;
- le code Vulkan à venir sera très long, je pense que tu vois ce que je veux dire… une fois démontré la première fois, je projette d'utiliser les nouvelles fonctions de SDL_GPU pour le raccourcir et se concentrer sur la boucle de rendu.
Qu'en penses-tu ?