Modifier son framebuffer

Quelque soit votre carte vidéo, vous trouverez toujours beaucoup d’info sur le net sur des personnes qui vous conseillent telle ou telle configuration de framebuffer pour améliorer le fonctionnement de votre carte, souvent ces solutions ont été trouvés par tâtonnement, et activent seulement une partie des ports vidéo, ce qui ne correspond pas forcément à vos besoins/utilisations.

Je vais donc vous montrer comment extraire de votre carte graphique la configuration des ports vidéo, et extraire de vos pilotes graphiques le profil de chaque framebuffer; ainsi que la façon d’interpréter ces données qui sont, il faut l’avouer, assez techniques à exploiter. De cette façon vous pourrez chercher un framebuffer qui correspond bien au profil de votre carte mère, et le cas échéant y apporter les modifications nécessaires pour qu’il le soit.

 

Pour commencer, un petit rappel sur les commandes de boot AtiConfig et AtiPorts:

-AtiConfig permet de spécifier dans votre fichier boot.plist le framebuffer à utiliser pour votre carte graphique. Sans cette commande, le framebuffer par défaut sera chargé; si vous ajoutez cette ligne, vous pourrez forcer OSX à utiliser un autre framebuffer.

-AtiPorts permet de préciser au système le nombre de ports vidéo que possède votre carte graphique, par exemple si le framebuffer utilisé par votre carte graphique contient les info pour 4 ports alors que votre carte en propose 5, en ajoutant la ligne AtiPorts=5, vous spécifier au système la présence de 5 ports vidéo, contrairement à ce qui est marqué dans le framebuffer. Le soucis c’est que ce 5ème port n’étant pas renseigné dans le framebuffer, il risque de ne pas marcher parfaitement…

Rq: petite piste, j’ai l’impression que l’intérêt de AtiPorts est de pouvoir charger un framebuffer qui contient plus de ports que n’en propose votre carte graphique, par exemple Duckweed contient 4 ports vidéo, si votre carte possède seulement 3 sorties, vous devrez utiliser AtiPorts=3 pour que cela marche avec Duckweed. (Si certains peuvent tester je suis preneur :-) )

 

1ère étape: extraire les données de votre carte graphique

 

Pour cela il va falloir d’abord extraire le VBIOS de votre carte graphique, puis appliquer dessus un script pour en lire les informations qui nous intéressent. Plutôt que d’utiliser une procédure compliquée pour extraire le VBIOS (qui demande le plus souvent de passer par une partition Windows) le plus simple reste à mon avis d’aller chercher ce fichier sur le net. En effet il est disponible sur ce site qui répertorie les VBIOS de quasiment toutes les cartes du marché.

 

Une fois ce fichier .rom en votre possession, il suffit d’appliquer le script radeon_bios_decode dessus (script créer par bcc9, membre de InsanelyMac), pour cela, ouvrez le terminal et entrez la commande suivante:

chemin_d’accès_au_script_radeon_bios_decode < chemin_d’accès_du_fichier.rom_de_votre_carte > fichier.txt

Plutôt que de rentrer manuellement le chemin d’accès de chaque fichier, il suffit de le glisser sur la fenêtre du terminal qui remplira automatiquement le chemin d’accès. Attention à bien respecter les espaces entre le nom des fichiers et les signes «>», «<«. Enfin, donner le nom que vous voulez au fichier.txt (remplacer «fichier» par ce que vous voulez), appuyez sur entrée pour valider, et le fichier texte contenant les infos apparaitra dans votre dossier utilisateur (par ex: /Users/itOtO/).

exemple:

 

Vous aurez ce genre de réponse: (pour ma carte Gigabyte Radeon HD 6870 avec 1xDP, 1xHDMI, 2xDVI):

 

ATOM BIOS Rom:
SubsystemVendorID: 0x174b SubsystemID: 0x174b
IOBaseAddress: 0×0000
Filename: 174X03B0.S4I
BIOS Bootup Message:
BARTS XT HYNIX/ELPIDA GDDR5 32MX32 BIOS

PCI ID: 1002:6738
Connector at index 0
Type [@offset 44283]: DisplayPort (10)
Encoder [@offset 44287]: INTERNAL_UNIPHY2 (0×21)
i2cid [@offset 44393]: 0×90, OSX senseid: 0×1
Connector at index 1
Type [@offset 44293]: HDMI-A (11)
Encoder [@offset 44297]: INTERNAL_UNIPHY2 (0×21)
i2cid [@offset 44420]: 0×93, OSX senseid: 0×4
Connector at index 2
Type [@offset 44303]: DVI-D (3)
Encoder [@offset 44307]: INTERNAL_UNIPHY1 (0×20)
i2cid [@offset 44447]: 0×95, OSX senseid: 0×6
Connector at index 3
Type [@offset 44313]: DVI-I (2)
Encoder [@offset 44317]: INTERNAL_UNIPHY (0x1e)
i2cid [@offset 44484]: 0×94, OSX senseid: 0×5
Connector at index 4
Type [@offset 44323]: DVI-I (2)
Encoder [@offset 44327]: INTERNAL_KLDSCP_DAC1 (0×15)
i2cid [@offset 44484]: 0×94, OSX senseid: 0×5

 

A la ligne PCI ID, vous retrouvez la ligne id_constructor:id_device de la carte (1002:6738 dans mon cas). En dessous, les info pour chaque connecteur, on retiendra le «index x» qui correspond au numéro du connecteur, le type (DisplayPort, HDMI, etc) et le i2cid qui permet de calculer la valeur du «OSX Senseid»: Senseid=0xy avec y= le dernier chiffre du i2cid + 1 (exemple: i2cid=0×92, alors Senseid=0x(2+1)=0×3).

Avec ce script, les valeurs données pour l’Encoder (Uniphy2, etc) sont fausses, donc on va utiliser un second script pour les obtenir. C’est exactement la même procédure que plus haut mais cette fois avec le script Redsock_bios_decode (pensez à ne pas mettre le même nom pour le fichier.txt) et vous obtiendrez une réponse comme celle-là:

 

R687OGD.F2 :
GV-R687OC-1GD/F2

Subsystem Vendor ID: 1458
Subsystem ID: 21fa
Object Header Structure Size: 407
Connector Object Table Offset: 52
Router Object Table Offset: 0
Encoder Object Table Offset: 12a
Display Path Table Offset: 12
Connector Object Id [19] which is [DISPLAY_PORT]
encoder obj id [0x21] which is [INTERNAL_UNIPHY2 (osx txmit 0x12 [duallink 0x2] enc 0×4)] linkb: false
Connector Object Id [19] which is [DISPLAY_PORT]
encoder obj id [0x21] which is [INTERNAL_UNIPHY2 (osx txmit 0x22 [duallink 0x2] enc 0×5)] linkb: true
Connector Object Id [12] which is [HDMI_TYPE_A]
encoder obj id [0x20] which is [INTERNAL_UNIPHY1 (osx txmit 0x11 [duallink 0x1] enc 0×2)] linkb: false
Connector Object Id [3] which is [DVI_D]
encoder obj id [0x20] which is [INTERNAL_UNIPHY1 (osx txmit 0x11 [duallink 0x1] enc 0×2)] linkb: false
Connector Object Id [2] which is [DVI_I]
encoder obj id [0x1e] which is [INTERNAL_UNIPHY (osx txmit 0x10 [duallink 0x0] enc 0×0)] linkb: false
Connector Object Id [2] which is [DVI_I]
encoder obj id [0x15] which is [INTERNAL_KLDSCP_DAC1 (osx txmit 0x00 enc 0x10?)] linkb: false

 

Cette fois on ne note que les valeurs de l’encoder: Uniphy, Uniphy1 ou Uniphy2, et la valeur correspondante: 0xab (ex: 0×22, 0×11, …). Vous noterez la présence entre crochet de «duallink 0xb», qui équivaut à remplacer la valeur a par 0 (et 0x0b peut s’écrire 0xb) pour activer le Dual Link, dans le cas de ma carte graphique, il n’y a que le port DVI-I qui supporte ce protocole, donc il faudra remplacer l’encoder 0×10 par 0×00 pour activer le Dual Link dessus.

Rq: Je reviendrais sur ces règles d’écriture plus loin.

 

On utilisera ces valeurs plus bas au niveau du framebuffer.

 

Vous remarquerez qu’il y a 6 connecteurs alors que ma carte n’en possède que 5 et que les deux derniers se ressemblent, en fait ils correspondent tous deux au port DVI-I qui contient à la fois une sortie DVI-D (numérique) et une DVI-A (analogique).

 

2ème étape: extraire la liste des framebuffers

 

Pour cela on va encore utiliser un script créer par bcc9, qui va aller chercher la liste des framebuffers (compatible uniquement pour OSX 1.6.4 et + et 10.7 et +). Dans Snow Leopard, cette liste est présente dans le fichier ATIFramebuffer.kext, alors que dans Lion, chaque profil de Framebuffer est présent directement dans le kext qui l’utilise (ex: les framebuffers des cartes Radeon 6xxx sont dans le ketx ATI6000Controller.kext). Le script est capable de faire la recherche automatiquement, donc cela n’a pas d’importance pour l’instant.

Ouvrez une nouvelle fenêtre du terminal et entrée la commande suivant:

perl chemin_d’accès_du_script_ati-personnality pour les framebuffers en 32bits

perl chemin_d’accès_du_script_ati-personnality -x pour les framebuffers en 64bits

 

Vous vous retrouvez alors avec une longues liste affichant les profils de chaque framebuffer classés en fonction du kext dont ils sont issus si vous êtes sous Lion (ATI6000Controller.kext, ATI5000Controller.kext, etc).

Par exemple, pour le profil Gibba:

 

Personality: Gibba
ConnectorInfo count in decimal: 5
Disk offset in decimal 177040
0000000    00  04  00  00  04  03  00  00  00  01  00  00  12  04  05  01
0000010    00  04  00  00  04  03  00  00  00  01  00  00  22  05  04  02
0000020    00  08  00  00  04  02  00  00  00  01  00  00  11  02  06  04
0000030    00  02  00  00  14  02  00  00  00  01  00  00  00  00  03  05
0000040    04  00  00  00  04  02  00  00  00  01  00  00  11  02  01  03
0000050

 

Vous retrouvez alors le nom du profil (ici Gibba) le nombre de connecteurs (ici 5) et l’adresse du profil au niveau du pilote (offset) qui est donné en décimal (Attention, nous utiliserons cette valeur plus tard pour modifier le framebuffer, et il faudra d’abord la convertir en hexadécimal).

En dessous, un bloc de chiffres avec le numéro du connecteur à gauche (00=0, 10=1, 20=2, etc) et une ligne hexadécimale de 16 octets (bytes en anglais) correspondante (16 octets = 16 paires du type xx).

 

A présent, ça se complique, il faut pouvoir interpréter ces données brutes, pour cela je vais  vous présenter chaque fonction et les valeurs qu’elle peut prendre:

Chaque ligne correspond donc à un des connecteurs, ensuite il faut diviser chaque ligne de 16 octets en 8blocs:

Si on isole la deuxième ligne:

 

00 04 00 00 – 04 03 00 00 – 00 01 – 00 00 – 2205 – 04 – 02

 

1- ConnectorType : 00 04 00 00 > 0×00000400 – - -
2- ATY,ControlFlags : 04 03 00 00 > 0×00000304 +++
3- Features : 00 01 > 0×0009 +++
4- ??? : 00 00 > 0×0000 – - -
5- Transmitter : 22 > 0×22 – - -
6- Encoder : 05 > 0×05 – - -
7- HotplugID : 04 > 0×04 – - -
8- SenseID : 02 > 0×02 ++++++

 

Quelques règles pour comprendre l’écriture:

pour un octet simple (ab) l’écriture devient 0xab donc par exemple, 45 devient 0×45

pour un bloc de plusieurs octets (ab cd ef gh) l’écriture devient 0xghefcdab (on le lit à l’envers mais par groupe de deux), donc 12 34 56 78 devient 0×78563412.

Un octet (xy) comprend 8bits, les bits 0, 1, 2 et 3 sont représentés par le chiffre de droite (y), les bits 4, 5, 6 et 7 par le chiffre de gauche (x).

 

Les données les plus importantes sont le ATY,ControlFlags, le Features et le SenseID, si elle sont mal renseignées, cela ne marchera pas, attention, les autres lignes, si elles ne sont pas exactes, peuvent poser soucis dans certain cas, même si elles sont moins importantes!

 

1- Connector Type (4 octets)

Connector-Type_LVDS      0×00000002    (correspond à un écran interne rétro-éclairé de portable)
Connector-Type_DVI         0×00000004    DVI-D (à vérifier)
Connector-Type_VGA         0×00000010
Connector-Type_S-V         0×00000080
Connector-Type_DVI         0×00000200    DVI-I (à vérifier)
Connector-Type_DP          0×00000400
Connector-Type_HDMI      0×00000800
Connector-Type_DVI         0×00001000    DVI-A?

 

Souvent simplifiée en ne gardant que les 4 derniers chiffres (correspond au 2 premiers octets): 0×00000400 devient 0×0400.

 

2- ATY,ControlFlags (4octets)

Pour chaque Connector-Type, plusieurs ControlFlags sont possibles:

 

0×0002 : LVDS           >       ControlFlag : 0×0040 / 0×0100
0×0004 : DVI-D           >       ControlFlag : 0×0016 – 0×0014 / 0×214
0×0010 : VGA             >       ControlFlag : 0×0010
0×0080 : S-Video        >       ControlFlag : 0×0002
0×0200 : DVI-I           >       ControlFlag : 0×0014 / 0×0214 – 0×0204
0×0400 : DisplayPort  >       ControlFlag : 0×0100 – 0×0104 – 0×0304 / 0×0604 – 0×0400
0×0800 : HDMI           >       ControlFlag : 0×0200
0×1000 : DVI-A?           >       ControlFlag : 0×0016

 

Comme précédemment, les 2 derniers octets ne contenant que des 0, on utilise que les deux premiers: 0×00000304 devient 0×0304.

 

3- Features (2 octets)

Les features se combinent ensemble, par exemple un écra, de portable (LVDS) est interne + retro-éclairé, donc la caleur de Features sera 0×01+0×08= 0×09.

Feature_USE_INTERNAL                    0×01
Feature_USE_RGB_ON_YUV          0×04
Feature_USE_BACKLIGHT             0×08
Feature_BACKLIGHT_INVERTED      0×10
Feature_USE_CLAMSHELL             0×20

 

Pour chaque connecteur:

0×0002 : LVDS           >       Features  :  0×09
0×0004 : DVI-D          >       Features  :  0×00
0×0010 : VGA            >       Features  :  0×00
0×0080 : S-Video        >       Features  :  0×04
0×0200 : DVI-I          >       Features  :  0×00
0×0400 : DisplayPort    >       Features  :  0×00
0×0800 : HDMI           >       Features  :  0×00
0×1000 : DVI-A?          >       Features  :  0×00

 

Une fois encore, le premier byte étant toujours 00, on simplifie en écrivant uniquement le deuxième byte, 0×0004 devient 0×04.

Les framebuffer pour 6xxx ne comportent que trois profils différents: 0×01, 0×05 ou 0×19; pour obtenir ces nombres il faut obligatoirement utiliser le feature «Use Internal) donc les framebuffer Apple sont tous destinés à des écrans internes (logique, ces cartes sont vendues sur des iMac et Macbook), les features des framebuffer pour 5xxx (cartes vendues sur les Macpro) sont aussi avec des chiffres impairs, ce qui semble vouloir dire que même sur les Mac Pro, Apple utilise le Features «Use Internal».

 

4- Inconnu… (2 octets)

 

5- Transmitter (1 octet)

Cela va permettre de définir le canal utilisé pour transmettre le signal au connecteur, et pouvoir attribuer à certain la capacité d’utiliser un signal Dual Link (donc d’utiliser 2 canaux).

Il y a trois types de transmetteurs: Uniphy, Uniphy1 et Uniphy2, chacun pouvant supporter deux canaux (canal A et canal B, pouvant être combiné et A+B)). Cela permet donc de supporter 6 connecteurs single-link (A,B,C,D,E,F) ou 3 connecteurs dual-link (AB, CD, EF).

Le transmetteur est représenté par le deuxième chiffre du byte, et le canal utilisé par le premier chiffre:

UNIPHY    0×00
UNIPHY1   0×01
UNIPHY2   0×02

DUALLINK  0×00 // LINKA + LINKB
LINKA     0×10
LINKB     0×20

UNIPHYA    0×10 // = UNIPHY:LINKA
UNIPHYB    0×20 // = UNIPHY:LINKB
UNIPHYAB   0×00 // = UNIPHY:DUALLINK
UNIPHYC    0×11 // = UNIPHY1:LINKA
UNIPHYD    0×21 // = UNIPHY1:LINKB
UNIPHYCD   0×01 // = UNIPHY1:DUALLINK
UNIPHYE    0×12 // = UNIPHY2:LINKA
UNIPHYF    0×22 // = UNIPHY2:LINKB
UNIPHYEF   0×02 // = UNIPHY2:DUALLINK
DACA       0×00
DACB       0×10

 

DACA et DACB correspond au transmetteur pour les liaisons analogiques (VGA…), qui en fait utilise la transmetteur Uniphy (vous constaterez que les valeurs sont les mêmes).

 

 

6- Encoder (1 octet)

Ca c’est les règle générales pour trouver l’encodeur DIG à utiliser en fonction de votre série de carte graphique (4xxx, 5xxx, 6xxx).

DIG Encoder/Transmitter Setup
685  * DCE 3.0/3.1 (RV6XX, Radeon HD 3XXX Series and older)
686  * – 2 DIG transmitter blocks. UNIPHY (links A and B ) and LVTMA.
687  * Supports up to 3 digital outputs
688  * – 2 DIG encoder blocks.
689  * DIG1 can drive UNIPHY link A or link B
690  * DIG2 can drive UNIPHY link B or LVTMA
691  *
692  * DCE 3.2 (RV7XX, Radeon HD 4XXX Series)
693  * – 3 DIG transmitter blocks. UNIPHY0/1/2 (links A and B ).
694  * Supports up to 5 digital outputs
695  * – 2 DIG encoder blocks.
696  * DIG1/2 can drive UNIPHY0/1/2 link A or link B
697  *
698  * DCE 4.0 (RV8XX, Radeon HD 5XXX Series)
699  * – 3 DIG transmitter blocks UNPHY0/1/2 (links A and B ).
700  * Supports up to 6 digital outputs
701  * – 6 DIG encoder blocks.
702  * – DIG to PHY mapping is hardcoded
703  * DIG1 drives UNIPHY0 link A, A+B
704  * DIG2 drives UNIPHY0 link B
705  * DIG3 drives UNIPHY1 link A, A+B
706  * DIG4 drives UNIPHY1 link B
707  * DIG5 drives UNIPHY2 link A, A+B
708  * DIG6 drives UNIPHY2 link B
709  *
710  * Routing
711  * crtc -> dig encoder -> UNIPHY/LVTMA (1 or 2 links)
712  * Examples:
713  * crtc0 -> dig2 -> LVTMA   links A+B -> TMDS/HDMI
714  * crtc1 -> dig1 -> UNIPHY0 link  B   -> DP
715  * crtc0 -> dig1 -> UNIPHY2 link  A   -> LVDS
716  * crtc1 -> dig2 -> UNIPHY1 link  B+A -> TMDS/HDMI
717  */

 

Chaque encodeur DIG étant ensuite représenté par une valeur qui correspond au numéro du DIG moins 1:

DIG4 devient 0×0(4-1)=0×03

Ce qui donne:

DIG1   0×00 // = DIGA
DIG2   0×01 // = DIGB
DIG3   0×02 // = DIGC  Uniquement pour les Radeon 5xxx et sup
DIG4   0×03 // = DIGD  Uniquement pour les Radeon 5xxx et sup
DIG5   0×04 // = DIGE  Uniquement pour les Radeon 5xxx et sup
DIG6   0×05 // = DIGF Uniquement pour les Radeon 5xxx et sup

 

7- HotplugID (1 octet)

Correspond à un identifiant unique pour chaque port, en pratique il suffit d’attribuer à chaque port un identiant différent pour que ce soit bon (ex: 01, 02, 03, 04 et 05).

 

8- SenseID (1 octet)

Se calcule à partir du i2cid:

SenseID=dernier chiffre du i2cid+1

ex: i2cid=0×95, SenseID=0×0(5+1)=0×06

 

 

Et voilà! Maintenant vous savez lire les infos du framebuffer comme un pro!

 

Prenons un exemple avec la première ligne du framebuffer Gibba:

0000000    00  04  00  00  04  03  00  00  00  01  00  00  12  04  05  01

 

Donc, dans l’ordre:

  • Port numéro 0
  • Connector Type= DisplayPort
  • ATY ControlFalgs= DisplayPort
  • Features= Use Internal
  • Transmitter= Uniphy2 LinkA
  • Encoder= DIG5
  • HotplugID= 4
  • SenseID= 1 (donc i2cid= 0×90)

Maintenant si vous vous souvenez du VBIOS de ma carte, pour le premier connecteur on avait:

Pour le radeon_bios_decode:

Connector at index 0
Type [@offset 44283]: DisplayPort (10)
Encoder [@offset 44287]: INTERNAL_UNIPHY2 (0×21)
i2cid [@offset 44393]: 0×90, OSX senseid: 0×1

Et pour le redsock_bios_decode:

Connector Object Id [19] which is [DISPLAY_PORT]
encoder obj id [0x21] which is [INTERNAL_UNIPHY2 (osx txmit 0x12 [duallink 0x2] enc 0×4)] linkb: false

 

Donc:

  • Port numéro 0
  • ConnectorType= DisplayPort
  • Features= Internal
  • Encoder= Uniphy2 en link A (0×12)
  • On en déduit le DIG: Uniphy2+linkA=DIG5=0×04
  • SenseID= 1

 

C’est plutôt bon signe non?

Si on continuais, on verrais que mes trois premiers connecteurs (2xDP et HDMI) sont parfaitement pris en charge, par contre mes deux connecteurs DVI (donc deux sorties DVI-D et une DVI-A) c’est pas franchement nickel, le port numéro 3 se retrouve avec un mauvais SenseID qui est celui du port numéro 4; et pour la composante VGA du DVI-I, je ne sais pas trop s’il faut créer une ligne qui lui est propre en entrant les mêmes info que pour le signal digital du DVI-I, ou si le système se démerde….

 

3ème étape: confronter la liste des framebuffer aux infos issues du VBIOS

 

Le but étant de trouver un Framebuffer qui correspond à votre carte Graphique, ou en tout cas qui permette de faire fonctionner les sorties dont vous avez besoin.

 

Par exemple dans mon cas, le framebuffer Gibba me permet d’avoir mes deux DP et mon HDMI de totalement fonctionnels, au niveau des DVI c’est moins parfait, mon port DVI-I est reconnu et fonctionnel, car même s’il est enregistré comme connecteur numéro 3 dans le framebuffer alors qu’il est en numéro 4 dans le VBIOS, c’est le SenseID qui compte (05 dans le cas présent) et vu qu’il est configuré en Uniphy qui supporte l’analogique (ce n’est pas le cas de Uniphy 1 et 2), mon VGA doit marcher.

Par contre mon port DVI-D ne marche pas, car ayant 06 comme SenseID dans le VBIOS et mon framebuffer utilise le SenseID 03 pour le deuxième port DVI. Donc le système ne le voit pas, mais il suffirait de modifier ce 03 en 06 pour que ça marche. C’est d’ailleurs ce que nous allons voir ensuite.

 

4ème étape: modifier le framebuffer

 

Vous venez de parcourir la liste des framebuffer, mais malheureusement, aucun ne correspond à votre configuration, la solution est alors de modifié ce un des framebuffer pour qu’il corresponde parfaitement à votre configuration.

Je vais prendre l’exemple de ma configuration, le framebuffer Gibba ajoute un connecteur numéro 4 qui est bien un connecteur DVI, mais avec un SenseID de 03 alors que celui de mon connecteur DVI qui ne fonctionne pas est 06. On va donc simplement changer ce 03 en 06.

Pour cela, il faut utiliser un éditeur Hexadécimal, j’utilise personnelement 0xED sous Mac, mais n’importe lequel fera l’affaire.

 

Vu que je mon système tourne en 64bit, je ne ferais la modification que sur le Framebuffer pour 64bit.

 

Dans la liste des Framebuffer 64bits, à la rubrique ATI6000Controller, au début du Framebuffer Gibba il est indiqué «Disk offset in decimal 177040», cela correspond à son adresse au sein du fichier ATI6000Controller. Pour trouver ce fichier, aller dans /System/Library/Extensions (/S/L/E) et chercher le kext ATI6000Controller.kext, faites un clic droit dessus, sélectionner «Afficher le contenu du paquet» puis naviguer jusqu’à /Content/Mac OS/ vous trouverez alors le fichier binaire ATI6000Controller.

Faites en une sauvegarde au cas où, et ouvrez ce fichier avec votre éditeur héxadécimal. Chercher alors l’offset hexadecimal 2b390 qui correspond au nombre 177040 en base hexadecimal (google est votre ami pour faire la conversion :-) ).

 

Vous devriez alors être renvoyer vers cette ligne:

00  04  00  00  04  03 …

qui correspond au début de la première du framebuffer Gibba.

Vu que je veux modifier uniquement le SenseID du connecteur numéro 4 et qu’il y a 16bytes par ligne (1byte= xx), je vais aller 5×16=80 bytes plus loin (ou plus rapidement, à l’offset 177040+80=2b3e0 en hexadécimal), qui devrait être 03. Je le modifie alors en 06, je sauvegarde, je répare les autorisations avec le terminal:

 

chmod -R 775 /System/Library/Extensions/ATI6000Controller.kext

puis

chown -R root:wheel /System/Library/Extensions/ATI6000Controller.kext

 

Ensuite, j’ouvre mon boot.plist, j’y ajoute la ligne AtiConfig=Nom du framebuffer (Gibba dans mon cas):

<key>AtiConfig</key>
<string>Gibba</string>

Et je vérifies que la ligne GraphicsEnabler=Yes est déjà présente sinon je l’ajoute.

 

Plus qu’à re-démarrer et c’est bon!

 

Attention, gardez une copie du kext original en sauvegarde, ainsi qu’une avec le framebuffer modifié, car à chaque mise à jour d’OSX, ce kext sera probablement écrasé et vous devrez réinstaller votre kext modifié, ou recommencer la manipulation sur la version mise à jour du kext Apple.

De la même façon, préférez les modifications les plus simples possibles, afin de pouvoir les refaire rapidement en cas de besoin (par exemple dans mon cas, pour être exact j’aurais du  modifié le 03 par 06 puis inverser les lignes des connecteurs 3 et 4, mais comme ça marche sans, pourquoi s’embêter!).

Si vous commencer à modifier complèetement un framebuffer, faites bien attention à respecter les règles, par exemple si vous attribuez l’encoder Uniphy2 Link A à deux connecteurs, vous ne pourrez jamais les branchez simultannément.

 

 

J’ai utilisé de multiples sources que j’ai du croiser et vérifier pour faire ce guide (et aussi comprendre, pas forcément le plus facile surtout quand des choses se contredisent), mais plus particulièrement les guides de bcc9 et Mucha sur le forum d’Insanelymac, qui m’ont grandement facilité la tâche, une partie de cet article n’est d’ailleurs que la traduction (à ma sauce :-) ) de leurs guides, et les scripts que j’utilise sont de bcc9.

 

Télécharger les fichiers: Scripts

Site référençant tous les différents VBIOS: http://www.techpowerup.com/vgabios/index.php

  • jeremy
    #1 écrit par jeremy Il y a 2 ans

    J’ai tous lu (c’etait long et bien détaillé) et je suis bien content, tu nous a filé le kext tous fais pour la sapphire 6870 car je pense que j’aurai surement loupé un truc et si tu te trompe a un endroit pour trouvé la faute après…

  • jeremy
    #2 écrit par jeremy Il y a 2 ans

    EDIT : [i] les features des framebuffer pour 5xxx (cartes vendues sur les Macpro) sont aussi avec des chiffres impairs, ce qui semble vouloir dire que même sur les Mac Pro, Apple utilise le Features «Use Internal».[/i] a ton avis quel intérêt pour apple de faire sa ?

    • itOtO
      #3 écrit par itOtO Il y a 2 ans
      −1

      J’avoue que je sais pas trop, mais ça a l’air de pas changer grand chose…

      Dans le même genre, pour les framebuffers des 5xxx, il y a deux profils qui correspondent aux 5770 et 5870, et la seule différence entre les deux profils c’est que les deux ports display ports sont inversés, ce qui en pratique ne change strictement rien… Donc parfois il y a des trucs qui n’ont pas vraiment de sens :-)

  • Onakaaa
    #4 écrit par Onakaaa Il y a 2 ans

    Est ce que c’est possible de modifier le Frambuffer pour son HD3000 (1 port HDMI, 1 port VGA) ?

    Merci

    • itOtO
      #5 écrit par itOtO Il y a 2 ans

      Dans l’absolu, oui, il faudrait modifier ce kext: AppleIntelSNBGraphicsFB.kext
      Le problème c’est que, au contraire des kext ATI, dans ce cas précis je ne connais ni les différents framebuffer, ni de script permettant de les extraire facilement pour les analyser, ni comment ils sont écrit (ce n’est pas la même écriture que pour les framebuffers ATI).
      Sur ce guide pour activer l’audio HDMI sur le Intel HD3000 (http://tonymacx86.com/viewtopic.php?f=162&t=45795) ils modifient le framebuffer, donc si tu trouves suffisamment de données pour les croiser et essayer de comprendre le sens des modif ça pourrait le faire…

  • Onakaaa
    #6 écrit par Onakaaa Il y a 2 ans

    Merci pour ta réponse, j’ai cru que c’est c’est la même chose pour l’intel. Concernant le tuto de l’HDMI, j’ai un IDT et non pas un ALC, je suis coincé dans la partie où il traite le layout-id (= audio-id), franchement je ne sais pas comment je vais l’avoir ce layout-id :(

    • itOtO
      #7 écrit par itOtO Il y a 2 ans

      Taper « layout-id et la référence de ton chipset IDT » dans google, et espérer que la réponse soit quelques part sur le net :)

      • Onakaaa
        #8 écrit par Onakaaa Il y a 2 ans

        est-ce que le layout-id est le même layout-id présent au niveau du kext AppleHDA /layoutXX.xml ?? ou bien c’est autre chose ?

        • itOtO
          #9 écrit par itOtO Il y a 2 ans

          normalement c’est un numéro qui sert à identifier ton chipset audio, il faut que tu le trouve sur le net, car tout ce que tu trouveras comme référence dans les kext risque d’être faux. C’est quoi ton chipset audio? IDTxxx?

          • Onakaaa
            #10 écrit par Onakaaa Il y a 2 ans

            C’est IDT 92HD87B1/3 (VenID : 111D / ProdID : 76D1)

  • dudenay
    #11 écrit par dudenay Il y a 2 ans

    Wouaaah, bravo et merci pour ce post plutôt clair, même pour un noob comme moi.
    Suite à l’installation de la CS6 d’adobe, tous les softs de la suite s’ouvrent sauf After Effects.
    De nombreux graphistes semblent bloqués, dont moi, et le plantage vient peut-être d’un mauvais adressage du framebuffer.
    Ton post va peut-être me permettre de corriger cela, donc de débloquer pleinement l’openGL et de pouvoir lancer After Effects CS6.
    Je repasserai par là pour te dire si ça a marché.

    • itOtO
      #12 écrit par itOtO Il y a 2 ans

      Salut,
      Pour OpenGL tu peux utiliser open gl extension viewer qui permet de voir si toutes les versions d’opengl sont actives sur ta machine.

      • dudenay
        #13 écrit par dudenay Il y a 2 ans

        ok, alors voici le verdict de l’open gl extension viewer.
        Si je fais les choses convenablement, j’ai lancé un update depuis le « summary ».
        Ensuite, dans « openGL »: Core features, de 1.1 à 2.1 tout est à 100%
        le 3.0 est ok sauf le Shading language version: 1.30.
        Ensuite ça devient exotique et je vais éviter de tout énumérer sauf si tu le souhaites:
        3.1 est ok à 25%, 3.2 est ok à 70% et 3.3 à 10%.
        Toutes les versions 4 sont à 0%.

        Cependant, l’idée que le framebuffer est mal adressé vient du fait que le logiciel « lecteur dvd » ne se lance plus depuis le changement de carte graphique.
        J’ai lu sur un forum un témoignage de quelqu’un qui avait le même problème avec after effects cs6 et le logiciel lecteur dvd. Ce qui m’a amené à vérifier si mon logiciel lecteur dvd fonctionnait :-) .
        Depuis, le bonhomme a réussi sa motif de framebuffer, et tout est rentré dans l’ordre. Pour ma part, je n’ai pas encore réussi, malgré les explications très claires. Je vais poster les résultats du radeon_bios_decode et du redsock_bios_decoder ainsi que ce que j’en ai déduis comme adressage.
        Tu me diras si j’ai bien raisonné, si tu veux bien.

      • dudenay
        #14 écrit par dudenay Il y a 2 ans

        Voici le radeon_bios_decode:
        ATOM BIOS Rom:
        SubsystemVendorID: 0×1462 SubsystemID: 0×2091
        IOBaseAddress: 0×0000
        Filename: SV35234E.H01
        BIOS Bootup Message: 113-MSITV209MS.210
        CYPRESS CR PRO GDDR5 BIOS UCODEV:128
        PCI ID: 1002:6899
        Connector at index 0
        Type [@offset 44654]: DisplayPort (10)
        Encoder [@offset 44658]: INTERNAL_UNIPHY2 (0×21)
        i2cid [@offset 44754]: 0×90, OSX senseid: 0×1
        Connector at index 1
        Type [@offset 44664]: HDMI-A (11)
        Encoder [@offset 44668]: INTERNAL_UNIPHY2 (0×21)
        i2cid [@offset 44781]: 0×92, OSX senseid: 0×3
        Connector at index 2
        Type [@offset 44674]: DVI-I (2)
        Encoder [@offset 44678]: INTERNAL_UNIPHY (0x1e)
        i2cid [@offset 44818]: 0×94, OSX senseid: 0×5
        Connector at index 3
        Type [@offset 44684]: DVI-I (2)
        Encoder [@offset 44688]: INTERNAL_KLDSCP_DAC1 (0×15)
        i2cid [@offset 44818]: 0×94, OSX senseid: 0×5
        Et le redsock_bios_decoder:
        SV35234E.H01:
        113-MSITV209MS.210
        CYPRESS CR PRO GDDR5 BIOS UCODEV:128
        Subsystem Vendor ID: 1462
        Subsystem ID: 2091
        Object Header Structure Size: 320
        Connector Object Table Offset: 3e
        Router Object Table Offset: 0
        Encoder Object Table Offset: eb
        Display Path Table Offset: 12
        Connector Object Id [19] which is [DISPLAY_PORT]
        encoder obj id [0x21] which is [INTERNAL_UNIPHY2 (osx txmit 0x12 [duallink 0x2] enc 0×4)] linkb: false
        Connector Object Id [12] which is [HDMI_TYPE_A]
        encoder obj id [0x21] which is [INTERNAL_UNIPHY2 (osx txmit 0x22 [duallink 0x2] enc 0×5)] linkb: true
        Connector Object Id [2] which is [DVI_I]
        encoder obj id [0x1e] which is [INTERNAL_UNIPHY (osx txmit 0x10 [duallink 0x0] enc 0×0)] linkb: false
        Connector Object Id [2] which is [DVI_I]
        encoder obj id [0x15] which is [INTERNAL_KLDSCP_DAC1 (osx txmit 0x00 enc 0x10?)] linkb: false

        J’en ai déduis (le je laisse le hot plug id inchangé d’où les –):
        00 04 00 00 00 04 00 00 00 00 00 00 12 04 — 01
        00 08 00 00 00 02 00 00 00 00 00 00 22 05 — 03
        00 02 00 00 14 00 00 00 00 00 00 00 10 00 — 05
        00 02 00 00 14 00 00 00 00 00 00 00 00 10 — 05

        J’ai modifié le Uakari en offset 163040 du ATI5000Controller.kext

        Puis j’ai modifié le com.apple.Boot.plist de la façon suivante:

        Kernel
        mach_kernel
        Kernel Flags

        GraphicsEnabler
        Yes
        AtiConfig
        Uakari

        J’ai vraiment essayé de suivre tes indications à la lettre, mais comme les informations systèmes m’indiquent toujours une carte ATI Radeon HD 5000 au lieu de me préciser une série 5800, à priori j’ai toujours un problème de « framebuffer personality »…
        J’espère que tu auras le temps de m’aider là-dessus, de mon côté j’ai déjà dépassé mes limites grâce à toi :-)

        • itOtO
          #15 écrit par itOtO Il y a 2 ans

          Salut,
          Alors en fait il y a quelques petites erreurs dans ton framebuffer:
          -d’abord, dans il manque une ligne qui prend la valeur 01 ou 71 (dans le uakari original c’est 71 pour les quatre ports), ça correspond à un identifiant qui informe OSX du type d’écran (interne, externe, retro-éclairé, etc…). Que tu mettes 01 ou 71 je ne suis pas sur que ça change grand chose, mais laisser 00 ça pourrait expliquer que ça bug…
          -un des encoder est faux: le dernier devrait être 00 et non 10 (Uniphy link A+B = DIG1= 00)
          -pour ton port DVI-I il ne faut qu’une seule ligne (une ligne par port physique!), il suffit qu’il soit bien renseigner en DVI-I avec du Uniphy pour que ensuite OSX puisse l’utiliser pour faire passer un signal numérique (DVI-D) ou analogique (DVI-A)

          Donc au final il faudrait plutôt que tu modifies Langur ou Hoolock qui ne possèdent que trois sorties et mettre ça:
          00 04 00 00 00 04 00 00 00 71 00 00 12 04 04 01
          00 08 00 00 00 02 00 00 00 71 00 00 22 05 02 03
          00 02 00 00 14 00 00 00 00 71 00 00 00 00 06 05

          Tu peux aussi d’abord essayer d’ajouter AtiPorts3 dans le boot.plist pour que OSX ne tienne pas compte du 4ème ports du framebuffer, voir si ça passe…

          • dudenay
            #16 écrit par dudenay Il y a 2 ans

            Salut et merci!
            Bon, là j’ai bien tout modifié, mais j’ai du foirer le remplacement du ATI5000Controller.kext puisque j’ai droit à un écran noir.
            J’ai remis l’ancienne carte, elle marche bien.
            Remplacement du « kext modifié » par le « kext original » avec rétablissement des droits par le terminal, toujours rien et le rapport systeme m’indique « Une erreur s’est produite lors du recueil des informations de la carte PCI. » pour les cartes PCI et sur cartes vidéos, il voit bien qu’il a deux cartes, pour celle qui nous intéresse, j’ai  » Informations sur l’extension du noyau: Aucune kext n’est chargée ».
            Bizarrement, il ne reconnait plus cette carte et ne charge plus son kext.
            Si j’installe un autre systeme, elle fonctionne à nouveau…
            Y a t’il une procédure particulière pour remettre un kext et que le système le prenne à nouveau en compte?
            La seule différence, après rétablissement des droits via le terminal, entre un kext auquel je ne touche absolument pas et un kext modifié, c’est la suivante:
            J’ouvre le paquet>Contents>MacOS>ATI5000Controller, Information sur le fichier, le type de fichier est: Fichier exécutable Unix (Intel) alors qu’auparavant c’était un document.
            À part ça, je ne vois pas de différence.
            J’ai testé avec un autre disque dur, même config, même système, tout marche bien, il voit les deux cartes, je remplace le kext original par un autre kext original (donc par lui même), je rétablie les droits et je ne touche même pas au com.apple.Boot.plist, même bug… la 5850 n’est plus reconnu.
            Comment puis-je « ré-activer » le kext?
            C’est marrant parce que quand j’avais modifié le FrameBuffer Uakari, je n’avais pas eu ce problème. Peut-être que j’avais modifié le kext directement dans son emplacement d’origine.
            Si tu as (encore) une idée, ce serait super.
            J’ai trop envie de voir si ça marche avec tes indications de FrameBuffer et l’ATIPorts 3!
            Merci encore pour ton aide.

  • dudenay
    #17 écrit par dudenay Il y a 2 ans

    Hello,

    J’ai pas mal avancé mais toujours pas de retour d’écran.
    En passant par l’utilitaire de disque et en sélectionnant la partition, dans SOS, je clique sur le bouton « Réparer les permissions du disque » et je vois passer les fichier du kext qui me concerne.
    Ensuite, avec Onyx (excellent utilitaire de maintenance du mac & gratuit), je nettoie les caches de démarrage.
    Donc maintenant, dans le rapport système, je retrouve bien les deux cartes vidéo et la ref « ATI Radeon HD 5000″ est revenu, ainsi que l’identifiant du périphérique, bref, de ce côté là tout semble bien.
    Par contre j’ai toujours « Une erreur s’est produite lors du recueil des informations de la carte PCI. » pour la section « Cartes PCI ».
    De plus, l’écran ne s’allume toujours pas sur cette carte, mais bon on avance, on va y arriver.

  • dudenay
    #18 écrit par dudenay Il y a 2 ans

    Les messages s’affichent dans le désordre ;-)

  • dudenay
    #19 écrit par dudenay Il y a 2 ans

    Ok, la carte fonctionne à nouveau, ce matin avec les idées plus claires, j’ai vu que la prise HDMI était débranché… Le boulet, j’vous jure :-p
    Ceci dit, le nettoyage des caches système, et le rétablissement des autorisation (aussi possible par Onyx) c’était une bonne idée.

    Donc nous avons:
    Un kext modifié qui est bien vu par le système avec des autorisations bien définies et qui est bien vu comme un type de fichier « document », bref tout roule.
    Un com.apple.Boot.plist qui ressemble à ça:

    Kernel
    mach_kernel
    Kernel Flags

    GraphicsEnabler
    Yes
    AtiConfig
    Langur
    AtiPorts
    3

    Je redémarre, la carte marche bien sauf que dans dans les infos systeme, j’ai toujours « Une erreur s’est produite lors du recueil des informations de la carte PCI. » pour la section « Cartes PCI ».
    Du coup, sur un autre forum, il y avait cette ligne de commande pour voir le framebuffer utilisé par la carte graphique: ioreg | grep ATY
    Avec la carte graphique d’origine, ça fonctionne bien et ça me donne le nom du framebuffer.
    Avec la ATI R5850, ça me donne:
    | | | | +-o ATY,ATY,RadeonFramebuffer@0 <class AtiFbStub, id 0×1000003$
    | | | | | +-o ATY_ATY,RadeonFramebuffer <class ATIFramebuffer, id 0×10$
    | | | | +-o ATY,ATY,RadeonFramebuffer@1 <class AtiFbStub, id 0×1000003$
    | | | | | +-o ATY_ATY,RadeonFramebuffer <class ATIFramebuffer, id 0×10$
    | | | | +-o ATY,ATY,RadeonFramebuffer@2 <class AtiFbStub, id 0×1000003$
    | | | | | +-o ATY_ATY,RadeonFramebuffer <class ATIFramebuffer, id 0×10$

    Je précise que je redémarre maintenant avec une seule carte graphique dans la machine, la ATI R5850.
    Donc le mac n'utilise pas le FrameBuffer Langur que je cherche à lui faire utiliser via le com.apple.Boot.plist
    Comment puis-je le forcer à en passer par le FrameBuffer Langur?

    • itOtO
      #20 écrit par itOtO Il y a 2 ans

      Salut,
      Pour la suite ce serait plus simple que tu ouvres un sujet dans le forum, parce que dans les commentaires ça va vite devenir bordélique :-) http://itotoscreencast.fr/forum/hackintosh-group2/kexts-dsdt-forum5

      Sinon, pour la ligne Atiports=3, c’était pour le framebuffer uakari (vu qu’il comporte des infos pour 4 ports tu précise au système qu’il n’y en a que trois sur la carte), pour langur pas de raison d’utiliser cette ligne vu que le framebuffer ne possède déjà que 3 ports.

      Pour l’installation du kext, le plus propre c’est de faire une copie du kext original sur le bureau, d’en mettre une autre copie de coté pour pouvoir revenir en arrière si besoin, pui de modifier cette copie sur le bureau et de l’installer en utilisant un logiciel comme kextbeast, kext utility, etc… qui permettent d’installer le kext et de réparer les autorisations dans la foulée en reconstruisant aussi le cache des kext (car le système met en cache les kext pour accélérer le démarrage donc si tu ne mets pas a jour ce cache, tu risques d’avoir un conflit entre le vieux kext dans le cache et le nouveau dans le dossier extension).

  • Fry
    #21 écrit par Fry Il y a 2 ans

    Un immense merci pour ce site et ce tuto, j’ai un soucis entre une 5870 Vaporx, Steam et mon Triple Screen (2xDVI+DP).
    Je ferais une retour après l’avoir configurée aux ptits oignons ;)

  • thebestnono
    #22 écrit par thebestnono Il y a 2 ans

    bonjour
    super tuto, une petite question je souhaite faire fonctionner une ATI 4530 mobilité et gpuz ne peu récupérer mon Bios, il y a t’il une autre solution
    dans mes dernier test j’ai un écran rose – HMDI et VGA OK – qe/ci activé,
    à votre avis que dois je faire pour avoir ma carte fonctionnelle

    merci d’avance
    cordialement

  • Bruno21
    #23 écrit par Bruno21 Il y a 1 an

    Depuis ML, j’ai un msg d’erreur sur ati-personnality.pl


    alubook:~ bruno$ perl ati-personality.pl -x
    Kext ATI2400Controller
    lipo: can't open input file: /System/Library/Extensions/ATI2400Controller.kext/Contents/MacOS/ATI2400Controller (No such file or directory)
    Couldn't find segment for x86_64 architecture at ati-personality.pl line 75.

  • Bruno21
    #24 écrit par Bruno21 Il y a 1 an

    Depuis ML, j’ai un msg d’erreur sur ati-personnality.pl

    alubook:~ bruno$ perl ati-personality.pl -x
    Kext ATI2400Controller
    lipo: can't open input file: /System/Library/Extensions/ATI2400Controller.kext/Contents/MacOS/ATI2400Controller (No such file or directory)
    Couldn't find segment for x86_64 architecture at ati-personality.pl line 75.

  • Bruno21
    #25 écrit par Bruno21 Il y a 1 an

    Avec la dernière version 0.10 du script, ça va mieux…

  • itOtO
    #26 écrit par itOtO Il y a 2 ans

    J’ai trouvé layout-id 12 pour ton chipset audio, donc pour l’edition du DSDT ca donnerait 0x0c, 0×00, 0×00, 0×00

  • dudenay
    #27 écrit par dudenay Il y a 2 ans

    Un dernier détail, pour réparer les autorisations, je passe en root dans le terminal en tapant « sudo su » puis en donnant mon mot de passe root.
    Ensuite je tape tes lignes de codes en mettant 5000 au lieu de 6000 pour toucher le bon fichier.
    puis « exit ».
    Je précise pour que tu vérifies si ma procédure est bonne. Si je ne passe pas en root, il ne veut pas modifier les autorisations.

  • Vous pouvez utiliser ces mots-clés HTML : <a> <abbr> <acronym> <b> <blockquote> <cite> <code> <del> <em> <i> <q> <strike> <strong>
    Powered by sweet Captcha

  • Flux de commentaires pour cet article
Haut de page