Il y a quelques temps, Sébastien Rohaut a rédigé un journal qui m'a particulièrement intéressé : Utilisez une tablette ou tout autre ordinateur comme second écran
Mais aucune des solutions proposées ne convenaient vraiment à mon besoin. J'ai déjà Moonlight/Sunshine mais c'est une solution de streaming de l'host à travers le réseau et ce n'est pas exactement ce que je recherche.
Je cherchais à utiliser une solution qui utilise les possibilités natives de Wayland / wlroot + VA API, à pouvoir utiliser le refresh rate natif de ma tablette (144hz), à fonctionner sous Wayland + labwc/wlroots et ne pas avoir le contrôle du host depuis la tablette. En USB idéalement pour limiter la latence.
J'ai trouvé un projet qui n'était pas loin de répondre à mon besoin : Moreland
Son problème principal : il n'a juste pas de support labwc/wlroot.
Qu'à cela ne tienne, je n'ai aucune expérience en Rust… alors passons par un LLM.
J'ai pu forker et ajouter le support labwc/wlroot ainsi que la visibilité du curseur matériel grâce au LLM : Moreland-labwc
Voila, une poignée de lignes modifiées et mon fork de moreland intègre le support labwc/wlroot à présent.
Reste à créer une sortie virtuelle. Et ça, labwc sait le faire nativement !
Dans mon rc.xml j'ajoute mon keybind pour créer et supprimer cette sortie virtuelle :
<keybind key="W-t"> <action name="VirtualOutputAdd" output_name="moreland"/> <action name="Execute" command="sh -c 'sleep 0.2; ~/Scripts/moreland-start.sh'"/> </keybind> <keybind key="W-S-t"> <action name="Execute" command="pkill -x moreland"/> <action name="VirtualOutputRemove" output_name="moreland"/> </keybind>
Et mon script moreland-start.sh :
wlr-randr \
--output moreland \
--custom-mode 2560x1810@120Hz \
--pos 6002,0
if ! pgrep -x moreland >/dev/null; then
nohup moreland --fps 120 --position 6002 \
>/dev/null 2>&1 &
fi
J'ai choisi 120Hz plutôt que 144Hz parce que la latence était diablement meilleure, et à l'oeil voir les 24Hz manquants faut être quand même bien rodé…
C'est déjà fini… On branche sa tablette en USB et on utiliser notre keybind défini (super + T) pour créer notre sortie virtuelle et déclencher le script.
Partage d'écran sur la tablette, ici on voit la waybar en bas, une fenêtre Discord en fullscreen et une fenêtre Steam par-dessus. Désolé pour la qualité, c'était une photo POC pour un ami plutôt qu'une illustration de journal…
Je n'ai pas pu utiliser la résolution max de ma tablette parce qu'il y a visiblement un petit problème sur l'allocation de surfaces intermédiaires VA. Je n'ai pas cherché à résoudre ce cas parce que c'est très utilisable pour moi dans ces conditions, augmenter la résolution risque de réduire de trop la lisibilité pour moi.
Je n'ai pas proposé la PR en upstream parce que j'ai vibecodé et n'ai aucune maîtrise de Rust comme précisé précédemment. Cependant j'ai ouvert une discussion pour que l'auteur de Moreland soit au courant de ce qui a été fait sur le fork et qu'il puisse librement le rapatrier en upstream s'il estime ça pertinent :
https://github.com/adiimanav/moreland/discussions/5
J'ai décidé de partager avec vous ici pour compléter le journal de Sébastien Rohaut. Je trouve ma solution plus élégante parce qu'elle utilise uniquement les possibilités natives de Wayland, wlroot et VA API. Et elle est franchement simple à mettre en place. En contrepartie ça ne fonctionne qu'avec des GPU AMD et des DE/compositors supportés; en USB… Et X11 n'est évidemment pas supporté.
Et si ça vous intéresse, l'auteur de Moreland a l'air ouvert à la discussion pour intégrer des nouvelles features / corrections.
Désolé pour le côté un peu décousu et destructuré du journal, on est plus proche du billet de blog. Mais j'ose espérer qu'il servira à d'autres :).
# Recette labwc
Posté par Florian13 . Évalué à -2 (+1/-0).
J'ai lu surtout pour le bout labwc.
VirtualOutputAddpose un output nommé,wlr-randrle positionne, USB derrière. Recette courte, collée au compositor.Le fork Rust, bof. Une discussion GitHub plutôt qu'une PR vibe-codée collée à l'upstream, ça me va. L'auteur de Moreland n'a qu'à reprendre ou laisser tomber.
[^] # Re: Recette labwc
Posté par Nibel . Évalué à 2 (+0/-0). Dernière modification le 23 septembre 2026 à 12:43.
Je pensais avoir répondu à ton commentaire mais visiblement j'ai du fermer la fenêtre avant d'envoyer.
Au final le fork n'aura pas vécu bien longtemps, l'auteur a apprécié la contribution et l'a remonté rapidement en upstream en l'adaptant légèrement pour respecter ses conventions.
Le repo du fork a été supprimé car devenu caduc.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
# A tester
Posté par Sébastien Rohaut (site web personnel) . Évalué à 3 (+1/-0).
Merci pour la référence :)
C'est une avancée, de pouvoir utiliser Wayland. Il faudrait donc que je réinstalle une distrib Wayland pour tester ta solution, mais tu dis que ça ne fonctionne qu'avec des GPU AMD. La doc de Moreland indique juste VA-API :
A GPU with VA-API encode - AMD, Intel, or NVIDIA via nvidia-vaapi-driver
Est-ce à dire que tes modifications ne fonctionnent qu'avec AMD ?
Je vois aussi qu ça ne fonctionne qu'avec Android. L'avantage d'autres solutions est aussi de pouvoir utiliser n'importe quoi (PC, Mac, tablette, sous n'importe quel OS) via un navigateur compatible HTML5. Pourvu que l'auteur en tienne compte dans l'avenir.
[^] # Re: A tester
Posté par Nibel . Évalué à 3 (+1/-0).
J'ai été très imprécis sur ce point. L'auteur le précise un peu plus bas la compatibilité Intel / Nvidia VA-API est possible mais non testée. Et je n'ai pas de quoi tester non plus dans un de ces contextes.
J'ai réutilisé le fonctionnement existant de Moreland en l'adaptant pour le fonctionnement spécifique de labwc/wlroots. Ce compositeur ne dispose pas d'API de création à l'exécution mais labwc permet de créer une sortie virtuelle headless. Je branche seulement Moreland a cette sortie virtuelle une fois qu'elle est crée.
Donc si Moreland et labwc/wlroots fonctionnent avec Nvidia VA-API, mes modifications devraient également être compatibles.
Je sais que Nvidia a eu longtemps une implémentation de Wayland particulière et j'en ai conclu un peu vite que ce n'était pas compatible. Mon mauvais, c'est à tester.
Oui en effet, c'est une solution puremment Android pour le coup, bonne remarque. Les solutions que tu as proposé ont effectivement l'avantage d'être plus généralistes. Mais de fait c'est aussi plus difficile d'avoir des performances au plus proche de ce que l'écran de la tablette permet nativement, ce qui était spécifiquement mon point d'intérêt.
Dans tous les cas, merci pour ton journal qui m'a grandement inspiré et m'a fait sortir de ma procrastination maladive le temps d'une contribution.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
# Fréquence
Posté par steph1978 . Évalué à 1 (+0/-1). Dernière modification le 07 octobre 2026 à 11:29.
Sachant que la persistance rétinienne ne permet de distinguer que 20 images par seconde, au delà de 30Hz, ça joue surtout sur un "celui qui veut avoir la plus grosse" largement exploité par les vendeurs.
[^] # Re: Fréquence
Posté par Nibel . Évalué à 3 (+1/-0).
C'est une absolue connerie.
Et je te le démontre en 1s si tu as des yeux fonctionnels et un écran capable d'aller au-delà de 30Hz (la norme bureautique étant 60Hz) :
https://testufo.com/
Tu vois la différence en 30 FPS et 60 FPS. Et je vois la différence, comme des très nombreux joueurs, entre 60 FPS et 120 FPS. Au-delà je ne commence en effet à ne plus percevoir la différence.
http://www.100fps.com/how_many_frames_can_humans_see.htm
Un pilote de chasse, donc un individu entraîné, est capable de discerner un avion sur une photo flashée pendant seulement 1/220ème de seconde. Il est donc capable de suivre au moins 220 FPS.
Et vraiment, je comprends même pas qu'on puisse encore sortir cette ineptie en 2026. N'importe qui est capable d'en faire l'expérience par soi-même.
Jouer en 30 FPS, c'est une torture quand t'as goûté au high framerate.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Fréquence
Posté par steph1978 . Évalué à 4 (+2/-0).
Y avait sûrement moyen de le dire plus délicatement mais merci pour l'explication.
En creusant, je lis en effet qu'il n'y a pas de lien direct entre persistance rétinienne et rafraîchissement de l'écran ou du moins qu'il y a d'autres mécanismes qui rentrent en jeu.
Je ne suis pas joueur de jeux vidéo et très peu cinéphile donc il se peut que je n'ai pas eu l'occasion d'en faire l'expérience.
Sur tes conseils d'une infinie sagesse, je vais aller faire soigner ma connerie aiguë. Je croise les doigts pour que la médecine y puisse quelque chose. Et je vais aussi essayer nettoyer tout les inepties qu'elle a pu produire, espérant qu'elles ne soient pas trop encrassées. Merci encore.
[^] # Re: Fréquence
Posté par Nibel . Évalué à 6 (+4/-0).
Pardon pour la virulence de mes propos.
Je ne souhaitais pas paraître méprisant.
J'ai sans doute était un peu direct parce que ce sujet est récurrent sur Internet et si je peux le comprendre sur un espace moins technophile, c'est vrai qu'ici je m'attends (à tord) à ce que cette légende urbaine (ça ne sert à rien d'avoir +24 FPS) soit déjà acquise comme telle.
Parce qu'il est très simple d'en faire soi-même l'expérience au moins entre 30 et 60 FPS. Au-delà il faut du matériel adapté, j'en conviens.
D'autant plus que j'ai identifié ton pseudo et je sais que tu es un intervenant régulièrement intéressant et pertinent.
J'aurais du être effectivement plus délicat. Je te présente mes excuses.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.