Dell XPS 15 (9530) - Intel HD 4600 Graphics on QHD+ built-in display - Need some help

[the-darkvoid]

Ok so clicking "sleep" from the OS X menu acts like sleep in Windows.
The laptop lights fully go off and no indication is visible anywhere, opening the lid pops up with OSX (or Windows) immediately.

Everything seems to work as expected. Audio and wifi USB come back up.

Logs show the following:

Previous Sleep Cause: 5
The USB device HubDevice (Port 1 of Hub at 0x1a000000) may have caused a wake by issuing a remote wakeup (2)
The USB device HubDevice (Port 1 of Hub at 0x1d000000) may have caused a wake by issuing a remote wakeup (2)
ApplePS2SynapticsTouchPad: Unexpected byte0 data (00) from PS/2 controller
The USB device Integrated_Webcam_HD (Port 5 of Hub at 0x1a100000) may have caused a wake by being disconnected
SBF:    604.530    AppleUSBHubPort::FatalError - Port 2 of Hub at 0x1d100000 reported error 0xe0004061 while doing get status (first in port status change)
USBF:    604.530    AppleUSBHubPort::FatalError - Port 5 of Hub at 0x1d100000 reported error 0xe0004061 while doing get status (first in port status change)
TCON: Aux ready at HW
en1: attached with 2 suspended link-layer multicast membership(s)
en1: successfully restored 2 suspended link-layer multicast membership(s) (err=0)

Rehabman, those logs seem ok?

 

[RehabMan]

Ok so clicking "sleep" from the OS X menu acts like sleep in Windows.
The laptop lights fully go off and no indication is visible anywhere, opening the lid pops up with OSX (or Windows) immediately.

Everything seems to work as expected. Audio and wifi USB come back up.

Logs show the following:

Previous Sleep Cause: 5
The USB device HubDevice (Port 1 of Hub at 0x1a000000) may have caused a wake by issuing a remote wakeup (2)
The USB device HubDevice (Port 1 of Hub at 0x1d000000) may have caused a wake by issuing a remote wakeup (2)
ApplePS2SynapticsTouchPad: Unexpected byte0 data (00) from PS/2 controller
The USB device Integrated_Webcam_HD (Port 5 of Hub at 0x1a100000) may have caused a wake by being disconnected
SBF:    604.530    AppleUSBHubPort::FatalError - Port 2 of Hub at 0x1d100000 reported error 0xe0004061 while doing get status (first in port status change)
USBF:    604.530    AppleUSBHubPort::FatalError - Port 5 of Hub at 0x1d100000 reported error 0xe0004061 while doing get status (first in port status change)
TCON: Aux ready at HW
en1: attached with 2 suspended link-layer multicast membership(s)
en1: successfully restored 2 suspended link-layer multicast membership(s) (err=0)

Rehabman, those logs seem ok?

If everything is working, then no problem...

 

[DaviDemon]

Right well I've read through this whole thread hopefully it'll bring light to my situation.

Currently running OS X 10.9.4, QE/CI works and FHD with a HD4400 (I know this thread is about 4600 but they're almost same I believe?) Only issue is (as being described here??) is that there is a mismatch between allocated memory for the graphics. Running on a Sony laptop I haven't found a method to unlock the bios to change such a setting so I'm asking, is it possible to patch FBAzul to match the allocated memory rather than the former (editing bios to match memory).

Reason to believe that rolling back kexts and such do not work for my system is because it's using eDP and I heard that's not fully supported yet. In OS X It reports as LVDS so I was wondering how do I patch it so it would be recognised properly or something. Not sure how to put it in proper terms..

 

[RehabMan]

Right well I've read through this whole thread hopefully it'll bring light to my situation.

Currently running OS X 10.9.4, QE/CI works and FHD with a HD4400 (I know this thread is about 4600 but they're almost same I believe?) Only issue is (as being described here??) is that there is a mismatch between allocated memory for the graphics. Running on a Sony laptop I haven't found a method to unlock the bios to change such a setting so I'm asking, is it possible to patch FBAzul to match the allocated memory rather than the former (editing bios to match memory).

Reason to believe that rolling back kexts and such do not work for my system is because it's using eDP and I heard that's not fully supported yet. In OS X It reports as LVDS so I was wondering how do I patch it so it would be recognised properly or something. Not sure how to put it in proper terms..

If you find a reliable way of determining the IGPU memory window as set by BIOS let me know...

You could always use a process of trial/error...

 

[DaviDemon]

With a locked BIOS I don't think it's possible through those means, but trial and error seems like the only viable option. I know in Windows I get around 17xxmb of shared graphics memory whereas OS X reports only 1536. Maybe it's missing some?

 

[RehabMan]

... I know in Windows I get around 17xxmb of shared graphics memory whereas OS X reports only 1536. Maybe it's missing some?

That is something completely unrelated.

 

[DaviDemon]

Well anyway, still doesn't answer artifacts caused by a mismatch of allocated memory and the framebuffer. Still have no idea how to patch connector tables either lol

 

[RehabMan]

Well anyway, still doesn't answer artifacts caused by a mismatch of allocated memory and the framebuffer. Still have no idea how to patch connector tables either lol

How do you know if you haven't patched the framebuffer...

 

[DaviDemon]

I thought that was generally the case... That if OS X requires x amount of iGPU memory but the system isn't allowing it, problems occur like artifacting.
If that is incorrect then so be it I'll just live with it.

 

[RehabMan]

I thought that was generally the case... That if OS X requires x amount of iGPU memory but the system isn't allowing it, problems occur like artifacting.
If that is incorrect then so be it I'll just live with it.

The IGPU aperture size is different than the total amount of system memory used by the driver. I'm not 100% clear on the details, but I suspect that the IGPU aperture is the size of the memory window used to communicate from the CPU to the GPU. The physical memory addresses would be off-limits for use by the system.

I've never done any development work on video drivers, so I'm probably off on my thought in some way, as it is the kind of thing only someone who has done video driver development would truly understand.