Clover General discussion

[vector sigma]

Wouldn't be better to replace $EXTRAPKG with $4?

[Philip Petev]

No, because of that "set -u" at the beginning of the script.

 

Sent from my MI 5s using Tapatalk

[vector sigma]

Isn't a path, is an option and there's no need to make it immutable (apparently), just ensure it has a valid numerical value is enough Imho. just to write less characters. anyway works:

[[ "${4}" == [1-3] ]] && NOEXTRAS=${4} || NOEXTRAS=0

[apianti]

@Philip,

 

Yeah, that is much cleaner, except you need quotes in case EXTRAPKG is empty.

[[ "$EXTRAPKG" == [1-3] ]] && NOEXTRAS=${EXTRAPKG} || NOEXTRAS=0

Isn't a path, is an option and there's no need to make it immutable (apparently), just ensure it has a valid numerical value is enough Imho. just to write less characters. anyway works

 

What do you mean? "set -u" enforces that variables be set before being replaced or an error is emitted. The default behavior is to replace an unset variable with empty. So he was saying you can't use $4 at this place in the script because "set -u" was called previous to this meaning that if there aren't four arguments (i.e. when building the full package) $4 is not set and would therefore emit an error.

[vector sigma]

than make like that:

 

declare -r NOEXTRAS=$([[ "${4}" == [1-3] ]] && echo ${4} || echo 0)

 

can't fail   

[apianti]

Noooooo. That's terrible design. That creates a subshell to effectively do a comparison - an enormous waste of resources.

[vector sigma]

ha ha noooo  , 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.

[apianti]

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.....

[vector sigma]

Why I talked 

 

See you, have to go. Glad to discuss stuff with you all

[Philip Petev]

 

 

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

[tluck]

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.

[RehabMan]

one idea: DVMTfixup worked for me.

 

Did you test the current version or were you testing the older version?

[Sherlocks]

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.

[tluck]

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

[tluck]

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?

[RehabMan]

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.

[tluck]

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.

[apianti]

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....?

[RehabMan]

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...

[tluck]

Ah well. I agree then 1.1.3 without the old method was ineffective

[RehabMan]

Ah well. I agree then 1.1.3 without the old method was ineffective

 

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

[Sherlocks]

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에서 보냄

[RehabMan]

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.

[vector sigma]

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 May 18, 2017 by Allan
Code box added

[apianti]

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.