antistress a écrit 4409 commentaires

Ah ben ça c'est abordé dans la présentation de Martin Peres & Timothe Ravier à XDC2012 dont les slides sont ici (p 20-21) :

Proposal: a MAC framework

Mandatory Access Control

• Control enforced by the system (mostly the kernel);
• Based on a policy (no unprivileged user control).

Suggestions

• Should be implemented as a library to unify access control on every wayland compositors;
• Should define which applications are allowed to take screenshots/act as virtual keyboards/copy & paste/drag & drop/register global shortcuts. . .
• Generic model, could look like or be polkit; Integrating SELinux to use policy mecanisms.

Tiens un développeur Nouveau ("inactif" ?) grenoblois :-)

Merci pour ce point, tu viens de me faire comprendre en quelques lignes ce que j'avais du mal à réaliser depuis un bout de temps, en assimilant un peu vite OpenGL avec les fonctions 3D des puces graphiques

Il y aussi Cairo-gl que Lucas n'aborde pas ?

J'ai trouvé ceci :

the isolation between applications is a major issue of the traditional X11 model. It is well known that any application connected to X11 server can listen on arbitrary events.
Under the Wayland model, the application recieves only mouse and keyboard events only when it has
focus. The application can't steal events from other application. So this is much improved design.

http://lists.freedesktop.org/archives/wayland-devel/2012-June/004078.html

Par contre j'avais lu qu'avec Wayland on pouvait ouvrir une fenêtre(*) transparente faisant tout l'écran qui permettrait d'écouter le clavier ?

(*) je ne suis pas sûr du terme, désolé je ne maîtrise pas le sujet

N'hésite pas à balancer : c'est Hachette qui est rétrograde.

D'après ce qu'on peut lire les GPU NVidia sont inutilement complexes (sans doute comme les CPUs x86, obligés de se coltiner l'antériorité)

comparer :

NVIDIA doesn't know how to design simple hardware.

https://plus.google.com/108010086967233476835/posts/iy21rLJfeCk

et :

"From a technical point of view, ARM's Mali GPU is the perfect candidate for a reverse engineering project. The hardware is well structured and beautifully simple. The driver stack is equally structured and highly logical. The kernel interface is kept simple and sane. Compared to some of its competitors, the Mali is a thing of beauty. It gives this driver developer the same buzz that the original ATI R500 display engine did when implementing the radeonHD driver."

Luc Verhaegen does applaud the ARM Mali GPU design as being "clean" since their driver doesn't require any micro-code to be loaded manually nor does it do any register banging from user-space. This does help in the reverse-engineering process.

http://www.phoronix.com/scan.php?page=article&item=arm_mali_reverse&num=2

ah non, ça ferait un nouvel app store centralisé, il vaut mieux que chaque libraire gère son store

Certains commentateurs y voient de l'ironie http://phoronix.com/forums/showthread.php?55818-The-Linux-Kernel-Power-Issues-Continues-To-Bite-Users#post213861

ah oui, en effet, c'est un peu chien !

J'avais suivi ça vaguement, d'après ce qu'il avait dit il avait à débusquer le lièvre ? Auquel cas il peut s'en vanter.
Je suis pas sûr de comprendre la phrase anglaise

L'embargo sur certains bugs "afin de maximiser les profits"

Je n'ai pas compris ?

Tu peux même reprendre l'affirmation de Dave Airlie : ça ne permet pas l'écriture d'un pilote Mesa/Gallium.
(contrairement à ce qui est écrit dans la dépêche)

Alors Bravo !
C'est ce que j'avais compris quand j'avais fait un billet sur le projet :-)

Moi je suis assidûment Phoronix, le site n'a pas vraiment d'équivalent pour savoir ce qui se passe en cuisine

Je ne dis pas que vous auriez pu faire autrement, mais je soulignais que le commentaire précédent laissait entendre des choses partiellement inexactes.

Si j'ai bien compris TEA permettra d'avoir des app stores décentralisés en reproduisant le modèle des libraires actuelles (chaque librairie pourrait avoir son app store), à la façon du Mozilla Market Place ? Si c'est ça c'est un immense progrès.

Mais je trouve un peu rabat-joie de ne pas vouloir admettre que c'est tout de même une avancée d'avoir un morceau propriétaire en moins.
Oui, il reste un "firmware" fermé et visiblement incontournable, mais c'est déjà le cas pour beaucoup de matériels.

Tant qu'à faire, au lieu d'écrire que Broadcom avait libéré le pilote, ils auraient pu écrire qu'ils libéraient toute l'informatique.
Reconnais que ça aurait été un peu rabat-joie de ne pas vouloir admettre que c'est tout de même une avancée d'avoir un morceau propriétaire en moins.

Tea n'est pas opposé aux DRMs d'après ce que je lis.

Faudrait mettre à jour la dépêche, la fondation rpi a un peu annoncé n'importe quoi au final…

https://github.com/pathscale/pscnv/wiki

(plus d'infos dans une prochaine dépêche)

. KWin décorant lui-même les décorations, les logiciels KDE ne décoreront pas leurs fenêtres ;
. GNOME, Xfce puis les autres suivront probablement la même voie, ne serait-ce que pour que les logiciels KDE lancés sous GNOME aient des décorations.

Intéressant, j'ai jeté un œil :
Client Side Decorations est prévu dans GTK+ : pour GNOME, Xfce ou les deux ?
Mais c'était déjà prévu du temps de X.Org, indépendamment de tout plan concernant Wayland
En tout cas c'est toujours noté "to do" sur la roadmap

Bref, difficile de connaître les plans de GNOME et Xfce avec ces éléments

Accessoirement GTK+ relève ces avantages :

This involves better RGBA window support in the toolkit and improved mouse cursor handling.

Concernant KWin

I plan to support server side decorations in KWin. My main concern is inconsistency, I fear that GTK windows will look different than Qt windows and that’s something we should try to prevent IMHO.

Ça explique pourquoi d'après chaosreigns, Qt5 prend en charge Wayland sauf client side decorations (mais vu que Qt vise l'embarqué, faudra voir quel compositeur est utilisé là bas).

Bref, on sait que KDE n'utilisera pas Client Side Decorations, à part ça…

Même lien que donné ci-dessus :

We intend to write a portability layer that will allow the BSDs to use as much of the Linux drm code as possible. The developers of X.org / freedesktop.org related graphics drivers have their current efforts focused on Linux because they have to get something working anywhere as fast as possible. It is the BSDs responsibility to keep up with these efforts and to contribute back to these developers to justify the developers continuing to generously license their drm code under terms compatible with those of the BSD licenses.

(je grasse)

Un lien de la dépêche qui t’intéressera énonce que les pilotes sont dorénavant KMS et que dragonflybsd a intérêt à coller à KMS pour continuer à avoir des pilotes graphiques.
C'est clairement prioritaire pour eux.
Après, X.Org ou Wayland… X.Org a été modernisé et marche quand même à peu près donc il y a pas urgence à embrasser Wayland, en tout cas moins d'urgence.

It is especially vital for Linux drm GEM, TTM, KMS code to be ported immediately to the BSDs because developers are in the process of removing userland modesetting code from current graphics drivers. To paraphrase what we have been told by freedesktop.org developers, if we do not port this code, very shortly the BSDs will be left only using the simplest VESA driver at 1024 x 768 resolution with no hardware acceleration.

We believe that limiting divergence from Linux's drm code is the clearest path for the BSDs to be able to follow the latest drm developments.

Oui, c'est plus précis dit comme ça

j'ai abandonné les contributions suite à ça …

Ça ressemble quand même à une mauvaise excuse.

Il faut bien comprendre que les avantages pour les développeurs, à savoir une implémentation simple, claire et facilement maintenable, aura des répercussions sur l'utilisateur qui profitera potentiellement d'un produit moins bogué et plus performant. Ce sont les deux facettes d'une même médaille.
Le but de la couche compatibilité X et de pouvoir continuer à utiliser les applis existantes telles que. Après faudra voir si ça marche…