antistress a écrit 4763 commentaires

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

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

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

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

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

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

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

C'était à force de traîner sur Phoronix et de rien comprendre aux articles parce que chaque paragraphe utilisait au moins 10 éléments de la stack graphique :)

pareil !

Les pilotes privateurs çaÿlemal
J'achète des IGP Intel depuis que j'utilise Linux parceque je ne suis pas maso (GMA 950, HD Graphics 4000).
Sinon faut te plaindre à NVidia, pas aux développeurs Linux et co
Heureusement il y a de gros progrès dans les cartons pour Nouveau (attends la dépêche à venir sur linux 3.7)

Bonne idée, le sondage !

La bascule entre deux processeurs graphiques distincts au sein d'un même ordinateur portable, en fonction des priorités du moment (performance ou autonomie) sera rendu possible avec X.Org grâce aux derniers développements libres réalisés par Red Hat et Texas Instruments au sein de Linux 3.5 et RandR 1.4 (inclus dans X Server 1.13) + adaptation des pilotes correspondants.
Mais il faut des pilotes libres (couple nouveau/intel par exemple)

Sinon on peut lire la dépêche jusqu’au bout :

contrairement à ce que laisse entendre le titre tapageur de la dépêche, atteindre la version 1.0 ne signifie pas que Wayland va magiquement et instantanément remplacer X.Org dans toutes les distributions.

Comme dirait Ken : X.Org est mort mais il ne le sait pas encore

Quand tu regardes Mutter, GNOME a déjà un compositeur-gestionnaire de fenêtres, ils doivent l'adapter à Wayland à mon avis ça devrait pas être trop dur car basé sur Clutter qui est en phase avec Wayland (Intel des deux côtés).
Pour KDE ça risque d'être plus compliqué :

Our current planning is to make KWin our Wayland Compositor. […] it seems to me that extending KWin with Wayland support is the only possible solution right now. Now KWin is an X11 based window manager and compositor. It’s development started in a time when nobody expected that there could be anything else than X11, so you could say that it expects that all that exists is X11. This means the difficulty in porting KWin to Wayland is not in adding Wayland support to KWin, but in making it possible to have a KWin without X11 support or at least to be able to start KWin without needing an X Server.

Cependant :

the refactoring work I recently blogged about is an important step on the road towards Wayland. Especially the splitting of the OpenGL compositor is very important. This means that the actual Compositor (SceneOpenGL) does no longer depend on X11. The dependency has been moved into an OpenGLBackend with currently an GlxBackend and EglOnXBackend. This makes it much easier to add further backends in future to e.g. support KWin on top of another Wayland compositor or KWin on top of KMS through libgbm.

Arf c'était toi ? Le monde est petit ! L'idée était bonne, j'ai saisi la balle au bond quand j'ai écrit un article similaire sur mon blogue :-)
Et dimanche dernier j'ai fait un joli schéma explicatif

Je pige pas en quoi l'installateur doit être modifié pour prendre en compte UEFI ? Si UEFI est configuré pour booter sur CD ou USB, ça change quoi par rapport au BIOS vu que rien ne se passe tant que l'un ou l'autre (l'UEFI ou le bIOS) n'a pas rendu la main ?

ETC2 Texture Compression For Intel Is Happening

Before getting too excited, however, this ETC2 support isn't a full implementation for texture compression on the hardware but rather is just immediately decoding the ETC2 data into RGBX data.

Even if these patches aren't the best, at least in time for Mesa 9.1/10.0 in early 2013 we should have proper ETC2 support for at least the open-source Intel driver. They really want OpenGL ES 3.0 in Mesa by time of the next release and with GLES 3.0 comes the hard requirement on ETC2 support.

Par contre une texture ETC1 marche avec les appareils supportant ETC1 ou ETC2 (=un appareil ETC2 peut décoder le ETC1).
Et il est possible de stocker une texture ETC1 et ETC2 dans un même fichier sans pour autant que le fichier ne prenne la place de deux textures (certaines parties, on ne sait quel pourcentage, sont partagées). Voir ce lien.

ETC2 Texture Compression Looks Good For OpenGL

Par ailleurs : ETC2 Texture Compression For Intel Is Happening

Lié ou pas : Intel Mesa To Force On S3TC, Floating-Point Textures

Comme dit vers le milieu de la dépêche, les photos mais aussi les vidéos et les sons sont gérés !

merci !

Merci pour la précision même si je conçois mal la différence

Casey Muratori dissects the consequences of Windows 8's closed distribution model. "But how realistic is the assumption that the Windows desktop will still be a usable computing platform in the future? And what would be the consequences were it to disappear, leaving Windows users with only the closed software ecosystem introduced in Windows 8? To answer these questions, this volume of Critical Detail examines the immediate and future effects of Microsoft's current certification requirements, explores in depth what history predicts for the lifespan of the classic Windows desktop, and takes a pragmatic look at whether an open or closed ecosystem would be better for Microsoft as a company." The section that details how none - none - of this year's greatest games (or last year's fantastic Skyrim) and only one of this year's Emmy-nominated TV shows pass Microsoft's rules sent chills down my spine.

http://www.osnews.com/story/26471/Windows_8_the_next_twenty_years

(je grasse)

C'est sûr que les choix par défaut (conservés par 99% des utilisateurs) sont sans incidence.
http://www.framablog.org/index.php/post/2009/09/19/parametrage-par-defaut

Source : http://www.phoronix.com/scan.php?page=news_item&px=OTkxMQ

Oui! Mais il existe quelques incompatibilitées comme signalé en commentaire par Laurent ci-dessus ou sur le rapport de bogue Ubuntu.
Si ça pouvait être réglé, S2TC serait de mon point de vue une vraie avancée pour les OS libres.

Une remarque complémentaire sur les brevets de S3TC que j'oublie de mettre depuis le début de cette dépêche : S3TC serait dans le giron de HTC si j'ai bien suivi, et Intel a émis publiquement de sérieux doute quant à la validité du brevet. Mais tant que le brevet n'est pas invalidé…

Tu veux dire que mesa rejette S3TC pour cause de brevets et pourtant met quand même les deux pieds dedans au titre de la compression ?

Arf j'ai peut-être extrapolé.

J'avais déduit de cette phrase que les puces autres que PowerVR géraient ETC mais ce n'est pas ce qui est écrit en fait :

At the same time it will be interesting to see how developers adopt ETC. Just because it’s a standard doesn’t mean it has to be used, and while we can’t imagine Android developers not using it once OpenGL ES 3.0 is the baseline for applications, Apple bears keeping an eye on. As a PowerVR-only shop they have used PVRTC since day one, and so long as they don’t change to another brand of GPUs they wouldn’t need to actually back ETC.

Apparemment Mali-400 gère ETC 1 ou 2 ?

Pire, au niveau logiciel, Wikipédia EN ne parle que de ETC1

Android version 2.2 (Froyo) includes support for ETC1