Clover General discussion

[Slice]

Official 

 

 

UDK2017 is a subset of EDK II applicable to Intel architecture firmware. EDK II covers a broad set of requirements, including obsolete packages or features that can’t be verified on Intel platforms. 

Please make it so, that it could be build within Xcode...

Create makefile with one line

./ebuild.sh -t XCODE8

[apianti]

How is getting rid of EDK2 a good thing? Duplicate code, loss of library classes, loss of the ability to combine drivers via the dsc, loss of direct fdf inclusion...

 

Because it's massive and a maintenance nightmare. Clover has duplicated many libraries from EDK2 because the EDK team refuses to fix bugs that are reported to them. I don't know what you mean by loss of ability to combine drivers via DSC, or what FDF has to do with anything. Clover 3 will have no legacy support. Those things are not needed at all.

 

 

Also I propose you stick to the Apple scheme of drivers so they are exchangable with the orig blobs.

 

I don't even understand what you mean by this. You mean modifying firmware? What's the difference if you have to replace one driver with ten? Still works right? Yeah...

 

 

Plz don't load on demand, that will be a terrible mess. Rather always load all drivers and let them register named event hooks in their EP for macOS boot

 

This is kind of what I was talking about, but I don't want to load macOS stuff when I'm booting windows or linux, and vice versa. It's a waste of resources and I don't know what you mean by terrible mess, seems pretty easy to me. As I said you can load the drivers and they will install protocols so if you want to put it in the firmware you can, but also there will be a stub to only load them on demand. I'm thinking about all this trash that gets left behind that no one seems to think matters but I know it does and I can even see in windows and linux that my system memory usage is much higher if I boot through clover compared to from the firmware menu.

[Badruzeus]

"Themes will probably be radically different, SVG support, and actual font support."

Sounds good with GUI, means responsive theme (vector)? But, "No Legacy support"..? Uhmmb.. 

[mhaeuser]

Because it's massive and a maintenance nightmare.

 

"EDK2" is not a dependecy, it is more of a toolcahin shim. You consume LibraryClasses, which aren't giant, depending on which you refer to. LibraryClasses enable you to write true non-agbostic code, by shimming everything that might be different for a certain build. Do you want to explicitely allocate over 4GB (which would require you to get the memory map on each allocation call as UEFI has no other way than AllocateAddress to ensure you get what you want), when the base firmware does so anyway? That can be eliminated by LibraryClasses. For proper UEFI firmware, use the default EDK2 UefiMemoryAllocationLib and for your normal Craptio fw, use the fixup lib. That is just one of many possible usecases.

 

Clover has duplicated many libraries from EDK2 because the EDK team refuses to fix bugs that are reported to them.

 

Idk what/how you are reporting, but literally every single patch I ever submited, which was not faulty, got merged, no single exception. This includes bug fixes, new code and oh-so-minor compiler improvements in form of conditional directives.

 

I don't know what you mean by loss of ability to combine drivers via DSC

 

You can include a driver's inf in a platform dsc file... if you now include other driver's infs in curly braces relative to the first driver, they will be consumed by the first, i.e. the first driver's EP gets called and then the ones of the 'child ones'. This lets you merges all Clover v3 modules into one, if wished, without adding any kind of 'merge module', maintainance work or whatever.

 

or what FDF has to do with anything. Clover 3 will have no legacy support. Those things are not needed at all.

 

Neither dsc, nor fdf have anything remotely to do with legacy. FDF is the describes the flash file, which is supposed to go onto the Flash Chip (or into the DUET file...). When building one's own fw, one could include the Clover v3 modules via the FDF, if it had an EDK2 inf, without any scripting magic.

 

I don't even understand what you mean by this. You mean modifying firmware? What's the difference if you have to replace one driver with ten? Still works right? Yeah...

 

Keeping the modules separate doesn't give you the ability to make them depend on each other statically, which would lower the risk for a Clover v2 v2 dramatically. If you plan to properly support the Apple protocols, you draw no benefit from having one driver to do several tasks.

 

This is kind of what I was talking about, but I don't want to load macOS stuff when I'm booting windows or linux, and vice versa. It's a waste of resources and I don't know what you mean by terrible mess, seems pretty easy to me. As I said you can load the drivers and they will install protocols so if you want to put it in the firmware you can, but also there will be a stub to only load them on demand.

 

How does that work when the drivers are placed in a FV? You would literally have to build a 'Clover v3 core module' that locates and decodes a proprietary Freeform file from the FV (which ofc requires UEFI PI compliance, which might be safe to assume nowadays, but is not amazingly great practice considering the specs are rightfully separate) and loads the drivers based on... what? Want an own file (with an own GUID) per OS (in case you plan to support multiple OSes, which cannot hurt)? On the HDD, want own folder names? What if a driver needs to do stuff on init and when macOS boots? You need an event there anyway, so what is the exact benefit of loading on demand? Right, you save a handful of KB which get scrapped a few milliseconds later. Furthermore remember, these modules will depend on your 'Clover v3 core module' and will misbehave when not loaded by it, which is not a great scenario in an UEFI environment.

 

I'm thinking about all this trash that gets left behind that no one seems to think matters but I know it does and I can even see in windows and linux that my system memory usage is much higher if I boot through clover compared to from the firmware menu.

 

Fix the problem by the root then and cut BS_data and BS_code from the memory map on GetMemoryMap().

[apianti]

Sounds good with GUI, means responsive theme (vector)? But, "No Legacy support"..? Uhmmb.. 

 

Yes, I'm sure you're aware because you make a bunch but the themes are a disaster. There were some mistakes, then I made more in trying to redesign it. The biggest problem is the difference screen size affects a theme, it could look nice, or like complete garbage based on your resolution. That's a pretty blatant {censored} bug. Vector graphics resize well, so should be the method of choice for drawing. Though I'm sure some static sized elements can't be helped. Also I was thinking about allowing themes to have scripting for cooler effects and stuff. Another is I was going to attempt to write an opentype font renderer, which would allow for different sized fonts, colors, style, and most importantly full character sets, lol. No more trying to make those little ridiculous font maps like it came from super nintendo games, hahahaha.

 

What I mean by no legacy support is that I will not be writing a legacy firmware, clover 2 already has legacy firmware. That firmware (or any other legacy emulation firmware) can be installed and used to launch clover 3. No point in rewriting the firmware since it works. Most likely clover 2 will either become legacy emulation firmware only or split into two branches, one firmware and GUI still, the other just firmware. Or maybe not, who knows.....

[Badruzeus]

Yes, I'm sure you're aware because you make a bunch but the themes are a disaster. There were some mistakes, then I made more in trying to redesign it. The biggest problem is the difference screen size affects a theme, it could look nice, or like complete garbage based on your resolution. That's a pretty blatant {censored} bug. Vector graphics resize well, so should be the method of choice for drawing. Though I'm sure some static sized elements can't be helped. Also I was thinking about allowing themes to have scripting for cooler effects and stuff. Another is I was going to attempt to write an opentype font renderer, which would allow for different sized fonts, colors, style, and most importantly full character sets, lol. No more trying to make those little ridiculous font maps like it came from super nintendo games, hahahaha.

NP, I started the design from vector based, I love it bcoz it was simpler (I think), and even a free Inkscape.app did the job.   Something new has to be learned then, though I could only follow the guides for it. Thanks anyway @apianti.

[magnifico]

 Clover 3 will have no legacy support. Those things are not needed at all.

 

 

    Good Idea 

 

The future has already been UEFI bios for many years, the Legacy is very obsolete .   

[nms]

Official 

Create makefile with one line

./ebuild.sh -t XCODE8

Well, (-; this is the war of citations? (-;

 

There is also a UDK2017 branch in github which is useful if developers want to track critical bug fixes that are made after the official release: https://github.com/tianocore/edk2/tree/UDK2017

[apianti]

"EDK2" is not a dependecy, it is more of a toolcahin shim. You consume LibraryClasses, which aren't giant, depending on which you refer to. LibraryClasses enable you to write true non-agbostic code, by shimming everything that might be different for a certain build. Do you want to explicitely allocate over 4GB (which would require you to get the memory map on each allocation call as UEFI has no other way than AllocateAddress to ensure you get what you want), when the base firmware does so anyway? That can be eliminated by LibraryClasses. For proper UEFI firmware, use the default EDK2 UefiMemoryAllocationLib and for your normal Craptio fw, use the fixup lib. That is just one of many possible usecases.

 

Anything that is relied on outside of your project is a dependency. I'm not writing anything that is platform specific, these have all been provided already through protocols from the firmware. Once again, not building firmware. Actually not sure what you mean but I've already solved that problem of the memory, I can't really prevent other stuff from allocate pages where it wants. But overriding AllocatePool and managing memory instead by allocating pages high up and serving from those pages, also allows to keep track of memory leaks. I've written my own libraries and they should be good for all uses, since it's not producing the protocols, they are being consumed.

 

Idk what/how you are reporting, but literally every single patch I ever submited, which was not faulty, got merged, no single exception. This includes bug fixes, new code and oh-so-minor compiler improvements in form of conditional directives.

 

I've reported several bugs, some of which they actually just removed the feature instead of fixing the bug. Like using macros in build files. I just stopped trying...

 

You can include a driver's inf in a platform dsc file... if you now include other driver's infs in curly braces relative to the first driver, they will be consumed by the first, i.e. the first driver's EP gets called and then the ones of the 'child ones'. This lets you merges all Clover v3 modules into one, if wished, without adding any kind of 'merge module', maintainance work or whatever.

 

I don't see how this is any different than any other build system. I also just don't like the EDK2 build system.

 

Neither dsc, nor fdf have anything remotely to do with legacy. FDF is the describes the flash file, which is supposed to go onto the Flash Chip (or into the DUET file...). When building one's own fw, one could include the Clover v3 modules via the FDF, if it had an EDK2 inf, without any scripting magic.

 

I already said I do not care about building firmware. You could still do this, get the built modules and include them just like the hfsplus.efi driver. And clover2 is still around doing exactly this, maybe it gets modified to be only firmware based and you can pull clover3 in or something, idk....

 

Keeping the modules separate doesn't give you the ability to make them depend on each other statically, which would lower the risk for a Clover v2 v2 dramatically. If you plan to properly support the Apple protocols, you draw no benefit from having one driver to do several tasks.

 

I had no plans on making only one driver to do everything. I said that it would be broken up. That's a large problem with clover2, it has a huge chunk of it's stuff built into the GUI and you must have it whether you need or want the feature or not.

 

 

How does that work when the drivers are placed in a FV? You would literally have to build a 'Clover v3 core module' that locates and decodes a proprietary Freeform file from the FV (which ofc requires UEFI PI compliance, which might be safe to assume nowadays, but is not amazingly great practice considering the specs are rightfully separate) and loads the drivers based on... what? Want an own file (with an own GUID) per OS (in case you plan to support multiple OSes, which cannot hurt)? On the HDD, want own folder names? What if a driver needs to do stuff on init and when macOS boots? You need an event there anyway, so what is the exact benefit of loading on demand? Right, you save a handful of KB which get scrapped a few milliseconds later. Furthermore remember, these modules will depend on your 'Clover v3 core module' and will misbehave when not loaded by it, which is not a great scenario in an UEFI environment.

 

No you misunderstand. The drivers themselves are perfectly functional, they can be loaded into the FV and work, they won't attempt to load anything. But when booted from disk there will be a shim, that waits until these drivers are needed then loads them - the shim won't function in the FV because it won't be able to find a file system protocol on it's loaded image device handle. There is no core module, it's protocols, and the protocol is in a library, if it's not found it's installed. The big difference is that if I don't boot macOS they are not loaded, and IDK what you mean by few KB but its probably more like MBs. I've already thought about all this stuff you are saying and they are not issues, they have solutions.

 

 

Fix the problem by the root then and cut BS_data and BS_code from the memory map on GetMemoryMap().

 

Boot services code and data are freed at exit boot services, the problem is the loader code and loader data which are not. And of course everything is dynamically allocated as loader data, and clover is allocated in loader code area. Not very much of this memory is freed.

 

And in case you were wondering what I meant about EDK2 being massive and a nightmare, it takes forever to pull and this is without touching, right after:

[mhaeuser]

Anything that is relied on outside of your project is a dependency.

 

 

I was talking about EDK2 as a whole. The actual dependencies are the LibraryClasses you consume, because the rest is either build system or not a dependency as it's not consumed.

 

But overriding AllocatePool and managing memory instead by allocating pages high up and serving from those pages, also allows to keep track of memory leaks. I've written my own libraries and they should be good for all uses, since it's not producing the protocols, they are being consumed.

 

 

So you literally replace Boot Services? Interesting...

 

I don't see how this is any different than any other build system. I also just don't like the EDK2 build system.

 

 

How do you merge two separate drivers into a single one with VS?

 

I had no plans on making only one driver to do everything. I said that it would be broken up. That's a large problem with clover2, it has a huge chunk of it's stuff built into the GUI and you must have it whether you need or want the feature or not.

 

When one driver caln replace ten, I am indeed worried...

 

 

the problem is the loader code and loader data which are not. And of course everything is dynamically allocated as loader data, and clover is allocated in loader code area.

 

Oh, I forgot. Well, don't alloc LoaderCode/Data then?

 

 

And in case you were wondering what I meant about EDK2 being massive and a nightmare, it takes forever to pull and this is without touching, right after:

 

How often do you pull a fresh EDK2? ;P

[apianti]

I was talking about EDK2 as a whole. The actual dependencies are the LibraryClasses you consume, because the rest is either build system or not a dependency as it's not consumed.

 

I understand your point of view but I was referring to external project dependencies, meaning relying on outside code. I want to be able to just pull the code for clover and build it. Nothing else.

 

So you literally replace Boot Services? Interesting...

 

Yeah, see no reason why not, only the pages are stored in memory map. There is no harm in replacing the pool allocation and free methods with a different ones.

 

 

How do you merge two separate drivers into a single one with VS?

 

I don't know what you mean, build it differently? Or use ILMerge or something else similar. Also probably never going to do that.....

 

 

When one driver caln replace ten, I am indeed worried...

 

No, lol, I said that the other way around, that you could replace one driver with ten if needed. There doesn't need to be a one to one module replacement.

 

 

Oh, I forgot. Well, don't alloc LoaderCode/Data then?

 

It's the default allocation method for applications in EDK2. An EFI application is always loader code, plus it needs to be since we still want some stuff around after exit boot services. Cleaning up after allocations is probably a much better choice, and maybe only allocating loader data when it must be used. Don't want to go back through and fix allocations or garbage collect in clover2. There's no point.

 

How often do you pull a fresh EDK2? ;P

 

More often than I care to admit, haha. But even still just pulling updates takes a few minutes sometimes and I'm rarely far behind.

[mhaeuser]

Yeah, see no reason why not, only the pages are stored in memory map. There is no harm in replacing the pool allocation and free methods with a different ones.

Well, *Pages and GetNemoryMap too, otherwise you'll be out of sync.

 

I don't know what you mean, build it differently? Or use ILMerge or something else similar.

ILMerge is for .NET, but that's the idea, yeah.

 

No, lol, I said that the other way around, that you could replace one driver with ten if needed. There doesn't need to be a one to one module replacement.

Ohh, I said to replace Clover's with Apple's, so ur message sounded like more Apple drivers than Clover ones... Yeah, though I don't know a single Apple module that could just be split, so it's 1:1 either way.

 

It's the default allocation method for applications in EDK2. An EFI application is always loader code, plus it needs to be since we still want some stuff around after exit boot services. Cleaning up after allocations is probably a much better choice, and maybe only allocating loader data when it must be used. Don't want to go back through and fix allocations or garbage collect in clover2. There's no point.

What except for AptioFix needs to survive ExitBS? Dont know anything tbh. And yeah, forget v2

 

More often than I care to admit, haha. But even still just pulling updates takes a few minutes sometimes and I'm rarely far behind.

Guess having EDK2 on a HDD separate from the OS, a i7-3770 and 50MBit/s spoiled me? ;P No update ever even remotely reached 10s.

[apianti]

Well, *Pages and GetNemoryMap too, otherwise you'll be out of sync.

 

I'm using those, why would it be out of sync? I'm using those to allocate the pool memory, as high as possible with AllocateMaxAddress and the address set to 0xFFFFFFFFFFFFFFFF to begin.

 

ILMerge is for .NET, but that's the idea, yeah.

 

Yeah, brain fart, wasn't thinking. Is there a tool that does that in EDK2 base tools? Cause then you can just use that.... I also don't see why you want to merge modules though.

 

Ohh, I said to replace Clover's with Apple's, so ur message sounded like more Apple drivers than Clover ones... Yeah, though I don't know a single Apple module that could just be split, so it's 1:1 either way.

 

I thought you meant firmware modules, but I have no idea man. I'm not going to be going crazy making unnecessary modules just so there's two hundred of them, lol.

 

What except for AptioFix needs to survive ExitBS? Dont know anything tbh. And yeah, forget v2

 

I think that is a runtime driver. I'm not exactly sure what needs to survive and what doesn't, that was kinda my point. But I'd definitely like it to be as little as possible. Plus good memory management is better anyway.

 

Guess having EDK2 on a HDD separate from the OS, a i7-3770 and 50MBit/s spoiled me? ;P No update ever even remotely reached 10s.

 

I have it on a separate SSD, an overclocked i5-2500K, 16GB overclocked RAM and 100Mbps internet.......... I wish I ever saw below or close to 10s....

 

EDIT: Clover2 builds faster than it takes to pull both EDK2 and clover2....

[mhaeuser]

I'm using those, why would it be out of sync? I'm using those to allocate the pool memory, as high as possible with AllocateMaxAddress and the address set to 0xFFFFFFFFFFFFFFFF to begin.

 

Not reliable, all that guarantees is that it won't exceed that address, it doesn't guarantee that it will be the highest address range available below that point

 

Yeah, brain fart, wasn't thinking. Is there a tool that does that in EDK2 base tools? Cause then you can just use that.... I also don't see why you want to merge modules though.

 

It's not a tool, it's done pre-compile. You save space because static libraries are only present once.

 

I have it on a separate SSD, an overclocked i5-2500K, 16GB overclocked RAM and 100Mbps internet.......... I wish I ever saw below or close to 10s....

 

EDIT: Clover2 builds faster than it takes to pull both EDK2 and clover2....

 

lol, pull as in "git pull", so only the diff from the revs newer than yours ;p

[apianti]

Not reliable, all that guarantees is that it won't exceed that address, it doesn't guarantee that it will be the highest address range available below that point

 

Seems to be that's what it does in the three firmwares I've run it on. Although, yes I guess you are correct that it doesn't guarantee to be the highest by the spec, just that the entire region is below that address. Oh well, I'll just change it to find the highest region available from the memory map and use AllocateAddress instead.

 

 

It's not a tool, it's done pre-compile. You save space because static libraries are only present once.

 

So, how can this not be done in VS? Seems like it could be easily done, create libraries for the modules and then create modules that use them...

 

 

lol, pull as in "git pull", so only the diff from the revs newer than yours ;p

 

Yes, I'm referring to that as well, that's what pull does. If you don't have anything it's still pulling changes, just all of them. Maybe you just have a better route over the internets, maybe I have more hops to get to the server or something.... Who knows, but I don't want to deal with EDK2 anymore. Especially since it's kinda easier to make modules without it....

 

EDIT: Oh yeah, and without EDK2 you can use C++ (you still need some C for the interaction with the spec), but it's pretty cool. Granted there is no CRT, so you have to be careful about not creating globals and also you need to override new, new[], delete, and delete[] operators to allocate from pool memory.

EDIT2: After some thought it is probably possible to look at the code for the CRT for VS and GCC and build a library that performs these functions and then C++ would probably work almost fully. I know there are some things that wouldn't still though, most of that stuff can be disabled and ignored though.

[smolderas]

    Good Idea 

 

The future has already been UEFI bios for many years, the Legacy is very obsolete .   

It's dead on arrival then...

[magnifico]

It's dead on arrival then...

what dead ? 

[smolderas]

what dead ? 

Dropping legacy support...

[apianti]

It's dead on arrival then...

 

What's dead on arrival? There is no legacy emulation firmware, you can still get another legacy emulation firmware for legacy (like clover2) to use clover3.

 

what dead ? 

 

Good question.

 

Dropping legacy support...

 

No reason to support legacy firmware, this is an EFI boot loader, there are other ways to get EFI firmware emulation for legacy. This is about EFI from now on, older computers can get an emulation firmware. Newer computers will have EFI, maybe there's probably some company that sucks out there still trying to sell legacy mobos. But since my computer takes less than five seconds to shutdown, restart, and be back at desktop, and the legacy machine sitting over there takes like three minutes just to boot, I don't see why legacy firmwares would still be produced.

[bronxteck]

intel is dropping/ depreciating BIOS support from UEFI spec in 2020. they support edk so its just a matter of time before it trickles down. if your hardware does not have EFI rom options then it will not be supported any longer that means most hardware manufactured before 2012. that does not mean apple will comply though since they like using "proven hardware" (aka old stuff they can make a big profit on) for new "innovations"

[Slice]

 

Something in KextPatch changed (I guess in commit 4305)

now this patch doesn't work (doesn't even appear in debug mode)

it's inside  IO80211Family.kext

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Comment</key>
<string>Wi-Fi Region to 0x64</string>
<key>Disabled</key>
<false/>
<key>Find</key>
<data>D7eH3AQAAA==</data>
<key>Name</key>
<string>AirPortAtheros40</string>
<key>Replace</key>
<data>uGQAAACQkA==</data>
</dict>
</plist>

 

Because Bundle Indentifier is

com.apple.driver.AirPort.Atheros40

as well for Broadcom

com.apple.driver.AirPort.Brcm4360

Previously it works because Clover searched the name through the whole Info.plist. But it leads to bug of patching dependencies kexts.

It is better to correct this two patches.

[Slice]

 Themes will probably be radically different, SVG support, and actual font support.

It will be very good. Just hard to do.

. Clover 3 will have no legacy support.

Agree. As well as no 32bit support.

I also may propose exclude huge list of videocards names. Let it be common name or user defined.

[Badruzeus]

Because Bundle Indentifier is

com.apple.driver.AirPort.Atheros40

as well for Broadcom

com.apple.driver.AirPort.Brcm4360

Previously it works because Clover searched the name through the whole Info.plist. But it leads to bug of patching dependencies kexts.

It is better to correct this two patches.

Thanks @Slice, it works for my AR928x under 10.11.6 (15G18013) with Clover r4323 after..

mv AirPortAtheros40 com.apple.driver.AirPort.Atheros40

Now, I no longer get issue with "ATHR: unknown locale xx" messages as seen on..

$ cat /private/var/log/system.log | grep ATHR

[RehabMan]

Probably better, yes.

 

I don't mind the change, but you may want to give a heads up in Clover Change Explanations, as it can introduce quirky behavior for custom SSDT users.

 

For instance I've Clover replace GFX0 → IGPU, followed by PEGP → GFX0… but in my AMD SSDT I already had device defined as GFX0, thus it became IGPU. Easy fix though once I realized what was going on.

 

 

Nah… I don't think we want special config parameters for myriad possible use cases. Keep it simple.

Please attach your EFI/Clover (as ZIP, don't forget to press F4 to generate ACPI/origin), without themes and Clover bootlog.

I'd like to see your setup and what is in your XSDT.

If your XSDT has NULL values in it, I can see where the current Clover will give you some unexpected results.

I am working on a significant cleanup to AcpiPatcher.c that will restore the old behavior for NULL entries (and fix some bugs in it), but it would be great to see an ACPI set that actually contains this NULL data.

 

Unless you have AutoMerge=true, any SSDTs you have in ACPI/patched should not be subject to config.plist/ACPI/DSDT/Patches.

But with a mergeable file in ACPI/patched, and AutoMerge=true, the game changes quite a bit (by design).

[smolderas]

Because Bundle Indentifier is

com.apple.driver.AirPort.Atheros40

as well for Broadcom

com.apple.driver.AirPort.Brcm4360

Previously it works because Clover searched the name through the whole Info.plist. But it leads to bug of patching dependencies kexts.

It is better to correct this two patches.

Hi Slice,

 

I have the same problem with following patch:

<key>KextsToPatch</key>
		<array>
			<dict>
				<key>Comment</key>
				<string>Boot graphics glitch, 10.13 beta (based on denskop patch)</string>
				<key>MatchOS</key>
				<string>10.13.x</string>
				<key>Disabled</key>
				<false/>
				<key>Name</key>
				<string>com.apple.iokit.IOGraphicsFamily</string>
				<key>Find</key>
				<data>AQAAdSI=</data>
				<key>Replace</key>
				<data>AQAA6yI=</data>
			</dict>
		</array>

The bundle identifier is:

plutil -p /System/Library/Extensions/IOGraphicsFamily.kext/Info.plist |grep BundleIdentifier|sort -u
      "CFBundleIdentifier" => "com.apple.iokit.IOGraphicsFamily"