Gengik84

quindi stai usando sempre l'ultima release dei kext? in caso era dovuto alla luminosità bassa

mm ok, riprova config.plist 4.zip se non va, prova a rimettere i kext precedenti, in particolare WEG Fai sapere se il comportamento è uguale

ok ma lo schermo nero è da subito, appena dopo che clicchi per avviare il disco?

hai aggiornato solo OC o anche i kext? la configurazione è comunque rimasta la medesima rispetto a prima?

aspetta, io pensavo schermo nero dopo il boot, praticamente quando dovresti vedere il desktop prova anche questo config.plist 3.zip

Prova config.plist 2.zip

Scusa volevo dire SMCBattery al posto di acpibattery

quale prezzo e quale sarebbe il tuo budget?

Quelle nel topic di Ciro sono tutte compatibili con BigSur, il problema è comprarle di questi tempi. i prezzi sono alle stelle.

SSDT per il PM è dinamico, viene eseguito un solo codice in base a "ciò che serve" quindi non ha senso e di fatto non serve a nulla andare a editarlo limitandolo Altrimenti che l'abbiamo fatto a fare...... Riguardo a Basic, se usi questo non devi avere nient'altro, neanche il PM Scusa ma perchè sei andato a emulare la NVram? funziona bene e non serve assolutamente emularla..

puoi provare con VirtualSMC? giusto per curiosità dell'eventuali differenze

Ciao si si provala ci mancherebbe 🙂

si sono patch anche per quello, non so se ne servono altre per BigSur come anche il discorso RTC di fatto anche x99/X299 necessitano di patch e varie aggiunte

i kext li trovi già compilati basta che tu vada nella parte Download

ciao no quello non è compatibile, guarda i Sabrent

Ciao, prova a sostituire config.plist.zip

nelle prove che ti ho detto qui https://www.macos86.it/topic/4465-big-sur-livello-batteria-chuwi-corebook-pro-skylake-6157u-1-sempre/?do=findComment&comment=107836 No non deve esserci, va bene uguale se lo tieni disattivato dal config perchè cosi facendo non viene caricato ma devi avere tutti l'altri SSDT iniziali tra cui anche SSDT-BATT

sono voci che circolano da un po', vedremo... di sicuro ci darebbero altro tempo in hack

ok però le prove che ti ho detto devi farle tu su quella configurazione che hai con i soli SSDT Poi fai sapere i risultati di queste

un'altra cosa che puoi provare con la tua configurazione, quindi con vari SSDT è aggiungere SSDT-XOSI con relativa patch sul config in caso non funzionasse o rimanesse come al solito all'1%, puoi aggiungere la patch, il rename _DSM to ZDSM sul config, giusto per vedere se nel caso ci fossero dsm che creano problemi/conflitti a riguardo nelle tabelle NOTA: ripeto la tua configurazione quindi senza DSDT, ma con SSDT e relative patch

nelle prove si, ovviamente perchè non hai un SSDT per la batteria etc Di fatto quel SSDT-Batt che hai è corretto, ma anche qui non ti funziona, qualsiasi modifica aggiuntiva per prova, ti crea problemi dei più vari

si ancora siamo troppo alti anche per le schede madri.. speriamo ribassino ma visto i tempi credo ci vorrà del tempo

ok ma mi era sembrato che tu dicessi fosse un errore, frainteso io.... Comunque riguardo a questo discorso è veramente una cosa soggettiva a riguardo, non indica problemi e alla fine nemmeno un errore di definizione Come dissi anche giorni fa è un punto di visto personale: Se vediamo come unica porta quindi è di colore blu, possiamo mettere 0x03 sia nella hs sia nella relativa ss Se invece la ragioniamo solo ed esclusivamente sulla definizione 2.0 o 3.0 allora la HS possiamo metterla 0x00 Personalmente uso sempre 0x03 sia ssxx sia per relativa hsxx Però veramente ci tengo a dire e ripetere la possibile soggettività personale a riguardo e in entrambi i casi, va bene

No non hai capito HSxx è solo 2.0, lavora così quindi all'atto pratico può essere definita 0x00. non è un problema di fatto

poi prova questo sia con mio ultimo config e in caso col tuo allegato DSDT.aml.zip