đŸ’Ÿ Archived View for lord.re â€ș posts â€ș 144-sway â€ș index.gmi captured on 2022-06-03 at 23:07:19. Gemini links have been rewritten to link to archived content

View Raw

More Information

âžĄïž Next capture (2024-08-18)

-=-=-=-=-=-=-

Sway la suite spirituelle de i3

-------------------------------------------------

[13/12/2018] - ~6mins - #sway #linux #ux

-------------------------------------------------

J'utilise *i3 depuis bientÎt dix ans maintenant et ça fait maintenant prÚs d'un mois que j'ai migré sur Sway*.

Attends attends c'est quoi déjà tout d'abord ?

Son rĂŽle est donc de placer les fenĂȘtre Ă  tel endroit, les organiser, les afficher ou non.

Il permet également de gérer les raccourcis globaux pour lancer un programme ou une action lorsqu'il détecte une combinaison de touche.

Tout ça est possible, car la gestion de l'affichage sous Linux est basĂ© sur le protocole X11 qui dĂ©fini tout un tas de rĂšgles et propriĂ©tĂ©s


Bref on s'en fout un peu de tout ce blabla


X11 est donc un vieux protocole qui remonte à la moitié des années 80 et qui a subit des changements certes mais rien de bien folichon non plus.

Depuis le temps, vous vous doutez que le matériel et le logiciel a radicalement changé.

Maintenant certains concepts du protocole sont désuets et plus du tout adapté au matériel d'aujourd'hui.

Du coup, un ensemble de nouveaux protocoles ont été développés pour remplacer X11 : *Wayland*.

Beaucoup de devs de Xorg ont donc décidé de participer à cette nouvelle initiative depuis dix ans et depuis ça mûrit doucement mais surement.

Les plus gros environnements graphiques ont déjà (au moins partiellement) adopté Wayland (notamment GNOME et KDE).

Mais tous les gestionnaires de fenĂȘtre X11 n'ont pas encore commencĂ© la transition.

{{< img src="sway.thumb.jpg" link="sway.jpg" alt="Une capture d'Ă©cran prise lors de la rĂ©daction de cet article." title="Un petit aperçu de la bĂȘte." >}}

Il faut dire que contrairement à X11, Wayland a une architecture complÚtement différente.

Alors que sous X11, il suffit de peu de code pour implĂ©menter un gestionnaire de fenĂȘtre, sous Wayland, le concept mĂȘme de gestionnaire de fenĂȘtre n'existe plus.

En plus de gĂ©rer les fenĂȘtres, il faut gĂ©rer les entrĂ©s utilisateurs (claviers/souris/_), gĂ©rer les sorties (Ă©crans), gĂ©rer la composition d'affichage, gĂ©rer les fenĂȘtres


Bref il faut faire implĂ©menter tout le protocole Wayland et non juste apprendre Ă  manipuler les fenĂȘtre de X11.

À cause de cela, le foisonnant Ă©cosystĂšme de gestionnaires de fenĂȘtres pour X11 ne migrera pas vers Wayland.

Alors qu'avant c'était un ptit exercice de code pour un projet le temps d'un week-end pour les développeurs, implémenter l'équivalent pour Wayland est amplement plus compliqué et chronophage.

Mais heureusement certains projets existent pour faciliter la tĂąche aux autres devs.

Bon ok mais du coup sur Wayland, il y a quoi ?

Il est arrivé assez tÎt mais au fil du temps a été abandonné car le code a été bidouillé un peu dans tous les sens sans vision globale (pas étonnant pour un projet qui défriche une nouvelle techno).

Il est tout nouveau, tout beau pour le moment.

Il est développé par une communauté de devs issus de différents projets ayant monté un crowdfunding pour accélerer le projet.

Il sert de base à plusieurs projets comme *Sway (un simili-i3) mais aussi Way-cooler (un simili-awesome), pour ceux qui suivent réguliÚrement mon blog, Purism s'en sert de base pour leur Phosh* (interface pour téléphone portable sous Linux)


Le projet a donc déjà beaucoup plus de recul grùce à l'expértise acquise via WLC, on peut donc espérer qu'il saura se montrer robuste dans le temps.

On peut donc avoir un comportement identique entre Sway et i3.

La migration de l'un Ă  l'autre est donc transparente et sans douleur.

Ou presque.

Au départ, Sway était basé sur WLC mais cette lib a vite montré ses faiblesses.

Maintenant (tout du moins les derniĂšres beta) s'appuient sur wlroots et le projet atteint parfaitement son but d'ĂȘtre compatible avec i3.

Du coup pour migrer il faut ?

Déjà, faut *<kbd>emerge sway</kbd>* en veillant à bien prendre les beta de la branche 1.x et non les versions en 0.1x qui sont basées sur wlc encore.

D'ailleurs quitte Ă  migrer sur Sway, autant en profiter pour recompiler le plus de paquets possibles avec le support de wayland : dans /etc/portage/make.conf on rajoute <kbd>wayland</kbd> dans les <kbd>USE</kbd>. Puis un ptit *<kbd>emerge -UDnav @world</kbd>* .

Une fois fait il vous reste plus qu'à démarrer votre sway !

Bon dans mon cas je n'utilise pas *systemd ni elogind ni policy-kit et mon gestionnaire de session est qingy*.

Donc pour rajouter sway, on crée /etc/qingy/sessions/sway

{{< highlight "bash" >}}

! /bin/sh

if test -z "${XDG_RUNTIME_DIR}"; then

export XDG_RUNTIME_DIR=/tmp/${UID}-runtime-dir

if ! test -d "${XDG_RUNTIME_DIR}"; then

mkdir "${XDG_RUNTIME_DIR}"

chmod 0700 "${XDG_RUNTIME_DIR}"

fi

fi

exec /usr/bin/sway >> /var/log/sway.log

{{< / highlight >}}

Bon ça fait rien de bien palpitant : ça crée le dossier temporaire qui va bien et aprÚs ça lance sway.

Facile !

Ouai ouai.

Bon en vrai le fichier de conf i3 faut le compléter un peu.

PremiĂšre chose, ajouter la conf du clavier dans ~/.config/sway/config :

input 65261:24672:Lord_Corp_Kbd_0.1 {
  xkb_layout fr,fr,us
  xkb_variant bepo,,
}

Si ce n'est pas le cas, il faut passer tous les bindsym en bindcode c'est-Ă -dire virer tous les symboles et le remplacer par le keycode.

Pour avoir ça, il faut utiliser l'utilitaire *xev* et appuyer sur la touche correrspondante.

Exemple en bépo pour <kbd>é</kbd> :

KeyPress event, serial 34, synthetic NO, window 0x800001,
    root 0x39c, subw 0x0, time 15988577, (963,-103), root:(2190,1340),
    state 0x0, keycode 25 (keysym 0xe9, eacute), same_screen YES,
    XLookupString gives 2 bytes: (c3 a9) "Ă©"
    XmbLookupString gives 2 bytes: (c3 a9) "Ă©"
    XFilterEvent returns: False

Le keycode est donc 25.

AprĂšs la conversion c'est bon pour Sway.

Quelques ajustements dans l'environnement ?

Bon premier truc à savoir, par défaut Sway (si configuré avec le use <kbd>X</kbd>) fera tourner vos applis X11 via XWayland sans rien faire à tel point que vous ne vous rendrez pas compte si une appli est native ou non.

Et c'est le cas mĂȘme pour des applis qui semblerait difficilement compatible (genre *xclip* fonctionne bien) mais pourtant


Bon par contre aurevoir *scrot*.

Le meilleur outil pour faire des captures d'Ă©cran ne fonctionne pas mais il existe

Grim

qui s'en rapproche surtout lorsqu'on le couple avec

Slurp

.

Concernant *mpv, si vous aviez fait de la config particuliÚre, il faut désormais faire en sorte d'utiliser la sortie vidéo <kbd>gpu</kbd>*.

Concernant *QuteBrowser*
 bha mĂȘme s'il peut tourner nativement avec Wayland il a quelques soucis un poil chiant pour le moment, du coup je le fais tourner via XWayland.

Mais Ă  quoi bon ?

Bha c'est plus moderne.

Bon c'est aussi pour aider Ă  essuyer les plĂątres en reportant les bugs.

Mais il y a quand mĂȘme un avantage non nĂ©gligeable pour l'utilisateur de base : *Plus de processus tournant avec les droits root*.

D'un point de vue sécurité c'est excellent.

Qui plus est, il me semble que contrairement Ă  X11, les risques de keylogger sont bien moindres.

PS : et tout roule ?

Tout.

Sauf, les jeux.

- *GzDoom* ne sait pas gérer la souris comme il faut.

- *Quake3* ne sait pas locker la souris mĂȘme avec des builds issues de git.

- *RetroArch* tourne nickel.

PS 2020 : petite update

Alors tout roule encore mieux.

Les applis Qt tournent vraiment bien mieux désormais.

Plus de ptits bugs relous, le copier/coller fonctionne comme on l'attend.

Concernant les jeux plus de soucis.

Les jeux natifs tournent bien et au final j'utilise de moins en moins XWayland.

------------------------------------

🏠 Retour à la home

------------------------------------

[13/12/2018] [sway linux ux]

------------------------------------

[>> Suivant >>] ⏭ Une histoire de 'Magie'

[<< PrĂ©cĂ©dent <<] ⏼ Eternal Jukebox