Lilu.kextとLiluプラグイン.kextを設定するためのとても詳細なガイドがtonymacx86にありました。ここからLiluとWhatEverGreenの部分を抄訳して紹介します。原文は下のリンクを見てください。
An iDiot's Guide To Lilu and its Plug-in'sLast Update: 22nd Jan 2021 (Add note about OpenCore config.plist modifications)About this GuideThis guide is written as a helping hand to those users who have some understanding of using legacy hackintosh methods but are considering using Lilu as a... An iDiot's Guide To Lilu and its Plug-ins - tonymacx86.com |
Liluの開発にも携わっているjaymonkeyさんが書いてくださったガイドです。かなり長いですので、LiluとWhatEverGreenの部分を紹介します。残りの、 AppleALCに関してはこちらをご覧ください。
Lilu.kextとLiluプラグイン.kextを設定するためのとても詳細なガイドがtonymacx86にありましたのご紹介します。今回はAppleALCの使い方の部分の抄訳です。原文は下のリンクを見てください。Liluの開発にも携わっているjaymonkeyさんが書いてくださったガイドです。かなり長いです。前回は、WhatEverGreenを紹介しました。AirportBrcmFixupに関しても後ほど紹介したいと思います。(ここから抄訳)AppleALCとはAppleALCはLiluのプラグインです。ネイティブでないオーディオコーデックに対してHigh Definition Audio (HDA)を有効にするた... Liluとプラグイン:(2) AppleALCの使い方 - Boot macOS |
AirportBrcmFixupに関しても後ほど抄訳したいと思います。
(ここから抄訳)
Table of Contents
Liluとは何か
LiluはmacOSのパッチエンジンです。カーネルとシステム拡張を起動時に拡張します。使用することのメリットは多いです。
- 特定のブートローダーに依存しない
- リカバリーモードやmacOSインストーラ・アップデータでも動く
- シンボリックパッチエンジンもサポートする
- カーネルとシステム拡張へのAPIアクセスを可能にする
- 起動中のプロセスの変更も可能
Liluはパッチの仕組みを提供するだけで、それだけでは何もしません。プラグインと一緒に使うことで機能します。Liluパッチを作成するための開発キット(SDK) も用意されています。有名な3種のパッチは、WhateverGrenn, AppleALC, AirportBrcmFixupです。以下ではこれらについて説明します。Liluプラグインの全てのリストはLiluのGitHubをご覧ください。(訳注:VirtualSMCもLilu使ってたんですね。)
Liluプラグインはそれだけで機能し、同様の機能を提供する従来型のCloverのパッチやkextを置き換えます。そのため、関係するClover設定、FakeID, パッチ、kextがすでに導入されていたら、それを取り除いてください。例えば、LiluプラグインであるAppleALC.kextをインストールしたら、CloverのAppleHDAパッチとHDA Enabelerのパッチやダミーのkextは全て取り除くか無効にします。競合するパッチが残っていると、システムが予想外の動作をしたり、不安定な状態になります。
Hackintool
以下の説明ではHackintoolを使います。ぜひ備えておいていただきたいツールですので、ここからダウンロードしておいてください。
Liluとプラグインのインストール方法
LiluとそのプラグインはmacOSのkextとして提供されます。これらは、 /Library/Extensionsに入れるべきです。Cloverのkexts/Otherに入れるとしたガイドも多いですが、この方法は試験や開発だけに留めておくのが良いです。サードパーティのkextを入れる正式な場所は/Library/Extensionsです。(訳注:どちらが良いかは議論のあるところだと思います。簡単なのでkexts/Otherで良いのではないかと思います。これ以降、/Library/Extensionsに入れるための方法が続きますが省略します。Catalinaになるとセキュリティ保護が厳しくなるので、かなり面倒なようですね。)
WhatEverGreen (WEG)
WhatEverGreen(以下WEG)は2017年にAMD GPUのためにリリースされましたが、現在(2019年)では以下の機能を統合しています。
- IntelGraphicsDVMTFixup –> Intel IGPU DVMT Pre-allocationのパッチ
- IntelGraphicsFixup –> Intel IGPU’sをサポートするための多数のパッチ
- NvidiaGraphicsFixup –> Nvidia GPUをサポートするための多数のパッチ
- CoreDisplayFixup –> High DPI表示のパッチ (pixel clock patch)
- Shiki –> DRMで保護されたビデオ再生のためのパッチ
- AzulPatcher4600 –> HD4600 IGPUのAzulフレームバッファのためのパッチ
- AppleBacklightFixup –> バックライト制御のプラグイン
- EnableLidWake –> ラップトップの蓋操作でスリープ解除するためのパッチ
このようにWEGは、GPU/IGPUとディスプレイに関する全ての解決策を提供します。また、統合されてしまった上記のプラグインは、WEGと一緒に使わないでください。カーネルパニックやOSの異常動作を引き起こす可能性があります。
WEGの前準備
Cloverのconfig.plistから、IGPUに関する全てのインジェクション、設定、フェイクIDなどを除去してください。これを行わないと、WEGの動作と衝突することになり、想定外の結果を引き起こします。
最新版のLiluとWEGを/L/Eに入れます。(訳注:kexts/Otherでも良いと思います。)
WEGはデバイス改名処理も行います。なので、Cloverのconfig.plistに次のようなACPI Fix/Renameの箇所があれば、これを削除します(もしくは無効にします)。
- GFX0をIGPUに変更するパッチ
- PEG0をGFX0に変更するパッチ
- HECIをIMEIに変更するパッチ
これらのClover ACPI Fix/Renameの手法は、ACPIのテーブル全体に変更を与えてしまうために、後に問題を引き起こす可能性があります。WEGの方法は特定のACPIコードを探索して、そこだけを変更しますので、優れています。
AMDとNvidiaのdGPU
AMDとNvidiaユーザは、Lilu と WEGをインストールすることで、フレームバッファもdGPU関係のパッチも全て対応できます。上級者向けには起動オプションが多数ありますので、WEGのreadme.mdを見てください。Liluの概要で述べたように、AMDとNvidiaのGPUに関するパッチは、config.plistから削除してください。WEGがこれらを全てやってくれます。
IntelのiGPU
iGPUだけのシステム、もしくはdGPUと併用するシステムでは、WEGは従来の方法より早くて簡単なカスタマイズ手段を提供します。従来の方法では、Cloverを使ったり、Intel iGPUドライバーにパッチを当てたり、フレームバッファkextにパッチを当てたりしていました。
WEGをそのまま使う
最近のWEG (V1.3.0以降) は、改善されたiGPU自動検出と自動設定の機能があり、追加の作業なしでたいていのシステムでそのまま動きます。まずは、上記で説明したWEGの前準備を実行しておいてください。その後、単にLiluとWEGをインストールして再起動するだけです。なお、SMBIOSの記述はWEGの自動設定に影響を与えます。
(訳注:GPUを動かすためには、「前準備」をして、LiluとWEGを入れるだけで良いということです。それで問題なく動く場合は、この先は参考程度に読んでください。)
WEGの自動設定は非常に改善されてはいますが、完璧ではなく、全てのシステムで機能するわけではありません。自動設定が機能しない場合は、WEGを手作業で設定しなければなりません。また、dGPUが搭載されている場合、WEGはiGPUを「ヘッドレス」に設定したいところです。でもそのためにはiGPUとdGPUがBIOSで正しく設定されている必要があります。ヘッドレスに関して後で詳細に説明します。
WEG手動設定に必要なID情報
WEGはDevice Propertiesを使って設定を行います。これはCloverを使ってデバイスioregディレクトリーツリーのカスタムプロパティを定義する比較的新しい方法です。Lilu開発メンバーからのリクエストでCloverに実装された手法です。デバイスプロパティについての詳細はClover開発ブログのこちらをご覧ください。
デバイスプロパティは、Cloverのconfig.plistのDevices –> Propertiesセクションで定義されます。プロパティは、PCIパスで決まる名前とデータ値から構成されます。名前とPCIパスは<key>タイプで、データ値は次の3種類のうちの一つで表現されます。
- <data>
- <number>
- <string>
iGPU デバイスプロパティ
全てのiGPUパッチは、Hackintoolのトップメニューの2番目のアイコンにあるパッチモードで実行できます。また、下のバーメニューを使ってパッチモードのサブ機能を使えます。Patchをクリックして、infoを選択してみました。
もしHackintoolがシステムのCPU世代を正しく特定しているものの、Platform IDドロップダウンメニューが空で、FramebufferとConnectorサブメニューにデータが表示されない場合は、、HackintoolのメニューバーのFramebufferをクリックして、macOSバージョンを使用中のものに設定してください。
もしHackintoolがCPU世代を自動的に特定できなくて、Current Framebuffer Infoボックスに???が表示されたり、Hackintoolが誤った世代のCPUを選択しているようならば、ドロップダウンメニューから手作業で正しいCPU世代を設定できます。
Hackintoolを最初に起動すると、iGPUを検出して、それ用のデフォルトPlatformIDを選択しますが、多くの場合、これらは正しくないので、最初にこれを正しく選択させる必要があります。
Infoサブ機能を選択すると、検出されたiGPUのタイプが下のCurrent Framebuffer Infoボックスに表示されます。また選択されたPlatformIDの詳細と、合致したSystem Definitions (SMBIOS)が上のSelected Framebuffer Infoボックスに表示されます。
例えば、2017年版HP Spectre X350ラップトップで最初にHackintoolを動かした時は、PlatformIDとして0x591B0000が選択されて、System Definition (SMBIOS) としてMacBookPro 14,3が推奨されました。
上の図では、矛盾した情報が表示されています。iGPUは正しく検出されていて、Current Framebuffer InfoボックスにはHD 620であると表示されていますが、Selected Framebuffer Infoボックスには0x591B0000はHD 630 iGPUであると表示されています。なので、PlatformID 0691B0000は間違っていることがわかります。これをPlatformIDドロップダウンメニューから正しいものに変更します。もし、必要とするPlatformIDが分からないなら、ドロップダウンメニューから一つ一つ順番に選択して、iGPUタイプに合致するIDを探します。(訳注:https://arc.intel.com/で使用しているCPUを検索すると16進数4桁のデバイスIDが分かります。IntelのベンダーIDは8086なので、このデバイスIDと8086をつなげた番号がGPU Device IDに現れるべき数値になります。Platform IDを変えていくと画面に表示されるGPU Device IDも変化するので、上位4桁がarc.intel.comの番号に合うように選択すると良いと思います。)
ラップトップPCの場合は、モバイル用のPlatform ID(Mobile の欄に Yesと表示が出ます)を選択します。デスクトップPCの場合はMobileがNoのものを選択します。
私のHP Spectre X360ラップトップでは、0x59160000が必要であると分かっていましたので、ドロップダウンメニューからこれを選択しました。
さてこれで、Selected Framebuffer InfoボックスとCurrent Framebuffer Infoボックスで同じiGPUタイプが表示されるようになりました。HP Spectre X360ラップトップはMobile HD 620 iGPUで、推奨のSystem Definition (SMBIOS)はMacBookPro14,2です。
プロの技:@haedkazeさんによるリストを使うことでも、PlatformIDを見つけることができます。これは、macOSで使えるPlatformIDとFrameBufferのリストです。これを使えば、例えば、Coffee Lake CPUを使う場合、Coffee Lake CPUセクションまでスクロールすると、最初に全てのPlatform IDがまとめられています。ここには、MobileかDesktopシステムなのかが書いてあります。またコネクタの数が0になっているIDは、ヘッドレスのものです。
それぞれのPlatform IDの詳細は、少しスクロールすると見ることができます。例えばPlatform ID 0x3E9B0000の詳細は以下のように書かれています。
この情報から、このPlatform IDがMacBookPro15,1で使われていることがわかり、これがIntel UHD 630 iGPUのPlatform IDだとわかります。Hackintoolからもこれらの情報はわかりますが、リストアップされた形式で確認する方が簡単なこともあります。
HD 4600 iGPUに関する特記事項:上記のリストでIntel HD 4600 のPlatform IDが0x4160000になっています。でも私の経験では、Platform IDを0x0D220003 (これはIntel Iris Pro Graphics 5200のものです)にし、device-idは0x0412 (これはIntel HD 4600のもの)にし、iMac14,2にするのがよかったです。またHDMIを使うためには、こちらのパッチが必要です。この理由はわかりませんが、おそらくmacOSが他のIntel CPUとは違うAZUL Framebuffer kextを使っていることが原因かと思われます。
重要:選択したPlatform IDに合ったSystem Definition (SMBIOS)を使うようにしましょう。Hackintoolは多くの場合、推奨するSMBIOSを上のSelected Framebuffer InfoボックスのModel(s)欄に表示してくれます。Platform IDと合致しないSMBIOSを使うとmacOSが動作不良に陥ります。
注意:いくつかのPlatformIDでHackintoolのModel(s)欄に推奨System Definition (SMBIOS)が表示されない、もしくはUnknownと表示されることがあります。これはそのGPU、IGPU、Platform IDと合致するMac機種が存在しないからです。しかし、IGPU Platform IDは有効で機能するはずです。でも、できるならば、使用しているiGPUに合致したフレームバッファを持つ他のPlatform IDを選択し、それから推奨されるSMBIOSを選ぶのが良いです。
適合するPlatformIDが見つからない場合
もし使用しているiGPUに合致するPlatform IDを見つけられない場合、最も近いものを代わりに選ぶことになります。例えば、UHD 620を使っている場合、最も近いのはおそらくUHD 630のPlatform IDです。他の例では、HD 4400 iGPUの場合は、HD 4600またはHD 5200のPlatform IDを選ぶと良いです。これらの場合、システムをちゃんと動かすために、異なるPlatform IDをいくつか試すことになります。
もしシステムがラップトップならば、MobileがYesになっているモバイル用のiGPU Platform IDを選択します。(訳注: arc.intel.comで該当するCPUの仕様を見ると、「システムの種類:Mobile」などと書かれた項目があるので、それに合わせるのが良いと思います。)
もし、iGPUと合致しないPlatform IDを使う場合、対象のiGPUタイプのデバイスIDを知る必要があります。これは後で説明します。
適合するSMBIOSが見つからない場合
もし推奨SMBIOSに対するPlatform IDが見つからない場合でも、動かないわけではありません。この場合は、作ろうとしているシステムに一番近い、合致するSMBIOSを推測することになります。この作業に便利なツールがMacTrackerです。
注意:もしSMBIOSを変更する必要がある場合、iCloudなどのAppleのオンラインサービスからログアウトすることを忘れないでください。また、iDiot’s Guide To iMessage を見て、新たに設定をおこなってください。(訳注:Appleからbanされることもあるので注意しましょう。SMBIOSの試行錯誤をする場合は、ネットから切り離して作業するのが良いと思います。)
ヘッドレスPlatform ID
デスクトップHackintoshユーザが、Hackintoolが推奨するPlatform IDを上書き変更したいと思うもう一つの状況は、iGPUをヘッドレスモードで使いたいという場合です。(訳注:ヘッドレスというと、通常は、PCをネットから制御することを前提に、ディスプレイ無し使用することを言います。でもここでは、dGPUにはディスプレイを接続するけど、iGPUにはディスプレイを接続しないという意味のようです。)
iMacや幾つかのMac miniのように、デュアルGPUを搭載している純正のデスクトップ型Macは、ヘッドレスPlatform IDを使っています。これにより、macOSにiGPUには物理的なディスプレイが接続されていないこと、しかしハードウェア加速機能のためにmacOSがiGPUを使用できること、を伝えています。iGPUがヘッドレス利用と設定されると、macOSはiGPUを、AirPlayのミラーリング表示機能や、静止画・動画の符号化・復号化機能 (Intel Quick Sync -iOS)などで使うための、ある種のGPU副プロセッサとして使用します。これはmacOSの重要な機能です。ですので、もしdGPUの他にサポート対象のiGPUがあるならば、iGPUをヘッドレス構成に設定すべきです。
注意:ワークステーションクラスのCPU (Intel Xeon) を搭載したシステムは、iGPUを備えていません。なので、ヘッドレスPlatform IDを設定してはいけません。
もし、ヘッドレス構成が不要ならば、次の、「WEGの手動設定」まで読み飛ばしてください。
Hackintoshの主ディスプレイアダプターがNvidiaやAMDのdGPUであり、サポート対象のiGPUも備えていたら、ヘッドレスPlatform IDを使えば、そのHackintoshシステムは安定になり、iGPUによるハードウェア加速機能を備えた純正のMacのように振る舞います。
iGPUをヘッドレスモードで動かすためには、以下のBIOS設定を行います。
IGPU -> Enabled Primary Display Adapter -> dGPU (PEG) Multi-Monitor Mode -> Enabled (このオプションがある場合)
また、デュアルGPU構成をサポートし、使用中のCPU/iGPUタイプに合致するMacのSystem Definition (SMBIOS) を正しく設定しておく必要があります。ヘッドレスPlatform IDのためのオススメのSMBIOSは以下です。
- Coffee Lake CPU = SysDef: imac19,x
- Kaby Lake CPU = SysDef: imac18,x
- SkyLake CPU = SysDef: imac17,x
- Haswell CPU SysDef: imac14,x または imac15,x
- Ivy Bridge CPU SysDef: imac13,x または macmini6,x
- Sandy Bridge CPU = SysDef: imac12,x または macmini5,x
注意:もし使用中のCPU. iGPUと選択したヘッドレスPlatform IDが既知のMac構成と合致するなら、Hackintoolは合致したSystem Definition (SMBIOS)を上のSelected Framebuffer Infoボックスに表示します。
現在知られているヘッドレスPlatform IDは以下です。
- Coffee Lake CPU
9th Gen UHD-630 IGPU = 0x3E980003 (MacOS 10.14.4+で使用)
8th Gen UHD-630 IGPU = 0x3E920003 or 0x3E910003 (MacOS 10.13.6 〜 10.14.Xで使用) - Kaby Lake CPU
HD-630 IGPU = 0x59120003 (MacOS 10.13.Xで使用)
Unknown = 0x59180002 (推奨しません) - SkyLake CPU
HD-510 IGPU = 0x19020001
GT2f IGPU = 0x19170001
HD-530 IGPU = 0x19120001
Iris Pro 580 = 0x19320001 - Haswell CPU
HD-4600 IGPU = 0x0412000B or 0x04120004 - Ivy Bridge CPU
HD-4000 IGPU = 0x01620006 or 0x01620007 - Sandy Bridge CP
HD-3000 IGPU = 0x00030030
注意:モバイル用CPUであるCannon-Lake と Ice-Lake CPUにはヘッドレスPlatform IDはありません。
Hackintoolを使って、Connectors機能を選択することで、選択したPlatform IDがヘッドレスであるかどうかを確認できます。全てのエントリーは次の値を持っている場合、ヘッドレスです。
- index = -1
- bus id = 0x00
- pipe = 0
- type = dummy
これに加えてHeadlessアイコンが表示されます。HaswellのヘッドレスPlatform IDである0x0412000Bの例を示します。
注意-1: ヘッドレスiGPUモードはデスクトップ機のデュアルGPU構成 (dGPU + iGPUの構成)でのみ良好に動きます。両方のGPUの出力が同じディスプレイに接続されるラップトップ機のデュアルGPU構成では動きません。このような構成では、RehabManさんのガイドのようにdGPUを常に無効にしないとmacOSが動かないからです。
注意-2: 既に述べたように、ヘッドレスPlatform IDの使用は、推奨された機種のSMBIOSでのみ機能します。それ以外のシステムを設定すると不安定になります。
注意-3: ヘッドレスPlatform IDを使う場合、iGPUは、BIOSで有効に設定してあっても、システム情報 -> ハードウェア -> グラフィックス/ディスプレイ には現れません。これは正常です。これによりヘッドレスiGPUモードが機能していることを確認できます。
注意-4: Hackintoshに1個または複数のThunderbolt 3ポートが実装されていて、これをdGPU + ヘッドレスiGPUの表示に使いたい場合は、BIOSで”Above 4G Decoding”オプションを有効にする必要があります。
注意-5: iGPUをヘッドレスに設定した後、IORegistryExplorerを使ってIOREGを調べることで、全てが正しく設定できたことを確認できます。”IGPU”で検索して、iGPUエントリーのAAPL, ig-platform-idプロパティが、ヘッドレスPlatform IDに設定されていて(バイト順が逆になっています)、適合したモデル設定になっていることを確認します。
WEGの手動設定
HackintoolのPatchモードの他のサブ機能のボタンをクリックすると、現在選択されたフレームバッファー設定と変更をチェックできます。大抵の場合、ここでは何も変更する必要はないです。詳しくは WEG guideのpost #2を見てください。全てokでしたらPatchサブ機能ボタンを押します。
iGPUなりすまし
もしiGPUに合致しないPlatform IDを使用しているなら、iGPUのdevice IDを他の値に偽装しなければならなりません。
例えば、UHD 620 iGPUを使用する場合、これに対応するPlatform IDはありません。もっとも近いPlatform IDはUHD 630 iGPUです。それでUHD 630のPlatform IDを選ぶことになり、iGPUをUHD 630に偽装する必要があります。
iGPUのなりすましを行うためには、Advancedページを使います。(訳注:上のアイコンでPatchを選び、下のボタンでPatchを選んだ後に上部に現れるAdvancedタブです。)ここでSpoof Video Deviceにチェックを入れ、ターゲットのiGPUデバイスIDを隣にあるドロップダウンメニューから選びます。下のスクリーンショットでは、UHD 620 iGPUをUHD 630になりすましさせています。
iGPUパッチ生成
次に、Generalのサブページをクリックして、Devices/Propertiesラジオボタンを選択して、Graphic Deviceチェックボックスを選択し、それ以外のチェックボックスはとりあえず非選択にします。そしてGenerate Patchボタンをクリックします。大抵の場合、AAPL,ig-platform-id (またはSandy Bridgeの場合はAAPL,snb-platform-id)がDevice Propertyとして設定されれば、WEGはiGPUを正しく設定できます。追加のプロパティーは、オプショナルですが、iGPUを正しく特定するために役立ちます。以下では、HackintoolをIntel HD 620 iGPUを搭載し、Platform IDが0x59160000である2017年版HP Spectre X360ラップトップで動かした例を示します。
このパッチコードを、plistの正しい構造を維持しつつ、config.plitにコピーペーストします。<key>と<dict>のブロックのの部分を選択してコピーします。
次に、これをconfig.plistのDevices -> Propertiesセクションにペーストします。上の例の場合、このような感じになります。
<key>Devices</key> <dict> <key>Properties</key> <dict> <<----- ここの後にHackintoolのパッチをペーストする <key>PciRoot(0x0)/Pci(0x2,0x0)</key> <dict> <key>AAPL,ig-platform-id</key> <data> AAAWWQ== </data> <key>AAPL,slot-name</key> <string>Internal</string> <key>device-id</key> <data> FlkAAA== </data> <key>device_type</key> <string>VGA compatible controller</string> <key>framebuffer-patch-enable</key> <data> AQAAAA== </data> <key>model</key> <string>HD Graphics 620</string> </dict> </dict> </dict>
注意: Sandy BridgeではDevice Propertyの名前はAAPL,snb-platform-idになります。 (AAPL,ig-platform-idではありません)
暗黒画面とコネクター不全
ほとんどの場合Hackintoolが生成するデバイスプロパティはWEGが正しくiGPUを構成するのに十分な情報量です。 しかし、いくつかのシステムではさらにフレームバッファデフォルト値を変更する必要があります。例えば、iGPUのポートをDVIからDPに変更したい場合や、DPからHDMIに変更したい場合です。この場合、Hackintoolを使ってさらなる設定を行い、新たなパッチを作成して、config.plitのDevice Propertiesに追加します。これに関してはCaseySJさんの素晴らしいガイドがあるので、以下を見てください。
General Framebuffer Patching Guide using HackintoolPlease do not quote this guide in its entirety. Post a link instead.15 Jan 2019: Intel FB-Patcher has been renamed to Hackintool.19 Jan 2019: Guide overhauled. Please be aware of possible HDMI hot-plug issues. After boot you may have to... [GUIDE] General Framebuffer Patching Guide (HDMI Black Screen Problem) - tonymacx86.com |
高DPI表示とデュアルモニター
高DPIディスプレイを使う場合、または私の場合のようにラップトップに外部ディスプレイを接続する場合、macOSの起動オプションに -cdfon を追加します。これにより、WEGのピクセルクロックパッチを有効にします。これにより高DPI表示に必要な解像度とリフレッシュレートを可能にします。この機能は、以前はCoreDisplayFixUpプラグインが担っていましたが、今はWEGに統合されました。
この場合iGPUのVRAMをデフォルト値の1536MBから2048MBに増加しておくことをお勧めします。これにより2面の1080P表示が可能になります。これには、config.plistのDevice Propertiesセクションに以下を追加します。
<key>framebuffer-patch-enable</key> <data> AQAAAA== </data> <key>framebuffer-unifiedmem</key> <data> AAAAgA== </data>
注意: VRAMを2048MBに増やす設定は1080Pディスプレイ1個のシステムや、ヘッドレスPlatform IDのシステムでは何の効果もありません。
変更をテストする
必要な変更をconfig.plistに書き込んで再起動します。うまく起動したらHackintoolで状況を把握して、加速機構などが機能していることを確認します。
また、WEGがHECIデバイスを正しくIMEI (Intel Management Engine Interface)に改名できているかどうか確認することをお勧めします。これにはターミナルで以下のコマンドをタイプします。
ioreg | grep IMEI
IMEIに改名するパッチが効いている場合、以下のように表示されれるはずです。
| | +-o IMEI@16 <class IOPCIDevice, id 0x100000264, registered, matched, active, busy 0 (36 ms), retain 11>
もしWEGによる改名が確認できない場合は、従来のCloverのHECI -> IMEI改名パッチを使ってください。
<dict> <key>Comment</key> <string>change HECI to IMEI</string> <key>Disabled</key> <false/> <key>Find</key> <data> SEVDSQ== </data> <key>Replace</key> <data> SU1FSQ== </data> </dict>
DRM問題
DRM (Digital Rights Management, デジタル著作権保護)されたコンテンツが再生できないことがあります。解決は困難です。特にKaby Lake以降のiGPUだけを使ったシステムでMojave以降を使用する場合、現状では対応不可能です。
WEGはDRMに対応していたShikiの機能を引き継いでいます。もし、iTunes、ウェブブラウザでのNetFlix再生などができない場合は、起動オプションでshikigva=1などして、試してください。shikigvaの番号には以下の機能があります。
- 001 = Force Hardware Online Renderer
- 002 = Allow Non BGRA
- 004 = Force Compatible Online Renderer
- 008 = Add Executable Whitelist
- 016 = Disabled Unused
- 032 = Replace Board ID
- 064 = Unlock FP10 Streaming
もしshikigva=1 (001 = Force Hardware Online Renderer)でも表示されなければ、shikigva=57 (001 + 008 + 016 + 032) を試してください。これはmacOSに別のBoard IDを使わせることになり、DRM問題を解決することもあります。
shikigvaの001オプションを使うと、macOSはもっとも適切なハードウェアレンダラーを使うようになります。でもこの自動設定を変更してDRM再生GPUを指定したい場合は、以下のどれかのコマンドを使います。
Intel iGPUを使うように指定する
defaults write com.apple.AppleGVA forceIntel -boolean yes
AMD/ATI dGPUを使うように指定する
defaults write com.apple.AppleGVA forceATI -boolean yes
Nvidia dGPUを使うように指定する
defaults write com.apple.AppleGVA forceNV -boolean yes
私の理解では、AMD GPUは多くの場合、良好に動作します。一方でNvidia GPUとIntel IGPUは世代によって良かったり悪かったりします。
もしshikigva=1でもshikigva=57でもDRM再生ができない場合は、shikigva=60 (004 + 008 + 016 + 032) を試してみてください。これは、代替Board IDを使い、さらに別の互換性のある、GPUハードウェアを使用しないDRMレンダラー手法を使う設定です。もしどれも(1, 57, 60のいずれも)だめなようでしたら、他に問題があると思われます。他の値を試してみてください。
ちなみにmacOSのDRM設定を元のデフォルト設定に戻すには、以下のコマンドを一つずつ使います。
defaults delete com.apple.coremedia defaults delete com.apple.AppleGVA sudo rm -rf /Users/Shared/SC\ Info sudo defaults delete com.apple.coremedia sudo defaults delete com.apple.AppleGVA
DRM問題はいまだに上手くいくこともあれば動かないこともある問題です。おそらくはハードウェアの特定の組み合わせ (Chipset + CPU + GPU) とSMBIOS設定に関係していると思われます。純正のMacであっても、Appleフォーラムで動かないという問題が指摘されています。主にIvy BridgeとHaswellで問題が多いようです。Appleのドライバーそのものが原因かもしれません。
DRM再生はCoffee Lakeシステム (第8世代と第9世代)において特に困難なようです。私はCoffee Lakeを持っていないのですが、@Jaco1960さんによる第8世代を使った報告によると、DRMを動かすたった一つの方法は、iMacPro1,1に設定することだそうです。その結果は以下のようです。(訳注:どの方法を使ってもSideCarが動かなくなるということかな。これは手を出しにくいですね。)
@pastrychefさんも、Coffee Lakeで動かすためには、iMacPro1,1の設定が必要と報告しています。現在は、DRMを100%動かせる方法はありません。