- Joined
- Nov 1, 2014
- Messages
- 12
- Motherboard
- Lenovo m93p tiny
- CPU
- i5-4570T
- Graphics
- hd4600
- Mac
- Classic Mac
- Mobile Phone
Hello,
Please help me debug this; not sure if it's a bad monitor or bug with Chimera. Let me know if it should be in the bug reports section.
The setup:
The problem:
Extra notes:
Please help me debug this; not sure if it's a bad monitor or bug with Chimera. Let me know if it should be in the bug reports section.
The setup:
- Asus PB287Q 4k/UHD display (native 3840x2160@60Hz)
- Lenovo m93p desktop with HD4600 / Q87 Haswell / Core i5-4570T. DisplayPort and HDMI inputs, although the HDMI input is an optional add-on due to the small case (smaller and more powerful than Mac Mini )
- Monitor works great at native 60Hz in Ubuntu / Windows 8.1 connected via DisplayPort
- All symptoms the same no matter how much VRAM I pre-allocate in the BIOS
- Boot.plist options are:
- DropSSDT=yes
- EthernetBuiltIn=yes
- GraphicsEnabler=yes
- HDAEnabler=yes
- HDEFLayoutID=01000000
- IGPEnabler=yes
- Kernel Flags=kext-dev-mode=1
- Legacy Logo=yes
- Timeout=2
The problem:
- Booting chimera 4.0.1 from an old ViewSonic display using a VGA -> DP adapter works fine, all OS X settings and usefulness work as expected
- Booting from the Asus using HDMI input boots fine, but resolutions available in OS X do not include options over 1920x1080 (not sure if related, but at least it boots)
- Booting from the Asus using DisplayPort input results in: "Memory allocation error! Addr: 0xdeadbeef, Size: 0x0, File: gui.c, Line:505 This is a non recoverable error! System HALTED!!!"
- Booting with GUI=no in the Boot.plist at least gives me the Chimera boot prompt, but if I let it boot, it very quickly results in a reboot loop; ~15 blue smiley faces are displayed immediately and the PC reboots
- If I boot with -x and -v at that point, it'll load a bunch of kexts before it reboots
- Big freaking clue that ties back to the gui.c error: when I do a ?video at the chimera prompt on all input methods described above, I see mostly normal graphics modes EXCEPT for DisplayPort to the Asus where I see an entire list of "0x0x0 mm:0 attr:0" for all modes listed.
- Is this a hint that something in the Monitor is screwed up or that there's a bug with Chimera? Or neither?
Extra notes:
- Clover boots into a funky video state as well with Asus via DisplayPort when I've tried it. I get a nice pretty boot screen with clover and the DisplayPort -> VGA adapter on the ViewSonic.
- I've tried all sorts of different SMBIOS and IGPEnabler / GraphicsEnabler combos
- No matter what else I've tried, I can't get OS X to allow a 3840x2160 display mode when I hot plug the Asus via DisplayPort after a successful boot with a different input type. Again, other OSes work great with that resolution and the HD4600 can indeed output 3840x2160@60Hz via DisplayPort 1.2 with my processor type.
- Tried the pixel clock / IOKit patch
- Tried a custom Overrides with EDID and scaled-resolutions
- Tried my best with SwitchResX once booted / hot plugged
- The relevant line from gui.c makes sense; it tries to malloc(0) because it doesn't find any supported modes / heights / widths. So I guess the question is: how do the modes get there in the first place?
- gui.backbuffer->pixels = malloc( window->width * window->height * 4);