Bonjour à tous. Joyeux noël (et bientôt bonne année 2009) ! :-D

J'ai reçu un vaio vgn-z11mn il y a peu. J'ai vite viré vista puis réinstallé windows xp downgrade et fedora 10. J'utilise le noyau PAE vu que j'ai 4GB de ram avec et tout fonctionne si ce n'est la gestion graphique... (donc ça fonctionne pas tant bien au final)

L'ordinateur portable possède un switch software permettant d'utiliser soit une carte graphique intégrée Intel GM45 (pour la durée, l'autonomie sur batterie), soit une carte Nvidia 9300GS (pour pouvoir faire quelques petites choses plus intéressantes, mais au coût de l'autonomie réduite).

Pour les infos :
http://www.nvnews.net/vbulletin/showthread.php?t=120810
http://vaio-online.sony.com/prod_info/series1/z/interview_Z/index_05.html

A savoir :
Le switch est logiciel et non hardware. Et malheureusement, seul Vista a la fonction intégrée pour l'utiliser en plein utilisation. Reste que cela ne me dérangerait pas de pouvoir l'utiliser avec une contrainte de reboot.
Actuellement, j'arrive à faire fonctionner la bête en démarrant d'abord sous windows xp, puis en redémarrant - à ce moment, le switch s'allume pour le choix sélectionné - et en démarrant alors sur fedora 10. Reste que je dois par la suite configurer correctement X pour utiliser le bon driver... mais ce n'est pas si grave, j'ai créé deux fichiers xorg.conf différents pour l'occasion.

Mon problème, c'est de rendre la première partie automatisée. J'aimerais pouvoir activer le switch sans avoir à faire tout le processus win start - reboot - linux start à chaque fois.

Vu que les drivers nvidia sont actuellement loin de fournir cela (en tout cas pas les versions de nvidia), et que ce n'est pas prévu pour les drivers nouveau avant bien longtemps, j'aimerais au moins automatiser le processus de "passage" par windows.
Avez-vous des idées spécifiques ?

Actuellement, mon idée est :

[1]. placer une option dans grub pour ce processus start->reboot.
Pour faire cela, il suffit de pouvoir spécifier une entrée windows (en plus de l'entrée windows déjà existante) et de lui passer des paramètres qui puissent être examinés au démarrage de windows par un programme exécuté en tâche de démarrage. Simple à imaginer, mais je suis un peu bloquer par ... tout.

[2]. le programme défini au démarrage de windows vérifiera les paramètres passés au démarrage et s'il trouve un paramètre spécifique forcera le redémarrage de l'ordinateur portable... et hop, on peut démarrer (automatiquement) sur linux fedora 10 fonctionnel !

Au pire, dès que l'information du choix a été passé à windows, si j'arrive à la récupérer avec n'importe quoi, je vois bien comment faire pour le reste. Mais peut-on passer des paramètres à windows qui soient récupérables via un programme après le démarrage de base ?

Actuellement, le grub.conf : 
... blabla de fedora

title Windows XP
    rootnoverify(hd0,1)
    chainloader +1
Partitions : hda1 pour la RECOVERY, hda2 pour Windows xp, hda3 pour le /boot, hda4 étendue contenant /, /home et swap.

Peut-on passer des paramètres spécifiques à windows ? si oui, lesquels ? et comment récupérer ces valeurs par la suite au démarrage de windows ?
Je pense que passer par Windows est une idée sangrenue et qui ne fonctionnera pas. Il faudrait plutôt aller voir du BIOS et de Fedora 10. Pour moi, l'idée est plus d'avoir deux entrée dans GRUB, une utilisant la carte Intel, l'autre utilisant la carte Nvidia.

Première chose à savoir, est ce que Fedora n'utilise bien qu'une carte tandis que l'autre est "éteinte" ? (une méthode : en utilisant le chipset Intel, tu lances Nvidia-config (pilotes proprio), pour voir comment la carte NVidia est déctecté) Parce que je confierais pas en un voyant.
Deuxième chose, comment le système voit les cartes, donc colle le résultat de la commande "lspci"

Après on vera :-D
Tout dépend du fonctionnement du switch.

Actuellement, il y a déjà une solution post-switch :
http://neotokyo.sytes.net/vgn-z11/Ubuntu8.10_vaio_vgn_z11.html

Dès que le switch sera possible sans passer par windows, bas ça sera ok.
lspci renvoie :
1. switch "stamina" : seulement la carte intel est fonctionnelle (tant mieux, c'est le but)
2. switch "speed" : semblerait que les deux cartes soient fonctionnelles chez moi.. mais au moins la nvidia fonctionne bien (compiz & co marchent)
3. switch null : si pas de passage par windows, le switch est éteint et les deux cartes sont visibles, mais rien ne fonctionne

Donc le passage par windows est pas joli du tout, mais nécessaire pour faire fonctionner le switch.
Le fait de passer par windows, au contraire, fonctionnera certainement vu que c'est ce que je dois faire manuellement actuellement. Et ça marche ! :-P
Y con esto esta listo para que nuestro Vaio vng-z11 arranque nuestras X bajo cualquier circunstancia. La unica pega es que para realizar la conmutacion de una tarjeta a otra hay que arrancar primero en Windows XP el modo que deseemos utilizar stamina o speed y reiniciar.
Espero que os sea de utilidad.

Si averiguais la manera de conmutar la tarjeta sin la necesidad de arrancar en Windows XP, por favor remitírmelo a freeshark@gmail.com
Un saludo y gracias.
Effectivement, s'il y a moyen de toucher au bios pour faire fonctionner le switch, je veux bien... sauf que c'est un bios réduit insydeh20 bios qui ne contient que très peu d'options et surtout aucune à propos du switch...
Les vaio sz avaient une option permettant le switch hardware, donc peut-être qu'il y a moyen d'utiliser le bios des sz à la place... mais je n'ai aucune idée de comment on modifie le bios - ça doit pas être sans danger 😐 - ni si le bios des sz fonctionnerait.

Note : j'ai réussi à faire planter systématiquement windows xp au démarrage pour le faire rebooter :
ajouter un os "virtuel" au boot.ini pointant sur une partition de linux ou autre... (mais pas une bonne) vu qu'il est paramétré pour redémarrer en cas d'erreur, bas vu qu'il charge une mauvaise partition, ça foire et il redémarre... sauf que windows n'a pas vraiment démarré et le switch ne s'allume malheureusement donc pas... et ça ne fonctionne pas. 🙁

Dommage, j'aurai au moins essayé. Il reste donc la solution du démarrage sur windows complet puis redémarrage que j'aimerai automatiser.
Et il semblerait que grub ne permette pas de passer des options spécifiques au chainloader... donc il faudra probablement passer par boot.ini de winxp. Ou alors existe-t-il un moyen d'exécuter des programmes avant le démarrage qui aient des accès en écriture à quelque part ? (pour y placer une valeur spécifique correspondant au choix dans grub)

Et quelqu'un sait-il comment ce switch fait pour savoir comment et quand il doit s'allumer ? il ne s'allume qu'au redémarrage après avoir été sous windows xp (ce qui est fort étrange, car ça veut dire qu'il doit se passer quelque chose à ce redémarrage et c'est ça qu'il faudrait comprendre).
La solution du double xorg.conf est celle utilisée par la plupart des gens ayant ce type de notebook. Regarde quant même de ce côté (attention c'est du ubuntu) http://forum.ubuntu-fr.org/viewtopic.php?id=101072 voir les posts de Veskit (surtout le #15 qui devrait t'intéresser).
Refuznik wrote:La solution du double xorg.conf est celle utilisée par la plupart des gens ayant ce type de notebook. Regarde quant même de ce côté (attention c'est du ubuntu) http://forum.ubuntu-fr.org/viewtopic.php?id=101072 voir les posts de Veskit (surtout le #15 qui devrait t'intéresser).
A vrai dire, ça ne concerne pas mon problème. Effectivement, si je voulais activer toutes les foncitonnalités des cartes graphiques lorsque celles-ci fonctionnent. Bas il me serait utile de gérer les diverses librairies doublons pour opengl. Dans mon cas, je vais me restreindre pour l'instant à utiliser le mode stamina uniquement pour faire des choses de base ne nécessitant pas d'accélération graphique ou très peu (pas de 3d en tout cas).

Le problème est que ce post est relatif aux sz qui possèdent : un switch hardware, un bios permettant de spécifier la carte à activer.
Je possède un vaio z (!= sz) : un switch software, un bios ultra-réduit insydeh20 ne possédant rien pour spécifier la carte à activer.

La partie qui m'intéresse est de faire fonctionner le switch. Pour le reste, j'arrive à le gérer plus ou moins bien. Mais pour faire fonctionner le switch, il me faut démarrer sur windows puis redémarrer actuellement. C'est long, fastidieux. J'aimerais automatiser cela. Au mieux, trouver comment windows fait pour indiquer quel switch doit être démarré et comment le bios fait pour le savoir au démarrage (j'imagine que c'est le bios qui active le switch).

A ce qu'il paraît (lu sur nvnews), le bios fait son choix relativement au nom de l'os de la machine.
Y a-t-il un moyen d'accéder au code source du bios ?
Pour le BIOS, généralement plus fermé tu meurs. Donc hormis si tu as envie de coder un nouveau BIOS, ne passe pas par là ^^

Je ne comprends pas trop comment fonctionne le switch. Ça fonctionne à partir d'un logiciel sous Windows qui permet de choisir soit une carte soit l'autre ou bien c'est un bouton qui potentiellement "relié" à un pilote ? En gros, est ce que t'as besoin que windows démarre en entier ou non et comment choisi la carte à utilisée ? Aussi, le "chainloader +1" t'amène au gestionnaire de boot de Vista ou celui de XP ?

Enfin, là, ça s'oriente soit vers de reverse-ingineering soit vers un scriptage du démarrage de Windows.
Le switch est un bouton, cependant il fonctionne via ... ça dépend en fait.

Actuellement, je n'a que windows xp et fedora 10 en dual boot. Cela m'est nécessaire pour fedora car vista désinitialise le switch au redémarrage tandis que ce n'est pas le cas de windows xp.

Pour l'instant, je ne sais pas jusqu'à quel point windows xp doit démarrer pour que ça fonctionne. Il semble plutôt que le bios utilise une information fournie par le système d'exploitation au redémarrage.

Comment le switch fonctionne :

[Vista]
Le bios gère peut-être le switch au démarrage, cependant, sous Vista, on peut modifier le switch pendant l'exécution de Vista en modifiant le switch (bouton).

[Windows XP]
Le bios gère le switch relativement au dernier os qui a fonctionné. Si c'était windows xp, le switch s'allume sur le mode sélectionné avant le nouveau démarrage. (Cependant, même si le switch n'est pas allumé, windows arrive à utiliser les cartes graphiques)
Si c'était linux, le switch ne s'allume pas.

Donc le bios doit regarder à quelque part quel était le dernier OS qui a démarré. Si c'est windows xp, il fait fonctionner le switch. Sinon... bas c'est pas le cas pour linux... 😐

[Linux]
Si Windows xp était le précédent os, ça fonctionne sur la carte choisie avant le démarrage.
Sinon, les deux cartes sont allumées (le switch est éteint) et rien ne fonctionne.
Dans tous les cas, lorsque linux s'éteint, il désinitialise le switch et au prochain démarrage, le switch sera éteint.

Finalement, ça dépend donc de l'os qui a fonctionné précédemment.

A propos du switch :
Le switch est un bouton qui peut être soit sur "stamina", soit sur "speed". Chaque côté possède un LED. Soit ils sont les deux éteints, soit stamina est allumé, soit speed est allumé. Lorsqu'on modifie l'état du switch pendant l'exécution, ça ne modifie pas le LED allumé à moins d'être sous windows Vista.
Donc le LED allumé indique la carte graphique utilisée. Sur XP, on aura beau changé, la carte utilisée ne changera pas. Sous linux non plus. Sous vista oui.
Par contre, si aucun LED n'est activé, linux n'arrive pas à faire fonctionner les cartes graphiques et les deux semblent disponibles (d'après lspci).

A voir :
http://www.nvnews.net/vbulletin/showpost.php?s=d983c74e9dfc85a80e19f7aca9368b48&p=1856567&postcount=13
Short story long, I think this is a combination of factors biting us - a poor system BIOS that is completely unconfigurable (I've never seen a BIOS with fewer options), that relies on detecting Windows versions to determine operation (this is something we may be able to leverage, though it's really an ugly hack). Plus the long-standing poor handling of multiple VGA adapters under linux, and probably some xorg and nvidia-drivers deficiencies in int10 initialization.

All that said, I've never looked at any of this code before, so I could be completely wrong in all of my assertions. My theory and hope though is, if Vista can initialize the card when booted in the same state we get it in Linux, then we should be able to do so too...

We could probably work around these problems temporarily with the bios-from-file hack, but BiosLocation has now been removed completely for being 'dangerous' (don't use it unless you need it, but don't remove it while it's still useful!), and various other sections have changed. I may look at implementing some analogue (maybe just mmap the bios dump and point BiosBase at it would work?) against the current code...

I have some register dumps from Windows when flicking the stamina/speed switch if they're at all usefull, but I've not been able to trace the ACPI calls involved since my Vista seems to hang after about 30 seconds when debug is enabled.
A mon avis, les solutions :

[1]. Démarrage windows, redémarrage automatique et passage sous linux automatisé (mais c'est très lourd et long)

[2]. Modifier le bios (mais je vois mal comment)

[3]. Forcer l'information du dernier OS fonctionnel à être Windows XP... mais où cela se trouve-t-il ?
En fait, j'ai plus l'impression que le problème c'est que Linux désinitialise le switch lorsqu'il s'éteint. Donc, je pense qu'il faudrait presque plus tracer les appels du noyau que d'aller voir chez Windows. Par exemple, si tu lances "tail -f /var/log/messages", et que tu modifies le switch, tu as quelque chose ?
Si je modifie le switch, rien ne se passe, que ce soit avec 
tail -f /var/log/messages
ou 
dmesg
.
Bon, alors refait les mêmes commandes après avoir démarré avec l'option "debug" à la fin de la ligne "kernel". Si t'as toujours rien, tu utilises l'artillerie lourde et tu mets "noapic acpi=off irqpoll" comme options (c'est pas dangereux, mais je pense que c'est peut-être une connerie de mettre irqpoll et nopic en même temps), et tu regardes si Linux désinitialise le switch à l'arrêt.
Yes, tu as trouvé l'os ! :-D

L'option "debug" ne me fournit rien. Lorsque je modifie le switch à l'exécution, ça ne fait rien, quelles que soient les options (debug, noacpi, noapic, acpi=off, irqpoll ...).

Par contre, si j'active le switch en passant par windows xp, puis que je redémarre sur linux en passant les options du noyau noacpi, noapic, acpi=off et irqpoll, rien de nouveau, si ce n'est qu'au redémarrage, linux n'a pas désinitialisé le switch qui est toujours allumé ! :-D
En fait, il me suffit d'utiliser l'option acpi=off pour que le switch ne soit pas désinitialisé.

Par contre, si je modifie la position du switch, au démarrage, le LED n'a pas changé. Et au final, la carte graphique n'a pas été modifiée (si j'étais sur nvidia, ça reste nvidia).
Donc ça permet de pouvoir passer indéfiniment sur linux sur la carte définie au redémarrage après win xp, mais il faut repasser sur windows pour changer la carte choisie... :-?

Au moins tu as vu juste. C'est l'ACPI qui cause la désinitialisation du switch. Mais est-ce embêtant d'utiliser acpi=off de manière courrante ? Que cela implique-t-il ?

Dans tous les cas, c'est toujours trop contraignant, il faudrait au moins pouvoir modifier la carte graphique au démarrage sans passer par windows xp.
Merci déjà, c'est un bon pas en avant. 🙂

Edit : si je force la fermeture via le bouton on/off, bas au redémarrage, le switch reste ok, mais il ne se modifie pas.
En même temps, c'était un peu prévisible que ce soit l'ACPI. Par contre, en mettant "acpi=off", tu perds tout ce qui est gestion de l'énergie, pas très cool sur un portable. De manière a avoir un effet un peu moins global sur le système, teste avec "pci=noacpi" ou "pnpacpi=off" à la place de "acpi=off"

Je pense plus ou moins avoir trouvé une solution grâce au site Less Watt (merci Intel). À partir cette page (tout à la fin), sans option relative à l'acpi au boot, tu effectues les 3 premières étapes de "How to Build a custom DSDT into the kernel" et tu colles ici le fichier "DSDT.dsl".
OK, pour les tests d'options, je ferait ça demain (ou plutôt aujourd'hui ...).
Pour le fichier DSDT.dsl, vu sa taille, je l'ai uploadé sur un serveur :

http://projects.wox-xion.ch/intern/vaio-z11/acpi/DSDT-02.01.2009_01.dsl

Edit : j'avoue ne pas comprendre ce qui est contenu dans ce fichier (va falloir que je lise les docs du site que tu as proposé), mais les passages tel que : 
Name (_HID, EisaId ("PNP0A08"))
            Name (_CID, 0x030AD041)
            Name (_ADR, Zero)
            Method (_INI, 0, NotSerialized)
            {
                Store (One, GPO9)
                Store (0x07D0, OSYS)
                If (CondRefOf (_OSI, Local0))
                {
                    If (_OSI ("Linux"))
                    {
                        Store (0x03E8, OSYS)
                    }

                    If (_OSI ("Windows 2001"))
                    {
                        Store (0x07D1, OSYS)
                    }

                    If (_OSI ("Windows 2001 SP1"))
                    {
                        Store (0x07D1, OSYS)
                    }

                    If (_OSI ("Windows 2001 SP2"))
                    {
                        Store (0x07D2, OSYS)
                    }

                    If (_OSI ("Windows 2006"))
                    {
                        Store (0x07D6, OSYS)
                    }
                }

                HGWH (0x05)
            }
Je les aime bien. Ou plutôt, ça ressemble à des choses qui peuvent intéresser vu le contexte. 🙂

Edit 2 : ça vaut la peine que je fasse la manip pour chaque situation ? (switch nvidia, switch intel, switch off) pour faire un diff des versions et peut-être voir les données qui changent ? (todo, but tomorrow)
Resalut.
Pour information supplémentaire donc...
Ni pnpacpi=off ni pci=noacpi ne fonctionnent : le switch est quand même désinitialisé.

Ajout : j'ai refait la manipulation DSDT pour chaque cas (NVIDIA, INTEL et NOTHING) en vérifiant si ça se modifiait après un démarrage avec windows (1st ou 2nd).
Quelques exemples :
- nvidia (2nd) : http://projects.wox-xion.ch/intern/vaio-z11/acpi/nvidia/DSDT-02.01.2009_02.dsl (voir post précédent pour 1st)
- intel (1st) : http://projects.wox-xion.ch/intern/vaio-z11/acpi/intel/DSDT-02.01.2009_01.dsl
- nothing (1st) : http://projects.wox-xion.ch/intern/vaio-z11/acpi/nothing/DSDT-02.01.2009_01.dsl
- nothing (2nd) : http://projects.wox-xion.ch/intern/vaio-z11/acpi/nothing/DSDT-02.01.2009_02.dsl

Si on fait un diff, on remarque que - mis à part le header commenté où est inscrit la date - les seuls changements sont entre la version NVIDIA et celles INTEL/NOTHING.
Si on redémarre avec windows, ça ne change rien (nvidia 1 et nvidia 2 sont les mêmes à la date près).
Le diff (nvidia - intel) : 
5c5
<  * Disassembly of DSDT.cat, Fri Jan  2 17:23:07 2009
---
>  * Disassembly of DSDT.cat, Fri Jan  2 17:35:02 2009
140c140
<     OperationRegion (MBOX, SystemMemory, 0xBBCBEC18, 0x000002BC)
---
>     OperationRegion (MBOX, SystemMemory, 0xBFEBEC18, 0x000002BC)
557c557
<     OperationRegion (NVST, SystemMemory, 0xBBCBEED4, 0x000000D8)
---
>     OperationRegion (NVST, SystemMemory, 0xBFEBEED4, 0x000000D8)
Les versions INTEL et NOTHING (aucun led) sont identiques (à la date près).
Bon, puisque ni pnpacpi=off ni pci=noacpi ne fonctionne, utilise acpi=ht, celui là devrait fonctionner.

Pour le fichier DSDT, ça peut être intéressant quand j'aurais trouvé l'équivalent d'un manuel :-D Le diff par contre donne des informations un peu mystérieuse ; peut-être l'activation de la mémoire de carte Nvidia où quelque chose dans le genre ...

Par contre, dans le même genre de diff, pourrais tu également le faire avec les commandes dmidecode et lspci -vv.
Pour acpi=ht, ça fonctionne : le switch n'est pas désinitialisé, mais je ne peux pas le modifier (si je le modifie, le led ne change pas, même après reboot).

Pour lspci -vv et dmidecode, voici les résultats respectifs :
- nvidia :
http://projects.wox-xion.ch/intern/vaio-z11/acpi/nvidia/lspcivv-02.01.2009_01
http://projects.wox-xion.ch/intern/vaio-z11/acpi/nvidia/dmidecode-02.01.2009_01
- intel :
http://projects.wox-xion.ch/intern/vaio-z11/acpi/intel/lspcivv-02.01.2009_01
http://projects.wox-xion.ch/intern/vaio-z11/acpi/intel/dmidecode-02.01.2009_01
- nothing :
http://projects.wox-xion.ch/intern/vaio-z11/acpi/nothing/lspcivv-02.01.2009_01
http://projects.wox-xion.ch/intern/vaio-z11/acpi/nothing/dmidecode-02.01.2009_01

Et le diff est plus verbeux :
# diff nvidia intel 
diff nvidia/lspcivv-02.01.2009_01 intel/lspcivv-02.01.2009_01
6a7
>     Kernel driver in use: agpgart-intel
8c9,10
< 00:01.0 PCI bridge: Intel Corporation Cantiga PCI Express Graphics Port (rev 07) (prog-if 00 [Normal decode])
---
> 00:02.0 VGA compatible controller: Intel Corporation Cantiga Integrated Graphics Controller (rev 07) (prog-if 00 [VGA controller])
>     Subsystem: Sony Corporation Device 9025
10c12
<     Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
---
>     Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
12,22c14,17
<     Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
<     I/O behind bridge: 00007000-00007fff
<     Memory behind bridge: d2000000-d4ffffff
<     Prefetchable memory behind bridge: 00000000c0000000-00000000cfffffff
<     Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
<     BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-
<         PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
<     Capabilities: [88] Subsystem: Sony Corporation Device 9025
<     Capabilities: [80] Power Management version 3
<         Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
<         Status: D0 PME-Enable- DSel=0 DScale=0 PME-
---
>     Interrupt: pin A routed to IRQ 16
>     Region 0: Memory at d4400000 (64-bit, non-prefetchable) [size=4M]
>     Region 2: Memory at c0000000 (64-bit, prefetchable) [size=256M]
>     Region 4: I/O ports at 7130 [size=8]
25,48c20,32
<     Capabilities: [a0] Express (v1) Root Port (Slot+), MSI 00
<         DevCap:    MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
<             ExtTag- RBE+ FLReset-
<         DevCtl:    Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
<             RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
<             MaxPayload 128 bytes, MaxReadReq 128 bytes
<         DevSta:    CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
<         LnkCap:    Port #2, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <256ns, L1 <4us
<             ClockPM- Suprise- LLActRep- BwNot-
<         LnkCtl:    ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
<             ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
<         LnkSta:    Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
<         SltCap:    AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surpise-
<             Slot #  1, PowerLimit 75.000000; Interlock- NoCompl+
<         SltCtl:    Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
<             Control: AttnInd Off, PwrInd On, Power- Interlock-
<         SltSta:    Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
<             Changed: MRL- PresDet+ LinkState-
<         RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
<         RootCap: CRSVisible-
<         RootSta: PME ReqID 0000, PMEStatus- PMEPending-
<     Capabilities: [100] Virtual Channel <?>
<     Capabilities: [140] Root Complex Link <?>
<     Kernel driver in use: pcieport-driver
---
>     Capabilities: [d0] Power Management version 3
>         Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
>         Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 
> 00:02.1 Display controller: Intel Corporation Cantiga Integrated Graphics Controller (rev 07)
>     Subsystem: Sony Corporation Device 9025
>     Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>     Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>     Latency: 0
>     Region 0: Memory at d7800000 (64-bit, non-prefetchable) [size=1M]
>     Capabilities: [d0] Power Management version 3
>         Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
>         Status: D0 PME-Enable- DSel=0 DScale=0 PME-
56,58c40,42
<     Region 0: Memory at de200000 (32-bit, non-prefetchable) [size=128K]
<     Region 1: Memory at de224000 (32-bit, non-prefetchable) [size=4K]
<     Region 2: I/O ports at 8100 [size=32]
---
>     Region 0: Memory at daa00000 (32-bit, non-prefetchable) [size=128K]
>     Region 1: Memory at daa24000 (32-bit, non-prefetchable) [size=4K]
>     Region 2: I/O ports at 7100 [size=32]
74c58
<     Region 4: I/O ports at 80e0 [size=32]
---
>     Region 4: I/O ports at 70e0 [size=32]
84c68
<     Region 4: I/O ports at 80c0 [size=32]
---
>     Region 4: I/O ports at 70c0 [size=32]
94c78
<     Region 4: I/O ports at 80a0 [size=32]
---
>     Region 4: I/O ports at 70a0 [size=32]
104c88
<     Region 0: Memory at de225c00 (32-bit, non-prefetchable) [size=1K]
---
>     Region 0: Memory at daa25c00 (32-bit, non-prefetchable) [size=1K]
118c102
<     Region 0: Memory at de220000 (64-bit, non-prefetchable) [size=16K]
---
>     Region 0: Memory at daa20000 (64-bit, non-prefetchable) [size=16K]
147,148c131,132
<     Memory behind bridge: dd200000-de1fffff
<     Prefetchable memory behind bridge: 00000000d8100000-00000000d90fffff
---
>     Memory behind bridge: d9a00000-da9fffff
>     Prefetchable memory behind bridge: 00000000d4800000-00000000d57fffff
189,190c173,174
<     Memory behind bridge: dc100000-dd1fffff
<     Prefetchable memory behind bridge: 00000000d9100000-00000000da0fffff
---
>     Memory behind bridge: d8900000-d99fffff
>     Prefetchable memory behind bridge: 00000000d5800000-00000000d67fffff
231,232c215,216
<     Memory behind bridge: db100000-dc0fffff
<     Prefetchable memory behind bridge: 00000000da100000-00000000db0fffff
---
>     Memory behind bridge: d7900000-d88fffff
>     Prefetchable memory behind bridge: 00000000d6800000-00000000d77fffff
273c257
<     Region 4: I/O ports at 8080 [size=32]
---
>     Region 4: I/O ports at 7080 [size=32]
283c267
<     Region 4: I/O ports at 8060 [size=32]
---
>     Region 4: I/O ports at 7060 [size=32]
293c277
<     Region 4: I/O ports at 8040 [size=32]
---
>     Region 4: I/O ports at 7040 [size=32]
303c287
<     Region 0: Memory at de225800 (32-bit, non-prefetchable) [size=1K]
---
>     Region 0: Memory at daa25800 (32-bit, non-prefetchable) [size=1K]
317c301
<     Memory behind bridge: d6000000-d80fffff
---
>     Memory behind bridge: d2000000-d40fffff
337,342c321,326
<     Region 0: I/O ports at 8128 [size=8]
<     Region 1: I/O ports at 8134 [size=4]
<     Region 2: I/O ports at 8120 [size=8]
<     Region 3: I/O ports at 8130 [size=4]
<     Region 4: I/O ports at 8020 [size=32]
<     Region 5: Memory at de225000 (32-bit, non-prefetchable) [size=2K]
---
>     Region 0: I/O ports at 7128 [size=8]
>     Region 1: I/O ports at 713c [size=4]
>     Region 2: I/O ports at 7120 [size=8]
>     Region 3: I/O ports at 7138 [size=4]
>     Region 4: I/O ports at 7020 [size=32]
>     Region 5: Memory at daa25000 (32-bit, non-prefetchable) [size=2K]
357,358c341,342
<     Region 0: Memory at de226000 (64-bit, non-prefetchable) [size=256]
<     Region 4: I/O ports at 8000 [size=32]
---
>     Region 0: Memory at daa26000 (64-bit, non-prefetchable) [size=256]
>     Region 4: I/O ports at 7000 [size=32]
362,400d345
< 01:00.0 VGA compatible controller: nVidia Corporation Device 06e5 (rev a1) (prog-if 00 [VGA controller])
<     Subsystem: Sony Corporation Device 9025
<     Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
<     Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
<     Latency: 0
<     Interrupt: pin A routed to IRQ 16
<     Region 0: Memory at d4000000 (32-bit, non-prefetchable) [size=16M]
<     Region 1: Memory at c0000000 (64-bit, prefetchable) [size=256M]
<     Region 3: Memory at d2000000 (64-bit, non-prefetchable) [size=32M]
<     Region 5: I/O ports at 7000 [size=128]
<     Capabilities: [60] Power Management version 3
<         Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
<         Status: D0 PME-Enable- DSel=0 DScale=0 PME-
<     Capabilities: [68] Message Signalled Interrupts: Mask- 64bit+ Count=1/1 Enable-
<         Address: 0000000000000000  Data: 0000
<     Capabilities: [78] Express (v2) Endpoint, MSI 00
<         DevCap:    MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, L1 <4us
<             ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
<         DevCtl:    Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
<             RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+
<             MaxPayload 128 bytes, MaxReadReq 512 bytes
<         DevSta:    CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
<         LnkCap:    Port #0, Speed 5GT/s, Width x16, ASPM L0s L1, Latency L0 <256ns, L1 <1us
<             ClockPM- Suprise- LLActRep- BwNot-
<         LnkCtl:    ASPM L0s L1 Enabled; RCB 128 bytes Disabled- Retrain- CommClk+
<             ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
<         LnkSta:    Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
<         DevCap2: Completion Timeout: Not Supported, TimeoutDis+
<         DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
<         LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
<              Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
<              Compliance De-emphasis: -6dB
<         LnkSta2: Current De-emphasis Level: -6dB
<     Capabilities: [100] Virtual Channel <?>
<     Capabilities: [128] Power Budgeting <?>
<     Capabilities: [600] Vendor Specific Information <?>
<     Kernel driver in use: nvidia
<     Kernel modules: nvidiafb, nvidia
< 
407c352
<     Region 0: Memory at dc100000 (64-bit, non-prefetchable) [size=8K]
---
>     Region 0: Memory at d8900000 (64-bit, non-prefetchable) [size=8K]
442c387
<     Region 0: Memory at d8000000 (32-bit, non-prefetchable) [size=4K]
---
>     Region 0: Memory at d4000000 (32-bit, non-prefetchable) [size=4K]
444,445c389,390
<     Memory window 0: e0000000-e3fff000 (prefetchable)
<     Memory window 1: e4000000-e7fff000
---
>     Memory window 0: dc000000-dffff000 (prefetchable)
>     Memory window 1: e0000000-e3fff000
459c404
<     Region 0: Memory at d8001000 (32-bit, non-prefetchable) [size=2K]
---
>     Region 0: Memory at d4001000 (32-bit, non-prefetchable) [size=2K]
472c417
<     Region 0: Memory at d8001900 (32-bit, non-prefetchable) [size=256]
---
>     Region 0: Memory at d4001900 (32-bit, non-prefetchable) [size=256]
485c430
<     Region 0: Memory at d8001800 (32-bit, non-prefetchable) [size=256]
---
>     Region 0: Memory at d4001800 (32-bit, non-prefetchable) [size=256]
# diff intel nothing 
diff intel/lspcivv-02.01.2009_01 nothing/lspcivv-02.01.2009_01
9,10c9
< 00:02.0 VGA compatible controller: Intel Corporation Cantiga Integrated Graphics Controller (rev 07) (prog-if 00 [VGA controller])
<     Subsystem: Sony Corporation Device 9025
---
> 00:01.0 PCI bridge: Intel Corporation Cantiga PCI Express Graphics Port (rev 07) (prog-if 00 [Normal decode])
12c11
<     Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
---
>     Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
14,17c13,23
<     Interrupt: pin A routed to IRQ 16
<     Region 0: Memory at d4400000 (64-bit, non-prefetchable) [size=4M]
<     Region 2: Memory at c0000000 (64-bit, prefetchable) [size=256M]
<     Region 4: I/O ports at 7130 [size=8]
---
>     Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
>     I/O behind bridge: 00007000-00007fff
>     Memory behind bridge: e2000000-e4ffffff
>     Prefetchable memory behind bridge: 00000000c0000000-00000000cfffffff
>     Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
>     BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
>         PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
>     Capabilities: [88] Subsystem: Sony Corporation Device 9025
>     Capabilities: [80] Power Management version 3
>         Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>         Status: D0 PME-Enable- DSel=0 DScale=0 PME-
20,22c26,49
<     Capabilities: [d0] Power Management version 3
<         Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
<         Status: D0 PME-Enable- DSel=0 DScale=0 PME-
---
>     Capabilities: [a0] Express (v1) Root Port (Slot+), MSI 00
>         DevCap:    MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
>             ExtTag- RBE+ FLReset-
>         DevCtl:    Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
>             RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
>             MaxPayload 128 bytes, MaxReadReq 128 bytes
>         DevSta:    CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
>         LnkCap:    Port #2, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <256ns, L1 <4us
>             ClockPM- Suprise- LLActRep- BwNot-
>         LnkCtl:    ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
>             ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>         LnkSta:    Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
>         SltCap:    AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surpise-
>             Slot #  1, PowerLimit 75.000000; Interlock- NoCompl+
>         SltCtl:    Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
>             Control: AttnInd Off, PwrInd On, Power- Interlock-
>         SltSta:    Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
>             Changed: MRL- PresDet+ LinkState-
>         RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
>         RootCap: CRSVisible-
>         RootSta: PME ReqID 0000, PMEStatus- PMEPending-
>     Capabilities: [100] Virtual Channel <?>
>     Capabilities: [140] Root Complex Link <?>
>     Kernel driver in use: pcieport-driver
24c51
< 00:02.1 Display controller: Intel Corporation Cantiga Integrated Graphics Controller (rev 07)
---
> 00:02.0 VGA compatible controller: Intel Corporation Cantiga Integrated Graphics Controller (rev 07) (prog-if 00 [VGA controller])
29c56,61
<     Region 0: Memory at d7800000 (64-bit, non-prefetchable) [size=1M]
---
>     Interrupt: pin A routed to IRQ 10
>     Region 0: Memory at e8400000 (64-bit, non-prefetchable) [size=4M]
>     Region 2: Memory at d0000000 (64-bit, prefetchable) [size=256M]
>     Region 4: I/O ports at 8130 [size=8]
>     Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Count=1/1 Enable-
>         Address: 00000000  Data: 0000
40,42c72,74
<     Region 0: Memory at daa00000 (32-bit, non-prefetchable) [size=128K]
<     Region 1: Memory at daa24000 (32-bit, non-prefetchable) [size=4K]
<     Region 2: I/O ports at 7100 [size=32]
---
>     Region 0: Memory at ee900000 (32-bit, non-prefetchable) [size=128K]
>     Region 1: Memory at ee924000 (32-bit, non-prefetchable) [size=4K]
>     Region 2: I/O ports at 8100 [size=32]
58c90
<     Region 4: I/O ports at 70e0 [size=32]
---
>     Region 4: I/O ports at 80e0 [size=32]
68c100
<     Region 4: I/O ports at 70c0 [size=32]
---
>     Region 4: I/O ports at 80c0 [size=32]
78c110
<     Region 4: I/O ports at 70a0 [size=32]
---
>     Region 4: I/O ports at 80a0 [size=32]
88c120
<     Region 0: Memory at daa25c00 (32-bit, non-prefetchable) [size=1K]
---
>     Region 0: Memory at ee925c00 (32-bit, non-prefetchable) [size=1K]
102c134
<     Region 0: Memory at daa20000 (64-bit, non-prefetchable) [size=16K]
---
>     Region 0: Memory at ee920000 (64-bit, non-prefetchable) [size=16K]
131,132c163,164
<     Memory behind bridge: d9a00000-da9fffff
<     Prefetchable memory behind bridge: 00000000d4800000-00000000d57fffff
---
>     Memory behind bridge: ed900000-ee8fffff
>     Prefetchable memory behind bridge: 00000000e8800000-00000000e97fffff
173,174c205,206
<     Memory behind bridge: d8900000-d99fffff
<     Prefetchable memory behind bridge: 00000000d5800000-00000000d67fffff
---
>     Memory behind bridge: ec800000-ed8fffff
>     Prefetchable memory behind bridge: 00000000e9800000-00000000ea7fffff
215,216c247,248
<     Memory behind bridge: d7900000-d88fffff
<     Prefetchable memory behind bridge: 00000000d6800000-00000000d77fffff
---
>     Memory behind bridge: eb800000-ec7fffff
>     Prefetchable memory behind bridge: 00000000ea800000-00000000eb7fffff
257c289
<     Region 4: I/O ports at 7080 [size=32]
---
>     Region 4: I/O ports at 8080 [size=32]
267c299
<     Region 4: I/O ports at 7060 [size=32]
---
>     Region 4: I/O ports at 8060 [size=32]
277c309
<     Region 4: I/O ports at 7040 [size=32]
---
>     Region 4: I/O ports at 8040 [size=32]
287c319
<     Region 0: Memory at daa25800 (32-bit, non-prefetchable) [size=1K]
---
>     Region 0: Memory at ee925800 (32-bit, non-prefetchable) [size=1K]
301,302c333,334
<     Memory behind bridge: d2000000-d40fffff
<     Prefetchable memory behind bridge: 00000000d0000000-00000000d1ffffff
---
>     Memory behind bridge: e6000000-e80fffff
>     Prefetchable memory behind bridge: 00000000e0000000-00000000e1ffffff
321,326c353,358
<     Region 0: I/O ports at 7128 [size=8]
<     Region 1: I/O ports at 713c [size=4]
<     Region 2: I/O ports at 7120 [size=8]
<     Region 3: I/O ports at 7138 [size=4]
<     Region 4: I/O ports at 7020 [size=32]
<     Region 5: Memory at daa25000 (32-bit, non-prefetchable) [size=2K]
---
>     Region 0: I/O ports at 8128 [size=8]
>     Region 1: I/O ports at 813c [size=4]
>     Region 2: I/O ports at 8120 [size=8]
>     Region 3: I/O ports at 8138 [size=4]
>     Region 4: I/O ports at 8020 [size=32]
>     Region 5: Memory at ee925000 (32-bit, non-prefetchable) [size=2K]
341,342c373,374
<     Region 0: Memory at daa26000 (64-bit, non-prefetchable) [size=256]
<     Region 4: I/O ports at 7000 [size=32]
---
>     Region 0: Memory at ee926000 (64-bit, non-prefetchable) [size=256]
>     Region 4: I/O ports at 8000 [size=32]
345a378,417
> 01:00.0 VGA compatible controller: nVidia Corporation Device 06e5 (rev a1) (prog-if 00 [VGA controller])
>     Subsystem: Sony Corporation Device 9025
>     Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>     Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>     Latency: 0
>     Interrupt: pin A routed to IRQ 16
>     Region 0: Memory at e4000000 (32-bit, non-prefetchable) [size=16M]
>     Region 1: Memory at c0000000 (64-bit, prefetchable) [size=256M]
>     Region 3: Memory at e2000000 (64-bit, non-prefetchable) [size=32M]
>     Region 5: I/O ports at 7000 [size=128]
>     Expansion ROM at <ignored> [disabled]
>     Capabilities: [60] Power Management version 3
>         Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
>         Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>     Capabilities: [68] Message Signalled Interrupts: Mask- 64bit+ Count=1/1 Enable-
>         Address: 0000000000000000  Data: 0000
>     Capabilities: [78] Express (v2) Endpoint, MSI 00
>         DevCap:    MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <4us
>             ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
>         DevCtl:    Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>             RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>             MaxPayload 128 bytes, MaxReadReq 512 bytes
>         DevSta:    CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
>         LnkCap:    Port #0, Speed 5GT/s, Width x16, ASPM L0s L1, Latency L0 <512ns, L1 <1us
>             ClockPM- Suprise- LLActRep- BwNot-
>         LnkCtl:    ASPM L0s L1 Enabled; RCB 128 bytes Disabled- Retrain- CommClk+
>             ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>         LnkSta:    Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
>         DevCap2: Completion Timeout: Not Supported, TimeoutDis+
>         DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
>         LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
>              Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
>              Compliance De-emphasis: -6dB
>         LnkSta2: Current De-emphasis Level: -6dB
>     Capabilities: [100] Virtual Channel <?>
>     Capabilities: [128] Power Budgeting <?>
>     Capabilities: [600] Vendor Specific Information <?>
>     Kernel driver in use: nvidia
>     Kernel modules: nvidiafb, nvidia
> 
352c424
<     Region 0: Memory at d8900000 (64-bit, non-prefetchable) [size=8K]
---
>     Region 0: Memory at ec800000 (64-bit, non-prefetchable) [size=8K]
387c459
<     Region 0: Memory at d4000000 (32-bit, non-prefetchable) [size=4K]
---
>     Region 0: Memory at e8000000 (32-bit, non-prefetchable) [size=4K]
389,390c461,462
<     Memory window 0: dc000000-dffff000 (prefetchable)
<     Memory window 1: e0000000-e3fff000
---
>     Memory window 0: f0000000-f3fff000 (prefetchable)
>     Memory window 1: f4000000-f7fff000
404c476
<     Region 0: Memory at d4001000 (32-bit, non-prefetchable) [size=2K]
---
>     Region 0: Memory at e8001000 (32-bit, non-prefetchable) [size=2K]
417c489
<     Region 0: Memory at d4001900 (32-bit, non-prefetchable) [size=256]
---
>     Region 0: Memory at e8001900 (32-bit, non-prefetchable) [size=256]
430c502
<     Region 0: Memory at d4001800 (32-bit, non-prefetchable) [size=256]
---
>     Region 0: Memory at e8001800 (32-bit, non-prefetchable) [size=256]
Hum, il y a quelque chose qui m'intrigue. Si tu as installé Windows XP from scratch, tu n'avais donc aucun logiciel qui pourrait gérer le switch, c'est à dire que soit XP gère nativement le switch (ce que je crois guère) soit ça passe exclusivement par le BIOS. Donc à savoir si sous Linux c'est le BIOS qui bloque le switch ou si c'est le noyau qui intercepte (avec l'ACPI).

Donc, d'après "How to build a custom DSDT into an initrd" du site que je t'ai donné, est ce que tu pourrais tester de mettre un DSDT où tu changerais dans la partie que tu montres dans le message #13 le code héxadécimal de Linux en le passant de "Store (0x03E8, OSYS)" à "Store (0x07D2, OSYS)" et démarré avec ?
Ok, il paraît logique d'essayer. Par contre je n'ai jamais recompilé de kernel.
Est-ce que le tutorial http://doc.fedora-fr.org/wiki/Recompilation_du_noyau_Fedora suffit ?

Quelle différence entre construire le noyau de A à Z ou seulement construire le initrd ?
(http://doc.fedora-fr.org/wiki/Recompilation_du_noyau_Fedora#Etape_10_:_G.C3.A9n.C3.A9ration_du_RAM_Disk)

Pour construire le initrd, je dois faire tout ce qui précède de toute façon, non ?
Bon, j'ai plus ou moins réussi à recompiler le noyau avec les options pour le fichier DSDT.hex. (j'ai tout recompilé)
Cependant, je devais bien me résoudre à utiliser un des deux DSDT que j'ai (celui nvidia ou celui intel). J'ai choisi celui NVIDIA.

... la compilation du noyau est assez longue, mais ça passe. Au redémarrage par contre, surprise ! Le switch est on sur Nvidia. Quoi que je fasse, il reste sur nvidia tant que j'utilise le noyau que j'ai compilé avec le DSDT.hex pour nvidia. Je vais encore tester pour voir si c'est vraiment absolu et je vais tenter une recompilation avec le DSDT.hex pour la carte intel... qui sait, ça pourrait ne faire que fonctionner la carte intel. Auquel cas j'aurai juste à préciser le noyau choisi selon ... la carte à utiliser. (mais risque d'y avoir besoin d'un reboot linux) :-?

En passant, le kmod-nvidia n'est pas fait pour le noyau que j'ai recompilé et donc ça ne fonctionne pas tant. On fait comment pour que les éléments du kmod-nvidia soient chargés aussi pour le noyau personnalisé ?

Edit : mince, je ne suis pas tant sûr d'avoir pris le dsdt pour nvidia... plutôt celui pour intel... arghk.. je vais test les divers cas de toute façon. 😉

Ajout : c'est bien le dsdt d'intel... et ça a amené à des éléments nouveaux :
- en mode NOTHING, la carte intel est désormais fonctionnelle bien que les deux cartes soient visibles via lspci (par contre la carte nvidia est out)
- le switch ne se règle pas au boot !

En fait, la modification dans le DSDT.hex a permis de forcer la non-désinitialisation que fait linux (étrangement). Par contre, le résultat est donc le même que si j'utilisais l'option acpi=ht : le switch reste activé sur ce sur quoi il était activé... et je suis obligé de passé par windows pour modifier l'état du switch en redémarrant.
Ce qui voudrait dire que windows fait plus que juste informer l'os. (mais c'est déjà un bon début 😉 )

Et j'ai aussi trouvé un groupe réalisé autour du problème (mais sans solution pour l'instant) : https://launchpad.net/~z-series
xion.luhnis wrote:Ok, il paraît logique d'essayer. Par contre je n'ai jamais recompilé de kernel.
Est-ce que le tutorial http://doc.fedora-fr.org/wiki/Recompilation_du_noyau_Fedora suffit ?

Quelle différence entre construire le noyau de A à Z ou seulement construire le initrd ?
(http://doc.fedora-fr.org/wiki/Recompilation_du_noyau_Fedora#Etape_10_:_G.C3.A9n.C3.A9ration_du_RAM_Disk)

Pour construire le initrd, je dois faire tout ce qui précède de toute façon, non ?
Justement l'avantage de ne pas compiler, c'est que ça prend beaucoup moins de temps, surtout si on doit le refaire plusieurs fois 🙂

Bon, j'ai plus ou moins réussi à recompiler le noyau avec les options pour le fichier DSDT.hex. (j'ai tout recompilé)
Cependant, je devais bien me résoudre à utiliser un des deux DSDT que j'ai (celui nvidia ou celui intel). J'ai choisi celui NVIDIA.

... la compilation du noyau est assez longue, mais ça passe. Au redémarrage par contre, surprise ! Le switch est on sur Nvidia. Quoi que je fasse, il reste sur nvidia tant que j'utilise le noyau que j'ai compilé avec le DSDT.hex pour nvidia. Je vais encore tester pour voir si c'est vraiment absolu et je vais tenter une recompilation avec le DSDT.hex pour la carte intel... qui sait, ça pourrait ne faire que fonctionner la carte intel. Auquel cas j'aurai juste à préciser le noyau choisi selon ... la carte à utiliser. (mais risque d'y avoir besoin d'un reboot linux) hmm
C'est à quoi je veux arriver 🙂 Et ce serait déjà un exploit d'y arriver.
Ajout : c'est bien le dsdt d'intel... et ça a amené à des éléments nouveaux :
- en mode NOTHING, la carte intel est désormais fonctionnelle bien que les deux cartes soient visibles via lspci (par contre la carte nvidia est out)
- le switch ne se règle pas au boot !

En fait, la modification dans le DSDT.hex a permis de forcer la non-désinitialisation que fait linux (étrangement). Par contre, le résultat est donc le même que si j'utilisais l'option acpi=ht : le switch reste activé sur ce sur quoi il était activé... et je suis obligé de passé par windows pour modifier l'état du switch en redémarrant.
Ce qui voudrait dire que windows fait plus que juste informer l'os. (mais c'est déjà un bon début wink )
Intéressant ça 🙂 Si je comprend bien ça donne une gestion de l'ACPI différente, spécifique à Windows, qui doit répondre de manière générique aux demandes du BIOS. C'est vraiment du tatonnement, donc il faudrait voir si utiliser le code héxadécimal de "Windows Xp (2001)" ou "Windows Vista (2006)" change quelques choses au comportement de l'ordinateur.

Sinon, en faisant pas mal de recherche, j'ai vu qu'il y avait plein de fichier dans /proc qui était directement relié au BIOS (comme ioports, interrupts). Il faudrait voir si l'un de ces fichiers ne réagit pas lors de la modification du switch.

P.S.: Oh, élément intéressant ! En cherchant la valeur OSYS dans le fichier DSL, on voit qu'il y a pas mal de modification pour Vista (0x07D6). C'est à approfondir.
Bouska wrote:
xion.luhnis wrote:Ok, il paraît logique d'essayer. Par contre je n'ai jamais recompilé de kernel.
Est-ce que le tutorial http://doc.fedora-fr.org/wiki/Recompilation_du_noyau_Fedora suffit ?

Quelle différence entre construire le noyau de A à Z ou seulement construire le initrd ?
(http://doc.fedora-fr.org/wiki/Recompilation_du_noyau_Fedora#Etape_10_:_G.C3.A9n.C3.A9ration_du_RAM_Disk)

Pour construire le initrd, je dois faire tout ce qui précède de toute façon, non ?
Justement l'avantage de ne pas compiler, c'est que ça prend beaucoup moins de temps, surtout si on doit le refaire plusieurs fois 🙂
Ca veut dire que je peux générer le initrd sans avoir à compiler le kernel ? Donc l'action de génération du initrd ne dépend pas des opérations de compilation précédentes ?
Effectivement, si ça fonctionne, c'est d'autant mieux. 🙂
Bouska wrote:
Bon, j'ai plus ou moins réussi à recompiler le noyau avec les options pour le fichier DSDT.hex. (j'ai tout recompilé)
Cependant, je devais bien me résoudre à utiliser un des deux DSDT que j'ai (celui nvidia ou celui intel). J'ai choisi celui NVIDIA.

... la compilation du noyau est assez longue, mais ça passe. Au redémarrage par contre, surprise ! Le switch est on sur Nvidia. Quoi que je fasse, il reste sur nvidia tant que j'utilise le noyau que j'ai compilé avec le DSDT.hex pour nvidia. Je vais encore tester pour voir si c'est vraiment absolu et je vais tenter une recompilation avec le DSDT.hex pour la carte intel... qui sait, ça pourrait ne faire que fonctionner la carte intel. Auquel cas j'aurai juste à préciser le noyau choisi selon ... la carte à utiliser. (mais risque d'y avoir besoin d'un reboot linux) hmm
C'est à quoi je veux arriver 🙂 Et ce serait déjà un exploit d'y arriver.
Ouaip, de même. Etonnamment, le groupe de launchpad a directement des visions plus grandes : https://launchpad.net/~sony-vaio-z-series

Pour eux, l'idée c'est de réussir à faire fonctionner le switch sans reboot comme vista... sauf qu'on en est même pas encore à le faire fonctionner comme windows xp avec un reboot, alors je vois mal un telinit 3 - telinit 5 pour faire changer le switch... mais bon, s'ils arrivent à trouver quelque chose pour faire ça, personne ne s'en plaindra ! :-D
Bouska wrote:Intéressant ça 🙂 Si je comprend bien ça donne une gestion de l'ACPI différente, spécifique à Windows, qui doit répondre de manière générique aux demandes du BIOS. C'est vraiment du tatonnement, donc il faudrait voir si utiliser le code héxadécimal de "Windows Xp (2001)" ou "Windows Vista (2006)" change quelques choses au comportement de l'ordinateur.
Je vais tester les diverses possibilités dès que j'ai du temps (c'est-à-dire à la fin de la semaine prochaine vu que je suis en période d'examens).
2 mois plus tard
Rebonjour à tous. Ca faisait un petit moment.

Le problème du switch graphique est toujours d'actualité, mais il y a eu des tas d'avancements de divers côtés.
Une grande part de ces avancements est relatée sur la page suivante :
https://launchpad.net/~sony-vaio-z-series

A noter :
[1]. Un package sony-laptop réalisé pour désactiver le switch nvidia et faire fonctionner correctement la carte intel avec peu d'énergie

=> http://www.basyskom.org/~eva/log_installation_vaio_z21vnx.html

[2]. Si on boot avec linux DSL (Damn Small Linux) en livecd, à l'extinction, le switch est reinitialisé (ce que je cherche à faire avec fedora).
Il s'agit d'un noyau inférieure (2.4 je crois), mais j'espère qu'on peut en tirer quelque chose pour permettre la reinitialisation depuis fedora (au reboot au moins).

=> https://lists.launchpad.net/sony-vaio-z-series/msg00043.html

Y a-t-il eu un changement majeur spécifique à l'acpi entre le noyau 2.4 et le noyau 2.6 pour que cela fonctionne "avant" mais plus "maintenant" ?

[3]. A noter que si on démarre sur l'installation de winxp, après quelque étapes, on peut redémarrer et le switch aura été reinitialisé correctement :

=> https://lists.launchpad.net/sony-vaio-z-series/msg00004.html
un mois plus tard
Perso j'ai suivi ce tuto :

Positionnez le bouton sur "stamina" et le wifi sur "on"
Après avoir installé ubuntu Feisty Fawn un petit test que la carte intel :

# glxinfo | grep direct rendering

Normalement vous devriez avoir "Yes" sinon il faut réinstaller les pilotes intel (page)

faite une sauvegarde des fichier xorg.conf et les librairies GLX

en root :

# cp /etc/X11/xorg.conf /etc/X11/xorg.conf.stamina
# cp /usr/lib/xorg/modules/extensions/libglx.so /usr/lib/xorg/modules/extensions/libglx.so.stamina
# cp /usr/lib/libGL.so.1.2 /usr/lib/libGL.so.stamina

Ensuite il faut installer les driver NVIDIA

# apt-get install nvidia-glx-new
# nvidia-xconfig --composite --add-argb-glx-visuals -d 24

On ajoute quelques options dans le xorg.conf :

# gedit /ect/X11/xorg.conf

Section "Screen"
...
Option "TripleBuffer" "true"
Option "NoLogo" "true"
...
EndSection

On reboot et après redemarrage on vérifié l'acceleration 3D


# glxinfo | grep direct rendering

Normalement vous devriez avoir "Yes"

faite une sauvegarde des fichier xorg.conf et les librairies GLX de la carte geforce

# cp /etc/X11/xorg.conf /etc/X11/xorg.conf.speed
# cp /usr/lib/xorg/modules/libglx.so /usr/lib/xorg/modules/libglx.so.speed
# cp /usr/lib/libGL.so.1.2 /usr/lib/libGL.so.speed

ATTENTION !!!! les lib GLX intel et Geforce ne se trouvent pas au meme endroit !!!!!

"/usr/lib/xorg/modules/" pour la geforce
"/usr/lib/xorg/modules/extension" pour l'intel

Selecteur de carte graphique :

Maintenant que le plus dur est fait , il ne reste qu'a crée le petit script de switch speed / stamina mode

créer un fichier texte xorg-switcher et éditez le :

# switcher stamina / speed mode

VIDEO=`/usr/bin/lspci |grep -c nVidia`

if [ "$VIDEO" = 1 ]; then
cp -f /etc/X11/xorg.conf.speed /etc/X11/xorg.conf
modprobe drm
modprobe nvidia-agp
rm /usr/lib/xorg/modules/extensions/libglx.so /usr/lib/libGL.so.1 -f
ln -s /usr/lib/xorg/modules/libglx.so.speed /usr/lib/xorg/modules/libglx.so
ln -s /usr/lib/libGL.so.speed /usr/lib/libGL.so.1
else
cp -f /etc/X11/xorg.conf.stamina /etc/X11/xorg.conf
modprobe intel-agp
rm /usr/lib/xorg/modules/libglx.so /usr/lib/libGL.so.1 -f
ln -s /usr/lib/xorg/modules/extensions/libglx.so.stamina /usr/lib/xorg/modules/extensions/libglx.so
ln -s /usr/lib/libGL.so.stamina /usr/lib/libGL.so.1
fi

Copiez le dans /etc/init.d/xorg-switcher, rendez le executable et créer un lien symbolique (pour etre appelé à chaque démarrage:

# chmod +x /etc/init.d/xorg-switcher
# ln -s /etc/init.d/xorg-switcher /etc/rc2.d/S12xorg-switcher


Cependant ca a tout pété. Le libGL pour speed. Je ne l'avais pas dans modules mais /usr/lib/nvidia. Donc j'ai fini tout ce qu'il dit mais je n'arrive qu'à booter en speed. X ne se lance pas en stamina.

Une solution pour réparer mes conneries et faire marcher ce foutu switch?
Bon après avoir galéré tout l'aprem. petite mise à jour.

Il semblerait que le driver Intel soit incompatible avec le driver Nvidia !
En effet dès que kmod-nvidia est installé cela desactive le direct rendering au niveau de mon GMA.

Alors je me demande vraiment comme les possesseurs du SZ4 (voir la par ex : http://www.linux.it/~malattia/wiki/index.php/Vaio_VGN-SZ72B) ont réussi à installer un switch entre les deux cartes avec le direct rendering sur l'un ou sur l'autre.

Si vous avez une idée... En attendant je laisse désintallé le driver nvidia vu que je vais plus avoir besoin du mode stamina cette semaine.
J'ai modifié le script de veskit pour l'adapter aux nouveaux chemins (en me trompant surement). Mais toujours pas d'acceleration pour le gma tant qu'il y a le pilote nvidia... Veskit avait eu le meme probleme et c'est pour ca qu'il a fait ce script afin d'eviter que le driver nvidia empiette... Néanmoins je deconne toujours moi. Surement a cause des chemins qui doivent être toujours obselete genre le
ln -s /usr/lib/xorg/modules/extensions/libglx.so.stamina /usr/lib/xorg/modules/extensions/libglx.so
ln -s /usr/lib/libGL.so.stamina /usr/lib/libGL.so.1

Mon script :

VIDEO=`/sbin/lspci |grep -c nVidia`

if [ "$VIDEO" = 1 ]; then
cp -f /etc/X11/xorg.conf.speed /etc/X11/xorg.conf
modprobe drm
modprobe nvidia-agp
rm /usr/lib/xorg/modules/extensions/libglx.so /usr/lib/libGL.so.1 -f
ln -s /usr/lib/xorg/modules/libglx.so.speed /usr/lib/xorg/modules/extensions/nvidia/libglx.so
ln -s /usr/lib/libGL.so.speed /usr/lib/libGL.so.1
else
cp -f /etc/X11/xorg.conf.i810 /etc/X11/xorg.conf
rm /usr/lib/xorg/modules/extensions/nvidia/libglx.so /usr/lib/libGL.so.1 -f
ln -s /usr/lib/xorg/modules/extensions/libglx.so.stamina /usr/lib/xorg/modules/extensions/libglx.so
ln -s /usr/lib/libGL.so.stamina /usr/lib/libGL.so.1
fi
Salut.

Malheureusement, les SZs n'ont pas du tout la même technologie de switch que les Zs... :-?
SZ : switch matériel
Z : switch logiciel

Ayant un Z, c'est plus compliqué car le switch est géré par logiciel. Ainsi on pourrait potentiellement changer la carte en cours d'utilisation (ça fonctionne sur Vista, pas sur Xp, et encore moins sous linux malheureusement).
Avec les avancées de http://www.basyskom.org/~eva/log_installation_vaio_z21vnx.html, on arrive à faire le switch, mais on n'arrive pas encore à correctement gérer la carte Nvidia... ce qui est embêtant. 🙁

Actuellement, je désactive l'ACPI pour tenir sur une carte seulement, ou alors j'utilise DSL pour réinitialiser le switch après reboot. Ca fonctionne, mais ce n'est pas du tout satisfaisant à l'utilisation... (acpi=ht ou off est trop contraignant et DSL, c'est bien, mais c'est long)

Espérons qu'on aura des avancements intéressants sur le projet ci-dessus. 😉
Oui mais j'ai un SZ donc ca devrait etre plus simple mais en l'occurence ca ne l'est pas.... Car le pilote nvidia desactive l'acceleration du GMA... Je sais que pour le Z il n'y a pas encore vraiment de solution ; mais il est censé y en avoir pour le SZ... Néanmoins ca ne marche pas.....
un mois plus tard
Bon, je viens annoncer quelques bonnes nouvelles :

1. on peut utiliser le comportement de switch au reboot complet avec un petit paramètre au boot. Il s'agit du même procédé qu'utilisé dans le hack acpi, donc il s'agit de définir la valeur de la clé osi en ajoutant le paramètre :
acpi_osi="!Windows 2006"

Il faut l'ajouter à la ligne du kernel lors du boot (dans grub.conf, par exemple, ou en éditant la ligne en appuyant sur a / e dans le menu grub).
Ensuite, redémarrer une ou deux fois (selon l'état du switch au premier démarrage avec le paramètre) et on peut désormais switcher d'un mode à l'autre en redémarrant sans avoir besoin de passer par windows xp ni DSL ! :-D

Maintenant, il faut faire attention aux librairies graphiques partagées car il faut avoir un fichier de switching software installé dans son /etc/init.d. Il doit être appelé aux différents changements d'état.

Voici mon fichier, appelé hybrid_gfx_switch.sh :
#!/bin/bash

# on récupère la carte active
VIDEO=`/sbin/lspci | /bin/grep -i vga | /usr/bin/head -l | /usr/bin/awk {'print $5'}`

if [ $VIDEO = nVidia ]; then
echo "Nvidia X Configuration switch"
cp -f /etc/X11/xorg.conf.nvidia /etc/X11/xorg.conf
ln -sf /usr/lib/libGL.so.180.51 /usr/lib/libGL.so.1
ln -sf /usr/lib/xorg/modules/extensions/libglx.so.180.51 /usr/lib/xorg/modules/extensions/libglx.so
else
echo "Intel X Configuration switch"
cp -f /etc/X11/xorg.conf.intel /etc/X11/xorg.conf
ln -sf /usr/lib/libGL.so.intel /usr/lib/libGL.so.1
ln -sf /usr/lib/xorg/modules/extensions/libglx.so.intel /usr/lib/xorg/modules/extensions/libglx.so
fi
Ainsi, si la carte nvidia est disponible, on utilise les fichiers nvidia pour libGL.so.1 et libglx.so.
Sinon, on est sur la carte intel et on utilise les fichiers intel par défaut. A noter qu'il faut copier ces fichiers avant d'installer le driver nvidia. Si vous l'avez déjà installer, désinstallez-le, faite une copie protégée des fichiers libGL.so.1 et libglx.so (les fichiers réels, par les liens symboliques !), gardez-les bien protéger car l'installation du driver nvidia enlève les fichiers qui peuvent gêner (et ces deux fichiers particulièrement, il en fait une copie, je ne sais où pour les remettre lorsqu'on désinstalle, mais justement, je ne sais pas où...).
Dans mon cas, j'ai copié les deux fichiers, les ai placé dans un tar.gz, puis ai installé le driver nvidia. Puis j'ai récupérer mes fichiers par défaut et les ai renommé avec l'extension .intel.

Dans mon cas, ça marche impécablement. J'ai encore des problèmes, mais je peux utiliser les deux cartes (moyennant un reboot, mais c'est déjà bien mieux que de ne pas pouvoir utiliser les cartes... et qui plus est, l'acpi est fonctionnel ! donc c'est super :-D).
Les problèmes restants :

1. Carte intel :
- la résolution est même plus grande qu'avec la carte nvidia (allez comprendre), bien que ça m'affiche un screenSize max de 1024/768 alors que je devrais être en 1380/768 !
- compiz ne peut pas être utilisé ! Les effets de bureau ne fonctionnent pas ! Que faire pour installer correctement le driver intel ? C'est une carte Intel gma4500

2. Carte nvidia :
- l'applet gnome pour la luminosité ne fonctionne pas du tout... je suis contraint à utiliser l'utilitaire nvclock pour modifier en ligne de commande la luminosité de l'écran (nvclock -S value)
- system-config-display ne fonctionne pas, j'ai une erreur à l'utilisation, qui fait que rien ne s'affiche (que je n'ai pas avec la carte intel) :
Traceback (most recent call last):
File "/usr/share/system-config-display/xconf.py", line 312, in <module>
hardware_state = XF86HardwareState(xconfig)
File "/usr/lib/python2.5/site-packages/rhpxl/xhwstate.py", line 174, in __init__
self.init_from_xconfig(xconfig)
File "/usr/lib/python2.5/site-packages/rhpxl/xhwstate.py", line 260, in init_from_xconfig
if screen.device:
AttributeError: 'NoneType' object has no attribute 'device'
A la place, je peux utiliser le nvidia display panel, mais c'est bête d'utiliser vingt outils différents :-?

- la résolution est indiquée comme du 1380/768, mais je doute que ce soit vrai vu que sous intel, j'ai une plus grande résolution !

Edit : 1366/768 et non 1380/768 😉

Ajout : ENFIN ! suspend to ram et suspend to disk marchent les deux ! C'est la première fois que je peux l'utiliser correctement avec l'acpi activée. :-D
Le premier fonctionne très rapidement, superbe.
Le second est un peu plus lent, mais surtout, il faut redémarrer l'ordi, donc passer le screen du bios. Mais j'imagine que ça permet de ne pas utiliser du tout de courant et donc garder la batterie au chaud.