Jump to content

[pre-release] macOS Mojave

fantomas

By fantomas,
in New Releases and Updates

 Share
2,429 posts in this topic

Recommended Posts

MorenoAv
MorenoAv
Posted
Posted (edited)

something is very wrong with my Mojave 10.14, I installed VoodooHDA 2.9.0 v12, with Mojave support and still no audio devices... I have a SSDT-HDEF.aml and alc 1.2.8 v2 and still nothing... grrrr

Edited by MorenoAv
Link to comment
Share on other sites
Badruzeus
Badruzeus
Posted
Posted
2 minutes ago, MorenoAv said:

something is very wrong with my Mojave 10.14, I installed VoodooHDA 2.9.0 v12, with Mojave support and still no audio devices... I have a SSDT-HDEF.aml and alc 1.2.8 v2 and still nothing... grrrr

Then just try AppleHDA.kext from 10.13.x.. though in the name of vanilla, I don't recommend this.

Link to comment
Share on other sites
MorenoAv
MorenoAv
Posted
Posted

But I have put the DSDT in ACPI/Patched... but I'm going to see that right now again...

Yep is still there, if that don't show in my files I don't know why...

Link to comment
Share on other sites
ammoune78
ammoune78
Posted
Posted (edited)
12 minutes ago, MorenoAv said:

But I have put the DSDT in ACPI/Patched... but I'm going to see that right now again...

Yep is still there, if that don't show in my files I don't know why...

 

The HDEF-SSDT you have contain alc-layout-id, use this one:

HDEF-SSDT.aml, and put 10.13 AppleHDA IN S\L\E and rollback to a previous release of AppleALC or use on VoodooHDA

Edited by ammoune78
Link to comment
Share on other sites
Pavo
Pavo
Posted
Posted
1 hour ago, MorenoAv said:

Hi SavageAUS,

No I haven't tried to disable the patches, and they were for High Sierra 10.13, but I'm gone try that in just a minute...

PS: I have tried and disabled the patches, the result is the same... no audio devices... this time its difficult to solve this problem...

Thanks for your help

Right here is your issue, Lilu isn't loading. You are also not using the versions of AppleALC and Lilu I gave you.

kernel.log 

2018-06-12 09:04:04.470744+0100 0x73       Default     0x0                  0      0    kernel: (kernel) Lilu:  config @ automatically disabling on an unsupported operating system
2018-06-12 09:04:04.470748+0100 0x73       Default     0x0                  0      0    kernel: (kernel) Lilu:    init @ found a disabling argument or no arguments, exiting

boot.log 

8:571  0:008  Extra kext: EFI\CLOVER\kexts\Other\AppleALC.kext (v.1.2.6)
9:373  0:022  Extra kext: EFI\CLOVER\kexts\Other\Lilu.kext (v.1.2.3)

Actually add these this time and replace your config with this one.

Archive.zip

  • Like 1
Link to comment
Share on other sites
Pavo
Pavo
Posted
Posted
1 hour ago, ammoune78 said:

 

The HDEF-SSDT you have contain alc-layout-id, use this one:

HDEF-SSDT.aml, and put 10.13 AppleHDA IN S\L\E and rollback to a previous release of AppleALC or use on VoodooHDA

With AppleALC 1.2.8 alc-layout-id is preferred, as vit9696 stated you can still use layout-id but alc-layout-id is the new way of adding it. 

Starting with 1.2.8 AppleALC uses a different scheme to handle layout-id. This is done to avoid AppleHDA.kext file dependencies (i.e. we cannot use missing layoutXX.xml.zlib files) and improve codec compatibility (i.e. some layouts change DSP behaviour).
From now on AppleALC will operate on 2 identifiers:
alc-layout-id used to identify the layout within AppleALC itself (can be any number)
apple-layout-id reported to AppleHDA to avoid the issue above You may replace layout-id with alc-layout-id after an upgrade, but for compatibility reasons existing layout-id values will be automatically converted to alc-layout-id. Overrides with alcid=X boot argument are also supported.
To override apple-layout-id you may use alcaaplid=X boot argument. The default value to be reported to AppleHDA is 7.

 

Link to comment
Share on other sites
ammoune78
ammoune78
Posted
Posted
57 minutes ago, Pavo said:

With AppleALC 1.2.8 alc-layout-id is preferred, as vit9696 stated you can still use layout-id but alc-layout-id is the new way of adding it. 


Starting with 1.2.8 AppleALC uses a different scheme to handle layout-id. This is done to avoid AppleHDA.kext file dependencies (i.e. we cannot use missing layoutXX.xml.zlib files) and improve codec compatibility (i.e. some layouts change DSP behaviour).
From now on AppleALC will operate on 2 identifiers:
alc-layout-id used to identify the layout within AppleALC itself (can be any number)
apple-layout-id reported to AppleHDA to avoid the issue above You may replace layout-id with alc-layout-id after an upgrade, but for compatibility reasons existing layout-id values will be automatically converted to alc-layout-id. Overrides with alcid=X boot argument are also supported.
To override apple-layout-id you may use alcaaplid=X boot argument. The default value to be reported to AppleHDA is 7.

 

 

2 hours ago, ammoune78 said:

HDEF-SSDT.aml, and put 10.13 AppleHDA IN S\L\E and rollback to a previous release of AppleALC or use on VoodooHDA

 

Another time when quoting me, take a look two times before doing it, so have a look on what i said, now it will be on bold, to explain that:

The reason for this, my HDEF-SSDT contain "layout-id", instead of the one present on he's patched folder that contain "alc-layout-id",, and i was talking on old AppleALC not the newest, you always quote quickly before reading.

  • Haha 1
Link to comment
Share on other sites
MorenoAv
MorenoAv
Posted
Posted (edited)

Thanks Pavo for all your work and will to help, but after making all the changes you suggested, they don't work I have no audio devices yet. For that reason I re installed it again and I have implemented all your suggestions, but have no audio devices again... I don't know what to do more, and I don't want to be a pita, to everyone.

Thanks all

Edited by MorenoAv
Link to comment
Share on other sites
ammoune78
ammoune78
Posted
Posted (edited)
27 minutes ago, MorenoAv said:

Thanks Pavo for all your work and will to help, but after making all the changes you suggested, they don't work I have no audio devices yet. For that reason I re installed it again and I have implemented all you suggestions, but have no audio devices again... I don't know what to do more, and I don't want to be a pita, to everyone.

Thanks all

 

You'll not be a pita MAN, it's just confusion ^_^

 

Try this, but use AppleHDA from High Sierra, if you don't have it, I'll upload it.

 

In the config.plist change the name of the drive and the Theme

Kexts.zip

patched.zip

config.plist.zip

AppleHDA.kext.zip

Edited by ammoune78
  • Like 1
Link to comment
Share on other sites
Pavo
Pavo
Posted
Posted (edited)
1 hour ago, MorenoAv said:

Thanks Pavo for all your work and will to help, but after making all the changes you suggested, they don't work I have no audio devices yet. For that reason I re installed it again and I have implemented all your suggestions, but have no audio devices again... I don't know what to do more, and I don't want to be a pita, to everyone.

Thanks all

Add the files I suggested and do another Runme dump and upload the zip it creates. Need to verify  

1 hour ago, ammoune78 said:

 

 

Another time when quoting me, take a look two times before doing it, so have a look on what i said, now it will be on bold, to explain that:

The reason for this, my HDEF-SSDT contain "layout-id", instead of the one present on he's patched folder that contain "alc-layout-id",, and i was talking on old AppleALC not the newest, you always quote quickly before reading.

Yes this is the reason why I quoted you, you should never use older macOS version of the drivers unless its 100% absolutely needed. I wanted him to keep trying with the small modifications that I made in order to narrow down the real cause of his issue, if it is not supported anymore then yes using an older driver would be the next logical step. But you don't just jump to the very last step before debugging and narrowing it down. This helps the developers determine what exact drivers that are not 100% supported.

Edited by Pavo
  • Like 3
Link to comment
Share on other sites
ammoune78
ammoune78
Posted
Posted (edited)
33 minutes ago, Pavo said:

Yes this is the reason why I quoted you, you should never use older macOS version of the drivers unless its 100% absolutely needed. I wanted him to keep trying with the small modifications that I made in order to narrow down the real cause of his issue, if it is not supported anymore then yes using an older driver would be the next logical step. But you don't just jump to the very last step before debugging and narrowing it down. This helps the developers determine what exact drivers that are not 100% supported.

 

I use quickest solution for the MAN, your solution have to wait other DEVELOPERS to post final things as i see, rolling back AppleHDA or Atheros kext helped a lot of people, have you a solution for that instead, or what can you say Hhhh

Edited by ammoune78
  • Like 1
Link to comment
Share on other sites
Pavo
Pavo
Posted
Posted
1 minute ago, ammoune78 said:

 

I use quickest solution for the MAN, your solution have to wait other DEVELOPERS to post final things as i see, rolling back AppleHDA or Atheros kext helped a lot of people, have you a solution for that instead, or what can you say Hhhh

Betas are exactly made for that, to test and see what works and what doesn’t, a easy wrong over the hard right isn’t always the best overall solution.

  • Like 2
Link to comment
Share on other sites
MorenoAv
MorenoAv
Posted
Posted (edited)

After re install and implementation of your suggestions Pavo I tried to run the RUNMe App but it gave error, and never finishes...

That was my first thought, but because of the error, I didn't post it...

I' m all for experimenting all and if I remember correctly this is the first time that an macOS is that difficult to solve an problem, but we continue to try... 

Edited by MorenoAv
Link to comment
Share on other sites
Pavo
Pavo
Posted
Posted
Just now, MorenoAv said:

After re install and implementation of your suggestions Pavo I tried to run the RUNMe App but it gave error, and never finishes...

That was my first thought, but because of the error, I didn't post it...

Yes the Runme app is very unstable and buggy on Mojave, but if you allow it permissions it should work better. In the process of trying make it work better.

Link to comment
Share on other sites
Pavo
Pavo
Posted
Posted
Just now, MorenoAv said:

I gave all the permissions that the app requested, but in the end, didn't work... but I'll try again and again... 

Yeah I had to run it a few times to make it complete

Link to comment
Share on other sites
mnfesq
mnfesq
Posted
Posted

I have Mojave installed on a test partition (only 40 GB).  The nature of my testing, like everyone else, requires us to grant admin privileges to the apps we are installing or testing or even the mounting of the EFI partition.  Because of this, I like to use a VERY short password to reduce the amount of typing and reduce the likelihood of mistakes in entering my password.  However, Mojave requires a much stronger password.  Any idea how to disable that feature?

Link to comment
Share on other sites
bronxteck
bronxteck
Posted
Posted

 

1 hour ago, Nightf4ll said:

Safari is very buggy in Mohave.. It even freezes my computer when I leave it open and it goes to sleep (specially with sites like youtube)

if you are using intel graphics you might need the lilu plugin shiki and run it with -shikibeta flag

  • Like 1
Link to comment
Share on other sites
Nightf4ll
Nightf4ll
Posted
Posted (edited)
13 minutes ago, bronxteck said:

 

if you are using intel graphics you might need the lilu plugin shiki and run it with -shikibeta flag

no, RX480.. disabled the igpu. It just breaks after sleep though. Took me long enough to figure out that Safari was the cause lol, so thats why i wrote in here...

 

(although, haven't tested other browsers except chrome)

Edited by Nightf4ll
Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...