Jump to content

[Risolto] Sleep/Wake tramite iniezione nel DSDT


mrmojorisin17
 Share

116 posts in this topic

Recommended Posts

Ciao :)

 

Ho installato la retail di Snow e ho in seguito fatto l'aggiornamento alla versione 10.6.3.

Sto riscontrando alcuni problemi con la gestione della batteria.

Ho fatto prove con vari kexts ottenendo risultati differenti.

 

1. Ho provato Voodoopower.kext (patchato da tea per il Samsung NC10) in coppia con VoodooBattery.kext + NullCPUPowerManagement.kext; con questi kexts la batteria si comporta in modo strano, ovvero cliccando sull'icona nella barra del Finder mi dice che la batteria è da sostituire immediatamente e nonostante il tempo rimanente diminuisce la percentuale rimane sempre ferma a 100%.

 

2. Ho provato i medesimi kexts, che mi ha passato Alex, e il risultato è stato lo stesso.

 

3. Ho provato ad utilizzare il DSDT patchato da tea (con iniezione per il Vanilla Speedstep) + IntelCPUPowerManagement; la batteria sembra beneficiarne, però mi pare un controsenso utilizzare un DSDT ottimizzato per il kernel Vanilla con un kernel patchato (quello 10.3 per Atom). Il DSDT mi tornerebbe utile in quanto mi dà la possibilità di regolare la luminosità dello schermo con Fn + F12/Ins; sfortunatamente mi ha dato problemi di kernel panic (credo dovuti al DSDT). Per avere conferme però ci vorrebbero scrax o Smith@@.

 

4. Utilizzando il DSDT estratto con DSDT Patcher GUI + i kexts originali (IntelCPUPowerManagement.kext e AppleACPIBatteryManager.kext) la batteria dura meno.

 

Ecco, queste sono le prove che ho fatto. Se avete idee o consigli postate pure.

 

Grazie

Link to comment
Share on other sites

Guest James.1979

Io uso solo l'AppleACPIBatteryManager.kext in extra-->extensions e va bene.

 

Se vuoi fare una prova con il kext che uso io, fammi un fischio che te lo uppo.

Link to comment
Share on other sites

...

3. Ho provato ad utilizzare il DSDT patchato da tea (con iniezione per il Vanilla Speedstep) + IntelCPUPowerManagement; la batteria sembra beneficiarne, però mi pare un controsenso utilizzare un DSDT ottimizzato per il kernel Vanilla con un kernel patchato ....

Scusa ma che centra il DSDT con la versione del kernel?

Link to comment
Share on other sites

3. Ho provato ad utilizzare il DSDT patchato da tea (con iniezione per il Vanilla Speedstep) + IntelCPUPowerManagement; la batteria sembra beneficiarne, però mi pare un controsenso utilizzare un DSDT ottimizzato per il kernel Vanilla con un kernel patchato (quello 10.3 per Atom). Il DSDT mi tornerebbe utile in quanto mi dà la possibilità di regolare la luminosità dello schermo con Fn + F12/Ins; sfortunatamente mi ha dato problemi di kernel panic (credo dovuti al DSDT). Per avere conferme però ci vorrebbero scrax o Smith@@.

 

Il kernel è patchato in modo che parta anche sui processori "non ufficialmente supportati" la parte dello speedstep è "vanilla" anche nel kernel pachato, per quel che ne so.

io fossi in te proverei ad aggiungere le modifiche per lo speedstep di Tea al DSDT che non ti crea KP, così verifichi s'è il dsdt...

Link to comment
Share on other sites

Se dai un'occhiata alla mia guida, anche se abbiamo un netbook differente e il resto rimane "simile", puoi farti un'idea di tutte le variabili a cui sono andato in contro con speedstep vanilla e cio' che ne segue.

Mai avuto il problema che descrivi al punto 1.

Per quanto riguarda la batteria non ho notato grosse differenze nei consumi fra il prima con disabler e il dopo di cui sopra. La batteria da 3 celle continua a durare con tutto on circa un'ora/un'ora e 10, quella da 9 celle OEM intorno alle tre ore e trenta, ma e' nuova e la tengo come "riserva", la utilizzo principalmente in trasferta. In facolta' mi da' quell'autonomia necessaria per tornare a casa col piccolino ancora vivo. Non ho mai badato piu' di tanto a fattori di questo tipo, batteria, tempo, durata; per l'utilizzo che se ne fa e' perfetto.

 

Ciao :)

Link to comment
Share on other sites

 

Provati anche questi; la batteria dura intoro alle 5 ore (anche qualcosina meno) contro le 6 ore e 1/2 che ottengo con VoodooPower.kext patchato su Leopard.

 

Il kernel è patchato in modo che parta anche sui processori "non ufficialmente supportati" la parte dello speedstep è "vanilla" anche nel kernel pachato, per quel che ne so.

io fossi in te proverei ad aggiungere le modifiche per lo speedstep di Tea al DSDT che non ti crea KP, così verifichi s'è il dsdt...

 

Proverò a fare così!

Comunque ho notato che il DSDT patchato di tea mi crea problemi proprio quando utilizzo i tasti Fn + F12/Ins per il controllo della luminosità; infatti quando regolo la luminosità ogni tanto il PC si blocca e sono costrtto a riavviare forzatamente. Altre volte ho kp all'avvio del PC.

Ripeto però che di DSDT non ci capisco veramente nulla; ho confrontato il mio (estratto con DSDT Patcher GUI) con quello di tea con l'applicazione diffmerge per cercare di capirci qualcosa di più, ma ancora rancolo nel buio.

 

Se dai un'occhiata alla mia guida, anche se abbiamo un netbook differente e il resto rimane "simile", puoi farti un'idea di tutte le variabili a cui sono andato in contro con speedstep vanilla e cio' che ne segue.

Mai avuto il problema che descrivi al punto 1.

Per quanto riguarda la batteria non ho notato grosse differenze nei consumi fra il prima con disabler e il dopo di cui sopra. La batteria da 3 celle continua a durare con tutto on circa un'ora/un'ora e 10, quella da 9 celle OEM intorno alle tre ore e trenta, ma e' nuova e la tengo come "riserva", la utilizzo principalmente in trasferta. In facolta' mi da' quell'autonomia necessaria per tornare a casa col piccolino ancora vivo. Non ho mai badato piu' di tanto a fattori di questo tipo, batteria, tempo, durata; per l'utilizzo che se ne fa e' perfetto.

 

Ciao ;)

 

Intanto complimenti per la guida, a prova di n00b e dettagliata fin nei minimi particolari!

Io ho una batteria 6 celle che con il VoodooPower.kext patchato da tea sotto Leopard mi dura quasi 7 ore. Lo stesso kext sotto Snow mi crea il problema del punto 1.

Come suggerito da scrax domani provo ad iniettare la parte di codice relativa allo Speedstep del DSDT di tea in quello che uso io per vedere cosa succede.

La cosa che non mi torna è questa discrepanza che mi crea lo stesso kext (VoodooPower.kext) tra Leopard e Snow; soprattutto visto che il kext tea lo ha patchato e postato nella guida per installare Snow.

 

Grazi a tutti :D

Link to comment
Share on other sites

Eccomi qua.

Come consigliato da scrax ho modificato il mio DSDT iniettando sola la parte di codice relativa allo Speedstep del codice di tea; funziona, ho controllato il tutto con VoodooMonitor.app.

Adesso la batteria dura quanto deve durare (all'incirca 6-7 ore).

Grazie a scrax per il consiglio e a smith@@ per la sua guida da cui ho preso spunto per alcune cose!

 

Adesso i problemi che si pongono sono altri; col DSDT di tea ho la possibilità di regolare la luminosità tramite le combinazioni di tasti Fn + F12/Ins. L'intero DSDT, oltre ad essere fatto ad hoc per un altro netbook mi ha creato alcuni problemi e ogni tanto kp.

La mia richiesta, che non vuole essere una pretesa, per scrax e/o smith@@, è quella di indicarmi quali sono le parti di codice del DSDT di tea che devo aggiungere al mio per poter regolare la luminosità con quelle combinazioni di tasti, ammesso che sia possibile.

Inoltre, vorrei sapere se c'è la possibilità di ottenere, sempre tramite iniezione/i di codice nel DSDT, la funzione sleep; al momento, infatti, posso mandare il netbook in sleep, sia tramite la funzione "Stop", sia tramite il comando Fn+Esc; in entrambi i casi lo sleep funziona.

L'unico problema è che il "piccolo" non si risveglia dal "sonno", tanto che sono costretto a rimuovere la batteria, in quanto neanche tenendo premuto il tasto di spegnimento riesco a spegnere il PC.

 

Se siete disposti a darmi una piccola mano, io ci metto la volontà e la voglia di capire un pò meglio questo sconosciuto che ha nome DSDT.

 

Grazie

Link to comment
Share on other sites

Il mio primo consiglio, per mancanza di tempo e voglia, e' quello di girare un po' lo sguardo su projextosx E NON SOLO dove puoi affrontare argomenti descritti su, DSDT con il suo mondo, un po' piu' dettagliatamente.

E' una cosa che dovresti iniziare a "fare" e "capire" inizialmente da solo e scrax sarebbe della stessa idea, per un semplice motivo, le variabili in gioco per le iniezioni di cui parli possono essere diverse, poche o tante, ma solo tu sbattendoci la testa, puoi arrivare ad una conclusione. E non e' detto che ci sia sempre un risultato positivo. Non voglio dilungarmi per non tediare nessuno.

 

Riguardo il problema dello sleep di cui sopra devi, perche' non l'ho afferrato, se il mancato risveglio lo hai con speedstep vanilla o no, o con entrambi. Quel problema, forse ne ho parlato implicitamente in guida, e' fino ad un certo punto un problema riguardante lo sleep. Perche'. Perche' in sleep ci va, e' il wake a non funzionare, quindi io lo separerei da un problema di sleep. Questo problema l'ho affrontato su diversi hack, non solo sul piccolino e non puoi immaginare le diverse variabili andate in contro per la sua risoluzione.

Devi distinguere anche se il suddetto problema lo hai solo in modalita' batteria, o alimentazione esterna o entrambe.

 

Tipico esempio mio: siamo sull'msi u100, modalita' alimentazione batteria, airport extreme 1505 attivata(e' importante), identificazione con MacBookAir1,1, speedstep vanilla--->

Se vado in sleep senza disattivare(con questa identificazione) dal finder la schedina wireless(Airport Extreme, anche questo e' importante, con la schedian originale relatek non avevo il suddetto problema), il piccolino al wake NON SI RISVEGLIA, se lo fa impiega TEMPO e spesso rimane impallato.

 

Importante e' un'altra cosa, sempre con l'identificazione di cui sopra, questo problema si ripresentava anche in modalita' alimentazione esterna, FINCHE' non ho flaggato l'opzione in Risparmio Energia, Riattiva per l'accesso del network Airport. Questa opzione non esiste nella "tab" batteria, quando sono in batteria devo disattivare da Finder l'airport e andare in sleep, poco male. COn disabler e speedstep non vanilla non esiste per me questo problema.

Il senso qual e', se va in sleep, il codice per lo sleep e' gia' giusto, la mancanza del wake sul netbook puo' avere diverse cause, spesso banali.

 

Quello che voglio farti capire e' che le variabili in gioco sono tante, e dovresti giocarci principalmente tu :)

 

Per la luminosita' del monitor c'e' una parte di codice da iniettare semplicemente, anche questo su projectosx e' stato affrontato in passato.

 

Comunque per non tediarti, ora torno ai miei doveri, fra stasera e domani do un'occhiata ai dsl da te postati.

Link to comment
Share on other sites

Sei stato chiarissimo! :)

 

Detto questo, dopo questa spiegazione le cose mi sono un pò più chiare.

Riguardo al problema sleep, o meglio wake, posso per certo affermare che:

 

- il netbook va in sleep ma non si risveglia, sia che disattivi l'AirPort sia che non lo disattivi, prima di mandare in sleep; il tutto con modalità batteria;

 

- in alimentazione esterna la stessa cosa, sleep perfettamente funzionante, ma niente wake.

 

Il tutto utilizzando, come identificazione MacBookAir1,1 e DSDT con Speedstep Vanilla.

 

Una differenza che ho notato tra i due codici e che penso possa entrare qualcosa con lo sleep è l'aggiunta di parti di codice:

 

		Method (SOST, 0, Serialized)
	{
		If (CondRefOf (_OSI, Local0))
		{
			Store (0x07D1, OSYS)
			If (LOr [color="#ff0000"](_OSI ("Darwin")[/color], _OSI ("Windows 2006")))
			{
				Store (0x07D6, OSYS)
			}
			Else
			{
				If (_OSI ("Windows 2001 SP2"))
				{
					Store (0x07D3, OSYS)
				}
				Else
				{
					If (_OSI ("Windows 2001 SP1"))
					{
						Store (0x07D2, OSYS)
					}
				}
			}
		}
		Else
		{
			If (LOr (LEqual (SizeOf (_OS), 0x14), LEqual (SizeOf (_OS), 0x05)))
			{
				Store (0x07D0, OSYS)
			}
			Else
			{
				If (LEqual (SizeOf (_OS), 0x27))
				{
					Store (0x07CF, OSYS)
				}
				Else
				{
					If (LEqual (SizeOf (_OS), 0x12))
					{
						Store (0x07CE, OSYS)
					}
					Else
					{
						Store (0x07CD, OSYS)
					}
				}
			}
		}
	}
}

Scope (_SB)
{
	OperationRegion (TCG1, SystemMemory, 0x7F6E2CB6, 0x07)
	Field (TCG1, AnyAcc, NoLock, Preserve)
	{
		PPRQ,   8, 
		PPLO,   8, 
		PPRP,   8, 
		PPOR,   8, 
		TPRS,   8, 
		TPMV,   8, 
		MOR,	8
	}

	Method (PHSR, 1, Serialized)
	{
		Store (Arg0, BCMD)
		Store (Zero, DID)
		Store (Zero, SMIC)
		If (LEqual (BCMD, Arg0)) {}
		Store (Zero, BCMD)
		Store (Zero, DID)
		Return (Zero)
	}

	OperationRegion (SMI0, SystemIO, 0xFE00, 0x02)
	Field (SMI0, AnyAcc, NoLock, Preserve)
	{
		SMIC,   8
	}

	OperationRegion (SMI1, SystemMemory, 0x7F6E2EBD, 0x90)
	Field (SMI1, AnyAcc, NoLock, Preserve)
	{
		BCMD,   8, 
		DID,	32, 
		INFO,   1024
	}

	Field (SMI1, AnyAcc, NoLock, Preserve)
	{
				AccessAs (ByteAcc, 0x00), 
				Offset (0x05), 
		INF,	8
	}

	Method (_INI, 0, NotSerialized)
	{
		If (DTSE)
		{
			TRAP (0x47)
		}

		Store (0x07D0, OSYS)
		If (CondRefOf (_OSI, Local0))
		{
			If (_OSI ("Linux"))
			{
				Store (One, LINX)
			}

			If (_OSI ("Windows 2001"))
			{
				Store (0x07D1, OSYS)
			}

			If (_OSI ("Windows 2001 SP1"))
			{
				Store (0x07D1, OSYS)
			}

			If (_OSI ("Windows 2001 SP2"))
			{
				Store (0x07D2, OSYS)
			}

			If (_OSI ("Windows 2001 SP3"))
			{
				Store (0x07D2, OSYS)
			}

			If (LOr [color="#ff0000"](_OSI ("Darwin")[/color], _OSI ("Windows 2006")))
			{
				Store (0x07D6, OSYS)
			}
		}

 

Nel mio codice (_OSI ("Darwin") non c'è.

Per prima cosa provo ad aggiungere queste due parti al mio DSDT e vedo che succede.

 

Per quanto riguarda il controllo della luminosità credo di aver individuato le parti di codice nel DSDT di tea che dovrei iniettare nel mio; come suggerito do un'occhiata anche al forum di Project OS X.

 

Intanto ti ringrazio per i chiarimenti e, come ripeto, non ho nessuna pretesa, né da parte tua né da parte di scrax.

 

A presto

Link to comment
Share on other sites

Eccomi qua.

Il concetto fondamentale del DSDT è che è una cosa molto legata al hardware che usiamo ma anche, come ha fatto notare smith, a come lo usiamo. Per questo è molto difficile fare delle guide o trovare delle soluzioni che funzionino per tutti.

Vista la tua situazione credo che la cosa più semplice sia chiedere a Tea se si ricorda qual'è la parte del codice relativa ai tasti funzione o vedere se si trova qualcosa online.

Personalmente non ho mai lavorato su hack portatili quindi non ho proprio idea di dove potresti metter mano. Per cercare di capire qualcosa di più puoi provare fare un diff da terminale (se non sai come funziona con "man diff" senza virgolette ti visualizza il manuale per il comando diff) tra i due .dsl e così forse riesci a vedere le differenze e puoi immaginare cos'ha aggiunto o tolto Tea.

Altrimenti più semplice se hai installato i developer tools che trovi sul DVD di Snow o di Leo puoi usare filemerge che fa la stessa cosa ma da interfaccia grafica.

 

il codice Darvin mancante non credo sia determinante per due motivi:

-primo, nel mio DSDT extra ridotto non c'è proprio neanche il metodo, non solo la parte relativa a Darwin

-secondo, il DSDT.aml viene caricato (normalmente) solo da Osx quindi non ha senso farlo con delle variabili che contemplano l'uso di altri OS, per quelli ci sarà o il dsdt originale del BIOS (leggi per win) o un dsdt apposta nel kernel (leggi per linux)

 

In sintesi se il codice per Darwin funge allora ti basterebbe:

		Method (_INI, 0, NotSerialized) { Store (0x07D6, OSYS) }

 

e ancora meglio sarebbe trovare dov'è definito (se c'è) il valore OSYS e assegnarli già 0x07D6

 

EDIT: Rileggendo alcuni post ho notato che usi DSDTpatcherGUI per estrarre il DSDT e la cosa non è molto buona in quanto quel programma oltre ad estrarlo lo patcha in una maniera che non sempre è utile e specie nel tuo caso non ti permette di confrontare quello che hai realmente usato con quello di Tea, per estrarre il DSDT in uso senza modifiche la cosa più facile è DSDTSE.

Link to comment
Share on other sites

Il concetto fondamentale del DSDT è che è una cosa molto legata al hardware che usiamo ma anche, come ha fatto notare smith, a come lo usiamo. Per questo è molto difficile fare delle guide o trovare delle soluzioni che funzionino per tutti.

Vista la tua situazione credo che la cosa più semplice sia chiedere a Tea se si ricorda qual'è la parte del codice relativa ai tasti funzione o vedere se si trova qualcosa online.

Personalmente non ho mai lavorato su hack portatili quindi non ho proprio idea di dove potresti metter mano. Per cercare di capire qualcosa di più puoi provare fare un diff da terminale (se non sai come funziona con "man diff" senza virgolette ti visualizza il manuale per il comando diff) tra i due .dsl e così forse riesci a vedere le differenze e puoi immaginare cos'ha aggiunto o tolto Tea.

Altrimenti più semplice se hai installato i developer tools che trovi sul DVD di Snow o di Leo puoi usare filemerge che fa la stessa cosa ma da interfaccia grafica.

 

il codice Darvin mancante non credo sia determinante per due motivi:

-primo, nel mio DSDT extra ridotto non c'è proprio neanche il metodo, non solo la parte relativa a Darwin

-secondo, il DSDT.aml viene caricato (normalmente) solo da Osx quindi non ha senso farlo con delle variabili che contemplano l'uso di altri OS, per quelli ci sarà o il dsdt originale del BIOS (leggi per win) o un dsdt apposta nel kernel (leggi per linux)

 

In sintesi se il codice per Darwin funge allora ti basterebbe:

		Method (_INI, 0, NotSerialized) { Store (0x07D6, OSYS) }

 

e ancora meglio sarebbe trovare dov'è definito (se c'è) il valore OSYS e assegnarli già 0x07D6

 

EDIT: Rileggendo alcuni post ho notato che usi DSDTpatcherGUI per estrarre il DSDT e la cosa non è molto buona in quanto quel programma oltre ad estrarlo lo patcha in una maniera che non sempre è utile e specie nel tuo caso non ti permette di confrontare quello che hai realmente usato con quello di Tea, per estrarre il DSDT in uso senza modifiche la cosa più facile è DSDTSE.

 

Per prima cosa provo a riestrarmi il DSDT con DSDTSE! :(

Comunque per fare i confronti uso diffmerge, un programma con interfaccia grafica, che oltre a trovare le differenze, ti permette anche di applicarle in maniera semplice e veloce.

 

Per quanto riguarda la regolazione della luminosità ho trovato questo sul forum di Project OS X.

 

					 Method (_DSM, 4, NotSerialized)
				 {
					 Store (Package (0x0C)
						 {
							 "DisplayProductID",
							 Buffer (0x04)
							 {
								 0x5F, 0x9C, 0x00, 0x00
							 },

							 "DisplayVendorID",
							 Buffer (0x04)
							 {
								 0x10, 0x06, 0x00, 0x00
							 },

							 "AAPL,HasPanel",
							 Buffer (0x04)
							 {
								  0x01, 0x00, 0x00, 0x00
							 },

							 "AAPL,backlight-control",
							 Buffer (0x04)
							 {				
								 0xEE, 0x01, 0x00, 0x00
							 },

							 "AAPL01,DualLink",
							 Buffer (0x04)
							 {
								 0x01, 0x00, 0x00, 0x00
							 },

							 "AAPL01,EDID",
							 Buffer (0x80)
							 {
								 /* 0000 */	0X00, 0XFF, 0XFF, 0XFF, 0XFF, 0XFF, 0XFF, 0X00,
								 /* 0008 */	0X30, 0XE4, 0X8B, 0X01, 0X00, 0X00, 0X00, 0X00,
								 /* 0010 */	0X00, 0X12, 0X01, 0X03, 0X80, 0X1F, 0X11, 0X78,
								 /* 0018 */	0X0A, 0X4A, 0X05, 0X9E, 0X5B, 0X54, 0X95, 0X25,
								 /* 0020 */	0X18, 0X50, 0X54, 0X00, 0X00, 0X00, 0X01, 0X01,
								 /* 0028 */	0X01, 0X01, 0X01, 0X01, 0X01, 0X01, 0X01, 0X01,
								 /* 0030 */	0X01, 0X01, 0X01, 0X01, 0X01, 0X01, 0X3E, 0X1C,
								 /* 0038 */	0X56, 0XA0, 0X50, 0X00, 0X16, 0X30, 0X30, 0X20,
								 /* 0040 */	0X35, 0X00, 0X36, 0XAE, 0X10, 0X00, 0X00, 0X19,
								 /* 0048 */	0X00, 0X00, 0X00, 0X00, 0X00, 0X00, 0X00, 0X00,
								 /* 0050 */	0X00, 0X00, 0X00, 0X00, 0X00, 0X00, 0X00, 0X00,
								 /* 0058 */	0X00, 0X00, 0X00, 0X00, 0X00, 0XFE, 0X00, 0X4C,
								 /* 0060 */	0X47, 0X20, 0X44, 0X69, 0X73, 0X70, 0X6C, 0X61,
								 /* 0068 */	0X79, 0X0A, 0X20, 0X20, 0X00, 0X00, 0X00, 0XFE,
								 /* 0070 */	0X00, 0X4C, 0X50, 0X31, 0X34, 0X30, 0X57, 0X48,
								 /* 0078 */	0X31, 0X2D, 0X54, 0X4C, 0X41, 0X31, 0X00, 0X75
							 }
						 }, Local0)
					 DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
					 Return (Local0)
				 }

 

Controllando con diffmerge il DSDT di tea ho individuato questa parte di codice che, nel mio DSDT, ovviamente, non c'è.

 

La parte di codice del DSDT di tea è questa:

 

				 Name (_SUN, 0x05)
			 Method (_DSM, 4, NotSerialized)
			 {
				 Store (Package (0x10)
					 {
						 "AAPL,Haslid", 
						 Buffer (0x04)
						 {
							 0x01, 0x00, 0x00, 0x00
						 }, 

						 "AAPL,aux-power-connected", 
						 Buffer (0x04)
						 {
							 0x01, 0x00, 0x00, 0x00
						 }, 

						 "AAPL,backlight-control", 
						 Buffer (0x04)
						 {
							 0x01, 0x00, 0x00, 0x00
						 }, 

						 "AAPL,BacklightRestore", 
						 Buffer (0x04)
						 {
							 0x01, 0x00, 0x00, 0x00
						 }, 

						 "AAPL,HasPanel", 
						 Buffer (0x04)
						 {
							 0x01, 0x00, 0x00, 0x00
						 }, 

						 "device_type", 
						 Buffer (0x08)
						 {
							 "display"
						 }, 

						 "model", 
						 Buffer (0x07)
						 {
							 "GMA950"
						 }, 

						 "built-in", 
						 Buffer (One)
						 {
							 0x01
						 }
					 }, Local0)
				 DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
				 Return (Local0)
			 }

 

che è stata inserita subito sotto queste due righe:

 

Device (GFX0)

{

Name (_ADR, 0x00020000)

 

Provo ad iniettare questa parte di codice nel mio per vedere se ottengo risultati positivi.

 

Invece, per quanto riguarda la parte sleep/wake, potresti spiegarti un pò meglio riguardo a Darwin e OSYS?

Ho capito che Darwin c'entra poco o nulla; la cosa che non mi è chiara è quando dici:

 

In sintesi se il codice per Darwin funge allora ti basterebbe:

 

Method (_INI, 0, NotSerialized) { Store (0x07D6, OSYS) }

 

e ancora meglio sarebbe trovare dov'è definito (se c'è) il valore OSYS e assegnarli già 0x07D6

 

Cosa intendi?

 

Grazie anche a te per le spiegazioni e per l'aiuto che mi stai dando per cercare di capire un pò meglio come funziona il codice.

 

A presto :)

Link to comment
Share on other sites

Lascia perdere la parte del Darwin osys. Puoi eliminarla tranquillamente o la lasci nel modo in cui ti ha spiegato scrax. Avere la possibilta' di abilitare diverse tipologie di risorse per diversi sistemi operativi in un DSDT che viene caricato SOLO per OSX e' molto molto inutile, codice in piu' che eliminato. Disporre OSX ad abilitare risorse per il sistema a lui piu' vicino in ordine di tempo e non(07d6=Vista, Windows 2006), disabilitando il resto, rimane la strada migliore. Puoi anche eliminarlo tutto quel codice, non ti accrogerai delle differenze.

 

Ciao

Link to comment
Share on other sites

Invece, per quanto riguarda la parte sleep/wake, potresti spiegarti un pò meglio riguardo a Darwin e OSYS?

Ho capito che Darwin c'entra poco o nulla; la cosa che non mi è chiara è quando dici:

 

 

 

Cosa intendi?

 

Grazie anche a te per le spiegazioni e per l'aiuto che mi stai dando per cercare di capire un pò meglio come funziona il codice.

 

A presto :)

 

In pratica se noti il method è pieni di IF e cioè quel codice viene usato solo SE trova il SO corrispondente quindi considerando che a te seve specifico per Osx non t'importa che controlli che OS hai, e vedendo che il valore che da quando c'è darwin è 07D6 ti basta dargli solo quel valore, ma appunto non cambia nulla se il method c'è o no.

Link to comment
Share on other sites

Allora, mi sono estratto il DSDT con DSDTSE e l'ho confrontato tramite diffmerge con quello patchato da tea per il suo Samsung NC10. Ho aggiunto la parte di codice che "credevo" fosse relativa al controllo della luminosità però non è cambiato nulla.

Niente controllo con i tasti Fn+F12/Ins.

Al momento non ho il netbook sotto mano né il DSDT modificato da me per postarlo; domani vedo di postarlo.

Per quanto riguarda il discorso Darwin/OSYS nel DSDT che ho estratto con DSDTSE, la parte di codice corrispondente non c'è; qunidi un "problema" in meno.

 

ps Ho chiesto a tea però mi ha detto che non aveva sotto mano il DSDT e che non si ricordava le modifiche che aveva apportato per ottenere il controllo della luminosità attraverso le combinazioni di tasti sopra citate.

Link to comment
Share on other sites

Per quanto riguarda il discorso Darwin/OSYS nel DSDT che ho estratto con DSDTSE, la parte di codice corrispondente non c'è; qunidi un "problema" in meno.

 

infatti adesso che melo dici quella è una parteaggiunta da DSDTpatcherGUI

Link to comment
Share on other sites

Eccomi qua.

Ho provato ad iniettare nel mio DSDT il codice che dovrebbe permettermi di regolare la luminosità con le combinazini di tasti Fn+F12/Ins.

Per prima cosa ho aperto con diffmerge i due DSDT (quello di tea patchato per il Samsung NC10 e il mio); ho cercato la parte di codice nel DSDT di tea (o meglio le parti, in quanto sono due pezzi di codice, almeno credo!) e l'ho inserita nel mio DSDT:

 

33dcoro.png

 

9lh368.png

 

Una volta fatto questo ho aperto il mio nuovo DSDT.dsl patchato con DSDTSE:

 

2luxcl.png

 

25frts7.png

 

Ma al momento che vado a compilarlo ottengo il seguente errore:

 

Compile error, check output window for details. 255

 

come si può vedere dalla foto:

 

2rnzwwy.png

 

2iuups0.png

Link to comment
Share on other sites

Grazie smith@@.

Provato adesso, funziona a metà. Riesco solo a diminuire la luminosità con la combinazione di tasti Fn+F12, però il comando Fn+Ins per l'aumento della luminosità non funziona. Mi sa che mi sono perso una pezzo di codice per strada.

Adesso ricontrollo meglio, così cerco anche di capire le modifiche che hai aggiunto te.

Link to comment
Share on other sites

Non ho fatto nessuna modifica, a parte inserire il metodo DTGP, se non lo inserisci non puoi fare nulla, a meno che non ne inserisci uno diverso con la stessa funzione e chiudere il LID0 con una graffa.

 

Ciao!

Link to comment
Share on other sites

 Share

×
×
  • Create New...