Contribute
Register

Lenovo Yoga 910-13IKB

Status
Not open for further replies.
So, have you been using USB wifi so far? Which device did you use? I would definitely like to use a native (i.e. onboard) solution if possible. I think we can replace the mini-PCI-e controller, correct?

I've been using my android phone as a tether (using an app called FoxFI (you have to buy the full version for about $8 dollars) that you can use on mac, Linux, or Windows to tether your data OR WIFI connection to your computer).

I have the same three devices. According to the I2C guide, these models are "almost fully supported". I tried installing the VoodooI2C.kext using Kext Wizard, but this did not work. I then tried removing (renaming) the Apple Lpss kexts, and rebuilt the cache. But this caused a kernel panic, so I reverted. Perhaps I need to patch the DSDT to get the trackpad to work with VoodooI2C: any thoughts?
I had the same issue, I tried with DSDT patches, but it did nothing. You might be able to come out with a different outcome though, playing around with the different DSDT patches and settings.
 
Keep in mind there are two identifiers named SMD0.
One in root scope, in SystemMemory, 8 bits (no need for patching)
And another in _SB.PCI0.LPCB.H_EC scope, in EmbeddedControl, 256 bits (needs patching).
Don't patch code that is accessing the root scope SMD0...

Also, the offset you have commented for SMD0 is wrong.
Again... bad math...

Correct math:
Offset (0x06),
BARX, 64,//BARL,64, 0x06
BARY, 64,//BARH,64, 0x0e
Offset (0x18),
SMPR, 8, //0x18
SMST, 8, //0x19
SMAD, 8, //0x1a
SMCM, 8, //0x1b
SMDP, 256,//SMD0,256, //0x1c

You might want to read about hexadecimal (base 16), so you know how to do addition in hex...

OHHHHHHH...I get it now............Wow oooops :lolno:
I wasn't even adding in hex...
 
So for example, this:

Code:
Offset (0x47),
                CPUP,   16,
                BPWR,   16,
                PPWR,   16,
                TSR1,   8,
Would be:

Code:
Offset (0x47),
                CPUP,   16, //0x47
                BPWR,   16, //0x49
                PPWR,   16, //0x4b
                TSR1,   8,  //0x4c
 
Keep in mind there are two identifiers named SMD0.
One in root scope, in SystemMemory, 8 bits (no need for patching)
And another in _SB.PCI0.LPCB.H_EC scope, in EmbeddedControl, 256 bits (needs patching).
Don't patch code that is accessing the root scope SMD0...
How would I go about patching SMD0 in _SB.PCI0.LPCB.H_EC though?

And do I need to patch for a write buffer if:
Code:
Store (FB4, SMD0)
 
I've been using my android phone as a tether (using an app called FoxFI (you have to buy the full version for about $8 dollars) that you can use on mac, Linux, or Windows to tether your data OR WIFI connection to your computer).
Nice idea. I wasn't able to get FoxFi to work, but then I dug around and found Horndis. Seems to work pretty well using the native USB tethering on Android, and it's free. You might need to use the pre-release version, like I did.
HoRNDIS-rel8pre2-dbg.pkg
 
Nice idea. I wasn't able to get FoxFi to work, but then I dug around and found Horndis. Seems to work pretty well using the native USB tethering on Android, and it's free. You might need to use the pre-release version, like I did.
HoRNDIS-rel8pre2-dbg.pkg
Because you have to install PDANet on mac (it's free), FoxFI is the app for phone and PDANet is the client (Horndis alternative). Be careful as horndis might use data instead of wifi tethering
 
So for example, this:

Code:
Offset (0x47),
                CPUP,   16,
                BPWR,   16,
                PPWR,   16,
                TSR1,   8,
Would be:

Code:
Offset (0x47),
                CPUP,   16, //0x47
                BPWR,   16, //0x49
                PPWR,   16, //0x4b
                TSR1,   8,  //0x4c

No. Bad math again...

Correct math:
Offset (0x47),
CPUP, 16, //0x47
BPWR, 16, //0x49
PPWR, 16, //0x4b
TSR1, 8, //0x4d

Simple rule: The offset of a given field is the offset of the previous field plus the size of the previous field.

How would I go about patching SMD0 in _SB.PCI0.LPCB.H_EC though?

And do I need to patch for a write buffer if:
Code:
Store (FB4, SMD0)

That code needs to be changed to use WECB. Going from memory SMD0 is at offset 0x1c and is 256 bits... so:
WECB(0x1c, 256, FB4)
 
No. Bad math again...

Correct math:
Offset (0x47),
CPUP, 16, //0x47
BPWR, 16, //0x49
PPWR, 16, //0x4b
TSR1, 8, //0x4d

Simple rule: The offset of a given field is the offset of the previous field plus the size of the previous field.



That code needs to be changed to use WECB. Going from memory SMD0 is at offset 0x1c and is 256 bits... so:
WECB(0x1c, 256, FB4)
Got somewhat farther, but maybe a step backward at the same time. This is the most confusing part is multibyte EC fields.
 

Attachments

  • DSDT.dsl
    1.3 MB · Views: 145
Got somewhat farther, but maybe a step backward at the same time. This is the most confusing part is multibyte EC fields.

What is the question?
Note: More bad math (I stopped checking when I saw this mistake... you should check your work).

Offset (0x76),
ZDC0,8,ZDC1,8, //0x76
ZDV0,8,ZDV1,8, //0x79 (wrong: 0x76+2 is NOT 0x79)

Note: You're still patching SMD0 references that should not be patched. Let the compiler find the locations that need patching.
 
Because you have to install PDANet on mac (it's free), FoxFI is the app for phone and PDANet is the client (Horndis alternative). Be careful as horndis might use data instead of wifi tethering
Thanks for the heads up. I tested it by switching my phone onto airplane mode (turning off mobile data) and just using wifi, and that seemed to work just fine.

I don't know how much you've tested the USB C ports on the Lenovo 910, but I wanted to share my experience in case it's helpful. I have a phone with a USB C connection (OnePlus 3) and I tried connecting it to the Lenovo USB C ports with a C to C connector. This worked pretty much perfectly in macOS Sierra. I was able to mount the external device and transfer files easily, and I could also use it as an external internet connection using Horndis. It did occasionally flake out and disconnect, but I think this might be because I was using an extra long USB C to C cable, which I have heard suffers from this sort of problem.
 
Status
Not open for further replies.
Back
Top