[Kernel/FB] ScreenPad display static on FB initialization #4
Comments
|
Found a few item details from https://en.accessoires-asus.com/ regarding the Screenpad Plus:
^ Both the screenpad plus assembly and actual primary display cable have an 'EDP cable reference' id, which appear only to deviate by the length of the cable. There however appears to not be any individual catalog item for the screenpad plus's EDP cable (probably only included in the whole top-case assembly linked above). This also verifies the connector type from the datasheet @UsedDiscord provided, analyzed in #1 (comment) w/ the device schematic however pointing out a DP interface:
|
|
I've also noted in #2 (comment) that an entry for the EDID data for the screenpad plus display exists in the linux-hw repository:
#2 already confirms the validity of the EDID data present from the screenpad plus display. This can be further studied in Linux as to whether or not the display is connected to the iGPU through an eDP or a DP interface. (e.g. https://linux-hardware.org/?probe=d680085d25):
|
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
|
I don't have much idea about the technical details, but at the level of the system specs is detected with a wrong resolution, in case you didn't notice> |
|
That is interesting; I haven't noticed that at all in my testing. The 1280 x 720 resolution seems like it might be a fallback due to the odd display aspect ratio. Could you try running the below command in terminal? ioreg -l | grep -5 IODisplayEDID
This is what it should look like in system report: |
|
This is my output: |
|
Looks like many people are joining the problem! Glad to have people around :') |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Huh nothing looks wrong with the display's EDID data, and the entry otherwise looks identical to mine. I noticed a |
|
Using a mouse currently, and really glad about your efforts on making this hackintosh works. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
My device properties look like this |
|
And with that new frame buffer @Qonfused did you manage to use the second screen? or still the "analog noise" continuously there...? |
|
It also seems the injected EDID data from It might help clearing NVRAM if you've tried booting before with a different framebuffer patch? You'd have to press space in the opencore boot menu and look for a 'Clear NVRAM' option. There is also the option to clear kext cache ( |
This comment was marked as resolved.
This comment was marked as resolved.
|
Hi all, I'm now finished with University! Can you remind me, what can I do to help? I remember needing to dump some stuff? |
|
I have a debug script under To get logging from kexts, you'll also need to use debug builds of Lilu and WhateverGreen and add the ASUS-ZenBook-Duo-14-UX481-Hackintosh/src/config.yml Lines 323 to 331 in 877747d With these additional boot args, you can get kext logging from dmesg by running It may also help to include your config.plist file. The DeviceProperties section is the main interest for your specific issue if you just want to provide a screenshot instead. Feel free to create another issue here if you feel like you need more in-depth help for your specific issue (with your screenpad + primary display). |
|
Hello, I have read this thread and I've read many others, I've noticed a lot of Asus laptops have this issue on the second screen or display over HDMI. Im experiencing the same thing/similar over HDMI output. Try disable audio and see if you get a clear display output on 2nd screen/HDMI. |
|
@RobyRew By clear display output, do you mean the bottom screen works? Or is just black with working HDMI? If your screen works, what model you have and if possible, post your EFI, as I'm sure some of the smarter people are going to want it 😂 |
|
It is quite interesting this track because it seems to me that we have never studied it, however, I would like to know why the audio would cause this bug? What would be the relation between AppleALC & WhatEverGreen / Graphics of MacOS? Thanks for your help :) it's always nice to have someone help. (For the moment I'm in exam period, so I'll avoid to modify some things, I'll resume in a few weeks some tests) |
|
This would suggest a bug with how external display sinks are handled with audio, but from what I can observe, disabling or changing audio w/ AppleALC doesn't have an effect on this specific issue. A couple of internal display (connector) flags have been found to cause similar behavior with disabling external display audio + rotation.
@RobyRew Have you noticed behavior similar to my issue here (acidanthera/bugtracker#2243)? I was previously unaware of any behavior affecting HDMI devices. |
Qonfused
changed the title
|
Okay, I haven't totally finished my exams yet, but I think we should downgrade MacOS, and work on Catalina instead, indeed, according to Cobo, WhatEverGreen is harder to patch in terms of connector or Framebuffer...
I'm going to try various things soon, I'll tell you more soon :) |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
I pitched an idea to patch out HDCP initialization in the driver when I was talking to theroadw here a couple of weeks ago. Still, it seemed like he was guessing and may not actually be familiar with framebuffer behavior, so I can't vouch for the accuracy of his comments. On another note, I recently saw that the screenpad behavior initially seen from @danperks (ref) is reproducible on the (9th gen) UX581GV as well. This was already suspected although the video below (provided by @ooohlalaa) appears to be the first to confirm this: UX581GV.movI'm curious as to why this still doesn't consistently obscure the whole screen like on the UX481; there also seems to be a crop where the most salient behavior occurs. To me, this would seem like an issue with the horizontal sync width of the display; it's probably easiest to test EDID differences by injecting a display EDID from a known working UX582LV into one of the affected UX581GV/UX581LV models. While they use the same BOE085F panel, they have reported three distinct EDID profiles with different checksums. To aid this effort, I've created a repo for the UX581GV/UX581LV on parity with this project's changes. It should eventually be upstreamed here to the original UX582 project, and hopefully eliminate any configuration-specific issues. |
|
I doubt Sonoma will fix the Screenpad bug... |
|
Haven't seen any notable changes for Sonoma. KabyLake and up are still supported, so presumably none of the graphics stack should have changed. |
|
Not sure if this could be helpful but this is the EDID from my UX582. (Generated by SwitchResX.app) Also, I need to use https://github.com/xzhih/one-key-hidpi to enable HiDPI in macOS Ventura and use either RDM (https://github.com/avibrazil/RDM) or SwitchResX to switch to the HiDPI resolutions on ScreenPad. However, the only workable HiDPI resolutions are 2560x733 2048x587. The native resolution is 3820x1100. Before macOS Ventura, 1920x550 (HiDPI) worked well but now it does not work. |
|
The main differences I can see is that your display reports power management features; oddly my EDID has some redundant ASCII descriptors. I'd look into creating some custom resolutions with a display override; for HiDPI, you'd only need a 1920x550 and a 3820x1100 scale resolution to get 1920x550 HiDPI. Not sure why that's happening for you as you have both resolutions in your EDID's preferred timings (which should be respected). |
|
I removed the additional ASCII fields and injected the modified EDID, but it seems that was not problematic. Will provide it for reference as a good sanity check for EDID: # config.yml - ScreenPad BOE087F EDID injection
DeviceProperties:
Add:
PciRoot(0x0)/Pci(0x2,0x0):
AAPL01,override-no-connect: Data | <00FFFFFFFFFFFF0009E5752100000000011D0104A51F0878E4D22D9351578D28184E5200000001010101010101010101010101010101941B80A0700332203020550035531000001A121680A0700332203020550035531000001A0000000000000000000000000000000000000000000000000000000000000000000000000031> |
|
Will have to look into the i915 UEFI driver for Intel iGPUs: (context: https://www.reddit.com/r/VFIO/comments/innriq/successful_macos_catalina_with_intel_gvtg/) Came across it when discussing SR-IOV/passthrough support for macOS: https://discord.com/channels/186648463541272576/1057375050031968276/1129991118986166303 Makes a lot of sense to test with standard kernel debugging tools in a virtual machine, but so far the main challenge has been interfacing with the hardware directly. |
|
any updates on this problem? |
|
Nothing conclusive yet; unfortunately this issue has grown stale since my last update. It's hard to narrow the search path without any feedback from those unaffected by the issue. It is reproducible when passing through the hardware, and remaining issues with framebuffer initialization are still causing incorrect display data to be sent to the PCH. |
|
I was able to get the screenpad plus working for a decent bit after toggling the connector during boot (without hot-plug interrupts).
I did notice that the display still continued to work after toggling connector power a few times after the fact, but reverted after sleep (which forces hot-plug despite the device property). Here's a video showing roughly how to reproduce this; notice the timing of the last toggle: trim.7257200D-3F14-4CA5-848E-598FB77C310A.MOVAt the time I was experimenting with the below device properties: # Disables hot-plug events for the display
AAPL01,no-hotplug-interrupt | Data | 01000000
# 0x100 flag - Enables power well 2 (PW2) usage
framebuffer-con0-alldata | Data | 00000800 02000000 98010000
framebuffer-con0-enable | Data | 01000000What I figure is of the most relevance is the enabled usage of PW2 (with the |
|
Later, I was able to partially reproduce this again when trying to toggle the connector off after seeing static, then enabling again. I only briefly saw the Ventura wallpaper before it switched to black (screen is still detected, though the static is no longer present). However, after wake from sleep, the static was again present. Here's a video showing how to reproduce that behavior: 311614232-3956efce-2fa0-4b3c-b83f-8e18a46327d4.mov |
|
This may still turn out to be hard to reproduce, as so far these are triggered in a rather crude fashion similar to voltage glitching (or ghosting). This also does not persist through sleep, and will revert upon wake. I'll try to attach some more logging, etc below: boot.log.zip What is odd is that the display is detected in IORegistry and System Information, but has no corresponding display settings in System Preferences.
I still need to figure out a consistent method for debugging; I can't imagine any timing-based approach is at all a practical or portable solution. |
|
Normally when the screenpad is connected (on HPD assertion), the framebuffer controller first reads the DPCD capabilities from the display sink over the AUX channel. This is used by the driver to determine the lane count, link speed, enhanced framing, etc to be written to the link configuration field through the AUX channel. These values set the configuration parameters for link training, where the driver starts with the highest transmitter capabilities and finds a configuration the screenpad can support. Before enabling the main link (where the main data feed is sent), the driver will read the screenpad's EDID data to determine supported capabilities (particuarly the preferred resolution and timings). Curiously, this process seems to possibly have caused phase 1 link training to fail (possibly bypassing AGDC): |
|
@Qonfused You can check @wern-apfel 's repo, which has working ScreenPad. Also, you may try AI tools like, Cursor, to help you develop this hackintosh repo. You would need to dump the systems info and link the EFI files while you ask AI on how to fix your ScreenPad. You might need to describe your problem as specific as possible. |
He hasn't been open to sharing any details. I've been able to reproduce it in #4 (comment) but haven't pinpointed a precise event to investigate. I've shared steps to reproduce it in case others want to try.
Language models are universal in-context learners; they require a large corpus (and parameter size) to infer context and exhibit deduction and logical reasoning beyond basic token prediction. The trade-off is that niche (low-context) topics are very difficult for LMs to reason with as there are very few examples seen in training (and are unlikely to be absorbed as part of the model's "knowledge"). So instead, the model will prefer to solve the general description of the problem (as it has more examples in it's training data; high-context), which is too broad to give any reasonable responses to a much smaller problem domain. The work involved here requires reverse engineering a proprietary driver based on a proprietary display specification (also on proprietary display hardware). Much of what I've explained in this thread has been the first public explanation of various Apple and Intel confidential secrets. These are very esoteric systems that are far out-of-domain from what a Language model is capable of understanding even with general reasoning ability. |
Follow up to shiecldk/ASUS-ZenBook-Pro-Duo-15-OLED-UX582-Hackintosh#2 investigating scrambled screenpad plus display-out.
IMG_0838-H264_Proxy_half_size.mov
Current tasks:
The text was updated successfully, but these errors were encountered: