compilation and usage

[zohaad]

Do I compile with the debug version of Lilu.kext and install the kext in the same directory as the Lilu.kext release version? Or can I use the debug version for both, what is recommended?

[PMheart]

Hi,

For normal use, just Lilu + CoreDisplayFixup (both RELEASE). For debugging purposes, simply use DEBUG binaries instead.

[zohaad]

Thanks for the clarification, apparently I still can't get it compiled correctly for High Sierra, I get kernel panic:

as.vit9696.Lilu(1.2.2)[E650D28F-9633-3AA0-A938-35E22D295566]@0xffffff7f80b88000->0xffffff7f80bf1fff

[zohaad]

Also, why don't you include a pre-built kext?

[canyondust]

I also get kernel panic on boot (built with Lilu 1.2.1 for use with OSX 10.12.6)

[PMheart]

@zohaad As for compilation method, I have written something in README.

Note: Debug version of Lilu.kext should be put in the same folder as CoreDisplayFixup! And they should also be used together!

I did release something in the release page, please check it out here.

@canyondust I don't think I'm the correct one to be asked for this. You may consider opening an issue directly to Lilu.

[canyondust]

Sorry, I should clarify: Lilu is working fine, I get a kernel panic when booting with CDF (which I compiled from current commit (1.3.3) with Lilu 1.2.1 debug) :)

[PMheart]

@canyondust Sorry for the misunderstanding, could you please post more details?

[zohaad]

I tried it with both pre built release kexts, same error:

It pauses a bit at VM Swap Subsystem is ON and then spits the following out really quickly before showing which kexts have been loading and showing the kernel panic error message.

panic(cpu 0 caller 0xffffff0000388e21): Kernel trap at 0xffffff000049b040, type=page fault, registers:
CR0: 0x0000....

Backtrace (CPU 0), Frame : Return Address
....
    Kernel Extensions in backtrace:
        as.vit9696.Lilu(1.2.2)[E650D28F-9633-3AA0-A938-35E22D295566]@0xffffff7f80b88000->0xffffff7f80bf1fff

This data may be incorrect as it's hard to read from a video (used slow-motion mode to capture) with tiny letters at 3200x1800 at a quick speed. If you have ideas on how to capture this data (Clover's -v mode), please let me know.

[zohaad]

Forgot to mention my hardware: Lenovo Yoga 3 Pro with 3200x1800 screen and Core M-5Y70 processor with HD 5300 graphics

[canyondust]

6700K+GTX1080 here, here's a photo of the screen right before it auto-restarts.

[PMheart]

@zohaad @canyondust Could you please try DEBUG Lilu & CoreDisplayFixup binaries (You can download them here and here) And please boot with -v -liludbgall keepsyms=1 debug=0x100 and then upload the panic picture here. (Maybe even a video record for the whole progress I guess, which is better)

[zohaad]

The display moves really fast, I tried recording with slow-mo mode:

https://drive.google.com/file/d/1SDcR_ybsreitpSV7uk3yUWd1u5IvDeS7/view?usp=sharing https://drive.google.com/file/d/1ySqsf6NK5uvwH_4CYyWTK7yQBcGGXxE4/view?usp=sharing

[zohaad]

Somehow the problem has been resolved by updating to the latest version of macOS: 10.13.2

kextstat now shows CoreDisplayFixup loaded right after Lilu

[PMheart]

@zohaad Glad to hear that! @canyondust Any news?

[zohaad]

There is another issue with CoreDisplayFixup I believe, see picture attached.

Notable lines: VM Swap Subsystem is ON Then the screen flashes. I think windowserver crashes here, I may be wrong though. Lilu: file @ failed to find /System/Library/Frameworks/CoreGraphics.framework/Versions/A/Resources/WindowServer

Also:

Unsupported CPU for reporter

[PMheart]

It is expected because /System/Library/Frameworks/CoreGraphics.framework/Versions/A/Resources/WindowServer is for 10.10.x, and for your OS (maybe 10.13.x I guess?) it's simply missing.

Unfortunately I have no idea for now, have you tested my latest 1.3.4, by the way?

[PMheart]

Any news here?

[PMheart]

1.3.6 is out, which added 10.13.4+ compatibility, give it a try.

[PMheart]

Have not heard any news for a while. Issue closed. Feel free to reopen if there is any further report.