Pinaraf a écrit 3674 commentaires

Dans mes exemples, j'ai mis l'ACPI. Si ça c'est pas de l'hostile à Linux franchement, que te faut-il de plus ? Un système où le BIOS filtre sur l'OS, un système où un bytecode les trois quarts du temps non conforme est indispensable au fonctionnement de la machine...
Quand linux ne boote plus parce qu'on a augmenté la quantité de RAM et que la DSDT fait mal le mapping mémoire pour Linux, franchement, t'as de quoi chialer (et c'est du vécu)

Donc à côté de ça, il "suffit" que la lib OpenGL écrive dans son propre buffer, au lieu de vouloir l'écrire directement sur l'affichage, et de faire un lien entre les deux. Je me demande même si ce n'est pas possible même en étant en dehors du driver nVidia, étant donné que CUDA marche.
"Au pire", il doit être possible de lancer un serveur X sur la carte nVidia (sauf si le driver refuse parce qu'il ne trouve aucune sortie... ce qui est probable en fait.), d'avoir un genre de VNC qui affiche le contenu du serveur X de la nVidia, sur le serveur X de l'intel.
Hum, raté...

Tout d'abord, en effet, le pilote nvidia ne trouve pas de sortie, et donc il refuse de lancer un serveur X.

Sinon, pour la partie OpenGL, c'est assez complexe. OpenGL seul ne peut pas marcher, quel que soit l'OS. Il faut systématiquement un complément qui fournisse le contexte sur lequel le rendu se fera. Dans le cas de Windows, il s'agit de WGL. Dans le cas du serveur X, il s'agit de GLX.
Pour faire fonctionner Optimus en cassant le moins de choses possible sur l'architecture de X, il faudrait détourner la libGL et être capable de créer un contexte dans le pilote nVidia qui serve à faire le rendu dans un buffer qui soit dans le framebuffer de l'IGP Intel. Ce qui bloque sérieusement actuellement, c'est la création de ce contexte il me semble.

Au passage la platforme ion2 de nvidia en est réduite à un gpu sur bus pci-e alors que le ion était un vrai chipset (contrôleur usb, ddr)
En effet, le contrôleur mémoire est intégré au CPU. Et comme intel force sûrement encore la vente du chipset avec le CPU, ben nVidia a décidé de se simplifier la vie et de ne faire plus qu'un GPU à l'aide d'Optimus. Je ne vois pas comment leur reprocher ça...

La plateforme "ION1" est vouée à disparaître. Seul ION2 reste. À moins qu'AMD ne sorte un concurrent de l'Atom bien sûr...

Intel a pété sa gueule à ION en incluant dans l'Atom un IGP (et en refusant je ne sais quelle licence à nVidia).
nVidia a donc préparé ION2, avec la technologie Optimus, pour contrer ce coup bas d'Intel.

J'ai trouvé tous tes liens, j'avais fait mes recherches hein...

Sinon, l'autonomie est ridicule quand t'as la carte nvidia allumée en permanence, typiquement quand t'es sous linux et que t'as pas utilisé acpi_call ou une autre méthode pour éteindre la carte graphique.

Une mailing list sur launchpad est prévue explicitement pour ces problèmes : hybrid-graphics-linux@lists.launchpad.net.
Et pour info, l'avis de Dave Airlie sur Optimus : http://www.mail-archive.com/hybrid-graphics-linux@lists.laun(...)

Non, justement, il est catégoriquement impossible de faire marcher la carte nvidia, il n'est pas possible d'allumer la carte nvidia et d'éteindre la carte intel, ni avec switcheroo, ni avec aucune bidouille connue, ni avec les appels liés à Optimus dans la DSDT. Il n'y a pas de réglage dans le bios, pas de réglage dans windows... Rien, nada.
Le GPU Intel, avec les pilotes libres, marche pour la 2D uniquement, pour la 3D, ça rame sérieusement.

Je n'ai peut être pas été clair dans l'explication : nVidia Optimus, ce n'est pas du tout la même chose que les systèmes hybrides à base de deux cartes. Certains fabricants vont laisser un mécanisme "simulant" le système hybride, qui permet donc de faire marcher le tout sous Linux. Mais ce n'est pas le cas de l'Asus N61Jv...

Sur le très long terme tu veux dire ?
To make this as good as Windows we need to seriously re-architect the X server + drivers.

Et perso je ne considère pas qu'utiliser les pilotes libres intel, sur un GPU aussi minable que celui là, ça soit une bonne chose. C'est tellement lent que des trucs basiques vont ramer : même un jeu 3D minimal comme ksudoku (en mode roxdoku) rame... Si ça donne une bonne image du libre, je pige plus...

Sauf que pour modprobe, il faudrait installer le pilote.

Il s'agit de diodes éclairant le PC, sur le côté, autour du clavier... Toshiba appelle ça "illumination". Elles peuvent être éteintes, sous Windows, à l'aide d'un bouton sur le clavier. Sous Linux, elles restaient allumées en permanence, c'était pénible.

Bonsoir

Mon pote a, je pense, pas eu les bons réflexes, résultat il y a eu un court-circuit au niveau de la carte mère... et PAF quoi...

Effectivement, pour si peu de mails, c'est problématique.
Il faudrait que des efforts soient faits pour pouvoir rebasculer sur SQLite au lieu de MySQL, mais les performances de SQLite pour Akonadi sont... pas terribles on va dire... Une autre solution serait d'utiliser mysql embedded peut être ?

Mais il vaut mieux reprendre un serveur existant plutôt que de recoder soi-même tout le système d'indexation notamment, non ?

KMail 2.0 arrivera avec KDE 4.5.1 normalement...

Sauf que, depuis le début, l'idée c'est "une appli compatible Android == une appli compatible Linux", ce qui est faux, à moins de réduire Linux stricto senso à un noyau (et encore, le noyau des Android, avec sa couche de patchs, a des différences déjà), ce qui est assez débile à mon sens. Dans ce cas, tu peux dire qu'une appli UNIX est facilement portable sous Windows (ben oui, y'a une couche POSIX dans le noyau Windows NT5)... Tu peux aussi dire qu'une appli MacOS X est portable sous Darwin, c'est tout aussi vrai et faux.

Sauf que là, il ne s'agit pas de libraires à installer mais de librairies à écrire.
C'est comme dire que pour porter une appli sur Linux il suffit de la porter sur Windows et après d'utiliser wine... On est au même degré de similitude...

Pour ma part, Nokia navi et un coup du client googleMaps fait très bien l'affaire pour mes déplacements pédestres/cyclistes.
Oui, mais quand on voit des décalages variant de 5 à 20 mètres (voire parfois plus), ça montre que la puce n'est pas utilisable pour, par exemple, contribuer à OpenStreetMap.

Quant à la partie développement, il y a des démos interessantes sur le net, mais je suis toutefois intéressé par ton retour.
Facile : 15 minutes de développements, 15 heures pour tenter, sans réussir, de faire un environnement de cross compilation sous Linux...

Bien qu'on soit d'accord qu'Android n'est pas une distribution Linux classique, Android utilise quand même le noyau Linux.
Et alors ?
Si y'a *rien* en commun niveau espace utilisateur, ça changera quedal.
Si ton appli utilise directement les API Android pour l'affichage, le système de fichiers tordu d'Android, etc... Ben y'a aucune chance pour que ça marche sous un linux normal.

J'ai aussi un E71 pour le boulot.

Voici mon avis :
- puce GPS très très peu précise (ie ne faîtes pas d'OSM avec)
- le symbian libre, tu rêves, tu l'auras jamais sur ton E71 (déjà que tu peux pas avoir une version récente du symbian proprio)
- coder sous linux pour cet E71 relève du miracle... ou de la folie. Et même avec Qt et Qt Mobility. J'vais essayer de faire un journal sur ça le jour où ça marchera...

il est probable que Linux - avec l'aide des applications qui seront portées - pourrait profiter pour progresser sur le segment des Netbooks et des Laptops
Fail.
Android n'a rien à voir, en espace utilisateur, avec un système Linux classique. Il n'est pas possible d'utiliser une application android sous un Linux "normal". De même, une application classique (qu'elle soit KDE, Gnome, X11 directement...) ne marchera pas sous android.

Le soucis c'est la taille du journal je pense... Ça fait limite journal-marquepage...

Ce phénomène est plus vieux que cela, on le trouvait déjà à l'époque de leur appareil sans réception téléphonique, l'aphone...

Envoyé depuis mon Intel/nVidia/BIOS/Grub/Linux/X11/Qt/KDE/KHTML/Konqueror avec mon Input/Keyboard/Logitech

Yep, dommage pour ton commentaire...
Au passage, petite note pour ceux qui veulent essayer pareil : tentez aussi un coup avec la version shareware d'IDA 5.7, elle est bien plus performante et plus pratique à utiliser... (dommage que ce logiciel coûte si cher)

Il y a quelques années, le projet boomerang était intéressant : http://boomerang.sourceforge.net/ (mort lui aussi)

Sinon dans mon cas l'inclusion au noyau devrait être assez simple puisqu'il s'agit d'une "extension" d'un pilote existant... Après s'il faut séparer le pilote dans un nouveau pilote ou un truc comme ça, ça ne devrait pas poser de problèmes non plus...

J'avais également lu ton article, mais Toshiba n'utilise pas du tout WMI apparemment (en tout cas je n'ai pas trouvé de WMI dans la DSDT).
À la limite j'aurais préféré du WM, ça aurait pu être plus simple je pense...
Dans le cas de Toshiba, vu l'horreur qu'est la fonction GHCI, la DSDT ne sert pas à grand chose je pense. Ou alors c'est dans une partie vraiment compliquée à comprendre, mais je doute que l'on puisse trouver les valeurs magiques sans le pilote windows.

Sinon j'ai envoyé un mail à un type contribuant au noyau chez toshiba, merci pour l'idée de vérifier le git log (j'ai fait qu'un grep sur le code du noyau...)
On verra le résultat.

Sic, je ne me suis basé que sur la date des différents documents.

À titre d'information, quand j'ai écrit le code dans le noyau, je me suis inspiré des autres pilotes de diodes... Et j'ai vu que le pilote dell_led est écrit par des employés de Dell directement...