La sortie de la version stable 3.19 du noyau Linux a été annoncée le dimanche 8 février 2015 par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site kernel.org. Le détail des évolutions, nouveautés et prévisions se trouve dans la seconde partie de la dépêche.
Pour rappel, la page wiki rédiger des dépêches noyau signale quelques possibilités pour aider à la rédaction et s’y impliquer (ce que tout inscrit peut faire, ne serait‐ce que traduire^Wsynthétiser les annonces de RC).
Sommaire
- En bref
- Annonces des RC par Linus Torvalds
- Les nouveautés
- Le bilan en chiffres
- Appel à volontaires
En bref
- Architectures
- Changement dynamique possible de parties de l'arbre du device tree
- Gestion de Coresight, le traceur matériels pour processeurs ARM
- Développeurs
- Introduction de fonctions 64 bits pour la gestion du temps au delà de 2038
- Encore un nouvel appel système (!) :
execveat()
- Pilotes graphiques libres
- DRM : la gestion du mode graphique atomique approche à grands pas
- AMD/ATI : ajout du pilote AMDKFD pour la gestion de HSA
- Intel : gestion initiale de la famille Skylake
- NVIDIA : gestion initiale des nouveaux processeurs graphiques Maxwell
- Réseau
- Pilote pour la gestion des communications entre conteneurs
- Sécurité
- Intel Memory Protection Extensions (MPX)
- Correction de l'appel système setgroups()
- Systèmes de fichiers
- OverlayFS multi couche
- Données inline pour CephFS
- Virtualisation
- Gestion de Xen sur les systèmes non-cohérents
Annonces des RC par Linus Torvalds
RC-1
La version RC1 est sortie le samedi 20 décembre 2014 :
Donc, cela fait deux semaines à un jour près et la phase d’intégration est terminée.
Considérant combien de contributions sont arrivées tardivement, j’estime difficile de me préoccuper de quiconque déciderait de placer la limite plus loin que ceux qui l’ont déjà fait. Cela dit, il n’y a peut‐être aucun vrai retardataire — et à la vue de la taille de la RC1, il ne doit vraiment pas y en avoir beaucoup. Non seulement je pense qu’il y a plus de contributions qu’il n’y en avait dans linux-next : c’est historiquement une des plus grosses RC1 (du moins par les commits). Nous en avons eu de plus grosses (les 3.10 et 3.15 ont été précédées de longues phases d’intégration), mais ce n’était clairement pas une petite phase d’intégration.
En tout cas, nous avons eu des changements de tous les côtés, y compris une nouvelle architecture (Nios II). Mon « journal de fusion résumé » est joint et, comme d’habitude, je veux souligner qu’il attribue les contributions aux personnes me les envoyant, ce qui n’est en général pas du tout la même chose que les gens qui écrivent effectivement le code, même s’il y a évidemment un recoupement.
Dans les grandes lignes, cela ressemble à une sortie plutôt normale. À peu près deux tiers de mises à jour de pilotes, avec à peu près la moitié du reste qui sont des mises à jour d’architectures (et, non, les correctifs du nouveau Nios II ne sont pas du tout prédominantes, c’est à peu près pour moitié de l’ARM, dont la prise en charge du nouveau Nios II représente moins de 10 % des mises à jour d’architecture en nombre de lignes). Le sixième restant est « divers » : réseau, mises à jour des en‐têtes, documentation, systèmes de fichiers, outils et cœur du noyau (à peu près dans cet ordre).
Évidemment, les vacances arrivant, je m’attends à ce que les quelques prochaines semaines soient plutôt calmes, mais nous verrons bien. J’ose espérer que les gens auront le temps de tester cela entre tous leurs laits de poule,
Linus
RC-2
La version RC2 est sortie le dimanche 28 décembre 2014 :
Cette RC est minuscule, pour des raisons évidentes.
Je ne m’attends pas à ce que cela dure, mais nous aurons probablement une autre semaine de calme relatif avant un vrai retour à la normale.
À peu près 80 % de pilotes (le DRM formant la grande majorité), avec quelques petits correctifs concernant ARM64, l’audit et quelques petits mono‐lignes çà et là à d’autres endroits.
Linus
RC-3
La version RC3 est sortie le lundi 5 janvier 2015 :
Elle a été repoussée d’un jour — non pas à cause de problèmes de développement particuliers, mais simplement parce que je carrelais une salle de bain hier. Mais la RC3 est maintenant sortie, et les choses sont demeurées raisonnablement calmes. J’espère vraiment que cela signifie que le 3.19 a l’air bon, mais il est tout aussi probable que les gens récupèrent encore de leur période de vacances.
Un peu plus de trois quarts des changements concernent les pilotes — surtout du réseau, de la gestion de température, la couche de périphériques d’entrée, le son et la gestion de l’alimentation. Le reste est divers — systèmes de fichiers, infrastructure réseau, quelques correctifs d’architectures, etc. Mais l’ensemble est plutôt petit.
Donc, allez‐y, testez,
Linus
RC-4
La version RC4 est sortie le dimanche 11 janvier 2015.
Une autre semaine, une autre RC.
Les choses sont restées raisonnablement calmes, bien que nous ayons aussi eu quelques régressions de dernière minute dans la gestion de la mémoire. Heureusement, la plupart d’entre elles ont été corrigées rapidement, ne laissant qu’un problème avec ARM64 toujours en suspens.
Donc, allez plus loin et testez plus encore. Je serai en déplacement pour les deux prochaines semaines à cause du LCA, mais je devrais avoir Internet, et, si les choses continuent à être raisonnablement calmes, je ne pense pas que mon voyage soit réellement perceptible. Finalement, on est dans les temps, à l’inverse de plusieurs sorties de l’année dernière.
Quoi qu’il en soit, la version courte de mon journal de fusion en annexe donne les détails, mais à part les correctifs du
kgdbapparaissant comme une activité inhabituelle souskernel/debug/, les choses semblent plutôt normales : une majorité de mises à jour de pilotes (pilotes graphiques, pinctrl, HID, réseau), des mises à jour d’architectures (principalement x86 cette fois, quelques trucs mineurs pour ARM[64]) et quelques correctifs sur les outils (principalementperf).Linus
RC-5
La version RC5 est sortie le dimanche 18 janvier 2015 :
Une autre semaine, une autre RC.
Sortie plutôt normale, même si j’aurais souhaité qu’en RC5 nous nous soyons calmés davantage. Mais, non, avec les quelques inclusions dans l’arborescence des pilotes notamment, elle est en fait plus grosse que ne l’était la RC4.
Cela dit, ce n’est pas comme s’il y avait quoi que ce soit de particulièrement effrayant là‐dedans.
Le bogue mémoire ARM64 que j’ai mentionné comme mis en attente dans les notes de la RC4 a été corrigé un jour après cette précédente RC, et le reste a l’air plutôt standard. Surtout des pilotes (réseau, USB, cible SCSI, couche bloc, contrôleur mémoire, TTY, etc.), mais aussi des mises à jour d’architectures (ARM, X86, S/390 et quelques petites corrections sur PowerPC), quelques mises à jour de systèmes de fichiers (FUSE et NFS), des corrections de traçage et quelques corrections des outils d’analyse de performance.
La version courte de mon journal avec les détails est en annexe.
Allez‐y, testez.
Linus
RC-6
La version RC6 est sortie le dimanche 25 janvier 2015 :
Une autre RC, une autre semaine plus proche de la sortie. Et celle‐ci est légèrement plus petite que ne l’était la RC5, bien que plus petit encore serait toujours mieux.
Mais, comme la RC5, aucun des changements ne semble particulièrement effrayant et plus d’un quart ont été appliqués à la version stable, donc les choses ont l’air d’être sur les bons rails. Je m’attends, pour l’heure, à faire une RC7 la semaine prochaine, avec le 3.19 final dans deux semaines, selon le calendrier habituel.Les statistiques ont l’air tout à fait normales, avec un correctif comprenant à peu près 70 % de changements pour les pilotes (le retour en arrière d’un pilote pour les ordinateurs portables Dell représente le plus gros des correctifs, mais il y a le réseau, les médias, les pilotes graphiques, les entrée‐sorties GPIO, le son…) et à peu près 14 % de mises à jour d’architectures (x86 et ARM sont les plus grosses, mais il y a d’autres petites mises à jour également) et le reste se répartit un peu partout (mises à jour de documentation, du réseau, mises à jour de systèmes de fichiers — principalement Btrfs, etc.).
La version courte du journal des changements propose une sorte de résumé détaillé pour les gens qui veulent avoir une idée de ce qu’il s’est passé. Rien de vraiment particulier ne s’en distingue.
Linus
RC-7
La version RC7 est sortie le dimanche 1er février 2015 :
Tout semble être assez calme et normal, donc ce sera probablement la dernière RC, à moins que quelque chose d’inattendu ne survienne soudainement. Ce qui veut dire que j’aimerais voir plus de gens tester l’utilisation ce bébé [N. D. T. : chiot est le terme employé par Linus], juste pour validation.
Les statistiques de cette TC sont plutôt normales — à peu près 50 % de pilotes, 20 % de mises à jour d’architectures (pour la plupart ARM et ARM64, quelques x86), avec les systèmes de fichiers apparaissant un peu plus que d’habitude (largement dus aux changements dans le système de quotas), le reste étant « divers » — outils de test de performance, quelques changements mineurs dans le noyau et la mémoire virtuelle, etc.
Mais tout cela est assez petit. La version courte du journal des changements est jointe pour les curieux,
Linus
Version finale
La version finale est sortie le 8 février 2015 :
Alors, rien de bien passionnant et bien que que j’ai été tenté plusieurs fois de faire une RC8, il n’y avait vraiment aucune raison à cela.
À titre d’exemple, Sasha Levin a utilisé KASan et a trouvé un bogue intéressant dans les verrous tournants paravirtualisés. Mais, il s’est avéré qu’il était présent depuis toujours, et il n’est même pas évident qu’il puisse vraiment être déclenché dans la pratique. Nous le corrigerons et l’indiquerons dans la version stable, et aussi tentant que cela fût, ça n’était pas une raison valable pour retarder le 3.19.
Et les véritables corrections qui ont été faites (voir la version courte du journal de changements) étaient toutes franchement petites, à l’exception de quelques changements de taille moyenne dans InfiniBand qui étaient tous des suppressions de code qui n’était tout simplement pas prêt.
Donc, il est sorti — venez le récupérer. Et, par conséquent, la fenêtre d’intégration pour le 3.20 est évidemment désormais ouverte aussi.
Linus
Les nouveautés
Architecture
Allwinner
Cartes de développement
Deux nouvelles cartes de développement font leur apparition dans la liste des matériels supportés. La Banana Pi est une carte embarquée peu chère, très flexible et adaptée pour un usage au quotidien ou en tant que carte de développement. Pour un montant assez correct, vous disposerez d’un système monopuce Allwinner A20 (ARM Cortex-A7 double‐cœur, 1 GHz, processeur graphique Mali-400 MP2), de 1 Gio de mémoire vive DDR3, d’un connecteur HDMI et LVDS, de l’USB 2, du SATA, d’un contrôleur Ethernet Gigabit et d’un en‐tête d’extension où vous pourrez brancher plein de choses.
La A20-OLinuXino-Lime2 est une carte de développement en matériel libre produit par OLimex. Elle dispose d’un système monopuce Allwinner A20 (double‐cœur Cortex A7 cadencé à 1 GHz, un processeur Mali-400), 1 Gio de mémoire vive DDR3, un connecteur HDMI Full HD 1080p, un connecteur LCD (4,3″, 7,0″ et 10,1″), de l’USB 2.0, un contrôleur Ethernet Gigabit, un lecteur de carte microSD, un connecteur SATA et permet de connecter jusqu’à 160 GPIO. Ces deux cartes sont désormais prises en charge par le noyau Linux mainline.
A80
Le Allwinner A80, développé par la société Allwinner Technology, est le premier système monopuce de la série Allwinner A8X. Il dispose de l’architecture Big.LITTLE d’ARM avec huit cœurs, dont quatre Cortex A7 à basse consommation, et quatre autres cœurs Cortex A15 à haute performance.
La puce intègre un processeur graphique PowerVR G6230 gérant OpenCL 1.1, OpenGL 3.0, OpenGL ES Next 3.0 et 2.0. Par rapport à ses prédécesseurs, il intègre la prise en charge de l’USB 3, le décodage matériel H.265 et la prise en charge de caméras dont la définition peut atteindre 16 mégapixels.
Le Allwinner A80 est désormais pris en charge par le noyau. La carte de développement Optimus A80, sortie au même moment que le système monopuce, est également prise en charge.
Samsung Exynos
- gestion du nouveau système monopuce Exynos 4415 ;
- prise en charge de l’unité de gestion d’alimentation (PMU) pour les Exynos 5420 et Exynos 3250 ;
- gestion de la mise en veille en mémoire (suspend to ram) pour le Exynos 5420.
AMD Seattle
Les processeurs AMD Seattle sont maintenant gérés par Linux. Ce sont les premiers processeurs grand public de la firme AMD à être basés sur l’architecture ARM 64 bits (ARMv8-A Cortex A57) et non pas x86. Ils embarquent notamment un coprocesseur cryptographique.
Device tree overlay — surcouche d’arborescence matérielle
Le Device tree est une structure de données chargée au démarrage du noyau qui décrit la topologie et certaines informations matérielles. Le code du noyau qui gère certains microcontrôleurs ou même certains pilotes viennent ensuite y chercher des informations afin de s’initialiser correctement.
Cela permet d’avoir un code beaucoup plus générique avec moins d’informations codées en dur. Le souci est qu’il a été écrit de façon statique par ses créateurs, par conception et architecture logicielle. C’est extrêmement pratique et puissant pour exprimer plein de contraintes, mais cela reste lourd et complexe à mettre en place sur des cartes dont les possibilités matérielles ou la topologie peuvent rapidement changer, comme c’est le cas sur une BeagleBone ou une Raspberry Pi, par exemple.
Cette version du noyau introduit une nouvelle fonctionnalité : le Device tree Overlay. L’overlay est une fonctionnalité qui permet de venir modifier à chaud une portion de cette arborescence matérielle sur un noyau en train de tourner, ou de venir greffer une portion d’un autre device tree par dessus un autre qui est déjà en cours d’exécution. Cela va permettre de résoudre pas mal de problèmes, comme ceux évoqués plus haut.
Pour de plus amples informations au sujet du Device tree, je vous invite à lire ce paragraphe de notre précédente dépêche et cet article.
ARM Coresight
La technologie ARM Coresight est maintenant prise en charge par le noyau. Coresight est un mécanisme de débogage matériel d’un système monopuce ARM qui inclut une partie JTAG et une partie de traçage et de débogage de matériel et bus matériel assistée, nous nous focaliserons ici sur cette dernière.
Il est aujourd’hui très complexe de porter un nouveau système monopuce au sein du noyau ou d’un système d’exploitation temps réel, et de comprendre précisément et finement ce qu’il se passe à l’intérieur. Il y a, en effet, énormément de contrôleurs et de composants interconnectés : processeur graphique, contrôleur d’accès direct à la mémoire (DMA), processeur de traitement de signal (DSP), AMBA bus, etc. Cela peut rendre la tâche d’un développeur extrêmement ardue, afin de savoir quel signal est levé dans le processeur et à quel moment (IRQ, DMA), ou quel flux de données transite sur un bus. C’est précisément là que Coresight intervient.
Pour plus d’informations, vous pouvez consulter l’article écrit par Linaro sur le sujet.
Développeurs
Problème lié à l’année 2038
Le problème lié à l’année 2038 est toujours là. Les fonctions internes do_settimeofday(), timekeeping_inject_sleeptime(), et mktime() ont maintenant des remplaçants sûrs pour le bogue de l’année 2038. Dans chaque cas, la nouvelle version ajoute « 64 » au nom de la fonction, et passe au type time64_t ou timespec64 pour représenter le temps. Maintenant, il est possible de rendre obsolètes les anciennes versions et la conversion du code peut commencer.
Gestion des « interruptions hiérarchiques par domaine »
La prise en charge des interruptions hiérarchiques par domaine a été fusionnée au cœur du gestionnaire d’interruptions. Cette gestion est rendue nécessaire pour une prise en compte correcte du matériel complexe qui a de multiples contrôleurs d’interruptions, liés de différentes manières. Voir le nouvel article ajouté à Documentation/IRQ-domain.txt pour un peu plus d’informations.
ftrace
Les filtres utilisés à l’intérieur du sous‐système ftrace gèrent maintenant l’opérateur logique NON « ! » dans les expressions.
Option SO_INCOMING_CPU pour getsockopt()
Une nouvelle option de getsockopt() apparaît, SO_INCOMING_CPU. Elle retourne le processeur sur lequel un traitement est en cours pour une socket donnée. Les applications qui se servent de cette option, sur les grands systèmes, par exemple, mettront à profit le matériel à files d'attente multiples en répartissant le travail sur plusieurs processeurs.
Appel système execveat()
L’appel système execveat() rejoint les autres : comme pour les autres appels système terminant par at (à), il faut un descripteur de fichier pour le répertoire à utiliser comme point de départ pour trouver le fichier exécutable. Il sert aussi à exécuter un fichier binaire directement à partir d’un descripteur de fichier ouvert, pour une meilleure mise en œuvre de l’appel système fexecve(), trouvé sur d’autres systèmes de type UNIX.
Binder, le système de communication inter‐processus d’Android quitte la partie instable
Malgré quelques réclamations sur la liste de diffusion, le code du système de communication inter‐processus (IPC) Binder d’Android a été déplacé de staging vers la branche principale du noyau. En fin de compte, c’est une interface de programmation qui a été livrée sur des millions de systèmes et qui doit être gérée d’une manière ou d’une autre.
Pilotes graphique libres
Divulgation complète : Cette partie a été écrite par le contributeur habituel, mais celui‐ci travaille maintenant pour Intel. Son discours peut donc être biaisé. Ce contributeur a cependant affirmé sur son blog qu’il resterait factuel et juste envers tous les pilotes, comme il s’est efforcé de le faire depuis le début de ses contributions. Cette partie reflète uniquement son opinion et pas celle de son employeur.
DRM (Direct Rendering Manager)
Les travaux sur la gestion atomique du mode graphique avancent fortement dans cette nouvelle version. Pour rappel, grâce à cette gestion atomique, les applications telles que le serveur X peuvent changer les paramètres de tous les plans graphiques (exposés par l’interface de programmation universal plane, intégrée dans Linux 3.15) à la fois ; on évite aussi, par exemple, au compositeur d’utiliser les shaders plutôt que les plans graphiques pour le rendu vidéo. Ces plans graphiques sont plus efficaces, car ils sont généralement capables d’afficher les vidéos dans leur format natif (YUV) sans avoir à être convertis en RVB. De plus, ils sont généralement capables de redimensionner la taille d’une image de façon matérielle.
Sans la gestion atomique des plans graphiques, il est impossible pour un compositeur de migrer dynamiquement le rendu d’une image d’un plan graphique à un autre ou de faire la composition en utilisant des shaders. Une fois cette gestion stabilisée, il deviendra possible d’économiser de l’énergie grâce à cette technique. Pour l’instant, cette nouvelle interface est masquée par une option noyau. Plus d’informations sont disponibles dans la demande d’intégration 3.19 et sur le blog du mainteneur du pilote i915.
La deuxième principale nouveauté est l’ajout de deux nouvelles propriétés DRM afin de fournir une meilleure gestion des écrans par les processeurs graphiques virtuels [commit]. Ces propriétés en lecture seule sont à destination du serveur X et des environnements de bureau, afin qu’ils puissent positionner les écrans de la même façon que dans la machine hôte. Il faudra donc attendre quelques mois afin que le serveur graphique et les environnements de bureau utilisent ces propriétés. Le pilote de processeur graphique virtuel qxl, utilisé par KVM, a été modifié afin de lire ces propriétés depuis l’hôte avant de modifier les propriétés nouvellement ajoutées.
Comme d’habitude, la gestion de nouveaux panneaux a été étoffée, élargissant ainsi le paysage des plate-formes embarquées mues par des pilotes libres. Pour finir, une demande d’intégration de modifications diverses a été faite.
Pour plus d’informations, vous pouvez consulter la demande d’intégration DRM.
AMD/ATI (pilote Radeon)
Pour AMD, la version 3.19 du noyau apporte un changement très important, l’introduction du pilote AMDKFD (AMD Kernel Graphic Driver). Ce dernier expose une interface bas niveau aux applications utilisant le calcul générique sur un processeur graphique (GPGPU). Cette interface tire parti du modèle de programmation HSA (Heterogeneous System Architecture). Ce dernier vise une collaboration plus rapide entre le processeur graphique et le processeur central. Pour plus d’information sur HSA, vous pouvez consulter la page Wikipédia ou le site d’AMD. Pour plus d’informations concernant le code, vous pouvez consulter les demandes d’intégration.
Une autre nouveauté est l’amélioration de la gestion du ventilateur. Jusqu’à présent, le ventilateur était géré par un circuit intégré externe, configuré par le BIOS. Cependant, de nouveaux processeurs graphiques nécessitent maintenant une gestion du ventilateur par le noyau, comme c’est le cas pour le pilote Nouveau. Ce problème a été découvert et documenté dans un rapport de bogue par un utilisateur Radeon, il y a plus d’un an. Cet utilisateur a commencé par faire de la rétro‐ingénierie du pilote propriétaire grâce à l’outil MMIOTRACE, qui est également utilisé par le projet Nouveau et a trouvé la liste des écritures nécessaires pour gérer manuellement la vitesse du ventilateur. Cependant, en novembre, Alex Deucher d’AMD a fourni des correctifs plus complets, afin d’apporter cette gestion manuelle du ventilateur. Ces correctifs ont finalement été intégrés dans Linux 3.19. Il faudra cependant attendre au moins Linux 3.20 avant que cette gestion soit exposée via l’interface de HWMON. Pour plus d’informations, vous pouvez consulter le rapport de bogue qui détaille tout l’historique.
Outre ces changements, la gestion d’énergie pour la famille Canary Island s’améliore, ainsi que la gestion des espaces d’adressage par contexte graphique. Pour plus d’information, vous pouvez consulter les demandes d’intégration.
Intel (pilote i915)
Dans cette nouvelle version, le pilote i915 apporte une gestion basique des processeurs graphiques Intel Skylake qui succèdent à la famille Broadwell et qui devraient être disponibles à la vente en septembre 2015.
Malheureusement, contrairement à ce qui a été annoncé dans la dépêche précédente, la gestion du PPGTT (Per‐Process Graphics Translation Table) n’a pas pu être activée pour les processeurs Haswell à cause d’un bogue avec la gestion des contextes. Le PPGTT devrait cependant être activé dans Linux 3.20 pour les processeurs Broadwell.
La gestion atomique du mode graphique continue d’avancer, même si rien n’est encore utilisable. Dans cette nouvelle version, plusieurs portions du code ont été découpées en une partie de validation et une partie pour appliquer les changements. Le pilote prévient si une combinaison n’est pas possible avant de commencer à appliquer les changements. Une version préliminaire devrait être disponible dans Linux 3.20, si l’on en croit les dires du mainteneur i915.
La gestion des modes d’affichage en espace utilisateur — le User-based ModeSetting (UMS) —, ancêtre de l’actuelle gestion en espace noyau — Kernel-based ModeSetting (KMS) — qui fut introduite en 2009, commence à être supprimée du noyau. Il aura donc fallu 5 ans entre la suppression de la gestion du mode d’affichage en espace utilisateur dans le pilote X.Org xf86-video-intel et la suppression du code correspondant dans le noyau.
Étonnamment, cette nouvelle version apporte des correctifs pour des familles plutôt anciennes. Ainsi, les générations 3 et 4 ont reçu une meilleure prise en charge de la remise à zéro de l’état après un blocage du processeur graphique. De même, les processeurs graphiques i830M devraient avoir une gestion fonctionnelle de l’affichage.
Lors de la demande d’intégration, Linus a fait remarquer qu’un message d’avertissement était généré dans le journal noyau lors du démarrage. Après investigation, Linus « pas content » Torvalds a rappelé pourquoi il est inacceptable qu’une telle modification se soit retrouvée sur son ordinateur et a fait valoir son opinion en disant qu’il y avait un manque flagrant de tests.
Bien d’autres modifications importantes sont présentes dans cette nouvelle version. Si vous voulez en savoir plus, vous pouvez consulter l’habituel compte‐rendu détaillé des modifications de Daniel Vetter (mainteneur i915). Vous pouvez aussi consulter la demande d’intégration i915.
NVIDIA (pilote Nouveau)
Le changement principal pour Nouveau dans cette version est la gestion très préliminaire des nouveaux processeurs graphiques de la famille Maxwell. Il est maintenant possible d’avoir un affichage fonctionnel, mais sans aucune accélération. Cette accélération n’est en effet pas facile à fournir, car il est impossible d’envoyer le microcode de changement de contexte sans passer par le processeur de gestion d’énergie. Comme ce microcode doit nécessairement être signé par NVIDIA, Nouveau utilise celui inclus avec le VBIOS. Il reste donc à écrire ce microcode de changement de contexte.
NVIDIA a proposé de fournir son microcode avec les droits de redistribution, afin qu’il soit possible pour l’équipe de Nouveau de fournir une accélération graphique sur les générations futures. Malheureusement, il n’y a eu encore aucune concrétisation ; par conséquent, l’équipe ne sait pas quand l’accélération sera disponible.
NVIDIA poursuit son effort en ajoutant la gestion de la tension d’alimentation pour le GK20A présent dans le Tegra K1. Ce travail est indispensable pour la gestion du changement de fréquence, qui devrait arriver dans la prochaine version du noyau.
NVIDIA a également répondu à une question de Pierre Moreau (un troisième développeur Nouveau français actif !) concernant le rôle d’un registre qui, s’il est mal configuré, empêche Nouveau de fonctionner sur son MacBook Pro. Pierre a ainsi pu écrire un correctif qui a été accepté dans Linux 3.19.
GPU des systèmes monopuces
Le pilote Tegra pour les systèmes monopuces de NVIDIA a reçu la gestion des plans graphiques universels [commit]. Le pilote peut également utiliser l’IOMMU du système, lorsque celle‐ci est disponible. On évite ainsi, par exemple, d'allouer une grosse portion contiguë de mémoire, l’IOMMU se chargeant de mettre les pages dans le bon ordre dans l’espace d’adressage [commit]. Pour finir, plusieurs améliorations liées à l’affichage ont été faites pour les liens DSI. Pour plus d’informations, vous pouvez consulter la demande d’intégration.
Le pilote MSM, à destination des processeurs graphiques Adreno de Qualcomm, reçoit dans cette version la gestion de la famille a4xx. Pour profiter de la 3D, il sera cependant nécessaire d’utiliser Mesa 10.5, qui devrait sortir dans les prochaines semaines. Une autre amélioration majeure est la conversion du code d’affichage, afin d’utiliser la nouvelle interface de gestion atomique d’un mode graphique introduite dans cette version. Pour plus d’informations, vous pouvez consulter les différentes demandes d’intégration.
Le pilote Exynos, pour les processeurs graphiques Samsung, a reçu la gestion du système monopuce Exynos 4415, ainsi qu’un gros effort de nettoyage et débogage du code. Pour plus d’informations, vous pouvez consulter la demande d’intégration.
Réseau
La couche réseau a un nouveau sous‐système pour recourir au matériel approprié pour les fonctions de commutation et routage.
eBPF et socket réseau
Pour Linux 3.18, Alexei Starovoitov avait activement travaillé à introduire un nouvel appel système bpf(), couvrant la gestion de programmes BPF étendu. Ce système se veut générique et indépendant de la partie réseau. Ce sera un moyen d’envoyer depuis l’espace utilisateur des filtres compilés dynamiquement par LLVM à divers sous‐systèmes (réseau, sécurité). Cependant, dans la pratique, on ne pouvait pas encore utiliser la structure créée.
Une première implémentation pour les sockets réseau est maintenant disponible. Malgré le nom de Berkeley Packet Filter, la création de filtres n'est pas encore à l'ordre du jour. Pour l’instant, la structure n’a accès en entrée qu’au paquet réseau et non à toutes les métadonnées présentes dans la structure du noyau (skb). En sortie, elle n’a accès qu’à une table de hachage partagée avec l’espace utilisateur.
Cela en limite l’usage à la collecte de statistiques (des exemples sont disponibles), mais d’autres applications devraient être possibles dans les prochains cycles de développement.
Nouveau pilote pour gérer les connexions réseau entre conteneurs
L’interconnexion de conteneurs au travers de réseaux virtuels se fait grâce au nouveau pilote ipvlan. Ce dernier est conçu pour fonctionner avec les espaces de noms en réseau. Il est un peu comme le pilote macvlan existant, mais il fait son multiplexage à un niveau plus haut dans la pile.
Lors de la création de plusieurs espaces de noms, conteneurs ou invités (sous‐hôtes) sur un hôte, plusieurs modes de connexion au réseau sont généralement disponibles (hôte seulement, NAT, pont réseau).
Dans le cas d’un pont réseau (l’équivalent d’un switch), l’hôte possède une interface physique (généralement appelée maître), éventuellement une interface représentant le pont, et une interface reliée (esclave) pour chaque sous‐hôte.
Le plus généralement, on utilise le pilote bridge (cf. man brctl). Il est cependant utile de limiter les interactions de chaque sous‐hôte. Là où macvlan répartit les paquets en fonction de l’adresse MAC (niveau 2), ipvlan peut le faire en fonction de l’adresse IP (niveau 3).
Pagination à la demande pour InfiniBand
La couche InfiniBand prend maintenant en charge la pagination à la demande : le paramétrage d’un emplacement RDMA et le remplissage via des défauts de page lorsque la mémoire est effectivement utilisée. On évite ainsi un blocage inutile d’une zone mémoire.
Sécurité
Intel Memory Protection Extensions (MPX)
La prise en charge, pour les programmes en espace utilisateur, de la technologie MPX spécifique aux processeurs Intel a été ajoutée. Les processeurs disposant de cette extension matérielle (architecture Skylake, qui n’est pas encore disponible) pourront contrôler les accès à la mémoire en vérifiant notamment qu’ils sont effectués dans une région valide. Cette protection peut empêcher l’exploitation de vulnérabilités de type dépassement de mémoire tampon.
Pour que cette fonctionnalité soit efficace, il faut donner au processeur beaucoup d’informations sur les différentes zones mémoire dont l’accès est valide. Il est donc probable que l’adoption de cette technologie se fasse progressivement. La prise en charge dans la suite de compilateurs GCC ainsi que dans la bibliothèque glibc est en cours d’intégration. Plus de détails dans l’article sur LWN.net, dans la dépêche sur le noyau 3.14 et dans la documentation du noyau [correctifs].
seccomp et ARM64
L’architecture ARM64 peut maintenant faire usage du sous‐système seccomp.
Correction de l'appel système setgroups()
Le comportement de l’appel système setgroups() a été modifié pour corriger une éventuelle faille de sécurité. Ce problème a été expliqué dans un article de LWN.net, lorsqu’un développeur a essayé d’introduire dans Linux un moyen de réduire les privilèges d’une application. En effet, enlever un utilisateur d’un groupe peut parfois augmenter les privilèges, et quelques administrateurs utilisent les droits UNIX de cette façon.
Le problème est que Linux propose déjà à un utilisateur de diminuer ses privilèges lorsque celui‐ci s’exécute dans un espace de noms utilisateur. Cela a été corrigé dans cette nouvelle version, mais ce changement peut casser certaines applications.
Chargement non voulu de modules noyau
Dans certains cas, il était possible de charger des modules noyau non nécessaires sans avoir besoin d’être super‐utilisateur (root). Plus de détails sont disponibles dans cet article de Mathias Krause.
LSM
IMA & EVM
Un méchanisme (hook) a été ajouté pour charger un certificat X.509 directement dans le trousseau de clés IMA chargé de la vérification d’intégrité [correctifs : 1, 2, 3, 4 et 5].
SMACK
Pour qu’un processus puisse poser un verrou sur un fichier sur lequel il n’a que le droit d’accès en lecture, il doit disposer du mode d’accès SMACK « lock » (cf. dépêche noyau 3.13). L’étiquette « _ » étant utilisée comme étiquette pour le système de base, un processus quelconque ne peut verrouiller en lecture l’un de ces fichiers que si une règle est définie.
Comme c’est une opération très courante, l’étiquette « _ » a été modifié pour se comporter légèrement différemment, en autorisant le verrouillage en lecture pour tous les processus. Cela implique que les processus avec l’étiquette « ^ », qui peuvent lire tous les fichiers d’un système, peuvent désormais aussi les verrouiller en lecture. Ce changement a été effectué pour simplifier les politiques SMACK [correctif].
Liste non exhaustive des vulnérabilités corrigées
- CVE-2014-9529 [correctif] ;
- CVE-2015-0239 [correctif] ;
- CVE-2014-8480 [correctif] ;
- CVE-2014-8134 [correctif] ;
- CVE-2014-8989 [correctifs : 1, 2, 3, 4 et 5].
Pour plus de détails sur la vulnérabilité CVE-2015-0239 qui impacte KVM : [oss-security] KVM SYSENTER emulation vulnerability - CVE-2015-0239.
Systèmes de fichiers
OverlayFS multicouche
OverlayFS gère maintenant plusieurs couches. Il est utilisé pour les CD autonomes (live CD), car il rend inscriptible une couche en lecture seule, en y ajoutant une zone en lecture‐écriture.
Ceph avec des données inline
Le système de fichiers distribué Ceph gère les données inline pour augmenter les performances, principalement pour les petits fichiers, comme le font déjà ext4 et Btrfs. Il gère maintenant également le chiffrement des messages entre les clients et les serveurs.
Pour rappel, Ceph est un système de fichiers réparti sans point individuel de défaillance (SPOF), avec une bonne gestion de l’extensibilité.
SquashFS avec LZ4
SquashFS gère la compression LZ4 qui est une compression peu gourmande en temps processeur. SquashFS est un système de fichiers compressé en lecture seule, utilisé par les CD autonomes (live CD), par exemple.
Btrfs
Le RAID 5 et le RAID 6, pris en charge nativement par le Btrfs, sont améliorés. Le changement à chaud des disques est aussi mieux pris en charge. Il y a énormément de corrections de bogues, y compris une corruption après un crash ou dans une condition d’erreur.
F2FS
Une nouvelle option de montage nommée fastboot réduit un certain nombre de vérifications effectuées lors du montage du système de fichiers, et accélère donc potentiellement le démarrage du système d’exploitation.
NFS
Le client et le serveur NFS prennent maintenant en charge les options NFS 4.2 ALLOCATE et DEALLOCATE. La première peut être utilisée pour demander la préallocation du stockage d’un fichier, tandis que la seconde est utile pour libérer un emplacement.
Divers
- La multi‐file de blocs est améliorée et est prise en charge dans le pilote NVMe, qui gère les disques à mémoire Flash SSD directement reliés au bus PCI Express.
- Optimisation de la couche de la carte des périphériques (device mapper) responsable de la cryptographie et/ou de la couche RAID par bloc.
Virtualisation
KVM
La prise en charge de la virtualisation KVM pour l’architecture Itanium (IA64) a été supprimée. Elle n’était pas maintenue et, apparemment, n’était pas utilisée non plus.
Xen
Cette nouvelle version du noyau apporte une gestion complète des processeurs n’ayant pas de cohérence pour leurs caches, comme c’est le cas dans les processeurs ARM. L’hyperviseur a donc reçu un mécanisme permettant d’effectuer les opérations de maintenance de cache nécessaires sur ces processeurs.
Pour plus d’informations, vous pouvez consulter les demandes d’intégration Xen.
Virtio
Virtio, le cadriciel d’abstraction des entrées‐sorties à destination des hyperviseurs, passe en version 1.0.
Le pilote SCSI spécifique pour les machines virtuelles (virtio_scsi) peut faire usage de la gestion des files matérielles multiples (blk-mq : présentation sur blk-mq) qui est implémentée dans le noyau depuis la version 3.13 [correctif].
Pour plus d’informations, vous pouvez consulter la demande d’intégration Virtio.
Hyper-V
Prise en charge de l’enlèvement à chaud des interfaces réseau virtuelles (vNIC) [correctif].
Le bilan en chiffres
En ce qui concerne les statistiques du cycle de développement du noyau 3.19, le site LWN.net a publié son traditionnel article récapitulatif.
En nombre de modifications, on se situe à 12 461, soit environ 1 300 modifications de plus que la version précédente du noyau. Le nombre de contributeurs est, quant à lui, de 1 422. Ce nombre est resté relativement constant sur la dernière année.
Le développeur ayant écrit le plus de modifications est H. Hartley Sweeten (463) pour son travail de nettoyage des pilotes Comedi. Du côté des développeurs ayant le plus modifié de lignes, Malcolm Priestley remporte la palme grâce à son travail d’amélioration sur le pilote vt6655.
Environ 200 entreprises ont participé à l’élaboration de ce noyau. En tête, on retrouve Intel, qui a effectué 12 % des changements que l’on peut trouver dans cette nouvelle version. En deuxième place, Red Hat a contribué pour 8,3 % des changements. Il est cependant important de noter que les développeurs sans affiliation ont effectué 10,9 % des modifications, soit juste un peu moins qu’Intel, alors que les personnes non identifiées ont écrit 7,5 % des modifications. On peut donc dire, bien que le noyau soit majoritairement écrit par des employés d’entreprises, que les contributeurs indépendants sont toujours les bienvenus et sont même une majorité !
Appel à volontaires
Cette dépêche est rédigée par plusieurs contributeurs dont voici la répartition :
| Mainteneur | Contributeur(s) | |
|---|---|---|
| La phase de test | Aucun | Pierre Mazière et Davy Defaud |
| Arch | Romain Perier | |
| Développeurs | Aucun | |
| Pilotes graphiques libres | Martin Peres | |
| Réseau | Aucun | alpha_one_x86 |
| Systèmes de fichiers | Aucun | alpha_one_x86 |
| Sécurité | Timothée Ravier | |
| Virtualisation | Xavier Claude | Timothée Ravier et Martin Peres |
| Édition générale | Aucun | Martin Peres, Timothée Ravier, eggman, BAud et Davy Defaud |
Un peu de vocabulaire :
- le mainteneur d’une section de la dépêche est responsable de l’organisation et du contenu de sa partie, il s’engage également à l’être dans le temps jusqu’à ce qu’il accepte de se faire remplacer ;
- un contributeur est une personne qui a participé à la rédaction d’une partie d’une section de la dépêche, sans aucune forme d’engagement pour le futur.
Malgré cette équipe importante, beaucoup de modifications n’ont pas pu être expliquées par manque de temps et de volontaires.
Nous sommes particulièrement à la recherche de mainteneurs pour les sections Systèmes de fichiers et Réseau, les précédents n’ayant pas donné de signes de vie pendant la rédaction des dernières dépêches.
Si vous aimez ces dépêches et suivez tout ou partie de l’évolution technique du noyau, veuillez contribuer dans votre domaine d’expertise. C’est un travail important et très gratifiant qui permet aussi de s’améliorer. Il n’est pas nécessaire d’écrire du texte pour aider, simplement lister les commits intéressants dans une section aide déjà les rédacteurs à ne pas passer à côté des nouveautés. Essayons d’augmenter la couverture sur les modifications du noyau !
Aller plus loin
- Les noyaux précédents (505 clics)
- Site officiel du noyau Linux (403 clics)
- LWN : The 3.19 merge window opens (96 clics)
- LWN : 3.19 Merge window part 2 (54 clics)
- LWN : The end of the 3.19 merge window (52 clics)
- Kernel Newbies : Linux 3.19 (233 clics)
- arm-soc contents merged into 3.19 - Linaro (57 clics)
- Heise : Die Neuerungen von Linux 3.19 (52 clics)
# ..
Posté par gst . Évalué à 3. Dernière modification le 17 février 2015 à 00:50.
"Elle retourne au processeur .."
le processeur ?
sinon c'est comme d'hab: du tout bon :)
[^] # Re: ..
Posté par robin . Évalué à 4.
Le premier lien après le sommaire (sur execveat()) est cassé.
En passant, c'est toujours aussi agréable de lire cette dépêche.
bépo powered
[^] # Re: ..
Posté par Rolinh (site web personnel) . Évalué à 3.
Il y a un 'e' en trop dans le titre du paragraphe.
[^] # Re: ..
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci (pour les trois commentaires qui précèdent).
[^] # Re: ..
Posté par Gawan . Évalué à 3.
Une petite coquille dans la partie "Le bilan en chiffres" :
Ça ne devrait pas être 3.19?
[^] # Re: ..
Posté par Martin Peres (site web personnel) . Évalué à 5.
Mince! Mon plan génial de faire un gros copier/coller a été détecté !
[^] # Re: ..
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# Tres bon
Posté par walker17x . Évalué à 2.
je l'utilise sur ma Manjaro et ça fonctionne trés bien sans problèmes !
Il faut savoir aussi que Linus a posté un sondage ou il demande si on veux que la prochaine version sera linux 3.20 ou bien linux 4.0 et bien le gens ont majoritairement voté pour la 4.0
Enfin bref la seule chose que je regrette c'est l'évolution extrêmement lente des drivers open source nvidia surtout quand on compare aux drivers open source AMD ! jusqu'a maintenant y'a des gens qui ont de multiples craches avec nouveau , sans oublier les performances ridicules et l'acceleration graphique innexistante dans plusieurs cas
[^] # Re: Tres bon
Posté par Trollgouin . Évalué à 2.
Ça a peut-être à voir avec la politique ancienne de nvidia de livrer des pilotes aux sources fermées mais qui fonctionnent bien sous Linux. C'est pas libre, mais en pratique, ça marche bien (et c'est packagé). Ceci dit, quand on aura le choix entre deux bonne solutions, une libre (AMD) et une propriétaire (Nvidia), le choix du matériel sera vite fait…
[^] # Re: Tres bon
Posté par cluxter . Évalué à 10.
En effet, les pilotes libres pour les cartes Nvidia sont développés par rétro-ingénierie par la communauté du libre, contrairement à AMD qui a décidé d'embaucher des personnes à temps plein pour coder des pilotes graphiques open source.
Pour la petite histoire, AMD a recruté les développeurs (notamment Alex Deucher) qui bossaient depuis des années sur les pilotes libres des cartes AMD/ATI et qui prenaient sur leur temps libre pour cela. C'est donc admirable de la part d'AMD d'avoir recruté ces personnes et d'avoir initié un vrai changement dans leur politique de pilotes graphiques. Je me souviens qu'ils auraient aimé pouvoir le faire plus tôt, mais les clauses contractuelles de non divulgation des contrats industriels liaient fortement le matériel et le logiciel, donc AMD a dû attendre quelques années avant d'avoir le droit d'embaucher des salariés qui pouvaient accéder aux fiches techniques des puces pour coder et diffuser des pilotes graphiques libres.
En toute logique viendra un jour où les pilotes propriétaires d'AMD (les "Catalyst") seront entièrement remplacés par les pilotes libres (les "radeon"), puisque les "radeon" feront doublon avec les "Catalyst" et seront normalement (un jour…) aussi performants (sinon plus). Ca c'est moi qui le dit, mais le projet Gallium3D devrait permettre de mieux porter les pilotes entre différents OS, donc ça devrait aider.
Pour l'instant, AMD s'applique à implémenter toutes les fonctionnalités nécessaires dans les pilotes graphiques, pour l'ensemble de ses cartes graphiques depuis l'an 2000 (!!), qu'on peut suivre ici :
http://xorg.freedesktop.org/wiki/RadeonFeature/
Lorsque toutes ces fonctionnalités seront implémentées, il est probable qu'ils s'emploieront à optimiser davantage les pilotes.
Je me souviens lorsqu'Alex Deucher a été recruté en décembre 2007, ce tableau était complètement rouge. 7 ans après quasiment toutes les fonctionnalités ont été intégrées dans les pilotes libres. On peut aisément penser qu'il faudra 3 ans de plus pour terminer le boulot, donc il aura fallut 10 ans pour implémenter les pilotes graphiques libres pour toutes les cartes d'AMD, par une équipe de 5 développeurs officiels (+ les contributeurs de la communauté et d'autres entreprises, disons une dizaine à temps plein), sachant qu'AMD ne met pas beaucoup de moyens sur ces pilotes libres car ça ne représente pas beaucoup de parts de marché. C'est vraiment pas mal quand on sait à quel point les GPU sont des machines complexes.
Je vous invite à lire cette interview très enrichissante :
https://linuxfr.org/news/entretien-avec-jerome-glisse-developpeur-des-pilotes-graphiques-radeon-pour-red-hat
Pour en revenir à Nvidia, la communauté fait un boulot remarquable. Il est déjà extrêmement compliqué de coder des pilotes graphiques quand on a accès aux schémas des cartes, alors lorsqu'on procède par rétro-ingénierie ça relève de l'exploit. Donc oui ce n'est de loin pas parfait, mais c'est le mieux que la communauté puisse faire pour l'instant.
Ce qui est déplorable, c'est l'attitude de Nvidia qui n'a aucune intention d'ouvrir ses pilotes et de travailler sur des pilotes libres. Ce fameux témoignage où Linus Torvald dit qu'Nvidia est la pire des sociétés avec laquelle il a pu collaborer jusqu'à présent résume bien la chose :
https://www.youtube.com/watch?v=19jUboon5gI
Donc si tu souhaites des pilotes graphiques libres avec des performances correctes, tu ne vas pas pouvoir compter sur Nvidia, tu n'as pas d'autre choix que de te tourner vers AMD. Ou Intel ! Intel est une entreprise exemplaire quant au support des pilotes libres de son matériel. Les pilotes sont dans le noyau plusieurs mois avant que le matériel ne soit sur le marché, ce qui fait qu'on a des pilotes Intel supers stables quand on achète du nouveau matos (carte-mère, CPU, GPU, Wi-Fi, etc. ; le pied quoi !).
Voilà voilà, j'ai limite écrit un article entier à moi tout seul, j'espère que ce sera utile à certains ^
[^] # Re: Tres bon
Posté par xcomcmdr . Évalué à -5.
Et quand tu veux de vrais performances 3D (pour les jeux par exemple) c'est nVidia ou nVidia.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Tres bon
Posté par cluxter . Évalué à 2.
Ca aurait été encore mieux avec un lien pour justifier ta remarque :
http://www.phoronix.com/scan.php?page=article&item=linux_gpus_dec1412&num=1
Je ne suis pas sûr cependant qu'on compare des cartes tout à fait égales car l'auteur dit qu'il regrette de ne pas avoir de carte AMD R9 290X sous la main.
Ceci étant dit, tout dépend des besoins. Si on a absolument besoin de performances, alors effectivement Nvidia est sûrement mieux. Mais en l'occurrence Nvidia pèche très largement sur les pilotes libres. Donc ça dépend des priorités de chacun. A titre personnel, je préfère largement privilégier AMD car je n'ai pas besoin de performances fulgurantes, une Radeon 4870 X2 me suffit amplement.
[^] # Re: Tres bon
Posté par xcomcmdr . Évalué à 7. Dernière modification le 17 février 2015 à 18:27.
Il y a aussi pas mal de jeux (sur Steam Linux par exemple) où quand tu as une AMD ben tu peux pas jouer, ou avec des performances / stabilité / fiabilité des graphismes largement décevantes par rapport un nVidia, ou la même carte AMD sur Windows (même en utilisant les pilotes proprios).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Tres bon
Posté par cluxter . Évalué à 4.
Est-ce que tu as été confronté à des cas où en ayant un noyau + la pile graphique à jours (Mesa et compagnie), tu n'arrivais pas à lancer ces jeux en question ?
Car j'ai ce problème mais avec Debian Stable + backport pour le noyau, donc même si mon noyau est à peu près récent (v3.14), ma pile graphique remonte à il y a 2 ans et je sais qu'un certains nombre de bugs et de fonctionnalités ont été retirés et ajoutées entre temps dans les nouvelles versions de Mesa et consorts. Je n'ai plus ces problèmes en utilisant Debian Testing (= Jessie actuellement).
[^] # Re: Tres bon
Posté par whity . Évalué à 3.
J’ai le problème en jessie (donc avec quand même quelque chose de relativement à jour). Impossible de jouer à « Civilization » par exemple. D’autres jeux fonctionnent bien par contre, mais les perfs ne sont pas au niveau du windows.
Sachant que sous jessie, gnome-shell est pété avec les pilotes fglrx --> faut encore retourner sous windows de temps en temps.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Tres bon
Posté par claudex . Évalué à 5.
J'ai joué sur Jessie avec Civilization V et les pilotes libres AMD. J'ai testé aussi le Beyond Earth mais il y avait quelques bugs graphiques (j'ai quand même pu faire une partie sans problème).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Tres bon
Posté par JGO . Évalué à 3.
En ce qui me concerne (je ne suis pas joueur) j'utilise scilab qui fait appel à « Java2D OpenGL Pipeline », qui utilise les pbuffer (off-screen rendering) de la carte graphique. Or AUCUN pilote libre ne supporte cette fonctionnalité. L'affichage de graphiques (même 2D) dans scilab est donc impossible avec un GPU Intel, et les GPU ATI et Nvidia nécessitent le driver proprio.
[^] # Re: Tres bon
Posté par Martin Peres (site web personnel) . Évalué à 10. Dernière modification le 23 février 2015 à 13:00.
Ah ah, et c'est scilab qui a raison ici d'utiliser les pbuffers? Les framebuffer objects (OpenGL 3) remplacent avantageusement les pbuffers qui eux ne sont jamais rentrés dans le standard OpenGL.
Aucun nouveau pilote ne va supporter les pbuffers. Et je parle même pas des pilotes de GPU pour ARM! Je pense que Scilab devrait prendre les heures nécessaires pour utiliser les FBO.
[^] # Re: Tres bon
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
Avant scilab n'était pas libre donc n'était pas diffuser dans les distributions. Maintenant, il ne marche plus sur la grande majorité des PC… Je ne sais pas quelle sont les objectifs de l'équipe de développement mais elle aide bien à la diffusion de la plate-forme de python/numpy ;-)
[^] # Re: Tres bon
Posté par Clément David (site web personnel) . Évalué à 2.
Personnellement j'utilise Scilab tous les jours avec des pilotes libres Intel et le rendu graphique fonctionne bien (même pour les anciennes versions). À noter que dans les dernière version le moteur de rendu graphique n'utilise plus les p-buffers mais les FBOs.
[^] # Re: Tres bon
Posté par JGO . Évalué à 2.
Quelle version utilises-tu ? J'utilise le binaire officiel 5.5.1 64 bits. Par ailleurs le script de compilation gentoo fait dépendre scilab de jogl-2.1.4 (ce script). Peut-être passes-tu par un rendu logiciel, ou tu utilises le driver vesa ?
[^] # Re: Tres bon
Posté par Clément David (site web personnel) . Évalué à 1.
Scilab 5.5.1 (version binaire depuis scilab.org) avec le driver intel de base de ma machine (i915) intégré au kernel. Tout le rendu est bien accéléré par OpenGL. Je suis aussi packageur Scilab pour Fedora et la version est patchée pour supporter jogl-2.2.4. Sans doute peux-tu reporter un bug directement.
[^] # Re: Tres bon
Posté par med . Évalué à 3.
Quels jeux ? Parce que jusqu'à présent tout marche à la perfection ou presque pour moi, dont un certain nombre de gros titres : Crusader Kings II, Europa Universalis IV (avec une régression dans la dernière version de Mesa cela dit mais c'est déjà corrigé), Empire Total War, Civilization V, XCOM Enemy Within, etc. Je crois que j'ai une Radeon HD 5750.
[^] # Re: Tres bon
Posté par whity . Évalué à 1.
Je pense que ça dépend des cartes. Comme je l’ai dit plus haut, chez moi, tout n’est pas aussi rose (j’ai une 6850). X-com fonctionne très bien, mais Civ c’est pas la peine d’y songer (extrêmement lent et plantages à répétition).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Tres bon
Posté par Adrien . Évalué à 2.
Je pense que tu a oublié le mot « libre ».
En non-libre, il y a quelques solutions quand même : linux+nvidia, linux+fglrx… ou passer sous Windows.
[^] # Re: Tres bon
Posté par cluxter . Évalué à 7.
Je précise un point, donné par cette vidéo à 6m50s :
https://www.youtube.com/watch?v=hOmNWxx4Cwo#t=6m50s
Les pilotes graphiques propriétaires sont nécessaires car certains clients d'AMD ont besoin d'OpenGL 4.x, dont l'implémentation n'est pas libre. Dans cette vidéo, Alex Deucher dit que même si AMD mettait une armée de développeurs pour implémenter OpenGL 4.x sous forme libre (c'est le projet Mesa) le plus rapidement possible, ils seraient en retard et ne pourraient pas satisfaire leurs clients qui en ont besoin immédiatement. Donc AMD continue d'utiliser les Catalyst pour satisfaire certains clients, mais fondamentalement ils n'auraient rien contre le fait de s'en passer apparemment.
Il est donc probable qu'on aura donc toujours des pilotes propriétaires en parallèle des pilotes libres, mais on peut espérer arriver dans quelques années à une situation où les pilotes libres seront tout aussi performants que les propriétaires à fonctionnalités égales.
[^] # Re: Tres bon
Posté par eingousef . Évalué à 9.
Ben déjà il y a pas mal de vieilles cartes qui ne sont plus supportées par le pilote non-libre, seul le pilote libre est capable de faire fonctionner ces cartes sur un système à jour.
*splash!*
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tres bon
Posté par Martin Peres (site web personnel) . Évalué à 10.
Peut être que c'est ton écran qui indique n'importe quoi dans ses EDID et que le pilote propriétaire sait ça et a une copie corrigée. Je considère pas ca un bug de linux, mais un bug dans ton écran!
[^] # Re: Tres bon
Posté par fasthm . Évalué à 3.
Ah ben non, j'ai aussi eu un cathodique qui savait faire ça (un Compaq P1220).
Ceci dit, le 60Hz en cathodique ça pique les yeux.
La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10. Dernière modification le 26 février 2015 à 19:36.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tres bon
Posté par xcomcmdr . Évalué à 7.
Tu peux prouver que ce décrit Martin Peres est faux alors ? Ou tu parles sans savoir, comme d'habitude ?
(et si j'étais d'aussi mauvaise foi que toi je dirais : "Accessoirement, ça fait 10 ans qu'on est passé aux écrans LCD, alors ton CRT…")
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tres bon
Posté par xcomcmdr . Évalué à 10.
Bullshit. J'ai un matos ultra récent qui marche sous Linux sans rien faire.
Donc ta merde, tu peux la déverser ailleurs. Merci.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Tres bon
Posté par Anthony Jaguenaud . Évalué à 9. Dernière modification le 01 mars 2015 à 11:19.
Écoute, je me souviens il y a plus de 15 ans, on avait un script qui permettait de mettre à jour la configuration de XFree (xorg n’existait pas encore). Et ce script permettait de mettre les fréquences que tu voulais, la résolution que tu voulais. À ma connaissance, les champs sont toujours disponible dans le xorg.conf aujourd’hui. Mais il va falloir l’éditer à la main. Mettre une section Screen, une Card… tu ne pourras pas utiliser la configuration automatique parce que ton écran ne renvoie pas les informations le concernant sauf son nom.
Donc, s’il te plait au lieu de cracher sur tout le monde, cherche des tutos xfree (ou xorg) qui date un peu. (À l’époque on utilisait surtout le terme de HowTo).
Voir un petit :
man xorg.confpourra faire l’affaire si tu décrasses tes neurones.Bon courage et reviens nous voir avec une bonne nouvelle.
[^] # Re: Tres bon
Posté par Tonton Benoit . Évalué à 6.
Il ne s'agit pas d’intéresser un développeur ou pas. L'écran n'envoi pas d'EDID ou envoi un EDID buggé, le constructeur à poussé l'ini qui va bien dans Windows pour que ça marche et c'est tout.
Linux et le libre n'y peut pas grand-choses dans ce cas, à part un site contributif permettant aux utilisateurs de partager leurs modelines une fois crées ou adaptés à partir du .ini pour Windows, mais en 2015 bon courage pour la pérennité d'un tel projet :D
Oui j'ai galéré avec les modelines sous Red Hat 5.5 en 1998 et sans internet pour m'aider, à l'époque impossible aussi de passer ce 15 pouces en 800x600@60hz sous même Windows.
[^] # Re: Tres bon
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 7.
On pourrait parler des contre-exemples aussi tiens. Comme ce touchpad qui comprends le multi-touch (défilement à 2 doigts) sous Linux (Debian Jessie) sans la moindre configuration alors que la fonctionnalité n'est pas disponible sous Windows.
Est-ce là aussi de l'incompétence des développeurs, qui auraient du interdire cette fonctionnalité ?
La connaissance libre : https://zestedesavoir.com
[^] # Re: Tres bon
Posté par Albert_ . Évalué à 2.
Malheureusement wayland arrive avec libinput qui fait subir au driver de touchpad une cure d'amaigrissement que l'on pourrait qualifie de gnomisation… ie on enleve la plupart des options. Avec la raison qui tue: "Sous windows c'est comme ca aussi!"
[^] # Re: Tres bon
Posté par Renault (site web personnel) . Évalué à 9.
Bah voyons : http://wayland.freedesktop.org/libinput/doc/latest/scrolling.html
(par exemple hein).
Libinput est jeune, laisse-lui le temps d'implémenter ce qui manque !
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tres bon
Posté par xcomcmdr . Évalué à 4.
Bitch, please !
La dernière fois que j'ai compilé un pilote sous Linux c'était il y a 10 ans. Faut se mettre à jour.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tres bon
Posté par xcomcmdr . Évalué à 9.
Non, ça fait 10 ans que les drivers ne sont plus un problème et que la plupart sont dans le kernel.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tres bon
Posté par xcomcmdr . Évalué à 3.
Bah non, ce n'est plus un problème depuis longtemps.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Tres bon
Posté par ckiller . Évalué à -5.
huhuhuhuhuhuhuhuhuhuhuhhhuhuhu
perf de merde, à moitié terminée
huhuhuhuhuhuhuhuhuhuhuhhhuhuhu
[^] # Re: Tres bon
Posté par Antoine . Évalué à -3.
Tant d'assurance force l'admiration. Dans les années 50, tu aurais expliqué que le goulag est une invention de l'impérialisme américain ?
[^] # Re: Tres bon
Posté par xcomcmdr . Évalué à 3.
T'as des exemples ou tu dis juste de la merde ?
J'ai pas compilé de pilote, ni eu de matériel non-reconnu sous linux, depuis très longtemps. Et alors ?
Je vois pas le rapport avec ton troll puant sur le goulag.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Tres bon
Posté par Antoine . Évalué à -1.
Félicitations pour cette belle démonstration de politesse et d'ouverture d'esprit. C'est vrai que si tu n'as pas eu de problème de pilote depuis longtemps, les problèmes de pilote n'existent plus. Toutes les instances de problème matériel sous Linux qu'on peut trouver, par exemple avec Google (*), sont probablement postés par des employés Microsoft payés pour discréditer le logiciel libre…
(*) chercher, au hasard, "ubuntu laptop problem"
[^] # Re: Tres bon
Posté par xcomcmdr . Évalué à 8.
Oui et ?
Il n'empêche que le problème est bien plus réduit qu'avant.
Parce que bon, à ce compte là, je peux te montrer tous les problèmes de pilotes sous Windows (genre un que j'ai : pas de pilote disponible pour mon scanner pour Windows en 64 bits), et on sera pas plus avancé.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Tres bon
Posté par Antoine . Évalué à 0.
Ah ben tout va bien.
Faut être sérieux deux secondes : un fabricant de matériel pour PC grand public a en général intérêt à supporter son matériel sous Windows s'il ne veut pas faire faillite. Le matériel qui ne fonctionne pas correctement sous Windows ne peut être qu'une infime minorité.
Par contre, le matériel qui n'est pas supporté sous Linux, c'est encore très courant. Un exemple récent : les adaptateurs USB-Ethernet.
[^] # Re: Tres bon
Posté par whity . Évalué à 8.
Il a seulement intérêt à supporter son matériel au moment où il sort. Les passages à Vista puis au 64 bits, avec les changements qu’ils ont impliqué sur les drivers, ont fait mal à bon nombre de périphériques (scanners, imprimantes, cartes son, cartes graphiques…). Certes, c’est du vieux matériel, mais qui a envie de changer un scanner qui fonctionne ?
Amusant que tu cites cet exemple : j’ai justement un adaptateur usb-ethernet qui m’a servi de nombreuses fois pour faire les install linux sur des machines où le contrôleur réseau n’était pas supporté par le cd d’install (généralement, à cause d’un firmware non libre, ou simplement parce que le driver n’était pas inclus dans le noyau). De manière générale, le matériel tout nouveau n’est pas supporté (ou mal) sous linux, le matériel plus ancien, ça marche plutôt bien.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Tres bon
Posté par xcomcmdr . Évalué à 4. Dernière modification le 09 mars 2015 à 21:58.
On a pas la même définition de "très courant" alors. Avant, c'était plutôt les composants intégrés qui posaient problème (carte graphique, wifi, bluetooth).
Alors bon qu'il y a des problèmes avec des bidules externes, c'est peut-être frustrant mais on peut honnêtement pas dire que la situation est aussi naze qu'il y a 10 ans.
Faut dire que c'est hyper courant. La preuve j'en ai… jamais vu.
Il est aussi une infime minorité sous Linux. Seulement quand ça nous concerne, on fait forcément partie de la grande majorité… Alors que bon, y'a pas le moindre début de commencement d'idée d'ébauche de statistique pour étayer le propos… lequel tombe à l'eau.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Tres bon
Posté par Kioob (site web personnel) . Évalué à 4.
C'est de plus en plus fréquent pourtant : de nombreux appareils sont fournis sans port Ethernet désormais (Ultrabook, tablettes, et quelques netbook). Au boulot les 3 derniers appareils achetés n'ont pas de port Ethernet.
Par contre j'ai testé avec succès l'adapteur USB-Ethernet, qui a chaque fois a été reconnu automatiquement, sans rien faire, sur nos Debian. Tandis que sous Windows il a fallu installer le driver.
Par contre du matos qui ne marche pas sous Linux, j'en ai aussi (DisplayLink ?).
Quant au problème des drivers graphiques, je n'ai plus eu le moindre problème depuis que j'ai abandonné la marque Nvidia, mais je le reconnais bien volontiers : je ne joue pas.
alf.life
[^] # Re: Tres bon
Posté par ariasuni . Évalué à 9.
C’est-à-dire qu’il faut internet pour télécharger le pilote pour avoir internet. Donc sous Windows il faut avoir internet pour avoir internet. D’ailleurs c’est bien connu, sous Windows, il faut un clavier pour valider qu’on a bien lu le message indiquant l’absence de clavier. CQFD
Ah mince, on me communique à l’instant qu’on est pas vendredi.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Tres bon
Posté par Antoine . Évalué à -1.
En général, le portable a aussi un chipset wifi, hein. Donc tu te connectes en wifi pour choper le pilote de l'adaptateur Ethernet, et voilà.
[^] # Re: Tres bon
Posté par Albert_ . Évalué à 8. Dernière modification le 12 mars 2015 à 18:04.
Et quand tu n'as pas le wifi tu te connectes sur par Ethernet pour chopper le pilote du wifi. Et comment tu fais quand c'est les deux qui sont manquant comme cela est dans … 100% des PC dell que j'ai pu installer ces dernieres annees (je precise que je parle de windows)?
Ca devient circulaire ton truc.
[^] # Re: Tres bon
Posté par Antoine . Évalué à 2.
Ou alors tu utilises une clé USB, tu sais. Mais aujourd'hui, le wifi est le moyen de connection dominant, de toute façon.
Tu installes du Windows ? En général Windows est pré-installé, et j'imagine que les pilotes sont installés aussi.
[^] # Re: Tres bon
Posté par Albert_ . Évalué à 7.
Tu installes du Windows ? En général Windows est pré-installé, et j'imagine que les pilotes sont installés aussi.
Et oui la ou je bosse on install windows car on aime pas les 100 000 merdes qui sont pre-installe et donc on installe un windows "nu" et on met nos merdes a nous pas celle de Dell/Toshiba ou autre et donc je peux te garantir que windows n'a pas de drivers generique pour ethernet alors le wifi n'y compte meme pas. Alors oui un windows preinstalle ca fonctionnera mais bon un linux aussi curieusement.
[^] # Re: Tres bon
Posté par Antoine . Évalué à -1.
Vu la proportion de matériels sur laquelle Linux est pré-installé, on ne peut rien conclure sur la qualité du support matériel sous Linux. Au contraire de Windows. CQFD.
[^] # Re: Tres bon
Posté par Antoine . Évalué à 0.
Et ça tombe bien, parce que ce n'est pas ce que j'ai dit.
Par contre, c'est toi qui as prétendu que "ça fait 10 ans que les drivers ne sont plus un problème", ce qui fait plaisir aux anti-Windows de service mais est totalement faux.
[^] # Re: Tres bon
Posté par xcomcmdr . Évalué à 0. Dernière modification le 12 mars 2015 à 13:53.
Totalement faux, faut voir. D'abord, oui ça fait bien 10 ans que j'ai pas eu un seul périphérique non reconnu, aussi exotique soit-il (chipset wifi, carte graphique, hdmi, bidules bluetooth, …)
Et rien que ton exemple d'adaptateur Ethernet->USB, ben en fait on voit dans les réponses à ton post précédent que dans la majorité des cas cela fonctionne.
Alors je dirais que c'est totalement vrai, jusqu'à preuve du contraire (autrement dit, des chiffres, ou du moins pas un cas isolé sans importance, merci).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Tres bon
Posté par Antoine . Évalué à 1.
En fait, c'est simple : c'est toi qui affirmes quelque chose, c'est à toi d'avancer les chiffres.
[^] # Re: Tres bon
Posté par xcomcmdr . Évalué à 2.
Hum, non, ça ne marche pas comme ça.
Je dis que ça marche bien depuis 10 ans, car c'est mon expérience.
Toi, tu affirmes que c'est encore très courant de pas avoir de matériel supporté pour tout le monde. Mais un cas isolé n'est pas une preuve. Qu'est ce qui montre que c'est encore très courant ? Jusqu'ici, rien du tout.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Tres bon
Posté par Antoine . Évalué à 1.
Je te cite :
Suite à quoi tu te contredis :
En fait, si dès le début tu avais dit "dans mon expérience, ça marche bien", sans essayer d'en rajouter pour faire croire que le problème était de facto entièrement résolu, il n'y aurait pas débat.
Certes, dans certains cas ça marche bien et dans certains cas ça marche moins bien. Ce qui est tout le problème. Personne ne nie qu'il y a du matériel qui marche correctement sous Linux ; et avec un PC de bureau que l'on monte soi-même, c'est assez facile d'éviter les problèmes. Ça l'est moins quand on achète un portable…
[^] # Re: Tres bon
Posté par xcomcmdr . Évalué à 5.
Portable précédent : pas fait gaffe du tout à Linux -> fonctionne parfaitement sous Linux.
Portable actuel : pareil.
L'ordinateur portable qui ne fonctionne pas sous Linux, c'est plutôt une exception. Rien que pour la carte graphique, ils ont quasiment tous du Intel/nvidia/ATI.
Quant à la charge de la preuve, elle est de ton côté. C'est celui qui veut prouver l'existence de quelque chose à qui revient cette charge (je te rappelle : tu prétends que linux souvent ne fonctionne pas sur un portable ou avec un périphérique externe. Et jusqu'ici, ça n'a pas été démontré.). Et ici, ce serait plutôt avec des stats/études, histoire que ce soit un minimum intéressant…
Et puis ça c'est une pépite :
C'est oublier que Linux est sur des milliers de smartphones, machin-box, télévision, matériels embarqués, routeurs, serveurs, consoles de jeux, ..
Alors la part de marché et le support matériel de Windows est juste risible face à ça, hein…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Tres bon
Posté par Antoine . Évalué à -1.
Bon, attitude typique du gars qui cherche à sauver la face en oubliant ses propres propos, tout en déformant ceux des autres. J'arrête de jouer, ce n'est même pas amusant.
Ça fait une belle jambe quand on achète du matériel PC, ça ("ok, mon PC portable fonctionne à moitié mais je peux acheter un serveur 1U à la place"). Quant aux smartphones, télévisions, machin-box et autres systèmes embarqués, génial : Linux est dessus mais les systèmes sont verrouillés et une partie des couches est souvent propriétaire. Ce serait du Solaris ou du Windows que tu ne verrais même pas la différence… C'est du pur discours de fanboy.
[^] # Re: Tres bon
Posté par Tonton Benoit . Évalué à 4.
T'a eu des cas ?
Parce que pour ce genre de matériel y'a une norme, ou plutôt deux :
- La CDC du consortium USB
- La RNDIS de Microsoft, parce que Microsoft adore faire de la dissidence
Bon après y'a quelques originaux, mais comme les cartes son USB ou les contrôleurs Bluetooth USB j’achète les yeux fermer le truc à quelques centimes sur tinydeals et j'ai lamais eu de probleme de compatibilité, de qualité par-contre…
Le plus drôle c'est que Windows n'embarque pas le pilote pour sa propre norme, donc un périphérique RNDIS marchera direct sous Linux mais nécessitera d’installer le driver sous Windows… (c'est le cas des smartphones ZTE quand tu les configures en relais 3G)
[^] # Re: Tres bon
Posté par ariasuni . Évalué à 6.
Je branche une souris, Windows 7 cherche des pilotes, et pendant plus d’une minute la souris ne fonctionne pas, tout ça pour que Windows me disent qu’il n’a rien trouvé. Reproductible à l’infini, il suffit de débrancher et rebrancher immédiatement la souris. Testé avec deux souris différentes (une souris joueur filaire et une souris de bureau sans fil) sur deux ordinateurs différents (l’un à moi, l’autre à mon frère, avec du matériel différent, installés avec un CD différent, par une personne différente, à un moment différent).
Étrange, sous GNU/Linux c’est littéralement instantané.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Tres bon
Posté par Albert_ . Évalué à 5.
Je pense que ce que veut dire xcomcmdr< c'est que aujourd'hui il n'y a a peu pres aucun probleme pour avoir un systeme linux basique sur une machine et peut etre que ce n'est pas ton experience mais c'est en effet la mienne. Dans les annees 90 c'etait pas du tout mais alors pas du tout gagne d'avoir un linux fonctionnel aujourd'hui c'est un peu l'inverse et les problemes de matos c'est plus l'exception que la generalite.
De tout de facon (et je ne comprend pas pourquoi il insiste) il repond a une personne un peu borne qui melange tout et raconte des conneries pour nourrir le troll (et ne se sert pas et ne veux pas se servir de linux).
[^] # Re: Tres bon
Posté par xcomcmdr . Évalué à 9.
Et le rétro-éclairage de mon clavier que j'ai sous Linux sans rien faire alors que sous Windows 8 ça ne fonctionne pas ? C'est la faute aux dévs Microsoft qui sont trop incompétents ?
Et le défilement sur mon touchpad (linux only sans rien faire) ? Et sa désactivation automatique lors d'une saisie au clavier ou au branchement d'une souris (linux only) ?
Bref, poutre, paille, tout ça…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tres bon
Posté par xcomcmdr . Évalué à 2. Dernière modification le 01 mars 2015 à 08:45.
Aucune version sortie en tout cas ne fonctionne à 100% avec mon clavier (rétro-éclairage, pas mal de touches fn), ni mon touchpad (défilement à deux doigts, désactivation automatique).
[mode Riendf]
Pour rappel; un clavier n'a pas besoin de drivers (un écran oui mais PAS un clavier). Un écran avec des fonctions specifiques, si.
Bref aucune Windows n'est foutu simplement propose d'envoyer un signal de base a un clavier sans passer par la ligne de commande: pitoyable.
[/mode Riendf]
Alors oui, on a des pilotes génériques pour les écrans et les claviers, mais il va falloir m'expliquer comment fonctionne un périphérique sans le moindre pilote.
Moi j'me souviens qu'avant les pilotes génériques pour l'USB sou Windows, on s'emmerdait un maximum à trouver le pilote qui-va-bien. Et j'me souviens aussi que le pilote générique pour l'écran, ça marchait pas forcément sous Windows 9X (on pouvait choisir un autre pilote).
Pareil pour XP qui nécessite des pilotes ultra-spécifiques pour le SATA alors que Windows >= Vista a des pilotes génériques.
pilotes génériques != "pas besoin de pilotes".
A part ça, tu n'as toujours pas répondu à la question suivante (je te comprends, c'est plus facile de radoter sur tes grands chevaux car tu n'as aucun début d'embryon de commencement d'idée d'élément technique) :
Tu peux prouver que ce décrit Martin Peres est faux alors ? Ou tu parles sans savoir, comme d'habitude ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Tres bon
Posté par Moonz . Évalué à 3.
Généralement ça marchait mais en mode dégradé, limité à 640x480 avec 16 bits de profondeur.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tres bon
Posté par xcomcmdr . Évalué à 8.
Ben si. Il est peut-être générique, voire très simple, mais ça ne fonctionne pas tout seul comme par magie avec ton OS, tu sais.
Tu ne sais rien du tout. Tu ne sais d'ailleurs même pas répondre à une question simple. Donc bon, dans le genre cause perdue tu te poses, là…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tres bon
Posté par xcomcmdr . Évalué à 3.
Bah si.
Merci Captain Obvious.
Et c'est bien géré par un pilote.
Donc, essaie encore.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Tres bon
Posté par Tonton Benoit . Évalué à 9. Dernière modification le 07 mars 2015 à 02:51.
Tu ne sait rien ! Pire tu refuse d'apprendre, vu que tu préfère râler et railler des gens beaucoup plus compétents que toi plutôt que de les écouter et d'apprendre, tout ça sous le prétexte que "ça devrait être simple" .
Se tromper une fois, ça arrive, mais tu insiste alors qu'on t'a démontrés plusieurs fois que oui, un écran ça a bien besoin d'un pilote.
Ne m'oblige pas à réinstaller Windows dans une WM pour te mettre de dossier des pilotes d'écran sous le nez !
Et puis même pour les écrans récent avec un EDID correct, y'a un CD livré avec avec le profil de couleur, ça aussi c'est un pilote ! Un pilote pour optimiser le rendu de l"écran.
[^] # Re: Tres bon
Posté par claudex . Évalué à 2.
Les écrans haut de gamme alors, parce que je n'ai rien eu avec les miens (et on voit bien qu'ils n'ont pas le même profile de couleur, il suffit de mettre la même fenêtre sur les deux écrans).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Tres bon
Posté par Tonton Benoit . Évalué à 3.
Haut de gamme non, mais sérieux oui, mon Iiyama 27" ma coûté moins de 300€ et il est livré avec.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tres bon
Posté par Tonton Benoit . Évalué à 7.
C'est la carte graphique qui génère le signal, mais elle a besoin pour ça des spécifications de l'écran, les spécifications sont :
Les modes standards VESA permettant un affichage minimum sans aucun pilote graphique ni connaissance des spécifications de l'écran.
Les modes calculés à partir des informations EDID, mais cette table peut-être buggée ou volontairement bridée par le constructeur.
Les modes fournis par le fichier .inf inclut dans Windows ou les modelines sous Xorg.
Comme pour tous les périphériques non plug & play, si y'a aucun moyen d'identification automatique (pour un écran, c'est l'EDID) faut sélectionner le périphérique manuellement dans une liste. Et l'OS sait s'il est connecté à quelque-chose, la carte graphique rapporte cette information.
Windows connaît une liste d'écrans (plug & play ou non) et si tu connecte un écran non plug & play il sera reconnu comme "écran générique" et tu pourra affiner cette information à partir des propriétés d'affichage.
La liste des écrans connus de Windows se trouve dans le fichier monitor.inf, qui liste les écrans et leur associe un fichier .inf, voilà la structure d'un tel fichier : https://msdn.microsoft.com/en-us/library/windows/hardware/ff568432%28v=vs.85%29.aspx
Et un exemple pris au hasard dans le monitor.inf de Windows 7 : http://www.helpdrivers.com/Francais/Ecrans/Nanao/eF750i/
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10. Dernière modification le 07 mars 2015 à 21:28.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tres bon
Posté par xcomcmdr . Évalué à 6.
Bah s'il y a pas besoin du moindre code, c'est pas dépendant du noyau !
C'est pas cohérent ce que tu dis là. ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tres bon
Posté par Tonton Benoit . Évalué à 6.
Thanks Captain Obvious ! Mais avoue que c'est mieux de s'en tenir à un mode qu'on sait supporté en attendant que l'OS envoie plus d'info. C'est pour ça que le BIOS démarre en VGA (l'UEFI, lui, se base sur la norme VBE). Dans le cas contraire ton signal risque de ressembler canal+ en crypté, son inclus, voir de d’endommager physiquement un très vieux moniteur (genre d'avant 1993)
C'est bien ce que je dit, si c'est un port secondaire ça permet de détecter la présence d'un autre moniteur/projecteur etc., même non plug & play, et de permettre à l'utilisateur de le configurer.
Cette détection n'a besoin d'aucun retour de signal, si tu t'y connaît un peu en électronique tu aura remarqué le +5v et les masses sur le schéma de la prise VGA.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tres bon
Posté par Renault (site web personnel) . Évalué à 6.
Tu sais des normes de définitions d'écran, avec toutes les possibilités de fréquences et de mode (progressif ou entrelacé), tu peux avoir plus de 400 références au total.
Mais tu as raison, il faudrait à chaque fois sortir cette liste complète et espérer que l'utilisateur choisisse le bon. Ou alors on respecte les normes pour ne proposer que les résultats utiles.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tres bon
Posté par Renault (site web personnel) . Évalué à 5.
Sauf qu'il y a d'autres normes que VESA pour les timings tu sais, avec des détails bien plus pointus que tes "2 options".
Je dis ça mais justement je travaille sur le support d'un écran LCD pour une carte électronique, et oui c'est loin d'être aussi simple que tu le présentes.
[^] # Re: Tres bon
Posté par Albert_ . Évalué à 6.
Le temps qu'il a passe a trolle ici il l'aurait passe a ecrire un bug report cela aurait probablement et plus utile quoique vu que son ecran est tellement vieux et pourri que ca doit concerner… 1 personne au monde et comme cette personne ne veut pas utiliser linux je ne suis pas sur de l'interet…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10. Dernière modification le 08 mars 2015 à 12:09.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tres bon
Posté par Tonton Benoit . Évalué à 7.
Tu parle de driver graphique maintenant… tu change de sujet.
C'est sur que si tu utilise le pilote Vesa sous Linux, ben comme le pilote Vesa sous Windows tu aura que les résolutions Vesa…
Après le pilote graphique (genre nouveau) a besoin des spécifications de l’écran pour sortir de du mode Vesa et il faut bien qu’il les récupères de quelque pars.
Quand à la "liste des résolutions supportés", qui fournis bien plus d'informations que ça en fait, c'est bien un pilote, pilote ne veut pas forcement dire code exécutable. Les pilotes pour clavier USBHID se limitent souvent à une simple table corrigée, ça reste des pilotes.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10. Dernière modification le 08 mars 2015 à 01:16.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tres bon
Posté par Tonton Benoit . Évalué à 8.
En attendant pour afficher quelques-chose hors des normes Vesa l'OS a besoin des spécifications de l'écran, refuse d'appeler ça driver si ça te chante, mais n’empêche que si Windows gère t'on écran ça n'a rien à voir avec un tour de passe passe que Linux aurait-pu réussir lui aussi comme tu le prétend dans ton premier post mais d'une action du constructeur qui a fait enregistrer son .inf dans Windows.
Maintenant pour avoir dénigré pendant 15 ans Linux pour une chose qui n'est pas de son fait, ta punition sera de trouver cet .inf et de crée les modelines pour Xorg à partir des information qu'il contient ;)
[^] # Re: Tres bon
Posté par cluxter . Évalué à 5.
On attend que tu proposes un patch, puisque c'est comme ça que sont écrits le noyau Linux et les distributions. Si ça ne te convient pas je t'invite à te tourner vers un OS dont le développement se fait autrement.
Tu râles beaucoup mais on attend de voir ce que tu craches comme code. Si ça fait 18 ans que Windows est capable de gérer ton écran et pas une distrib Linux, ça veut aussi dire que tu avais 18 ans pour écrire un patch. Ca me semble amplement suffisant. Le temps que tu passes à te plaindre sur les forums serait mieux investit si tu le passais à coder ce patch.
Plutôt que de dire "Bref aucune distrib n'est foutu simplement propose d'envoyer un signal de base a un ecran sans passer par la ligne de commande: pitoyable.", on préfèrerait lire "Bref aucune distrib n'est foutu simplement propose d'envoyer un signal de base a un ecran sans passer par la ligne de commande: je vais voir ce que je peux faire pour enfin changer ça. Est-ce que quelqu'un pourrait m'aider à trouver des infos pour régler ce problème ?".
Par ailleurs, est-ce que Windows tourne sur les architectures ia64, des MIPS, des PowerPC, des SPARC ou des s390 ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10. Dernière modification le 05 mars 2015 à 20:50.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tres bon
Posté par Albert_ . Évalué à 8.
OH mais quel honte Linus Torvalds ne s'est pas penche sur le probleme d'ecran de Riendf. En meme temps vu que Riendf ne veut pas utiliser Linux, ne remplit pas de bug report, ne sait pas se servir d'internet tout le monde s'en fout. Riendf se sert de son OS prefere et il est content avec.
[^] # Re: Tres bon
Posté par xcomcmdr . Évalué à 7.
C'est ça, tu payes, mon œil. Prends nous pour des cons aussi !
Et si ça fonctionne bien. Un windows moderne fonctionne mal parce qu'il n'a pas de pilote pour le vieux matos d'il y a 20 ans ? Bien sûr que non !
Pareil pour Linux.
Alors arrête un peu avec tes conneries. C'était marrant au début. Là, c'est juste de l'acharnement puéril.
Source ?
Source ? KDE Le fait…
Bravo Microsoft (enfin surtout la correction de la merde du constructeur de ton écran)
J'ai surtout l'impression que c'est toi qui te regarde le nombril, mon pauvre. Pas foutu de sortir de ta rengaine et d'avoir une approche constructive depuis 20 ans. Tu vas faire un ulcère dans quelques secondes à ce train là (on va pas te regretter, remarque).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Tres bon
Posté par Tonton Benoit . Évalué à 8.
Déjà ton "problème" ne concerne pas le noyau mais Xorg, donc tu est hors sujet.
On peut choisir sa fréquence de la même façon sous Linux que sous Windows ! Si on a les bons pilotes…
Uniquement pour les modes définis par la norme Vesa, tout comme tu n'a pas besoin du pilote de ta carte graphique pour afficher le BIOS en 640x480.
Mais pour les modes un peu plus exotiques, il faut un pilote, certes un simple fichier texte suffit, on appelles ça des modelines, mais c'est bien un pilote et Windows le gère comme tel, dans Panneau de configuration -> Ajout de matériel.
Sans ça tu aura au choix pas d'affichage, des lignes horizontales qui vibrent avec un cri strident façon Canal+ sans décodeur (mon bon vieux 15 pouces réagissait comme-ça) ou un affichage d'une ligne sur deux sur un coté de l'écran et ce qui ressemble à une ombre de l'autre (ça c'est quand on utilises une mauvaise configuration pour l'entrelacement).
C'est pareil sous Linux et Windows. Si ton écran affiche une résolution non standard, soit il l'exporte via l'EDID, soit il exporte un EDID buggué (et le constructeur pourra pousse un quirk dans Windows pour qu'une correction soit appliqué automatiquement) soit il exporte rien du tout (pour les plus vieux moniteurs) et il faudra sous Windows, sélectionner l'écran dans ajout de périphérique éventuellement après avoir inséré le CD contenant le driver si le fabriquant ne l'a pas poussé dans Windows.
Sous Linux faudra trouver les bonnes modelines et les ajouter à la configuration de Xorg, on peut se baser pour ça sur le fichier .ini pour Windows ou utiliser un script de génération automatique en ligne et faire plusieurs essais.
À noter que si ce problème a quasiment disparus pour les écrans modernes, la même chose bat son plein en ce moment pour les périphériques d'entrée en USB (claviers, souris…), là déjà on est pas HS car ça concerne le noyau, mais le problème est pire : Les constructeurs buggent volontairement leurs tables USBHID (un peu l'équivalent de l'EDID) pour Forcer les utilisateurs de Windows à utiliser le logiciel fournis à fin de profiter des touches et fonctionnalités spéciales (alors que la norme USBHID est largement suffisante pour ces cas d'utilisation).
On peut se demander pourquoi tant d'acharnement à forcer l'utilisateur à utiliser des programmes alors qu'une norme supporté à la fois par Windows, Linux et MacOS permet de se passer du coût de leur développement. Espionnage ? Comme nous le rappelles Android à chaque fois qu'on installe un clavier virtuel, celui qui contrôle nos entrées a un large pouvoir.
Comment Linux gère ça, vu que bien sûr les fabricants s'en fiches de Linux ?
Ben en ajoutant au noyau des tables USBHID corrigés pour les périphériques buggés. Du coup il vaut mieux, si on ne veut pas avoir à créer ces tables corrigés soit-même (je l'ai déjà fait), acheter des grandes marques genre Logitech, ils sont pas moins buggés, mais le quirk arrive bien plus vite et bien plus sûrement dans le noyau.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tres bon
Posté par cluxter . Évalué à 3.
OK donc tu sais même pas ce que fait le BIOS en fait ? Nan mais tu peux le dire que tu sais pas ce que tu racontes et que t'es juste là pour essayer d'avoir raison sans arguments techniques, on t'en voudra pas tu sais (et tu passeras toujours moins pour un con qu'en essayant d'argumenter avec des arguments totalement foireux).
[^] # Re: Tres bon
Posté par cluxter . Évalué à 10.
Non seulement on le prétend, mais en plus on a raison.
Un exemple avec les cartes graphiques AMD :
http://xorg.freedesktop.org/wiki/RadeonFeature/
Le pilote libre est maintenu et de plus en plus optimisé pour toutes les cartes graphiques depuis l'an 2000. Le pilote propriétaire (avant tout à destination de Windows) ne l'est pas, alors que Windows représente 90 % des parts de marché. Cherchez l'erreur.
Essaie de faire tourner une carte graphique de 2008 sous Windows 8. Si tu y arrives, il te faudra passer l'épreuve des bugs qui ne seront jamais résolus car le support est terminé, donc on peut jeter la carte à la poubelle.
Là tu racontes vraiment que des conneries pour avoir raison et ça te ridiculise au plus haut point. Le panneau de configuration nommé "Affichage" dans XFCE permet de le faire. Donc si t'es pas capable de trouver ça, tu devrais juste arrêter d'utiliser un ordinateur parce que c'est encore plus simple à trouver que sous Windows.
Dixit le mec même pas foutu de cliquer sur "Menu", "Paramètres", "Affichage".
Linux est libre, donc gratuit. Si on te fait payer quelque chose, c'est le service de maintenance, et dans ce cas c'est après ton fournisseur de service que tu dois gueuler. S'il t'a vendu du rêve, c'est votre problème à tous les 2. C'est pourtant bien écrit dans la licence GPL (oui oui, c'est fait pour être lu) :
"This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
"
Pour ce qui est du modèle économique, Linux est utilisé sur les 1 milliards de smartphones/tablettes Android produits chaque année. A quoi il faut ajouter tous les produits électroménagers d'LG par exemple (aspirateurs-robots, réfrigérateurs, machines à laver,…). En fait Linux est dominant absolument partout sauf sur le desktop. Donc je pense que le modèle économique n'est pas trop mal.
Il y a des milliers d'ingénieurs informatique qui sont payés par Red Hat, HP, Intel, Google, Facebook, etc., pour coder Linux, même Microsoft paie des mecs pour ça. Donc si personne ne veut te payer pour que tu codes, c'est juste que t'es trop mauvais, c'est tout. Arrête de balancer ton incompétence sur les autres.
Et quant au fait de "devoir se plier a leur conditions a la con", je t'invite à lire les conditions d'utilisations générales de Microsoft qui sont extrêmement restrictives.
[^] # Re: Tres bon
Posté par jyes . Évalué à 5.
Non, car les résolutions et fréquences listées dans ce panneau reposent sur les informations fournies par l’écran, afin de ne pas lui envoyer un signal qu’il ne saurait pas traiter. Dans le cas de Riendf, il a un écran foireux qui envoie des informations erronées, et apprécie que sous Windows, on puisse envoyer n’importe quelle fréquence et n’importe quelle résolution, quitte à détériorer le matériel.
Du coup, ça me semble normal que XFCE ne le propose pas, c’est clairement un problème au niveau de l’écran, et c’est plutôt appréciable que l’interface d’XFCE ne t’incite pas à faire n’importe quoi. Par contre, ce que Riendf veux nous faire croire qu’il ne sait pas, c’est qu’il peut forcer les résolutions et court-circuiter l’auto-détection qui utilise les infos fournies par son écran, juste en remplissant les bonnes informations lui-même dans son Xorg.conf. Autrement dit, sur un système qui évite que l’utilisateur fasse des manipulations malencontreuses, dans le cas d’un matériel foireux comme le sien, il y a quand même un endroit où ceux qui savent ce qu’ils font peuvent régler leurs soucis.
La vie est bien faite (sous GNU/Linux), mais ça, il ne vous le dira pas !
[^] # Re: Tres bon
Posté par Renault (site web personnel) . Évalué à 3.
Mais le pire c'est qu'apparemment c'est possible mais il faut modifier un fichier de conf pour ça, il n'y a pas d'interface graphique proposant un service similaire.
Mais bon, par défaut Windows se limite de la même façon, ce sont des outils tiers qui permettent de s'affranchir des éventuels défauts d'un écran.
[^] # Re: Tres bon
Posté par Albert_ . Évalué à 8.
Le gars en question ne veut pas se servir de linux et il n'a meme pas essaye quoique ce soit. Il dit des conneries et il le sait c'est juste pour faire reagir et troller comme un goret.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tres bon
Posté par Albert_ . Évalué à 8.
Linux ne pretend pas supporter ton ecran non plus donc egalite balle au centre.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tres bon
Posté par xcomcmdr . Évalué à 5. Dernière modification le 07 mars 2015 à 09:10.
Aucun rapport. En plus, ton écran a au moins 15 ans.
Et encore une fois, tu dis n'importe quoi.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tres bon
Posté par xcomcmdr . Évalué à 6.
Oui donc l'EDID, les résolutions supportés, tout ça ça se gère sans le moindre code.
J'ai déjà dix mille fois que le driver pouvait être générique au possible (normes VGA, EDID, etc… heureusement qu'il n'y a pas un driver par écran…), être très simple, il n'empêche que quelque chose qui gère le mode d'affichage c'est… un putain de driver.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tres bon
Posté par SamG . Évalué à 6.
Tu dois avoir raison, mais alors ça serait sympa si tu pouvais contacter Microsoft pour leur dire que les Monitor Drivers ça sert à rien.
Sans parler de NEC qui sont de vrais rigolos de livrer des drivers pour plus de 200 écrans LCD.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tres bon
Posté par SamG . Évalué à 6.
ah ok, donc tu parles de ce genre de drivers pour écran CRT ?
Je pense que tu devrais un peu revoir à la baisse la haute opinion que tu as de toi-même…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tres bon
Posté par Moonz . Évalué à 8.
Linux n’a pas les drivers dont ton écran n’a pas besoin ? J’ai du mal à voir où est le souci du coup.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10. Dernière modification le 12 mars 2015 à 08:32.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tres bon
Posté par xcomcmdr . Évalué à 5.
Les drivers graphiques fonctionnent très bien au moins pour Intel, nVidia, et ATI. Qui représentent justement 99% du marché des cartes graphiques / IGP.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tres bon
Posté par xcomcmdr . Évalué à 5. Dernière modification le 01 mars 2015 à 08:53.
Tu crois qu'au rythme où sortent les écrans, chaque écran a du code/data spécifiques à intégrer par un dév' upstream ? Tu crois qu'ils ont que ça à faire ?!
Ton écran donne de la merde, ça se corrige en 30 secondes.
[mode Riendf]
Mais comme tous les wussers, t'es pas fichu d'appliquer une documentation. Pitoyable.
[/mode Riendf]
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tres bon
Posté par xcomcmdr . Évalué à 6.
Mais comme tous les wussers, t'es pas foutu de te sortir les doigts du cul. Tu préfères râler sur linuxfr plutôt que de résoudre ton problème ou acheter un meilleur écran (un sans bug à la con).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10. Dernière modification le 07 mars 2015 à 18:33.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tres bon
Posté par groumly . Évalué à 1.
Non, effectivement, ils preferent passer 2/3 de leurs patchs a reparer la compatibilite binaire du kernel qui pete tout toutes les 6 semaines.
Bon, je troll, mais qu'a moitie, riendf est de tres mauvaise foi, certes, mais faut pas pousser meme dans les orties non plus. Ya une raison pour laquelle la plupart des constructeurs n'ont jamais livre un support linux decent, parce qu'ils ont autre chose a faire que de patcher leur drivers (ou liste de resolutions, pour faire plaisir a riendf) en permanence juste pour qu'ils continuent a marcher.
Oui, je sais, "yzonka" liberer leur code, mais le fait est que l'approche "yzonka" ne marche clairement pas, sinon ca fairait pas 15 ans qu'on troll sur ce sujet.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Tres bon
Posté par Albert_ . Évalué à 1.
C'est incroyable linux ce systeme tout pourri dont les utilisateurs sont encore a utiliser des ecran noir avec les caracteres verts et naturellement sans aucun system de fenetre, a imprimer sur des imprimantes matricielles enfin d'apres les windowsiens et les appleiste…
Vous devriez rester dans votre petit monde et arrete de parler de chose qui ne vous interesse pas.
[^] # Re: Tres bon
Posté par Ytterbium . Évalué à 2.
Ça, ça m'intéresse. J'avais vus que c'était possible, mais j'avais pas réussi à le faire fonctionner correctement. As-tu configuré quelque chose ?
[^] # Re: Tres bon
Posté par Anthony Jaguenaud . Évalué à 2.
Je suis intéressé aussi, du coup…
[^] # Re: Tres bon
Posté par robin . Évalué à 2.
Il me semble qu'il faut regarder du coté d'udev.
Je laisserai xcomcmdr répondre bien évidemment :)
bépo powered
[^] # Re: Tres bon
Posté par ariasuni . Évalué à 2.
Pour la désactivation du pavé tactile pendant la frappe, je ne pense pas qu’on puisse régler ça dans X.org. Ça se règle en graphique dans KDE.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Tres bon
Posté par xcomcmdr . Évalué à 2.
première solution - parmi d'autres dans le lien - :
une règle udev
/etc/udev/rules.d/01-touchpad.rules
SUBSYSTEM=="input", KERNEL=="mouse[0-9]*", ACTION=="add", ENV{DISPLAY}=":0", ENV{XAUTHORITY}="/home/username/.Xauthority", RUN+="/usr/bin/synclient TouchpadOff=1"
SUBSYSTEM=="input", KERNEL=="mouse[0-9]*", ACTION=="remove", ENV{DISPLAY}=":0", ENV{XAUTHORITY}="/home/username/.Xauthority", RUN+="/usr/bin/synclient TouchpadOff=0"
seconde solution :
dans l'interface de configuration du touchpad de KDE (nommé kcm_touchpad, qui se rajoute à KDE 4), cocher "désactiver le touchpad quand la souris est branchée." ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Tres bon
Posté par Anthony Jaguenaud . Évalué à 2.
J’étais surtout intéressé par la désactivation pendant la frappe au clavier… le nombre de fois où je l’active pendant que j’écris…
[^] # Re: Tres bon
Posté par xcomcmdr . Évalué à 3.
Xfce le fait aussi, si tu as Xfce (dans le gestionnaire de paramètres).
Mais sinon, il suffit de rajouter ça au démarrage (autostart) :
syndaemon -i 1.0 -K -R -t
Comment: Disable touchpad while typing, with a reasonable delay and only for tapping and scrolling
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Tres bon
Posté par Frank-N-Furter . Évalué à 4.
Comment fonctionne un shift+click si on désactive le touchpad?
Depending on the time of day, the French go either way.
[^] # Re: Tres bon
Posté par robin . Évalué à 1.
Chez moi ça marche avec syndaemon d'activé. Je pense que ça ne désactive pas les touches modificatrices.
bépo powered
[^] # Re: Tres bon
Posté par Martin Peres (site web personnel) . Évalué à 3.
La vrai solution est d'utiliser xf86-input-libinput (FOSDEM2015). Je l'utilise sur mon nouveau portable (clickpad) et ça marche parfaitement.
[^] # Re: Tres bon
Posté par xcomcmdr . Évalué à 2.
Ah super !
Je vais tester ça. Jusqu'ici, je désactivais le touchpad au branchement d'une souris (une option proposée par la kcm tierce "kcm_touchpad" et je ne sais pas comment elle fait exactement mais ça marche mieux qu'avec udev).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Coquille
Posté par magnetik (site web personnel) . Évalué à 4.
Le lien vers "execveat()" dans "En bref" pointe vers l'espace de rédaction.
[^] # Re: Coquille
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# Linus multifonction
Posté par arnaudus . Évalué à 5.
Il n'est pas pété de thunes Linus? C'est sympa de refaire sa salle de bains tout seul, mais c'est quand même tentant de faire appel à un pro qui se pête les genoux à ta place, quand tu peux te le permettre…
[^] # Re: Linus multifonction
Posté par kowalsky . Évalué à 10.
Il aime peut être faire un peu les choses lui même.
Dans mon cas, par exemple, je suis pété de blé et j'aime faire certaines choses. Parce que l'ordinateur c'est bien, mais il faut aussi savoir faire des choses "dans la vrai vie". Donc quand je peux, je bricole à la maison, la voiture, tout ce que je peux !
Bon, en fait je ne suis pas pété de blé, mais le fait de bricoler certains trucs, même si je ne le fait pas pour ça, ça fait des économies par effets de bord.
Par exemple, changer bougies et bobine d'allumage : 300€ par le garage. Environ 100€ en le faisant moi même.
Mais c'est surtout que c'est dans l'esprit de se dire : Mais comment on fait ça ? Et comme pour tout, une fois fait, tu te rend compte que c'est simple. Pour d'autre choses, tu te rend compte que c'est moins simple parfois.
Ça permet de garder les pieds (et l'esprit) sur terre.
[^] # Re: Linus multifonction
Posté par Philip Marlowe . Évalué à 6. Dernière modification le 17 février 2015 à 09:57.
Tu ne comprends pas. C'est faire partie d'un club très exclusif de membres triés sur le volet que de s'occuper de l'évolution du noyau un jour et du carrelage de sa salle de bains un autre jour. Le plaisir de faire ce qu'on veut. Et puis on ne se pète pas les genoux en carrelant une salle de bains.
Edit : grilled.
[^] # Re: Linus multifonction
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 10.
Ça peut aussi être une bonne occasion de montrer à ces gamins ce que « to hack » signifie littéralement.
[^] # Re: Linus multifonction
Posté par MTux . Évalué à 10.
Peut-être qu'il a épuisé tous les artisans à force de les insulter quand un truc n'est pas droit.
[^] # Re: Linus multifonction
Posté par xcomcmdr . Évalué à 7.
Dire qu'ils devraient être avortés rétroactivement, ce n'est pas les insulter voyons !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Linus multifonction
Posté par Kytrix . Évalué à 4.
Je suis bien content d'apprendre que j'ai un point commun avec Linus ! Bah oué je ne fais pas de plongée, je ne contribue pas au noyau/logiciel-libre !
En revanche j'ai déjà carrelé 2 Sdb et une cuisine :D
[/mylife]
[^] # Re: Linus multifonction
Posté par cluxter . Évalué à 6.
Ce qui me fait vraiment halluciner et marrer en même temps, c'est de me dire que des milliards de machines et de personnes (oui des milliards puisque les smartphones Android s'écoulent à hauteur de presque 1 milliard par an) doivent attendre que Monsieur Torvald ait terminé sa salle de bain pour avoir droit à la mise à jour de leurs systèmes.
"- Chef ! Le noyau est en retard d'un jour et notre milliard de clients s'impatiente, chef !
- Ah, encore un coup des chinois du FBI, saperlipopette !
- Chef ! On me dit que c'est parce que M. Torvald termine sa salle de bain, chef !
- Tu t'fous d'moi, mon p'tit Baleine ?"
[^] # Re: Linus multifonction
Posté par arnaudus . Évalué à 10.
Si je pouvais mettre à jour mon Android comme n'importe quelle distribution Linux, qu'est-ce que je serais content! Mon smartphone est un gadget jetable, qui vivra toute sa vie avec le système avec lequel il est né.
[^] # Re: Linus multifonction
Posté par patrick_g (site web personnel) . Évalué à 5.
Moi mon Nexus 4 est régulièrement mis à jour via des updates automatiques. Il a commencé sa vie en version 4.2 et il tourne maintenant en version 5.0 Lollipop.
Faut savoir choisir des modèles qui ne seront pas abandonnés au bout de trois mois par leur constructeur :-)
[^] # Re: Linus multifonction
Posté par cluxter . Évalué à 4.
Le mieux ça reste de mettre un OS comme CyanogenMod. C'est ce que j'ai fait avec mon HTC Sensation et :
1) j'ai la dernière version d'Android à jour alors que la dernière version officielle date d'il y a genre 2 ans ;
2) j'ai énormément gagné en autonomie : ma batterie tient 24h quand elle tenait moins de 10h avec l'OS d'origine ;
3) c'est infiniment plus réactif : avant il fallait parfois plus d'une minute entre le moment où j'appuyais sur un contact et le moment où il appelait ce contact… Parfois je ne voyais même pas qui m'appelait car le temps que l'OS affiche le nom du contact, la personne était tombée sur le répondeur ! En ayant installé CyanogenMod, je bénéficie des optimisations faites pour CyanogenMod, je n'ai plus toute la surcouche HTC qui me ralentissait terriblement le téléphone et qui me pompait toute la batterie, et je n'ai plus la surcouche de mon opérateur téléphonique.
J'ai un peu galéré pour le mettre, c'est vrai, mais maintenant que c'est fait qu'est-ce que je suis content !! Ca valait vraiment la peine, je vous assure. Un ami a fait de même avec un Samsung Galaxy S4 et il est ravi.
[^] # Re: Linus multifonction
Posté par Albert_ . Évalué à 1.
Donc tu utilises un fork de android et pas la version google.
[^] # Re: Linus multifonction
Posté par cluxter . Évalué à 1.
Oui. Je répondais sur le fait d'avoir les dernières mises à jours. Android n'est plus maintenu à partir d'un certain moment, alors que CyanogenMod l'est. Donc s'il veut avoir facilement les mises à jour pour son smartphone, le mieux c'est d'utiliser un OS comme CyanogenMod.
[^] # Re: Linus multifonction
Posté par arnaudus . Évalué à 10.
Oui, mais du coup, ça veut dire qu'acheter un smartphone sous Android, c'est pire que d'acheter un PC livré avec Windows : on paye pour l'OS qu'on ne veut pas, et on risque de rendre le matériel inutilisable à la moindre mauvaise manip.
* Quid de la garantie?
* Quid du support de l'opérateur téléphone (oui, parce qu'un téléphone sert aussi à téléphoner!)
* Quid des offres commerciales (style "on reprend votre ancien appareil pour une somme symbolique et on vous fait payer le nouveau à crédit")?
Le problème, c'est qu'il y a une différence entre accepter d'utiliser un OS semi-proprio comme Android (on peut par exemple utiliser l'Android par défaut, et ajouter des applications libres, ça peut sembler un compromis acceptable) et rester bloqué sans mises à jour pendant des années. Quand Microsoft arrête le support d'une ancienne version de Windows, la mise à jour n'est plus possible à cause de Microsoft ; c'est une décision politique de la part du fournisseur de l'OS. Les problèmes qu'on a avec les tablettes et les smartphones, c'est que Google sort toujours de nouvelles versions de l'OS, mais que pour des raisons techniques et/ou commerciales, la possibilité de mettre à jour dépend exclusivement de la bonne volonté du constructeur de l'appareil, constructeur qui sort 57 modèles par an, et qui ne voit pas l'intérêt de proposer des mises à jour (il faut une équipe qui teste les mises à jour, un service qui gère les bugs dûs aux mises à jour, et on risque même d'améliorer le fonctionnement des appareils avec le temps, ce qui dissuade d'acheter de nouveaux modèles). Bref, tout est totalement verrouillé grâce à la connivence et aux ententes plus ou moins forcées entre les acteurs du marché, et c'est hyper-malsain.
Il y a 10 ans, je n'aurais jamais pu imaginer qu'une partie substantielle de l'humanité utilise Linux au quotidien. Mais je n'aurais jamais pu imaginer non plus que ces Linux soient virtuellement intouchables et que les appareil partent à la poubelle avec le même OS binaire au bit près que lors de l'achat.
[^] # Re: Linus multifonction
Posté par claudex . Évalué à 8.
Quand j'ai acheté mon Galaxy Nexus, il n'y avait pas de Nexus 4, j'ai dû le mettre sous Cyanogen Mod pour continuer à avoir des mises à jour (et accessoirement, une réinstallation, ça lui a fait gagner en réactivité).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Linus multifonction
Posté par Albert_ . Évalué à 2.
Euh essaye de mettre a jour un nexus one avec un truc recent qui a moins de 3 ans…
Google a bien merde sur le coup de celui la.
[^] # Re: Linus multifonction
Posté par Strash . Évalué à 4.
C'est fou, le mec a passé son dimanche à refaire son carrelage ! Quel ingrat !
[^] # Re: Linus multifonction
Posté par windu.2b . Évalué à 2.
Vivement que le travail le dimanche soit généralisé, qu'on n'ait pas à attendre le lundi pour avoir notre RC hebdomadaire !
[^] # Re: Linus multifonction
Posté par Benoît Sibaud (site web personnel) . Évalué à 8.
Il aurait suffit que des milliards de personnes mettent chacune un coup de truelle dans sa salle de bain, et ça aurait été fini beaucoup plus vite (moyennant la gestion des flux d'entrée/sortie des gens dans ladite salle de bain), même s'il avait opté pour une mosaïque à tous petits morceaux. Sinon elle a un numéro de version ou un nom de code cette salle de bain ?
[^] # Re: Linus multifonction
Posté par KiKouN . Évalué à 7.
Je pense que faire passer 1 milliards de personne par le couloir aurait un peu détruit le revêtement de ce couloir. Il aurait donc fallut refaire le couloir. Puis l'entrée ( 2 millards de personnes y ont passé quand même ). Puis l'allée du jardin ( 3 milliards ). Puis la route ( 4 milliards ). Puis les bus ( 5 milliards ) . Puis l'aéroport ( 6 milliards ). Puis les avions ( 7 milliards ) …
Bref, faire déplacé 3 fois l'humanité pour une salle de bain. Je préfére profité de mon dimanche.
[^] # Re: Linus multifonction
Posté par khivapia . Évalué à 5.
Surtout que ça serait compliqué, d'après l'auteur de XKCD
https://what-if.xkcd.com/8/
[^] # Re: Linus multifonction
Posté par Dring . Évalué à 2.
C'est nul son scénario. Les premiers à partir de l'île devraient être des conducteurs de bateau, qui ramèneraient des gros paquebots pour emmener tout le monde par la mer.
Ca empêcherait pas un carnage et une explosion de violence, mais bon…
[^] # Re: Linus multifonction
Posté par FantastIX . Évalué à 2.
s/fallut/fallus (sic)
--> []
[^] # Re: Linus multifonction
Posté par FantastIX . Évalué à 7.
Supposons qu'il faille environ une minute à une personne pour (au pas de course)
En appliquant ça à environ 6 milliards de personnes (à la louche, sans les enfants en bas-âge), il faudrait plus de 4 millions de journées (de 24 heures) soient environ onze mille ans pour s'occuper de la salle de bains… La construction des pyramides a probablement pris moins de temps.
Même si on arrive à faire tenir 10 personnes dans la salle de bains, on ne peut pas être certain qu'il y ait la place pour que 20 personnes se croisent. Et même si c'était possible de les faire défiler en une minute sans qu'elles se croisent, on dépasserait les mille ans malgré tout.
J'en déduis que l'hypothèse de départ est fallacieuse.
-->[]
[^] # Re: Linus multifonction
Posté par arnaudus . Évalué à 6.
Attends, 6 milliards de personnes, ça peut poser 6 milliards de petits carreaux. Même si on prend des petits carreaux de piscine ou de la mosaïque (1cm / 1cm), ça fait 600 000 mètres carrés de carrelage (un carré de 774m de côté, ou 387 picines olympiques.
Ça fait une belle salle de bains.
[^] # Re: Linus multifonction
Posté par barmic . Évalué à 6.
Tu ne prend absolument pas en compte le pipelining du travail.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Linus multifonction
Posté par Tonton Th (Mastodon) . Évalué à 5.
Et avec une salle de bain octo-core ?
[^] # Re: Linus multifonction
Posté par eingousef . Évalué à 9.
Given enough truelles, all petits carreaux de salle de bains are shallow :o
*splash!*
[^] # Re: Linus multifonction
Posté par Tonton Th (Mastodon) . Évalué à 2.
Il avait peut-être plus de 1000 followers G+ pour l'aider…
# Coquille(s) et verbe "permettre"
Posté par FantastIX . Évalué à 10. Dernière modification le 18 février 2015 à 15:03.
On emploie beaucoup le verbe "permettre" (environ 21 fois, dans cette dépèche), parfois même plusieurs fois dans la même phrase. Voici quelques suggestions pour améliorer son usage et éviter les redondances.
Cartes de développement
… d'un connecteur SATA et de 160 GPIO.
[…] également utilisé par le projet Nouveau et a trouvé la liste des écritures nécessaires pour gérer manuellement la vitesse du ventilateur.
Option SO_INCOMING_CPU pour getsockopt()
Les applications qui se servent de cette option, sur les grands systèmes, par exemple, mettront à profit le matériel à files d'attente multiples en répartissant le travail sur plusieurs processeurs.
Appel système execveat()
Avec quoi?
Il sert aussi à exécuter un fichier binaire directement à partir d’un descripteur de fichier ouvert, pour une meilleure mise en œuvre de l’appel système fexecve() […]
DRM (Direct Rendering Manager)
[…] grâce à cette gestion atomique, les applications telles que le serveur X peuvent changer les paramètres de tous les plans graphiques (…) à la fois; on évite aussi, par exemple, au compositeur d’utiliser les plans graphiques au lieu d’utiliser les shaders pour le rendu vidéo.
[…] la gestion des panneaux [d'affichage?] a été étoffée, élargissant ainsi le paysage des plate-formes embarquées mues par des pilotes libres.
AMD/ATI (pilote Radeon)
Pour AMD, la version 3.19 du noyau apporte un changement très important: l’introduction du pilote AMDKFD (AMD Kernel Graphic Driver). Ce dernier expose une interface bas niveau aux applications utilisant le calcul générique sur un processeur graphique (GPGPU).
Cette interface tire parti du modèle de programmation HSA (Heterogeneous System Architecture). Ce dernier vise une collaboration plus rapide entre le processeur graphique et le processeur central.
Intel (pilote i915)
Le pilote prévient si une combinaison n’est pas possible […]
GPU des systèmes monopuces
On évite ainsi, par exemple, d'allouer une grosse portion contiguë de mémoire […]
eBPF et socket réseau
Pour Linux 3.18, Alexei Starovoitov avait activement travaillé à introduire un nouvel appel système bpf(), couvrant la gestion de programmes BPF étendu.
Malgré le nom de Berkeley Packet Filter, la création de filtres n'est pas encore à l'ordre du jour.
Nouveau pilote pour gérer les connexions réseau entre conteneurs
L’interconnexion de conteneurs au travers de réseaux virtuels se fait grâce au nouveau pilote ipvlan. Ce dernier est conçu […]
Pagination à la demande pour InfiniBand
(C'est la fonction ou l'emplacement RDMA qui est "rempli de défauts de page"?)
«La couche InfiniBand prend maintenant en charge la pagination à la demande et le paramétrage d’un emplacement RDMA, rempli par des défauts de page lorsque la mémoire est effectivement utilisée. On évite ainsi un blocage inutile d’une zone mémoire.»
mais sans certitude d'avoir bien compris ce que l'original signifie.
OverlayFS multicouche
Il est utilisé pour les CD autonomes (live CD), car il rend inscriptible une couche en lecture seule […]
Je suis bien conscient qu'à ce point, il est préférable d'agir pendant la rédaction de la dépêche. Je reconnais. Ce sont juste quelques suggestions. Note pour plus tard ;-) .
[^] # Re: Coquille(s) et verbe "permettre"
Posté par FantastIX . Évalué à 3. Dernière modification le 18 février 2015 à 15:15.
Mince… une coquille dans la correction!
on évite aussi, par exemple, au compositeur d’utiliser les shaders plutôt que les plans graphiques pour le rendu vidéo.
[^] # Re: Coquille(s) et verbe "permettre"
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
[^] # Re: Coquille(s) et verbe "permettre"
Posté par Martin Peres (site web personnel) . Évalué à 6.
Je vois qu'on a un candidat pour devenir mainteneur "Édition générale"! Tu commences quand?
[^] # Re: Coquille(s) et verbe "permettre"
Posté par FantastIX . Évalué à 2. Dernière modification le 18 février 2015 à 17:08.
C'tait pas déjà fait?
[^] # Re: Coquille(s) et verbe "permettre"
Posté par Martin Peres (site web personnel) . Évalué à 3.
Nope, je parle de devenir mainteneur! C'est a dire faire ca pour chaque release, pour le plaisir des yeux de tout le monde :)
[^] # Re: Coquille(s) et verbe "permettre"
Posté par FantastIX . Évalué à 6.
Je plaisantais, bien sûr. Ceci dit, ce serait avec plaisir. Je ne garantis pas une contribution réglée comme de l'horlogerie suisse de luxe mais je ferai de mon mieux.
# Où est passé BTRFS ?
Posté par barmic . Évalué à 7.
On entend plus parler de btrfs, il en est où ? Je crois que les dernières informations que j'avais disant que le mainteneur était embauché par facebook pour tester le fs en vraies grandeurs. On a des retours ? Il n'y a plus de nouvelles fonctionnalités ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Où est passé BTRFS ?
Posté par Kioob (site web personnel) . Évalué à 3.
Je suis un peu les annonces Btrfs (mais pas beaucoup), de ce que je constate c'est qu'il n'y a plus grand chose de «sexy» qui arrive dans Btrfs : on voit surtout des corrections de bug, du fignolage sur les outils, et de grosses corrections dans btrfsck.
D'un point de vue utilisation, ça plante moins souvent qu'avant. Le hic de mon coté c'est que j'ai beaucoup de FS qui sont définitivement corrompus, et qui continuent à faire crasher les noyaux. Difficile de faire la part des choses dans ces conditions, et je n'ai malheureusement pas toujours le temps d'extraire les images en question pour les remonter aux devs.
alf.life
# Gestion atomique du mode graphique
Posté par antistress (site web personnel) . Évalué à 5.
C'est la 1re fois que je lis en français à quoi correspond la gestion atomique du mode graphique, un grand merci pour avoir comblé cette lacune :)
[^] # Re: Gestion atomique du mode graphique
Posté par Martin Peres (site web personnel) . Évalué à 5.
De rien! C'est vrai que vu que ça approche à grand pas, j'ai commencé à expliquer un peu plus à quoi ça correspond :)
[^] # Re: Gestion atomique du mode graphique
Posté par antistress (site web personnel) . Évalué à 5.
et c'est attendu pour économiser de l'énergie avec Wayland (ici pour GNOME : https://bugzilla.gnome.org/show_bug.cgi?id=742254) ;)
# Atomic modesetting
Posté par laviestbelle . Évalué à 6.
Salut les enfants !
J'ai beau me documenter je ne comprends pas vraiment ce que c'est et en quoi c'est une révolution, ça va juste faire une baisse de la consommation d'énergie où cela va engendrer un gain de fps ?
D'ailleurs je me pose la même question pour wayland est-ce qu'il augmente les performances graphique ?
Ah et phoronix.com t'as fait un article dédié à toi Martin pérès !
Ah et si quelqu'un pouvait me renseigner sur le nouveau IR de mesa et le nouveau "amdgpu" driver ça serai très sympa :D
Ps:c'est mon premier post sur Linuxfr et je savais pas trop où le mettre donc désolé si je suis un peu hors sujet vu que je parle de ce qui est à venir dans Linux et pas ce qui est présent dans cette version.
[^] # Re: Atomic modesetting
Posté par cedric . Évalué à 10.
Alors atomic modesetting, c'est un peu le truc qui aurait du etre fait de cette maniere la des le debut. En essayant de faire simple, ca permet de mettre a jour plusieurs plans graphiques de maniere synchronise. Cela evite les artefacts graphiques principalement. On peut faire sans, mais c'est tres moche :-)
Donc cela va permettre d'utiliser les plans graphiques dans les compositeurs et les toolkits graphiques. L'interet d'un plan graphique, c'est que tu peux le positionner ou tu veux a l'ecran et gerer son affichage sans passer par le GPU qui est couteux en ressource. Entre autre optimisation possible, faire que les fenetres actives soit directement mappe dans un plan graphique. Ce qui fait que le compositing des dites fenetres ne coute plus un redraw GPU, donc gain d'efficacite. Autre optimisation potentiel, les listes verticales qui defilent. Celle-ci necessite un redraw complet a chaque nouvelle position. Avec l'utilisation des plans graphiques tu peux dans certain scenario faire que le redraw n'est lieu que lorsqu'une nouvelle zone apparait a l'ecran (pour faire simple).
Ceux sont des optimisations qui ameliorent l'efficacite generale de la stack de rendu graphique. Cela se traduit maintenant que en gain d'energie, je n'ai pas de plateforme sur lesquel je n'ai pas 60FPS. Meme des telephones vieux de deux ans arrivent a faire du 60FPS, ce n'est plus la la problematique. Il n'y a que le cas des jeux un peu poussif qui ne tourne pas en plein ecran que ca pourrait aider.
Pour ce qui est de Wayland, on aura aussi une amelioration de l'efficacite generale du systeme, le gain principale etant a mon avis sur la gestion du dual screen ou le compositeur peut gerer les ecrans de maniere independante et permettre un jeu maximise sur un ecran d'etre aussi performant que si il etait en fullscreen. Mais le principal interet de Wayland, c'est de pouvoir enfin securiser la stack graphique, ce qui est necessaire si on veut ouvrir le developpement natif a des thirds party proprietaires.
[^] # Re: Atomic modesetting
Posté par Martin Peres (site web personnel) . Évalué à 4.
Très bien expliqué Cedric!
[^] # Re: Atomic modesetting
Posté par med . Évalué à 3.
Question bête. Ces plans sont-ils liés au matériel ? Par exemple une carte ne pourrait avoir que n plans (avec n faible) ?
[^] # Re: Atomic modesetting
Posté par laviestbelle . Évalué à -2.
Aucune idée med
[^] # Re: Atomic modesetting
Posté par Martin Peres (site web personnel) . Évalué à 5.
Oui, ils sont purement matériel et généralement très limité.
[^] # Re: Atomic modesetting
Posté par laviestbelle . Évalué à 2.
Wow ! Merci beaucoup :D le sujet est un peu pointu du coup j'ai pas tout compris mais j'ai compris dans la globalité.
Juste une dernière question la gestion atomique des plans et de Wayland devra demander un support des applications/jeux où bien ce sera un gain générique ? Ah et aussi est-ce que mantle va arriver sur Linux ? Glnext ? (Je suppose que oui et à noter qu'il s'appelera Vulkan)
Je me renseigne sur le monde passionant du libre depuis déjà longtemps mais j'ai fait le grand pas depuis quelques jours alors j'ai quelques questions donc est-ce qu'il y a un endroit sur le site où on peut poser des questions généralistes ?
Désolé de prendre votre temps :m
Merci en tout cas pour la rapidité de vos réponses :)
Eviv bulgroz !
[^] # Re: Atomic modesetting
Posté par claudex . Évalué à 5.
Oui, il y a les forums
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Atomic modesetting
Posté par laviestbelle . Évalué à 1.
Merci !
[^] # Re: Atomic modesetting
Posté par ariasuni . Évalué à 4.
J’adore ton pseudo. :)
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Atomic modesetting
Posté par laviestbelle . Évalué à 1.
Et j'adore faire adorer mon pseudo qui n'est autre qu'une hymne à la vie !
Sois heureux <3
(Glnext est sorti :D, c'est le début de la fin pour crosoft)
[^] # Re: Atomic modesetting
Posté par hervé Couvelard . Évalué à 2.
C'est aussi le titre d'un film qui est plutôt grave ;-)
[^] # Re: Atomic modesetting
Posté par ariasuni . Évalué à 2.
C’est le titre d’au moins 4 films. Tu parles duquel/desquels?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Atomic modesetting
Posté par windu.2b . Évalué à 2.
Du meilleur des 4, quelle question ! :-)
[^] # Re: Atomic modesetting
Posté par eingousef . Évalué à 6.
quel pseudo de merde :o
*splash!*
[^] # Re: Atomic modesetting
Posté par Martin Peres (site web personnel) . Évalué à 7.
Les applications ne devraient jamais avoir a connaitre le matériel jusqu'à ce niveau. Les plans graphiques ne sont pas exposés par OpenGL donc c'est hors limite pour les applications.
C'est par contre quelque chose que le compositeur Wayland devrait pouvoir utiliser de façon opportuniste sans soucis car il parle déjà avec l'interface KMS du noyau qui expose ces plans graphiques de façon unifiée depuis Linux 3.18 si je me souviens bien. Le gain devrait être assez fort pour le décodage vidéo.
[^] # Re: Atomic modesetting
Posté par laviestbelle . Évalué à 1.
D'accord ! Merci pour votre aide !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.