Ciao (_OSI ("Darwin")) se non _OSI a volte non Darwini

[A23SS4NDRO]

Salve a tutti, dal momento che l'uomo viene dalle scimmie... è _cOSI oppure no per Darwin? Ehm... forse ho iniziato troppo dall'inizio

 

Avrei un po' di dubbi sulle ultime modifiche a SSDT-PNLFCFL che è stato "sostituito" con una versione "aggiornata" dalla morfologia discutibile sull'uso di:

 

If (_OSI ("Darwin"))


{


}

 

al di fuori di un metodo.... cosa che a @Gengik84 non andava molto giù

 

Attendo vostre opinioni

 

https://github.com/acidanthera/OpenCorePkg/pull/279

[Gengik84]

intendi perchè ha lo scope interno?

in questo caso si potrebbe semplicemente mettere la condizione Darwin su _STA in PNLF ossia qui https://github.com/acidanthera/OpenCorePkg/blob/master/Docs/AcpiSamples/Source/SSDT-PNLF.dsl#L49

all'atto pratico if Darwin return 0x0B else return 0 cosi PNLF non è minimamente caricato

poi se anche questo da problemi a windows https://github.com/acidanthera/OpenCorePkg/blob/master/Docs/AcpiSamples/Source/SSDT-PNLF.dsl#L32 mettere un altro e semplice if (_OSI("Darwin")) per quella linea di codice 

[Gengik84]

SSDT-PNLF-2.dsl.zip

[dreamwhite]

Mi intrometto nel thread perchè ho ancora qualche dubbio:

perchè non mettere un

Quote

If (_OSI("Darwin")) { ... }

all'inizio dell'SSDT così il codice viene eseguito solo se il sistema operativo, o meglio il kernel, è Darwin?

Potrebbero esserci delle complicazioni su motherboard con BIOS legacy/primi UEFI?

La vedrei come una soluzione più pulita piuttosto che riempire gli SSDT di n-Darwin...

[foskvs]

È preoccupante che Windows vada in tilt con una semplice definizione di OperationRegion (che peraltro potrebbe essere definita già sul DSDT).

[Gengik84]

11 minuti fa, dreamwhite ha scritto:

Mi intrometto nel thread perchè ho ancora qualche dubbio:

perchè non mettere un

all'inizio dell'SSDT così il codice viene eseguito solo se il sistema operativo, o meglio il kernel, è Darwin?

Potrebbero esserci delle complicazioni su motherboard con BIOS legacy/primi UEFI?

La vedrei come una soluzione più pulita piuttosto che riempire gli SSDT di n-Darwin...

ma c'è di già e comprende tutto lo Scope https://github.com/acidanthera/OpenCorePkg/blob/master/Docs/AcpiSamples/Source/SSDT-PNLF.dsl#L29

Forse intendi altro?

Io avevo inteso da Alessandro di avere una variante anche forse migliore usando _STA per la condizione

 

7 minuti fa, foskvs ha scritto:

È preoccupante che Windows vada in tilt con una semplice definizione di OperationRegion (che peraltro potrebbe essere definita già sul DSDT).

Non ho windows quindi non posso provare ma anche se l'avessi, con tutto il rispetto per i bootloader, non lo avvierei da questi

Uguale su DSDT... forse ..ma RM** è Rehabman

[dreamwhite]

4 hours ago, Gengik84 said:

ma c'è di già e comprende tutto lo Scope https://github.com/acidanthera/OpenCorePkg/blob/master/Docs/AcpiSamples/Source/SSDT-PNLF.dsl#L29

Forse intendi altro?

Io avevo inteso da Alessandro di avere una variante anche forse migliore usando _STA per la condizione

 

Non ho windows quindi non posso provare ma anche se l'avessi, con tutto il rispetto per i bootloader, non lo avvierei da questi

Uguale su DSDT... forse ..ma RM** è Rehabman

My bad, ero convinto ci fossero 2 OSI.

Comunque come te concordo che sia meglio avviare Windows dal proprio bootloader o quantomeno non da OpenCore. Personalmente non ho Windows, ma ho impostato come bootloader principale systemd-boot con due entry: una per Arch e una che punta ad OpenCore.efi

[Lorys89]

Buongiorno a tutti, bei commenti ma comunque, premetto che if osi darwin all inizio l'ho aggiunto dopo la scoperta che su comet lake e ice lake al riavvio dovevo controllare lavori su windows e mi dava blu screen ed errore acpi.

Dopo tale avvenimento e varie prove, ho trovato quella soluzione.

Se voi non avviate windows da oc, rimuovete la condizione if osi darwin. 

 

La vera modifica di questo pnlf è il suo esser universale per tutte le generazioni. 

 

Buona giornata a tutti. 

[Lorys89]

15 ore fa, Gengik84 ha scritto:

intendi perchè ha lo scope interno?

in questo caso si potrebbe semplicemente mettere la condizione Darwin su _STA in PNLF ossia qui https://github.com/acidanthera/OpenCorePkg/blob/master/Docs/AcpiSamples/Source/SSDT-PNLF.dsl#L49

all'atto pratico if Darwin return 0x0B else return 0 cosi PNLF non è minimamente caricato

poi se anche questo da problemi a windows https://github.com/acidanthera/OpenCorePkg/blob/master/Docs/AcpiSamples/Source/SSDT-PNLF.dsl#L32 mettere un altro e semplice if (_OSI("Darwin")) per quella linea di codice 

https://github.com/acidanthera/OpenCorePkg/pull/279/commits/cd0e1cbc1688af406338d91b43cf70ae52a21b66

prova già fatta e non caricava il pnlf. 

provato a dare if osi darwin sotto lo scope gfx0 che comprendeva pnlf (modificando lo _STA in name 0x0B) pure ed in quel caso caricava il pnlf avviava windows ma il pnlf lavorava male avevo livelli di luminosità del 50% inferiori poiché caricava uid skl kbl e non quello cfl. 

la soluzione finale fa sì che se avvi windows da opencore non dia errori acpi e blu screen e su macos carica il valore pnlf corretto. 

Edited July 27, 2021 by Lorys89

[dreamwhite]

50 minutes ago, Lorys89 said:

Buongiorno a tutti, bei commenti ma comunque, premetto che if osi darwin all inizio l'ho aggiunto dopo la scoperta che su comet lake e ice lake al riavvio dovevo controllare lavori su windows e mi dava blu screen ed errore acpi.

Dopo tale avvenimento e varie prove, ho trovato quella soluzione.

Se voi non avviate windows da oc, rimuovete la condizione if osi darwin. 

 

La vera modifica di questo pnlf è il suo esser universale per tutte le generazioni. 

 

Buona giornata a tutti. 

Buongiorno a te 🙂

Inizio sottolineando come la mia era una semplice curiosità piuttosto che una provocazione 😅

Chiaramente quando parli di BSOD relativi ad errori ACPI su Windows intendi l'avvio di Windows stesso da OC, giusto?

Inoltre, non sarebbe più "giusto", una volta identificato il valore della variabile _UID, rimuovere da SSDT-PNLF stesso l'algoritmo di identificazione dell'UID per altre generazioni e definire il valore della variabile _UID, come fatto nel caso di SSDT-PNLFCFL?

[Lorys89]

1 minuto fa, dreamwhite ha scritto:

Buongiorno a te 🙂

Inizio sottolineando come la mia era una semplice curiosità piuttosto che una provocazione 😅

Chiaramente quando parli di BSOD relativi ad errori ACPI su Windows intendi l'avvio di Windows stesso da OC, giusto?

Inoltre, non sarebbe più "giusto", una volta identificato il valore della variabile _UID, rimuovere da SSDT-PNLF stesso l'algoritmo di identificazione dell'UID per altre generazioni e definire il valore della variabile _UID, come fatto nel caso di SSDT-PNLFCFL?

ciao Ivan, quell ssdt nasce per un pubblico di gente inesperta che non sa nemmeno cosa è un uid, te sei libero di fare e usare ciò che vuoi a tuo piacimento. 

[Gengik84]

2 ore fa, Lorys89 ha scritto:

prova già fatta e non caricava il pnlf. 

provato a dare if osi darwin sotto lo scope gfx0 che comprendeva pnlf (modificando lo _STA in name 0x0B) pure ed in quel caso caricava il pnlf avviava windows ma il pnlf lavorava male avevo livelli di luminosità del 50% inferiori poiché caricava uid skl kbl e non quello cfl. 

Ciao, strano che uno _STA,  che alla fine è il medesimo,

0x0B interferisca su altri condizionali (codice successivo) riguardo a uuid

Comunque ok

 

2 ore fa, Lorys89 ha scritto:

la soluzione finale fa sì che se avvi windows da opencore non dia errori acpi e blu screen e su macos carica il valore pnlf corretto. 

il bluscreen dovuto a OperationRegion?

giusto per sapere e conferma, come detto in precedenza non ho modo di provare

[Gengik84]

1 ora fa, dreamwhite ha scritto:

Inoltre, non sarebbe più "giusto", una volta identificato il valore della variabile _UID, rimuovere da SSDT-PNLF stesso l'algoritmo di identificazione dell'UID per altre generazioni e definire il valore della variabile _UID, come fatto nel caso di SSDT-PNLFCFL?

Si ma all'atto pratico non cambierebbe nulla

in condizionale fatto a modo funziona benissimo, usati oltretutto dagli OEM in gran numero.

Condizionali che ci sono su molti linguaggi di programmazione

[Lorys89]

esatto il bluscreen è dovuto a OperationRegion

[tuxy]

Quando leggi un thread e rimani a fissare lo schermo in stato catatonico! 😁

[dreamwhite]

19 minutes ago, Gengik84 said:

Si ma all'atto pratico non cambierebbe nulla

in condizionale fatto a modo funziona benissimo, usati oltretutto dagli OEM in gran numero.

Condizionali che ci sono su molti linguaggi di programmazione

Certo, più che altro il mio discorso volge all'ottimizzazione. Prendiamo ad esempio SSDT-PLUG: possiamo sia usare quello generico, che fa una serie di If CondRefOf, oppure usare quello specifico per il proprio hardware.

Differenze all'atto pratico non ne sono, fatta eccezione forse per i tempi di boot (idealmente)

[dreamwhite]

Comunque, piccola precisazione: _STA è un metodo, non una variabile, ergo non è corretto usare l'operatore di assegnazione Name 😄

[Gengik84]

11 minuti fa, dreamwhite ha scritto:

Differenze all'atto pratico non ne sono, fatta eccezione forse per i tempi di boot (idealmente)

millesimi di secondo.. 0,00000? 😄

anche su opencore si sono innumerevoli condizionali quindi uno che dovrebbe fare, rimuoverli e lasciare solo quelli per il suo caso?

Fattibile per carità ma a me sembra estremizzare la cosa 🙂

 

[foskvs]

20 minutes ago, dreamwhite said:

Certo, più che altro il mio discorso volge all'ottimizzazione. Prendiamo ad esempio SSDT-PLUG: possiamo sia usare quello generico, che fa una serie di If CondRefOf, oppure usare quello specifico per il proprio hardware.

Differenze all'atto pratico non ne sono, fatta eccezione forse per i tempi di boot (idealmente)

Nulla ti vieta di farlo. Se sai veramente cosa tocchi, non ci sono problemi.

Il problema c'è se il generico "Mario Rossi" si mette a togliere pezzi di codice perché "tanto non servono".

 

Alla fine, ci sono tantissimi modi diversi di fare la stessa cosa e non ce n'è uno più corretto degli altri.