Jump to content
1059 posts in this topic

Recommended Posts

21 hours ago, Allan said:

@headkaze how are you?

 

I'm using the Lenovo Gamming 3i as my main Hackintoh, and it's screen resolution is 1920x1080, but all the itens is soo terrible small.


And I wanna use Hackintool to add more resolution options, but before that I want to understand the options available at the app, such as:

 

  • HiDPI 1, 2 and etc...
  • Non Scaled
  • Auto

Wich I need to use?


I've made some tests, and add the .kext generated by the Hackintool with OpenCore, but after a reboot, the options that I want won't appears.

 

Thank you 😃

I believe the structure of each item in the scale-resolutions array is described in Apple open source IOKitUser/IOKitUser-1445.71.1/graphics.subproj/IOGraphicsLib.c

The latest version of this source file is for macOS 10.13.16 but I think IOGraphicsLib was replaced by CoreDisplay.framework (or it is part of CoreDisplay.framework now). Anyway, it might not be the latest info.

The structure can be Number or Data.

 

Number (32 bit): v << 16 | h.

 

Data (between one and five 32 bit numbers) : h, v, flags, setModeFlags, clrModeFlags

 

Only h is required. If v is zero or not specified then it is calculated from h using the native aspect ratio of the display.

 

flags can be one of these:

    // skips all the various checks and always installs
    kScaleInstallAlways         = 0x00000001,
    // disables the install of a stretched version if the aspect is different
    kScaleInstallNoStretch      = 0x00000002,
    // install resolution untransformed
    kScaleInstallNoResTransform = 0x00000004,
    // install resolution on mirror dependents of this display
    kScaleInstallMirrorDeps     = 0x00000008

setModeFlags and clrModeFlags can be any of these:
 

    kDisplayModeValidFlag               = 0x00000001,
    kDisplayModeSafeFlag                = 0x00000002,
    kDisplayModeDefaultFlag             = 0x00000004

    kDisplayModeSafetyFlags             = 0x00000007,

    kDisplayModeAlwaysShowFlag          = 0x00000008,
    kDisplayModeNeverShowFlag           = 0x00000080,
    kDisplayModeNotResizeFlag           = 0x00000010,
    kDisplayModeRequiresPanFlag         = 0x00000020,
    kDisplayModeInterlacedFlag          = 0x00000040,
    kDisplayModeSimulscanFlag           = 0x00000100,
    kDisplayModeBuiltInFlag             = 0x00000400,
    kDisplayModeNotPresetFlag           = 0x00000200,
    kDisplayModeStretchedFlag           = 0x00000800,
    kDisplayModeNotGraphicsQualityFlag  = 0x00001000,
    kDisplayModeValidateAgainstDisplay  = 0x00002000,
    kDisplayModeTelevisionFlag          = 0x00100000,
    kDisplayModeValidForMirroringFlag   = 0x00200000,
    kDisplayModeAcceleratorBackedFlag   = 0x00400000,
    kDisplayModeValidForHiResFlag       = 0x00800000,
    kDisplayModeValidForAirPlayFlag     = 0x01000000,
    kDisplayModeNativeFlag              = 0x02000000

    kMirrorOnlyFlags = (kDisplayModeValidForMirroringFlag),
    kAddSafeFlags = (kDisplayModeValidFlag | kDisplayModeValidateAgainstDisplay)

The options shown in Hackintool are probably supposed to be various combos of the above flags.

 

The Hackintool source code has this comment:

// https://comsysto.github.io/Display-Override-PropertyList-File-Parser-and-Generator-with-HiDPI-Support-For-Scaled-Resolutions/
// https://gist.github.com/ejdyksen/8302862
// https://github.com/xzhih/one-key-hidpi
// ---------------------------------------------
// 1. 1080p Display
//    - HiDPI1: 1920x1080 1680x945 1440x810 1280x720 1024x576
// 2. 2K Display
//    - HiDPI1: 2048x1152 1920x1080 1680x945 1440x810 1280x720
//    - HiDPI2: 1024x576
//    - HiDPI3: 960x540
//    - HiDPI4: 2048x1152
// 3. Manual Input Resolution
//    - Auto (HiDPI3 / HiDPI2)
// ---------------------------------------------
// - HiDPI2: 1280x720 960x540 640x360
// - HiDPI3: 840x472 720x405 640x360 576x324 512x288 420x234 400x225 320x180
// - HiDPI4: 1920x1080 1680x945 1440x810 1280x720 1024x576 960x540 640x360
// ---------------------------------------------
// - NonScaled: <xxxxxxxx yyyyyyyy>
// - HiDPI1: <xxxxxxxx yyyyyyyy 00>
// - HiDPI2: <xxxxxxxx yyyyyyyy 00000001 00200000>
// - HiDPI3: <xxxxxxxx yyyyyyyy 00000001>
// - HiDPI4: <xxxxxxxx yyyyyyyy 00000009 00a00000>
// ---------------------------------------------

 

HiDPI1 seems strange since the last 32 bit number is only 8 bits.

 

The other numbers probably translate to these:

00000001 = kScaleInstallAlways
00000009 = kScaleInstallAlways | kScaleInstallMirrorDeps
00200000 = kDisplayModeValidForMirroringFlag
00a00000 = kDisplayModeValidForMirroringFlag | kDisplayModeValidForHiResFlag

Using this info, it seems like it would be best to always select HiDPI4.

 

SwitchResX appears to always use flags: kScaleInstallAlways, modeFlags: kDisplayModeValidForMirroringFlag which corresponds to HIDPI2.

 

Edited by joevt
  • Like 2
  • Thanks 1
1 hour ago, Allan said:

Look how it looks, and I hope it helps.

 

I was using the one-key-hidpi script by @xzhih, but I have problems with sleep.

 

1600x900

 

1920x1080

 

At Windows I feel more comfortable with 1080p, but at the macOS all the thing is much smaller.

I don't see how scaled modes can cause sleep issues but I rarely put my computer to sleep; just the display.

 

Have you tried using SwitchResX to create the 3200x1800 scaled mode? It should be able to give you the desired 1600x900 HiDPI mode.

SwitchResX uses the display override method instead of the kext method.

The display override goes in the /Library/Displays/Contents/Resources/Overrides/DisplayVendorID-x folder.

SwitchResX uses this naming format: DisplayYearManufacture-*-DisplayWeekManufacture-* 

instead of the usual naming format DisplayProductID-*

 

  • Like 3
  • Thanks 1

Wow! Man that's a perfect explanation, thank you so much

 

I've create the .kext with Hackintool and put it on OC/kext folder + address it on config.plist, but nothing changes at the System Preferences > Displays

 

31 minutes ago, joevt said:

Have you tried using SwitchResX to create the 3200x1800 scaled mode? It should be able to give you the desired 1600x900 HiDPI mode.

Hmmm that's nice, I'll give it a try

  • Like 2
9 hours ago, Allan said:

Wow! Man that's a perfect explanation, thank you so much

 

I've create the .kext with Hackintool and put it on OC/kext folder + address it on config.plist, but nothing changes at the System Preferences > Displays

 

Hmmm that's nice, I'll give it a try

How was it specified in the config.plist? The kext doesn't have an executable. I've never tried the kext method. If it's loaded correctly, then the properties in the info.plist should appear in the IORegistry of all AppleDisplay class items. Hmm - I don't see how that can work properly when there are multiple displays - shouldn't there by some matching criteria in the info.plist? Or is that done by the IOProviderClass using the DisplayVendorID and DisplayProductID? I don't see any Apple open source code that describes this kext method. But you're saying it doesn't work for any display which is a different problem.

On 6/29/2022 at 10:43 PM, joevt said:

How was it specified in the config.plist?

Here is:

Screen Shot 2022-07-01 at 10.28.57.png

 

On 6/29/2022 at 10:43 PM, joevt said:

But you're saying it doesn't work for any display which is a different problem.

I'm using only for my built-in display.

On 7/1/2022 at 6:36 AM, Allan said:

In a nutshell something that I want is to increase/decrease scaling on macOS like Windows. :wacko:

 

Screen Shot 2022-07-01 at 10.34.32.png

 

 

The ability to choose arbitrary UI scaling factors in macOS was removed after Mac OS X 10.5. It's possible the code still exists in macOS, but I haven't tried making a patch to create a mode that is not 1x or 2x to test this.

 

Now you have to combine a UI scaling factor of 200% (per dimension) with an arbitrary resolution scale factor.

 

On the Windows side, you need to determine if the scale % that you want is referring to area (two dimensions) or length (single dimension) before you can translate this to macOS.

 

  • Like 2
  • Thanks 1
1 hour ago, LockDown said:

Does motherboad LGA775 ICH10 have 15-Port limit?

ICH10 doesn't support XHCI so it probably doesn't have 15 port limit.

ICH10 has multiple USB UHCI and EHCI controllers so while it can have more than 15 USB 1.1 or USB 2.0 ports, they are spread out among multiple USB controllers so that no single controller has more than 2 or 4 or 6 or 8 ports.

 

Intel® ICH10 Features

USB 2.0
— Six UHCI Host Controllers, supporting up to

    twelve external ports
— Two EHCI Host Controllers, supporting up

    to twelve external ports
— Two Configuration Options for EHCI

    Controllers 6+6 and 8+4
 

 

  • Like 2
  • Thanks 1
  • 5 months later...

I am using Hackintool 3.9.1 on multiple hacks without any issues.  It works great for me.  Most recently, I used Hackintool to generate USBPorts.kext for my HackBookPro6,2 (Dell Latitude E6410) here.  The resulting USBPorts.kext is attached to this post.  I am not having any USB functionality issues with my hack. I am only reporting this in case it helps to diagnose/debug issues with Hackintool.

 

When my hack is running macOS Big Sur and Monterey, Hackintool displays USBPorts as would be expected.  

Spoiler

1342890127_ScreenShot2022-12-05at4_59_46PM.thumb.png.d46d9c325c45f7af6c82642378bb60d0.png

 

However, when running Ventura 13.0.1, Hackintool displays only the USB Hubs EH01 and EH02 (none of the USB Ports):

Spoiler

2120397717_Screenshot2022-12-04at10_23_39AM.png.67605e6fc8034f7f19cf8f141ffcf08e.png

 

Despite this display issue in Hackintool, USB ports are working normally on my hack and USB ports are displayed as would be expected in IORegistryExplorer:

Spoiler

1201100712_Screenshot2022-12-04at10_26_47AM.png.32a931290287dfcd85c868aa08dd8a89.png

 

When a USB thumb drive is inserted into one of my hack's USB ports, the port status updates in IORegistry explorer, but Hackintool continues to show only the USB  hubs (even when Hackintool USB screen is manually cleared and refreshed.

 

Spoiler

1481781348_Screenshot2022-12-04at10_28_31AM.png.0c419de15fc9c57c1f5426b2edf8ca7c.png

 

I am only observing this Hackintool USB display issue when running Ventura.  This issue does not occur when running Big Sur and Monterey.  This is not a problem for me - I'm only reporting in case this helps @headkaze diagnose/debug issues.  

 

Thank you for a great tool, @headkaze!

USBPorts.kext.zip

Edited by deeveedee
Added screenshot of Hackintool USB listing in Big Sur
  • Like 2
1 hour ago, deeveedee said:

When a USB thumb drive is inserted into one of my hack's USB ports, the port status updates in IORegistry explorer, but Hackintool continues to show only the USB  hubs (even when Hackintool USB screen is manually cleared and refreshed.

I can only suspect yet another means of reading/enumerating the ports on Ventura that Hackintool hasn't caught up yet...

What is important @deeveedee is that the generated USBPorts (on Monterey I assume, and you kept using it) is working on Ventura OS well.

Could that be it @headkaze?  (and thanks from me too, once more, for the great tool!)

  • Like 1

@MacKonsti I ran Hackintool in Big Sur to generate USBPorts.kext.  It was a little tricky, because the Internal Port Type 255 works only for the Hub.  Assigning Internal Port Type 255 to any of the USB ports (children of the Hub) would break USB patching.  I had to go back to a Rehabman post (not sure which one) which assigned Port Type 2.  Note in my USBPorts.kext/Contents/Info.plist that the Hub uses UsbConnector while the Ports use PortType.

Edited by deeveedee
  • Like 1
  • Thanks 1

I used Hackintool 3.9.1 to assist with my installation of VoodooHDA.kext 2.9.8 in Big Sur (OC 0.8.7) as described here.  After installation of VoodooHDA.kext 2.9.8 and rebooting my hack, sound is working perfectly with internal laptop speakers.  However, when I attempt to view audio properties (Pin Configuration and Audio info) with Hackintool, audio properties are not displayed.  Hackintool did display audio properties when I was using AppleALC.  Is this intentional?  It's not a problem for me - just curious.

 

Hackintool 3.9.1 audio properties when using VoodooHDA.kext

Spoiler

1476172838_ScreenShot2022-12-07at2_47_35PM.png.d100f0da5df45bf88b0b88201e87b7b4.png

 

Hi @deeveedee I can suspect that the IORegistry is not created the same way when VoodooHDA is used thus Hackintool may not detect the right branches or devices etc. But as you say, I am also curious to know, if it was ever attempted to code it to detect VoodooHDA (not used as much as AppleALC I guess?)
Why don't you post a screenshot of your IORegistry Explorer or better, a sanitised export of IORegistryExplorer (without S/Ns if possible?) so that @headkaze can comment?  (just a tip ;) )

11 hours ago, deeveedee said:

I used Hackintool 3.9.1 to assist with my installation of VoodooHDA.kext 2.9.8 in Big Sur (OC 0.8.7) as described here.  After installation of VoodooHDA.kext 2.9.8 and rebooting my hack, sound is working perfectly with internal laptop speakers.  However, when I attempt to view audio properties (Pin Configuration and Audio info) with Hackintool, audio properties are not displayed.  Hackintool did display audio properties when I was using AppleALC.  Is this intentional?  It's not a problem for me - just curious.

 

Hackintool 3.9.1 audio properties when using VoodooHDA.kext

  Reveal hidden contents

 

I already reported to @headkaze that Hackintool will not see VoodooHDA.

  • Like 1
  • Thanks 2
On 12/7/2022 at 3:06 PM, MacKonsti said:

Why don't you post a screenshot of your IORegistry Explorer or better, a sanitised export of IORegistryExplorer (without S/Ns if possible?) so that @headkaze can comment?  (just a tip ;) )

 

I've never thought about sanitizing my posted IORegistry Explorer dumps before.  Where in IORegistry Explorer dumps do the S/Ns appear?  Thanks!

@Slice and @MacKonsti - I've never thought to sanitize my IOReg dump before posting.  Is there an easy way to remove the private parameters without corrupting the file?

 

EDIT: I am using IORegistry Explorer Version 2.1.

Edited by deeveedee
1 hour ago, deeveedee said:

@Slice and @MacKonsti - I've never thought to sanitize my IOReg dump before posting.  Is there an easy way to remove the private parameters without corrupting the file?

 

EDIT: I am using IORegistry Explorer Version 2.1.

There is other way to dump IOReg by using DarwinDumper. It has the privatize ability.

  • Like 3
  • Thanks 1
  • 1 month later...
On 12/5/2022 at 8:29 AM, deeveedee said:

@MacKonsti I ran Hackintool in Big Sur to generate USBPorts.kext.  It was a little tricky, because the Internal Port Type 255 works only for the Hub.  Assigning Internal Port Type 255 to any of the USB ports (children of the Hub) would break USB patching.  I had to go back to a Rehabman post (not sure which one) which assigned Port Type 2.  Note in my USBPorts.kext/Contents/Info.plist that the Hub uses UsbConnector while the Ports use PortType.

 

FYI ... I have continued to experiment with USB mapping on my HackBookPro6,2 (which is using Open Core 0.8.8 to boot Big Sur, Monterey and Ventura - all running extremely well) and have posted my latest observations here.  The USB maps generated by Open Core Legacy Patcher (OCLP) use property UsbConnector to define connector types for USB hubs and OCLP-generated USB maps use property PortType to define connector types for USB ports that are children of hubs.  I have experimented with both UsbConnector and PortType to define child-port connector types and don't see any behavioral difference.  My USB ports work just as well with both techniques.

  • 3 months later...

When running macOS Ventura on my HackBookPro6,2, Hackintool shows only my USB Hubs (no child ports) when first clicking the USB tab.

 

Only USB Hubs visible when first clicking USB Tab

Spoiler

1529042656_Screenshot2023-06-02at7_30_16AM.png.4430e3ce6b4e58fceeeccaacd01f7ee3.png

 

Clicking the Inject button shows the child ports for each hub

 

Inject Button

Spoiler

812695144_Screenshot2023-06-02at7_31_49AM.png.801102ac44d935385df8b1cfaf378bc8.png

 

After clicking Inject Button, all child USB ports are visible (not just Hubs)

Spoiler

169692617_Screenshot2023-06-02at7_41_22AM.png.d0a0c855f1f9b3e17e22c582ac5fdf2d.png

 

In previous versions of macOS (Monterey and earlier), Hackintool's USB tab shows hubs and child ports when the USB tab is first clicked (no need to click the Inject button to show the child ports). 

Edited by deeveedee
  • Like 2
3 hours ago, deeveedee said:

When running macOS Ventura on my HackBookPro6,2, Hackintool shows only my USB Hubs (no child ports) when first clicking the USB tab.

 

Only USB Hubs visible when first clicking USB Tab

  Hide contents

1529042656_Screenshot2023-06-02at7_30_16AM.png.4430e3ce6b4e58fceeeccaacd01f7ee3.png

 

Clicking the Inject button shows the child ports for each hub

 

Inject Button

  Hide contents

812695144_Screenshot2023-06-02at7_31_49AM.png.801102ac44d935385df8b1cfaf378bc8.png

 

After clicking Inject Button, all child USB ports are visible (not just Hubs)

  Hide contents

169692617_Screenshot2023-06-02at7_41_22AM.png.d0a0c855f1f9b3e17e22c582ac5fdf2d.png

 

In previous versions of macOS (Monterey and earlier), Hackintool's USB tab shows hubs and child ports when the USB tab is first clicked (no need to click the Inject button to show the child ports). 

Does it have USB 3.0 super speed port, or they are just High speed?

1 hour ago, ichelash said:

Does it have USB 3.0 super speed port, or they are just High speed?

Are you asking about my 2010 Dell Latitude E6410?  If so, the ports are USB 2.0.  But you made me look it up - I see that USB 3.0 was released in 2008, so it looks like Dell decided not to adopt the USB 3.0 standard for my laptop.

Edited by deeveedee
  • Like 1
  • 1 year later...

Hello @ll,

how can Kext drivers and other system extensions be installed in /System/Library/Extensions (S/L/E) on macOS Sequoia?

I am looking for a secure method to install Kext drivers (Kernel Extensions) as well as other types of system extensions, such as .bundle files, on macOS Sequoia. The reason I cannot use the current version of Hackintool is that this tool exclusively allows moving Kext files to the /System/Library directory. It does not support the relocation or installation of other system extensions. 

Unfortunately, this is insufficient for my specific requirements, as I need to install these extensions in `/System/Library/Extensions` (S/L/E). 

If anyone has useful instructions or detailed guidance that meets these requirements, I would be very grateful for your support. 

Attempts to bypass write protection using terminal commands or by disabling System Integrity Protection (SIP) and the Gatekeeper have unfortunately failed in my case. 

A better alternative would be if a future version of Hackintool could meet the requirements described above. 

 

  • Like 2
×
×
  • Create New...