Jump to content
30960 posts in this topic

Recommended Posts

ha ha noooo  :lol:, your cpu heatsink will save you (quip). Well, but why you check for only 3 argument passed, the fourth is optional?

if [[ $# -lt 3 ]];then
    echo "Too few arguments. Aborting..." >&2 && exit 1
fi

isn't? My proposition is safe to mantain 3 required args w/o making additional vars but all set.

Yeah, I think I just made that clear by saying that the fourth argument is not set when you are building the full package.
 
EDIT: If you want to make it so theres no new variables you could just do
 

declare -r -i EXTRAPKG="${4}"

or
 

declare -r -i NOEXTRAS="${4}"

 
depending. But that will enforce that it's an integer, so there could still be passed weird values but only less than 1, 1, 2, and 3 or more would become effective values.

 

EDIT2: As I already said I think it's a much better idea to pass argument flags instead, since maybe someone wants themes but not the configurator or manager, or whatever...

 

EDIT3: I think you are confusing that using another variable is somehow more wasteful than another subshell. It most assuredly is not, since to make a subshell it creates an entire new environment.....

  • Like 1

 

 

EDIT2: As I already said I think it's a much better idea to pass argument flags instead, since maybe someone wants themes but not the configurator or manager, or whatever...

You mean parsing the input parameters with getopts or...?

 

 

Sent from my MI 5s using Tapatalk

 

EDIT: Who said EXTRAPKG should be definitely read-only? Just tested this version and it works like a charm. One variable only (EXTRAPKG), declare -i will make sure $4 is integer only and EXTRAPKG will be set to 0 if anything different from 1, 2 or 3 has been passed to the script as $4.

buildpkg.sh_ only_EXTRAPKG.zip

Still get kernel panic related with sklframebuffer

 

one idea: DVMTfixup worked for me. However, when I combined it AppleALC/Lilu I had issues. So I merged all the required SKLFramebuffer edits for Audio and DVMT (what DVMTfixup was doing) into AppleALC which then removes the need for extra kext DVMTFixup.

one idea: DVMTfixup worked for me. However, when I combined it AppleALC/Lilu I had issues. So I merged all the required SKLFramebuffer edits for Audio and DVMT (what DVMTfixup was doing) into AppleALC which then removes the need for extra kext DVMTFixup.

 

thanks

dvmt is only for users who can't change dvmt value, if it include in applealc, i think this is not correct.

 

what is your bootloader version? if there is your mentioned issue, i think that have to report lilu issue.

 

 

i recieved report that two users success boot(1916,191b)(not sure they use kext with applealc). 

 

also they not use r4061. fail case in r4061.

I tested DVMTFixup 21 days ago - so probably the 1.1.2 version. 

 

yes i can not change DVMT ...  Since I am using AppleALC which is already patching AppleIntelSKLGraphicsFrameBuffer - and I like the Info.plist way of adding patches - i just added the all the SKL FBpatches in there. formerly i was using Clover to patch AppleHDA and AppleIntelSKLGraphicsFrameBuffer - now Lilu does it all as defined by a modified AppleALC.

 

Clover 4076, 10.12.5

well it was DVMTFixup 1.1.1

however, i just download DVMTFixup1.1.3 , removed my custom AppleALC and it was not good - got SKL KP?

 

Same result I had.

New version is broken.

Lilu can't find the pattern, maybe because it is in data, not code.

Same result I had.

New version is broken.

Lilu can't find the pattern, maybe because it is in data, not code.

 

LOL - well on 2nd view 1.1.3 works-- but only after I looked at the code *and uncommented* the DVMT patches!!! not sure why these lines ( what seem to be the main purpose) is commented out in the code?

 

and good news didn't conflict with AppleALC.

You mean parsing the input parameters with getopts or...?

 

 

Sent from my MI 5s using Tapatalk

 

EDIT: Who said EXTRAPKG should be definitely read-only? Just tested this version and it works like a charm. One variable only (EXTRAPKG), declare -i will make sure $4 is integer only and EXTRAPKG will be set to 0 if anything different from 1, 2 or 3 has been passed to the script as $4.

 

Well there's a number of ways to parse arguments but yeah I think it works better if you make it options like "-no-themes", "-no-pref-panel", "-no-updater", "-no-scripts", "-no-firmware". Since these things really aren't related in anyway, I could not want firmware because I have UEFI but in order to do that with the way it works I would have to forgo having the four other features as well... And as for the readonly, that was Mickey, probably just a that's how the rest are declared thing....?

LOL - well on 2nd view 1.1.3 works-- but only after I looked at the code *and uncommented* the DVMT patches!!! not sure why these lines ( what seem to be the main purpose) is commented out in the code?

 

and good news didn't conflict with AppleALC.

 

The other patches were the old code (eg. disabling the assertion, instead of patching the framebuffer).

Patching the framebuffer is preferred and works fine with KextsToPatch, but Lilu can't deal with it...

Yes... code changed, release built... clearly without testing.

I just test other user. But some users report that fail boot(framebuffer panic).

 

If you want to change some or idea, i will do it.

Now, i cant test myself. Because my laptop release dmvt 64mb from factory

 

나의 LG-F410S 의 Tapatalk에서 보냄

I just test other user. But some users report that fail boot(framebuffer panic).

 

If you want to change some or idea, i will do it.

Now, i cant test myself. Because my laptop release dmvt 64mb from factory

 

나의 LG-F410S 의 Tapatalk에서 보냄

 

I think the code in IntelGraphicsDVMTFixup is sound.

Problem is in Lilu...

I will need more time to become familiar with the Lilu code.

 

For now, I'd rather use KextsToPatch.  It is simple and reliable.

  • Like 3

Well there's a number of ways to parse arguments but yeah I think it works better if you make it options like "-no-themes", "-no-pref-panel", "-no-updater", "-no-scripts", "-no-firmware". 

Hi, something like that?

#!/bin/bash

usage="-------------------------\n\
t = themes\n\
c = CloverThemeManager\n\
u = CloverUpdater\n\
p = Pref Panel\n\
o = only uefi\n\
r = rc scripts\n\
-------------------------"

while getopts "tcupor" o; do
    case "${o}" in
        t)
            echo "will include themes"
            ;;
        c)
            echo "will include CloverThemeManager"
            ;;
        u)
            echo "will include updater"
            ;;
        p)
            echo "will include Pref Panel"
            ;;
        o)
            echo "will be UEFI only"
            ;;
        r)
            echo "will include rc scripts"
            ;;
        *)
            clear
            printf $usage && exit 1
            ;;
    esac
done

call the script with -tcupor (to build everything), or remove options  to skip something. You can still use the makefile sending only one arg this way, I think.

sending nothing getopt will not be used, and vars previously set can determine the standard behavior

Edited by Allan
Code box added

I would prefer that the argument options were the negation, so the default, if nothing is passed, is to build everything - since this is the current behavior. Also you would need to do some kind of bookkeeping here that keeps track of which features were disabled/prevented from building into the package. Either using an array of disabled features, or variables for each disabled feature, the array is probably a better approach.

I think the code in IntelGraphicsDVMTFixup is sound.

Problem is in Lilu...

I will need more time to become familiar with the Lilu code.

 

For now, I'd rather use KextsToPatch.  It is simple and reliable.

 

well I put your new framebuffer patch method into AppleALC and it worked... search/replace 7 instances - instead of the patch for assertion. 

 

Comment: 0x19160000/etc, 19MB framebuffer 9MB cursor bytes (credit RehabMan)

Name: AppleIntelSKLGraphicsFramebuffer

Find: 01030303 00002002 00005001

Replace: 01030303 00003001 00009000

no. not really. clover is a shim between bios and boot.efi it has no control over bios functions.

I try change source Clover to call BIOS SETTING from Clover and CLOVER from BIOS SETTING, it worked! I think i can change  functions in Bios Setting from Clover. The problem here is Graphic Lib allow me do that or not?

×
×
  • Create New...