Tarnyko a écrit 474 commentaires

Là où je donne raison à ton commentaire David : on avait un gros truc monolithique et dépassé (X11/X.org).

En passant à Wayland, on a supprimé le code dépassé, et en même temps :
- on a réinternalisé une toute petite partie de ce qui était omis par X11 (le window manager p.ex.) ;
- on s'est abstenu d'internaliser d'autres chose qui sur d'autres OS le sont depuis toujours (les widgets p.ex., largement pris en charge sous Nunux par des toolkits genre GTK/Qt);
- on a externalisé/délégué la partie initialisation bas niveau de l'affichage (qui se retrouve maintenant éclatée entre les différents compositeurs).

C'est un cas un peu unique dans le soft. D'une certaine façon, c'est très UNIXien dans le sens "modularité". Il se trouve que ça convient très bien à certains domaines comme l'embarqué, qui veulent remplacer et optimiser chaque brique facilement.
Mais ceux qui pensaient que ça aiderait le desktop ou simplifierait la partie "code commun" en sont pour leurs frais ;-).

Weston (le compositeur de référence), GNOME et Enlightenment ont chacun leur propre implémentation.

À noter que :
- Weston fournit une lib réutilisable du genre de wlroots. Qu'elle n'ait pas été si utilisée indique soit ses limites, soit le manque de commu autour  ;
- KDE s'appuie aujourd'hui beaucoup l'implémentation de Qt. Celle-ci est très utilisée dans d'autres contextes, notamment dans l'embarqué.

Céça !

Mais en gros, l'API Wayland, c'est plus chose de xcb que de la Xlib.
Un protocole plus bas niveau et asynchrone, qui expose davantage les rouages dans le but avoué du projet : éviter le tearing.

Alors oui effectivement, une API utilisateur à la SDL va s'occuper de ça pour les devs pressés…
…mais il faut relativiser le jugement :

1. Le coeur du protocole est très propre AMHA (la découverte des interfaces et leurs versions !);
2. Concrètement, la version de seulement 450 lignes utiles d'ici, -réduite à l'aide d'une lib "helper" officielle du projet- c'est pas plus long qu'une appli X11 qui essaie de fonctionner correctement sous les window managers de GNOME, KDE…et le reste du monde.

On y a pas mal gagné sur l'existant quand même, et je trouve pas ça si compliqué !
Juste le rendu software basé sur des concepts UNIX un peu avancés (mémoire partagée) oui ça faut l'apprivoiser.

Oui, et je trouve que ça ringe moins 😶.

Soutien clair et total.

La meilleure explication à mon sens.
Court et précis. Merci :-) !

Non mais d'accord :-D.
En ce qui me concerne c'est bien plus une affaire de sécurité !

Après là j'avoue, c'est surtout un "jeu" de comprendre le détail des choses. L'existant marche quoi qu'il arrive !

Mes pièces rouges : memset() casterait "volatile char*" en "char*", ce qui retirerait l'effet du "volatile".
C'est tout simple et cité plusieurs fois sur Stack Overflow entre autres.

Je viens d'essayer ça :

memset((volatile char*)password, 0, 16);

et ça m'a affiché :

memset_explicit.c:90:12: warning: passing argument 1 of ‘memset’ discards ‘volatile’ qualifier from pointer target type [-Wdiscarded-qualifiers]

Un avis là-dessus ?

Exact David !
D'ailleurs, et sans rapport direct… au début, la fin du code ressemblait à ça :

    puts("Your password is still in memory... Inspect it now! (press any key...)");
    getchar();

    memset(password, 0, 16);

    puts("Your password is now cleared! (press any key...)");
    getchar();
    return 0;  
}

C'est-à-dire qu'il y avait une séquence "puts()/getchar()" supplémentaire entre le memset() et le return final.
Eh bien dans ce cas-là… le compilateur n'optimise pas non plus ! Car il s'agit de fonctions d'I/O et il considère que ça peut interférer avec les buffers -;). (dit autrement : c'est sensible !)

En fait, comme le dit @David Demelier ci-dessous (et si j'ai bien interprété sa réponse qui avait l'air en rapport),
appliquer "volatile" à la variable ne va pas forcément empêcher le compilo de la sortir, comme cité ici (même si je reconnais que c'est capillotracté, et perso je n'avais même pas réussi à le reproduire).

C'est pour cette raison que, sur le conseil d'un ami qui se reconnaîtra -cf les logs de commit ;-), j'ai appliqué la même logique que la bibliothèque Botan en le mettant plutôt sur le pointeur de fonction.

Effectivement !
Et en effet si tu regardes, c'est ce qui est fait ici dans le pire des cas :

// ici on gère toutes les architectures connues
#else

static void* (*volatile memset_explicit_unk)(void*, int, size_t) = memset;

#endif

Je dis le "pire", car cela fait une indirection qui tape sur le pointeur de fonction de la lib C.

Très suffisant bien sûr ! Mais juste potentiellement moins efficace que d'avoir soit :
- une implémentation locale qui tirerait un assembleur adapté ;
- son propre assembleur adapté :-)
et le fait que ça verrouille une petite zone mémoire pour le besoin.

(tu le sais bien sûr, mais je précise pour les non-initiés : il ne faut pas appliquer "volatile" sur la variable de la zone à effacer -ici "password"- mais sur l'appel de fonction comme ci-dessus)

Propre (même si je n'utilise pas Clang) !

Pour ceux qui passeraient rapidement et auraient du mal à saisir: memcpy() est une fonction C bas niveau qui permet de copier rapidement une zone mémoire "telle quelle".
Ça ne pose pas de problème en C lui-même ; mais en C++ qui est un langage objet plein de magie (smart pointers, références, constructeurs et destructeurs…), lui passer un objet de ce genre n'est justement 1) en général pas ce qu'on veut vraiment faire 2) un portail potentiel vers le fun !

Ouais il triche.
Limite il fait du poutaclique.
Mais comme c'est mon langage de réf', je râle pas -encore- trop ;)

Par exemple ?

Je me goure ou alors c'est le cas d'usage typique du Flash ;-) ?

Installé… parfait, ça marche, merci !

Maintenant il me reste à trouver 1) un ami 2) un 2ème Android
pour tester toussa 😉.

Wow, merci pour la réponse 😀!

Eh bien du coup, je te le confirme, preuve à l'appui :

09-27 21:12:54.142 31981 31981 E AndroidRuntime: FATAL EXCEPTION: main
09-27 21:12:54.142 31981 31981 E AndroidRuntime: Process: bim.app, PID: 31981
09-27 21:12:54.142 31981 31981 E AndroidRuntime: java.lang.NoSuchMethodError: No static method createPredefined(I)Landroid/os/VibrationEffect; in class Landroid/os/VibrationEffect; or its super classes (declaration of 'android.os.VibrationEffect' appears in /system/framework/framework.jar!classes2.dex)


Hello Julien, ça a l'air cool !

Juste, parmi les infos souvent omises que j'aurais aimées trouver sur la page des releases, il y aurait la version minimale d'Android et les éventuelles dépendances (genre Google Play framework etc).

Ma remarque n'est pas innocente : j'ai installé l'APK et il ne démarre pas sur mon Android 9 habituel (bref écran noir, puis retour au homescreen).
Je n'ai pas le nécessaire ici pour t'en dire plus avec Logcat (ou son équivalent); par contre si tu veux bien me renseigner, je peux regarder -pour lundi au plus tard.

google à décidé d’arrêter google pay sur android 8

Il n'y a jamais vraiment eu de solution à ça ; ni sur Android, ni ailleurs.

Sinon les astuces sont sympa !

En réalité, je viens de regarder, tout dépend du contexte…

NVIDIA fournit-lui même des compositeurs Wayland pour ses distribs embarquées, par exemple DriveOS :

The full source code to the NVIDIA implementation of Weston is in:
drive-linux/samples/wayland/weston

(le code source en question nécessite un compte développeur NVIDIA)

Sur Wayland, je quand même assez d'accord qu'il ne cherche réellement à supporter que les OS qu'il fournit lui-même (Tegra et DriveOS). Dans ce contexte, un Linux non-standard et encore pire *BSD, ué on en est loin.

Merci beaucoup pour le tuto!
Ne prévoyant pas d'utiliser IPv6 dans l'immédiat, c'est surtout la partie UPnP qui m'a interessée : ne la connaissant qu'en utilisateur côté desktop, une install serveur me permettrait de faire des ajustements pour plein de cas.

Ici effectivement le cas est plus complexe: ces interfaces des drivers NVIDIA sont une cible mouvante. On a besoin d'une version récente du système graphique (modules noyau compris) sans sacrifier à la stabilité sur le reste de l'OS…
Les mecs qui bossent dessus ont typiquement une install sur mesure. Là c'est déjà pas mal que ça marchotte.

Ah OK. Dommage… ça a l'air à la fois plus grave et pas lié au GPU; mais tout est possible avec des drivers :).

Après on peut demander à Weston de logger extensivement :

weston --backend=drm --renderer=gl --log=$HOME/weston.log

peut-être y aura-t-il des lignes intéressantes à partir du moment où on perd l'input?

Intéressant.

Et ça, ça ressemble à un problème avec libinput.
Dans le temps Weston utilisait udev comme Xorg; par contre le réactiver c'est pas trivial, c'est un flag à la compil' (si tant est que le code existe encore).

Tu peux encore switcher vers une console fullscreen (avec [Ctrl]-[Alt]-[F4] p.ex.) quand ça se produit ?
Si oui, que se passe-t-il en retournant à Weston (qui lui doit être mappé sur [F1] ou [F7] de mémoire) ?

Aujourd'hui, les 2 drivers ont normalement le nécessaire pour faire tourner Wayland.

Plutôt que Sway (je crois basé sur wlroots), pourrais-tu essayer le compositeur de référence Weston -en général plus à jour sur le support des derniers drivers?

sudo apt install weston
weston --backend=drm --renderer=gl
# en cas d'échec:
# weston --backend=drm --renderer=pixman

Il contient une icône pour lancer un terminal; tu peux ensuite lancer ce que tu veux à partir de là.

Et aussi, je suppose que tu utilises un navigateur… si c'est une base Chrome, il faut savoir qu'il abuse d'extensions Wayland/GL vraiment spécifiques et pas bien gérées partout.
Pourrais-tu voir si ça se produit davantage avec lui; et si oui, éventuellement essayer Firefox par comparaison?