pepp a écrit 82 commentaires

  • # Remonter le souci sur le bug tracker

    Posté par  . En réponse au message Laptop amdgpu et sortie externe. Évalué à 1 (+0/-0).

    Ma question est donc la suivante, est ce que ce comportement est attendu ?

    La mise en veille quand la carte n'est pas utilisée et les quelques secondes pour la réveiller : oui.

    Que le branchement sur le port HDMI ne réveille pas la carte : non.

    Je te suggère d'ouvrir un ticket ici : https://gitlab.freedesktop.org/drm/amd/-/issues/ avec les mêmes infos que celle tu as déjà indiquées ici + dmesg.

  • [^] # Re: Lapin compris

    Posté par  . En réponse au lien GTK 4.14 Adding Graphics Offloading Capabilities Under Wayland (via phoronix) - GTK Development Blog. Évalué à 10.

    Les dmabuf sont un concept dans le noyau qui permettent d'exposer une zone mémoire d'un composant matérial sous la forme d'un pseudo-fichier ; justement pour ne pas faire de copie.

    Par exemple, une application utilisant OpenGL va effectuer son rendu, et transmettre le contenu de la fenêtre au compositeur sous la forme d'un dmabuf fd (file descriptor). Ensuite le compositeur va pouvoir utiliser ce dmabuf comme une texture pour dessiner le bureau complet. Comme le rendu du jeu et du compositeur sont effectués sur le même GPU, il n'y a besoin d'aucune copie.

    Mais dans certains cas, comme j'imagine une vidéo ou un jeu en mode fenêtré, GTK va faire quelque chose comme ça pour dessiner la zone de la vidéo :
    1) faire décoder au GPU la vidéo -> le résultat est un dmabuf
    2) importer ce dmabuf qui contient la vidéo
    3) dessiner la vidéo
    4) exporter le résultat dans un nouveau dmabuf pour le compositeur

    Dans le cas général, le contenu du dmabuf obtenu à l'étape 4 sera exactement le même que celui obtenu à l'étape 1. L'optimisation décrite c'est de permettre de sauter les étapes 2, 3, et 4 et de directement transmettre le dmabuf de 1 au compositeur.

    L'étape d'après étant de sauter aussi l'étape "envoyer le dmabuf au compositeur" et à la place l'envoyer directement à la partie affichage du GPU pour dessiner la vidéo "au dessus" du bureau produit par le compositeur (direct scanout).

  • [^] # Re: HDR

    Posté par  . En réponse au lien Le HDR est en phase d'arriver sous Linux - Merci Josh Ashton & Valve. Évalué à 5. Dernière modification le 04 janvier 2023 à 10:53.

    Cette année à la XDC il y avait une présentation (en anglais) sur le support du HDR sous Linux : https://www.youtube.com/watch?v=yTO8QRIfOjA&t=21172s

  • [^] # Re: Groupe render

    Posté par  . En réponse au message Vulkan, switch user et software vs hardware renderer. Évalué à 1.

    Je pense que user1 est dans le groupe video pour avoir le droit de lancer Xorg.

    Comme ce groupe gère /dev/dri/card0, je suppose qu'user1 hérite de la possibilité d'ouvrir /dev/dri/renderD128 (vu que c'est le même GPU, avec moins de droits).

    Cela étant dit, la bonne façon d'accèder au GPU pour GL/Vulkan c'est d'être dans le groupe render.
    xhost permet uniquement de communiquer avec X ; il se trouve que pour les applis GLX c'est également un moyen d'avoir accès au GPU.

    (et donc si user2 est ajouté à render, il faudra quand même utiliser xhost pour l'autoriser à discuter avec X pour créer sa fenêtre etc)

  • # Groupe render

    Posté par  . En réponse au message Vulkan, switch user et software vs hardware renderer. Évalué à 1.

    Il faut que ton user2 soit dans le groupe render.

    Je pense que OpenGL fonctionne parce qu'il obtient l'accès au GPU via X/GLX alors que Vulkan requiert l'accès direct.

  • # Confiner les applications avec systemd

    Posté par  . En réponse au journal Durcir nginx et PHP avec systemd. Évalué à 6.

    Merci pour le journal.

    Comme je n'utilise pas nginx et php, j'ai cherché à utiliser ces possibilités pour des applications classiques (= pas des services).

    C'est possible en utilisant systemd-run.

    Par exemple, pour lancer un shell qui n'aura pas d'accès au réseau, et pour lequel le répertoire Home sera en lecture seule:

    systemd-run --user --property=PrivateUsers=true --property=PrivateNetwork=true --property=ProtectHome=read-only --wait -q --shell

    Ou encore pour lancer gedit sans accès réseau ni accès au Home:

    systemd-run --user --property=PrivateUsers=true --property=PrivateNetwork=true --property=ProtectHome=yes --wait -q gedit

    (PrivateUsers=true semble être nécessaire pour pouvoir utiliser PrivateNetwork=true sans droits particuliers)

    En utilisant un alias, ça donne un moyen simple de lancer des applis avec des droits limités.

  • [^] # Re: solution "simple"

    Posté par  . En réponse au message Désactiver les messages d'erreur d'un driver. Évalué à 2.

    Si le noyau supporte dynamic debugging (ce qui je pense est le cas sur Ubuntu) alors il doit être possible de l'utiliser pour désactiver ce log qui provient d'un dev_err avec quelque chose comme :

    # echo -n "file pl2303.c -p" > /sys/kernel/debug/dynamic_debug/control
    
  • # Contributeurs de code

    Posté par  . En réponse à la dépêche Sortie de GIMP 2.10.28 et nouvelles autour du projet. Évalué à 4.

    Contributeurs de code : bootchk, Des McGuinness, Ian Martins, Jacob Boerema, Jehan, Lloyd Konneker, Luca Bacci, Marc Espie, Massimo Valentini, Michael Bazzinotti, Michael McLaughlin, Øyvind Kolås, saul, Simon McVittie et Stanislav Grinkov.

    Oh… mitch (Michael Natterer) ne contribue plus à Gimp (cf https://linuxfr.org/news/entretien-avec-michael-natterer-mainteneur-de-gimp) ?

  • # Taille des images bis

    Posté par  . En réponse à la dépêche Sortie de 0 A.D. Alpha 25 « Yaunā ». Évalué à 10.

    Merci pour la chouette dépêche !

    Une suggestion d'amélioration pour la prochaine : 25 Mo d'images c'est beaucoup…

    Sur les 16 images, 3 sont en jpg, les autres sont en png (entre 1Mo et 4.5Mo chacune). En utilisant imagemagick ou https://linuxfr.org/news/sortie-de-yoga-image-optimizer-1-0 on peut diviser la taille de chaque image par 5 sans perte de qualité visible.

    Par exemple avec 1675011643_nightscene.png.5bc0141ea08e15c12daf172c2e5730b8.png :
    - version png : 4.7 Mo
    - version jpg (convert image.png image.jpg) : 1.1 Mo
    - avec jpegoptim en plus (jpegoptim -s -m85 image.jpg) : 730 ko
    - en webp (convert image.png image.webp) : 440 ko

    (PS : oui j'avais fait le même commentaire sur une ancienne dépêche https://linuxfr.org/news/0-a-d-empires-ascendant-rapport-de-developpement-septembre-2019-mai-2020, désolé pour la répétition :))

  • [^] # Re: intéressant mais ?

    Posté par  . En réponse au journal Écran déporté et Wayland. Évalué à 3.

    L'option de passer par le partage d'écran de Jitsi fonctionne et c'est la solution utilisée quand il y a des participants non présents dans la salle.

    Par contre quand tout le monde est sur place, c'est moins pertinent : la compression dégrade la qualité et la conso CPU sur le mini-PC est sans commune mesure avec la version waypipe (à la louche 100% vs 5%).

  • [^] # Re: Tracim

    Posté par  . En réponse au journal Logiciels libres dans une association non-informatique. Évalué à 3.

    de grosses nouveautés arrivent en septembre (temps réel, notifications, mentions)

    Ah chouette ! Je retesterai à ce moment là parce que c'est le principal retour négatif qu'on m'avait fait quand j'avais fait tester Tracim (les testeurs étaient perturbés par la latence entre chaque action "ça a marché ? ou faut que je reclique ?")

  • # Taille des images

    Posté par  . En réponse à la dépêche 0 A.D : Empires Ascendant, rapport de développement septembre 2019 - mai 2020. Évalué à 6.

    La dépêche est intéressante et bien détaillée, merci !

    Un bémol : le poids des images, environ 20mo. Les png qui n'utilisent pas de transparence pourraient être remplacés par des jpg. Par exemple en utilisant convert image.png -quality 75 image.jpg la taille est divisée par 10 sans que la qualité ne soit affectée.

  • # quadplay

    Posté par  . En réponse à la dépêche PICO-8, TIC-80 et les consoles imaginaires. Évalué à 3.

    Il y a aussi la quadplay : https://github.com/morgan3d/quadplay qui est sous licence LGPL3.

    Pour jouer : https://morgan3d.github.io/quadplay/console/quadplay.html

    La documentation est par là (générée avec un autre projet du même auteur : Markdeep)

  • [^] # Re: Paradoxale ?

    Posté par  . En réponse à la dépêche ONLYOFFICE ouvre le code source des éditeurs de bureau. Évalué à 8. Dernière modification le 19 octobre 2016 à 14:22.

    En gros la manip MSword -> Libreoffoce.writer -> MSword fait perdre de l'information de mise en page.

    Pourquoi supposes-tu que le format docx (ou sa spécification) est l'unique responsable ?

    Mon expérience me pousse à penser que l'implémentation dans LO est largement aussi responsable, voir plus.

    Cette présentation d'un dév LO : http://conference.libreoffice.org/assets/Conference/Bern/slides/SushilShinde.pdf semble en accord avec mon point de vue (cf page 12, 13 notamment) :

    Reasons For Data Loss
    - MS Office feature is not supported
    - XML Nodes not handled
    - XML elements not mapped properly
    - Properties lost in shape conversions

  • # Markdeep

    Posté par  . En réponse au journal Écrire des diagrammes de séquences. Évalué à 4. Dernière modification le 24 août 2019 à 15:01.

    Un autre outil qui génère peut servir pour générer des diagrammes (et plein d'autre choses) : Markdeep. (NdM: lien corrigé)

    Comme c'est du markdown on peut soit le créer / l'éditer à la main, soit faire un outil qui génére le markdown à partir d'un langage comme le tiens.

    Pour ton exemple ça donnerait ça: http://soupeaucaillou.com/test.md.html

  • [^] # Re: Comparaisons de budgets

    Posté par  . En réponse au journal La fin de Firefox OS. Évalué à 4.

    Le graph proposé par Michael Meeks pour la sortie de LibreOffice 5.0 est plus représentatif, même si les couleurs sont discutables (voir l'article original ou la dépêche linuxfr) :
    Titre de l'image

    On voit que les commits sont globalement partagés en 3 parts égales : Collabora (ex-SUSE), RedHat et «Assigned» (je suppose que ce sont les «Individual» de ton graph).

    La Document Foundation n'emploie pas (ou peu) de développeurs.
    Son budget est utilisé pour des appels d'offres pour des développements particuliers (LO pour Android par ex) mais surtout aider la communauté à développer LibreOffice (Hackfest, infrastructure, etc) ; cf le budget 2014 pour plus de détails.

  • [^] # Re: color2gray et organisation du code

    Posté par  . En réponse à la dépêche G’MIC 1.6.2.0 : Colorisation de BD, transfert de couleurs, aide au détourage et autres réjouissances. Évalué à 4.

    Le découpage en fichier correspond aussi en général au découpage fonctionnel

    Ça n'implique pas qu'un découpage fonctionnel nécessite un découpage en fichiers.

    un fichier cpp qui commence à faire plus de 1000 lignes, c’est probablement une classe qui a trop de responsabilités

    Comment ça marche si tu as 2 classes dans le même fichier ? ou 10 ?

    Bref, chercher à appliquer les mêmes règles à tous les projets me parait absurde au plus haut point. Si l'auteur préfére 1 fichier, tant mieux pour lui.
    Accessoirement, avoir 1 seul fichier a un énorme avantage : ça rend l'intégration dans d'autres projets triviale.

  • [^] # Re: Réémission

    Posté par  . En réponse à la dépêche Linphone 3.8 est sorti. Évalué à 8.

    Les I-frame (images complètes) sont assez espacées dans le temps en VoIP.
    Donc avant si tu avais une erreur dans le flux il y avait 2 options : demander une nouvelle I-frame (au prix d'une bande passante plus élevée) ou ne rien faire (image dégradée).
    Je suppose que ça permet de demander une I-frame "partielle" qui permet de corriger l'erreur sans faire exploser la bande passante utilisée.

  • [^] # Re: Nuances sur le nettoyage XSLT

    Posté par  . En réponse à la dépêche LibreOffice 4.4 : sous le capot. Évalué à 2.

    Si tu parles du fait que le code Python fait moins de choses dans le cas qui nous concerne, et est donc naturellement plus court, c'est le point principal que je voulais montrer, effectivement.

    Tu es sûr de ça ? LibreOffice a quand même pas mal de tests autour de l'import des doc/docx et ça m'étonnerait que Miklos ait accepté une solution qui introduise des régressions.

  • [^] # Re: Pas sûr que trouver des erreurs/la fiabilité soit si important pour la communauté libre..

    Posté par  . En réponse à la dépêche [code] Trouver les erreurs. Évalué à 2.

    Pour ceux qui aimerait avoir plus de contexte sur cette citation souvent utilisée, il y a un article intéressant à lire ici.

    (spoiler : l'usage courant de cette citation s'approche du contre-sens de ce qu'a voulu exprimer Knuth)

  • [^] # Re: Comparaison ?

    Posté par  . En réponse au journal Journal Bookmark #2. Évalué à 4.

    On peut faire beaucoup de connerie en Rust en unsafe

    Je n'en doute pas - je ne connais de Rust que le tutorial.

    Mais là encore c'est manquer l'objectif de Rust et de l'article : dans Rust tu peux faire des conneries en mode unsafe (en demandant explicitement le droit de les faire), en C++ tu peux faire des conneries tout le temps.

    mais ce n'est pas pour ça qu'il faut taper sur C++ pour le plaisir

    Ce n'est pas taper sur le C++ que de dire qu'il est facile de faire des erreurs avec, si ?

  • [^] # Re: Comparaison ?

    Posté par  . En réponse au journal Journal Bookmark #2. Évalué à 6.

    Pour le 'broken iterator', il y a plus que le problème de boucle; c'est qu'il touche au conteneur pendant l'itération; et on ne fait jamais ça en c++;

    C'est justement le but de son article. Il illustre comment Rust «protège» le développeur en l'empêchant de faire des trucs dangereux.
    C++ te laisse faire ce que tu veux, mais s'il s'avère que ton usage était foireux ça va planter à l'éxecution.
    Rust détecte et bloque les usages foireux à la compilation.

  • [^] # Re: reverse

    Posté par  . En réponse au journal Que faire des formats propriétaires qui n’aiment pas l’interopérabilité?. Évalué à 2.

    Tu es sûr que ce n'est pas simplement compressé ?

    Sinon avant d'attaquer avec un décompilateur ou autre grosse artillerie, je commencerais plutôt par produire plusieurs fichiers avec de légères différences et voir l'influence sur le fichier de sortie (ou par ex: est-ce qu'enregistrer 2 fois le même fichier change le contenu ? ou sa taille ?).

    En tout cas c'est un challenge intéressant :)

  • [^] # Re: Benchmark

    Posté par  . En réponse au journal Veuillez instancier ce journal avant de le lire. Évalué à 1.

  • [^] # Re: Benchmark

    Posté par  . En réponse au journal Veuillez instancier ce journal avant de le lire. Évalué à 3.

    chaque entité créé provoque une allocation égale à la taille de tous les composants

    Si tu utilises un vector par type de composant tu peux limiter sa taille du tableau à "entité_max qui a ce composant - entité_min qui a ce composant + 1".
    Mais oui, ce stockage gaspille de la mémoire

    Si tu as des idées d'autres layouts, je cherche de l'inspiration!

    Pas tellement. J'avais commencé avec une implémentation simple : chaque système avait une map.
    Après quelques tests et benchmarks (cf mon commentaire sur perf), chaque système contient finalement :
    * un tableau (brut) de Composant (moins coûteux qu'un vector)
    * un std::vector d'entités, pour savoir quelles entités ont ce composant. Ce vector est trié pour optimiser l'utilisation du cache quand le système est mis à jour.

    Rien de bien original, mais ça me suffit pour mon usage :-)