UHD 630 missing 5120x1440

PlutoDelic · June 4

Hi,

I have a HP EliteDesk 800 G4 Mini 65W that i have set up based on Deeveedee's repo of the same device, with the only change being the USB Mapping through Windows with USBToolBox and 3xDP DeviceProperties, as i will be using DP or HDMI (and OC + Kext updated).

I have a Samsung Odyssey Neo G9 which has a monstrous resolution of 7640x2160 in 32:9 ratio (ultrawide).

Through Windows i have it confirmed that 5120x1440@60Hz (+ HDR) works as intended in both of the devices DP 1.2 ports, and a 3rd USB-C capable of DP 1.4 ALT. For obvious reasons, 5120x1440 is the limit both the GPU and the Ports have for at least 60Hz, i am not aiming for a higher resolution.

However, macOS does not see that resolution, even with the known apps it does not show up (tested with RDM, BetterDisplay, SwitchResX). Best i can get is 3840x1080@120Hz (+ HDR).

When i switch the monitor settings from DP 2.1 to DP 1.4, the resolution of 4K@60Hz becomes available in 16:9 ratio, but it really is not useful.

I've tried the default recommendation for the DeviceProperties, and edited my own one with custom connectors/pipes, but nothing seems to get the resolution to show.

Would really appreciate any input on this, it is pretty much the only setting that is stopping me from calling this a complete working setup.

EFI Tree

config.plist

DeviceProperties screenshot for quick look

Edited June 4 by PlutoDelic

joevt · June 5

Which macOS version are you using? I think you need at least Big Sur.

https://forums.macrumors.com/threads/intel-graphics-and-5120x1440-testing-in-big-sur.2244174/

PlutoDelic · June 5

17 hours ago, joevt said:

Which macOS version are you using? I think you need at least Big Sur.

https://forums.macrumors.com/threads/intel-graphics-and-5120x1440-testing-in-big-sur.2244174/

I am in Sonoma 14.5. I see you're the author of that thread.

Collectables

This is a Coffee Lake device. i5-8500, 48GB RAM.

I see that you did collect quite a few information for the 32:9's, do you need anything from mine, EDID export, etc? The collected information is showing i have two displays, i have no idea how that happened but i suspect it's one of the Apps such as BetterDisplay that caused it, as i certainly am not seeing that resolution reported there (OSD confirms it too).

In your thread, i see that you've maintained a fork of WhateverGreen, but i could not find it. Is igfxmaxscale=16383 part of the main whatevergreen?

EDIT: EDID Info

Edited June 5 by PlutoDelic

joevt · June 6

I don't think you need WhateverGreen patches as long as your display's EDID has a 5120 mode in the EDID. The EDID you posted does not include a 5120 mode.

The Graphics/Displays info says mirroring is enabled. What if you disable that?

Is the display connected with 4 lanes of DisplayPort?

Maybe try AllRez to get info from the display. https://github.com/joevt/AllRez

allrez > samsung_allrez.txt

zip the result and attach to a new post.

Get the allrez output for each port of the display.

HDMI

DisplayPort

USB-C

PlutoDelic · June 6

@joevt Thanks for taking your time for this, really appreciate it.

I've done an AllRex extract for all the 3 ports i have, and re-done them again with the EDID injection removed from config.plist in case if it affects the results.

With EDID Injection
1. DP1.2_Port1
2. DP1.2_Port2
3. USB-C_DP_ALT_DP1.4_Port3 (Part 1, Part 2)
Without EDID injection

At the moment, i do not have a HDMI source in the computer, but that should arrive in about two weeks (it's a module that i can exchange with the USB-C one).

Port 1 and 2 = DP to DP (DP 2.1 Cable, Monitor set to 1.4 Mode)

Port 3 = USB-C to HDMI 2.0

EDIT: EDID in Windows is not showing any different.

EDIT: When i stop mirroring. - OSD reports 4K. Display becomes 16:9 with what seems a pseudoresolution.

When i disable mirroring, i lose the home screen as it thinks i have two displays. It does this only in Port 2 and USB C Port, but not in Port 1.

No information about DP Lanes i'm afraid, first time i'm hearing about it.

EDIT: EDID Dump in my main machine, running at 7640x2160@120Hz + HDR is also reporting only 3820x1080 as max supported display mode.

Edited June 6 by PlutoDelic

joevt · June 7

I don't think the AllRez output was affected by EDID injection. I think EDID injection by Open Core doesn't affect macOS. It only affects the UEFI environment.

The only 32:9 mode currently available to you is 3840x2160 60Hz and 120Hz. You want a 5120x1440 60Hz mode which should be possible since it requires less bandwidth than 4K60.


"DP1.2_Port1.txt"                   # correct for monitor[0]
"DP1.2_Port1 2.txt"                 # correct for monitor[0]
"DP1.2_Port2 2.txt"                 # correct for monitor[0]
"DP1.2_Port2.txt"                   # correct for monitor[0]        ; missing extension blocks for monitor[1]
"USB-C_DP_ALT_DP1.4_Port3 2.txt"    # HDMI connection for monitor[0]
"USB-C_DP_ALT_DP1.4_Port3.txt"      # HDMI connection for monitor[0]; missing extension blocks for monitor[1]

I'm not sure why "DP1.2_Port2.txt" and "USB-C_DP_ALT_DP1.4_Port3.txt" report two displays. I can only see one connection in the AGDCDiagnose output. The other two Intel ports report "DDC Failed" just like all the other AllRez output files.

"USB-C_DP_ALT_DP1.4_Port3" is strange. It's a DisplayPort connection with HDMI adapter?

The 5120x1440 and 7680x2160 modes are in the 2nd extension block for the DP connected setups. Sometime Windows doesn't show more than 1 extension block after the base block? Did you try using CRU to dump the EDID in Windows? You might get better results with a different GPU (AMD vs Nvidia vs Intel).

As for MacOS, the reason it's not giving you a 5120x1440 mode is because something changed since the last version of macOS that was tested in that MacRumors thread (try Big Sur?) or because the display is larger than 5120. In either case, maybe my WhateverGreen patches can help? But you have to compile all your Lilu based kexts (including my WhateverGreen kext) with my Lilu code. Which Lilu based kexts are enabled in your config.plist?

EDID from PlutoDelic.zip

PlutoDelic · June 7

8 hours ago, joevt said:

"USB-C_DP_ALT_DP1.4_Port3" is strange. It's a DisplayPort connection with HDMI adapter?

Yes. I'm not sure if my choice to make the pipe connector to HDMI was logical in this case. Logically the Signal is still DisplayPort.

8 hours ago, joevt said:

The 5120x1440 and 7680x2160 modes are in the 2nd extension block for the DP connected setups. Sometime Windows doesn't show more than 1 extension block after the base block? Did you try using CRU to dump the EDID in Windows? You might get better results with a different GPU (AMD vs Nvidia vs Intel).

They look similar to what i extracted from macOS, but three different entries. CRU Active, CRU Second and CRU Third. Extracted from my main machine with an AMD 7900XTX. I'll see what the Intel iGPU extracts from Windows in a bit.

8 hours ago, joevt said:

As for MacOS, the reason it's not giving you a 5120x1440 mode is because something changed since the last version of macOS that was tested in that MacRumors thread (try Big Sur?) or because the display is larger than 5120. In either case, maybe my WhateverGreen patches can help? But you have to compile all your Lilu based kexts (including my WhateverGreen kext) with my Lilu code. Which Lilu based kexts are enabled in your config.plist?

KEXT List , just the usual suspects, and if my knowledge is correct, VirtualSMC (+ plugins), WEG and AppleALC, the rest are based on the hardware config.

These two are your patch repos, right:
https://github.com/joevt/Lilu

https://github.com/joevt/WhateverGreen

I've seen your compiling guide in the macrumours thread, i'll try my best to see if i can manage to go through it, that might be my last resort, as from the looks of everything, the arrival of the HDMI 2.0 module won't do much of a difference.

PS, again thanks for taking your time to respond, it's rare to meet someone's patience and willingness to help nowadays.

joevt · June 8

15 hours ago, PlutoDelic said:

Yes. I'm not sure if my choice to make the pipe connector to HDMI was logical in this case. Logically the Signal is still DisplayPort.

They look similar to what i extracted from macOS, but three different entries. CRU Active, CRU Second and CRU Third. Extracted from my main machine with an AMD 7900XTX. I'll see what the Intel iGPU extracts from Windows in a bit.

KEXT List , just the usual suspects, and if my knowledge is correct, VirtualSMC (+ plugins), WEG and AppleALC, the rest are based on the hardware config.

These two are your patch repos, right:
https://github.com/joevt/Lilu

https://github.com/joevt/WhateverGreen

I've seen your compiling guide in the macrumours thread, i'll try my best to see if i can manage to go through it, that might be my last resort, as from the looks of everything, the arrival of the HDMI 2.0 module won't do much of a difference.

PS, again thanks for taking your time to respond, it's rare to meet someone's patience and willingness to help nowadays.

I still don't understand. What did you use to connect to the USB-C port of the display to get the USB-C_DP_ALT_DP1.4_Port3 result (display product 29648) ?

CRU Active matches the DP1.2 EDIDs (display product 29814 with all extension blocks intact)

CRU Second is missing the extension blocks - it just contains the base block (display product 29814) same as the monitor[1] results (2nd monitor connection).

CRU Third is new (display product 29815). Where did this one come from?

- It doubles the frequency range from 48-120Hz to 96-240Hz, max pixel clock from 2230 MHz to 2380 MHz.

- It contains a 3rd extension block.

- It drops HDMI VICs for 1920x1080 120Hz and 3840x2160 120Hz

- It drops 120Hz timings for 1440p and 3840x1080.

- It drops 120Hz timings for 7680x2160 and 5120x1440.

- It adds 240Hz timings for 5120x1440, 4K, and 1080p.

- It adds 240Hz timings for 3840x1080, and 1440p.

Yes, joevt/* are my repos. I haven't updated them recently with latest Lilu/WhateverGreen changes. Maybe check the upstream versions to see if they have options that allow 5120 modes?

PlutoDelic · June 8

The USB-C interface is in the Source side.

USB-C Module (will soon replace with HDMI Module) > USB-C to HDMI Adapter > Display HDMI Port

Regarding the third CRU output, the 3rd profile showing in my Windows machine, i'm assuming it's seeing DP 2.1 info? Nevertheless, let me try that EDID output in OpenCore, it does indeed have a lot mor information.

Edited June 8 by PlutoDelic

joevt · June 8

3 hours ago, PlutoDelic said:

The USB-C interface is in the Source side.

USB-C Module (will soon replace with HDMI Module) > USB-C to HDMI Adapter > Display HDMI Port

Regarding the third CRU output, the 3rd profile showing in my Windows machine, i'm assuming it's seeing DP 2.1 info? Nevertheless, let me try that EDID output in OpenCore, it does indeed have a lot mor information.

I thought the display had a USB-C port? You said "both of the devices DP 1.2 ports, and a 3rd USB-C capable of DP 1. ALT". Is the device referring to the laptop or the display? I think it must be referring to laptop (but previously I thought it was display) because the Samsung product page for the G95NC only has one DisplayPort input (instead of 2) and 3 HDMI inputs.

I requested AllRez output for all ports of the display, but AllRez output for all ports of the laptop is also useful, to determine which GPU in the laptop is connected to each port (for laptops that have more than one GPU).

I don't think OpenCore EDID override affects the OS? I'm not 100% sure so it's worth a try.

I've updated my MacKernelSDK, Lilu, and WhateverGreen forks with the latest upstream changes but I haven't tested it yet.

The following command will check which kexts in the OpenCore kexts directory uses Lilu:


cd /Volumes/OPENCOREWD/EFI/OC/Kexts
grep --include Info.plist -R Lilu . | uniq

Change OPENCOREWD to match the name of the volume containing OpenCore.

PlutoDelic · June 8

Wouldn't be surprised if i confused you, sorry about that, by device i always assumed the PC, which is a small desktop.

Samsung Display has 1x DP (2.1) and 3x HDMI (2.1).

HP EliteDesk has two Built-in DP 1.2 ports and the modular USB-C (pic included has any empty module between the two USB pairs).

Regarding the all rez extracts, i thought you wanted AllRez from the ports of the computer side. I can either connect them DP to DP, or USB-C to HDMI.

LILU based Kext's

And some side notes, i found out the reason why the display was showing twice in macOS (the mirroring drama). The EDID Inject in DeviceProperties is PORT Specific which i did not know (AAPL00,override-no-connect, AAPL01,override-no-connect, etc).

I've also managed to inject the EDID kext with the values of the new info from CRU, but no results.

I guess i played all my cards, let's see if i am capable of compiling everything.

joevt · June 9

Not sure why I was thinking laptop but I think I understand everything now.

I tested my Lilu and WhateverGreen on a Macmini8,1 running Sonoma 14.5. I didn't test all the patches but I did verify that it can output 5120x1440 60Hz and 5120x2880 30Hz using DisplayPort. I don't think my Acer XV273K can accept > 4K via HDMI so I didn't test the HDMI port of the Mac mini.

I've attached the Lilu based kexts compiled on my Monterey 12.7.2 Hackintosh. I only tested Lilu and WhateverGreen.

Isn't IntelBTPatcher.kext obsoleted by IntelBluetoothFirmware.kext? I don't know for sure. I haven't used either of them. You had IntelBluetoothFirmware.kext in the list of Open Core kexts but not in the list of Lilu kexts.

The Lilu log in /var/log indicates that 3 displaypolicyd (dpd) user patches were performed successfully.

The Lilu log also indicates that kext load callbacks were performed for IOGraphicsFamily, AppleIntelCFLGraphicsFramebuffer, and AppleIntelKBLGraphics.

I used these boot-args in my OpenCore config.plist:

-liludbgall liludump=240 -lilubetaall -iofbon -cfdon dpd=3 igfxmaxwidth=16384 igfxmaxheight=16380 igfxmaxscale=16383

After creating the 5K custom timings in SwitchResX, I had to disconnect and reconnect the display for the timings to appear in the current resolutions list since the "Activate Immediately" button doesn't seem to work in Sonoma.

Hopefully you won't need to use SwitchResX to create the 5120x1440 60Hz timing since it exists in your display's EDID.

Latest Lilu Kexts joevt.zip

PlutoDelic · June 9

1 hour ago, joevt said:

I've attached the Lilu based kexts compiled on my Monterey 12.7.2 Hackintosh. I only tested Lilu and WhateverGreen.

I'll test it right away. Should feedback pretty soon. Thanks a lot.

1 hour ago, joevt said:

Isn't IntelBTPatcher.kext obsoleted by IntelBluetoothFirmware.kext? I don't know for sure. I haven't used either of them. You had IntelBluetoothFirmware.kext in the list of Open Core kexts but not in the list of Lilu kexts.

Per OpenIntel's , you need IntelBTPatcher.kext and IntelBluetoothFirmware.kext from their package, combined with BlueToolFixup.kext from BcrmPatchRAM to get BT to work post Monterey and up. Needs the 255 flag in USBMap and it works flawlessly.

1 hour ago, joevt said:

After creating the 5K custom timings in SwitchResX, I had to disconnect and reconnect the display for the timings to appear in the current resolutions list since the "Activate Immediately" button doesn't seem to work in Sonoma.

Hopefully you won't need to use SwitchResX to create the 5120x1440 60Hz timing since it exists in your display's EDID.

Glad it wasn't just me. The Beta version seems to have it function better but i faced that issue so much that it made me give up on the app.

As per EDID, things just become better and better. The USB-C to HDMI cable, for some reason i lost 5120x1440 in Windows. In macOS, if i inject the 7477 EDID to it, i get 3820x1080@120Hz, without it max it can do is 60Hz.

PlutoDelic · June 9

Sadly no success even with the new kexts.

LILU LOG

The USB-C port managed to switch to a scaled 5120x1440 (monitor still showed a 3820x1080 signal), and on the DP 1.2 ports, when i tried the correct 5120x1440 through SwitchResX, monitor changes to 4K output and turns off. And only through SwitchResX, the Display settings itself does not have that resolution.

Now the EDID is reporting ID 73D0. The ones in Windows were 7476 and 7477. The more things i try, the more variables turn up. I've managed to confuse myself to the point of not seeing any hope for this.

joevt · June 10

Maybe change liludump=240 to liludump=360. The log will be added to the /var/log after 6 minutes which should be plenty of time.

Try without EDID ejection.

Use SwitchResX to "Restore factory settings", or delete the override file at /Library/Displays/Contents/Resources/Overrides

- DisplayVendorID-4c2d/DisplayProductID-????
- DisplayVendorID-4c2d/DisplayYearManufacture-????-DisplayWeekManufacture-??

Reconnect the display after the override file is no longer present or any time you update the override file.

Post your config.plist.

Use DisplayPort only (or USB-C to DisplayPort).

If the mode appears in SwitchResX (current resolutions list), it should appear in Displays preferences panel. You may need to select "Show all modes".

Post a new AllRez dump showing the new 5120x1440 60Hz mode.

PlutoDelic · June 10

I haven't used EDID patches or injection on the last trials. But i've been using Hackintool to reproduce something i did earlier, and it just wont do it again.

And the 5120x1440 in SwitchResX is scaled, it still stays 3820x1080 in the display.

This is the AllRez from the DP port. It finds DisplayProductID = 29814 (0x7476);, but 29815 (0x7477) from Windows is not showing up and i managed to get Hackintool to extract a patch for it once. Don't see any surprise inside. There must be a way to force macOS to see and use 0x7477 instead of 0x7476.

config.plist / LILU DUMP

joevt · June 12

The 29814 (0x7476) product is ok as long as it has all the extension blocks, as your latest AllRez has. Strange thing is the EDID in the latest AllRez has preferred modes set to 5120x1440 60Hz and 120Hz, but previously, the preferred modes were 7680x2160 120Hz and 60Hz. The both have the same list of modes but in a different order for those 4 timings. Did you change a setting on the display?

I don't think we gain anything from the 29815 (0x7477) EDID unless you have a GPU that can use the 240Hz modes in macOS.

The AllRez doesn't show the desired 5120x1440 modes but LILU DUMP shows the necessary patches were made just as the previous LILU LOG did.

In the config.plist, -cfdon should be replaced with -cdfon

cdf stands for CoreDisplay framework. I don't think this is required for the 5K patch? I need to do some testing.

You can also maybe try adding msgbuf=1048576 and -v

I don't know if msgbuf matters. My lilu log appears to be larger than that, ≈ 2.2MB so it's maybe not related to lilu log?

I don't think igfxonln=1 igfxagdc=0 igfxfw=2 should have any affect on the 5K patch but I haven't tried them.

I should have given you the debug version of WhateverGreen. It will add a lot more useful info to the Lilu log. It will show what the graphics driver is doing, what modes it's validating, etc.

According to the WhateverGreen source code, if you have the igfxmaxwidth option, then the following will get patched:

getMaxTiming,

ValidateSourceSize,

ComputeTransformAndSetDimensions_Internal,

initTransactionCaps

The wrappers for each of those should get executed and appear in the Lilu log.

joevt WhateverGreen-1.6.7-DEBUG.zip

PlutoDelic · June 12

The only monitor change i do is change from DP 1.4/2.1 when i hit a resolution test that scrambles my display. In 2.1 it goes frenzy, when i switch to 1.4 it returns to its sanity, but i usually revert back.

LILU Logs

joevt · June 12

All your Lilu logs are too short, only ≈139 KB. They should be more like 2.2 MB. Maybe you do need msgbuf=1048576

The logs don't include timestamps so I can't tell if it's doing a full 6 minutes or not.

Please try the debug version of WhateverGreen attached to my previous post.

PlutoDelic · June 12

I did, both the debug kext and the added boot argument. Maybe OC needs the Debug option active as well? I made sure i waited 6 minutes before pulling it.

joevt · June 13

When looking at the /var/log directory, sort by Date Modified in reverse order so the latest Lilu log is at the top. Verify that the modification date is the correct time for this boot.

The last Lilu Log says "WhateverGreen bootstrap REL-167-2024-06-08" but it should be the new one that I attached "DBG-167-2024-06-09"

Did you replace the WhateverGreen in your OC Kexts folder?

PlutoDelic · June 13

Absolutely, i just redid it once again as i was starting to doubt myself.

Lilu       api: @ (DBG) got load request from WhateverGreen (167)
WhateverGreen      init: @ WhateverGreen bootstrap REL-167-2024-06-08

Copied from "joevt WhateverGreen-1.6.7-DEBUG.zip"

joevt · June 14

Open the WhateverGreen binary and search for the string DBG-167 or REL-167. It should be DBG-167.

Or use the strings and egrep command like this:

strings WhateverGreen.kext/Contents/MacOS/WhateverGreen | egrep '\d{4}(-\d{2}){2}'

Do you have more than one WhateverGreen.kext?

find /Volumes/OpenCoreVolume /System/Library/Extensions /Library/Extensions -name 'WhateverGreen.kext'

Maybe delete the old log file so you can make sure a new one is created.

Edited June 14 by joevt

PlutoDelic · June 14

Huh, OC was using the disabled WEG kext, maybe because i copied the line and renamed it W...joevt.kext. I renamed your one to the stock name and it loaded correctly.

With that said, here's the fat log.

Again, thanks for sticking with me in this. Every day i log in, i am humbled seeing you patiently responding to every weird obstacle of mine.

Lilu_1.6.8_23.5.txt

joevt · June 14

Maybe it's a bug in OC? Your config.plist had the following:


      13 => {
        "Arch" => "x86_64"
        "BundlePath" => "WhateverGreen_joevt.kext"
        "Comment" => "Video patches"
        "Enabled" => 1
        "ExecutablePath" => "Contents/MacOS/WhateverGreen"
        "MaxKernel" => ""
        "MinKernel" => "12.0.0"
        "PlistPath" => "Contents/Info.plist"
      }
      14 => {
        "Arch" => "x86_64"
        "BundlePath" => "WhateverGreen.kext"
        "Comment" => "Video patches"
        "Enabled" => 0
        "ExecutablePath" => "Contents/MacOS/WhateverGreen"
        "MaxKernel" => ""
        "MinKernel" => "12.0.0"
        "PlistPath" => "Contents/Info.plist"
      }

It seems like it should have loaded the WhateverGreen_joevt.kext version. Is OC not honoring the BundlePath?

You have some properties which might be interfering with a required patch:


      "PciRoot(0x0)/Pci(0x2,0x0)" => {
        "AAPL,GfxYTile" => {01000000}
        "AAPL,ig-platform-id" => {07009b3e}
        "device_type" => "VGA compatible controller"
        "device-id" => {9b3e0000}
        "enable-hdmi20" => {01000000}
        "enable-lspcon-support" => {01000000}
        "enable-metal" => {01000000}
        "force-online" => {01000000}
        "framebuffer-patch-enable" => {01000000}
        "graphic-options" => {0c000000}
        "rps-control" => {01000000}
      }

Do you need all of these? Do you need force-online? Do you need AGDCDisabler? etc.

You have a hackintosh so maybe some of those are necessary. I have a real MacMini8,1 and don't use any of those settings.

One issue I see is that the wrapGetMaxTiming method isn't getting called. It's the method that overrides the max width and height.

At the time wrapGetMaxTiming is expected to be called, your log has this:


Lilu    config: @ (DBG) PE_initialize_console 7
WhateverGreen      igfx: @ (DBG) getDisplayStatus forces 1
WhateverGreen      igfx: @ (DBG) SC: GetDPCDInfo() DInfo: Start to configure the LSPCON adapter.
WhateverGreen      igfx: @ (DBG) SC: fbSetupLSPCON() DInfo: [FB0] called with controller at 0xffffff954d036000 and framebuffer at 0xffffffc1ff74f000.
WhateverGreen      igfx: @ (DBG) SC: fbSetupLSPCON() DInfo: [FB0] No LSPCON chip associated with this framebuffer.
WhateverGreen      igfx: @ (DBG) SC: GetDPCDInfo() DInfo: Finished configuring the LSPCON adapter.
WhateverGreen      igfx: @ (DBG) SC: GetDPCDInfo() DInfo: Will call the original method.
WhateverGreen      igfx: @ (DBG) SC: GetDPCDInfo() DInfo: Returns 0x0.
WhateverGreen      igfx: @ (DBG) getDisplayStatus forces 1
WhateverGreen      igfx: @ (DBG) getDisplayStatus forces 1

but my log has this:


Lilu    config: @ (DBG) PE_initialize_console 7
WhateverGreen      igfx: @ (DBG) wrapGetMaxTiming: 3840x2160 override:16384x16380 r:0

When it comes time to validate active:5120x1440, your log has this:


WhateverGreen      igfx: @ (DBG) [ IGFX::wrapValidateSourceSize
WhateverGreen      igfx: @ (DBG) [ IGFX::wrapComputeTransformAndSetDimensions_Internal detailedTiming = { V2 id:0x00000000 5120x1440@59.976Hz 88.825kHz 469.000MHz (errMHz 0.0,0.0)  h(48 32 80 +)  v(3 10 28 -)  border(h0:0 v0:0)  active:5120x1440 (not scaled) inset:0x0 flags(0°,) signal() levels:0714_0286 links:2 vbext:0 vbstretch:0 vbshrink:0 encodings(RGB,) bpc(10,) colorimetry(NativeRGB,) dynamicrange(TraditionalGammaSDR,) dsc(0x0 0.0bpp) }
WhateverGreen      igfx: @ (DBG) ] IGFX::wrapComputeTransformAndSetDimensions_Internal transform = { 5120,1440,5120,1440,5120,1440,20480,1 }
WhateverGreen      igfx: @ (DBG) ] IGFX::wrapValidateSourceSize result:false

but my log has this:


WhateverGreen      igfx: @ (DBG) [ IGFX::wrapValidateSourceSize
WhateverGreen      igfx: @ (DBG) [ IGFX::wrapComputeTransformAndSetDimensions_Internal detailedTiming = { V2 id:0x00000000 5120x1440@59.984Hz 88.837kHz 469.060MHz (errMHz 0.0,0.0)  h(48 32 80 +)  v(3 10 28 -)  border(h0:0 v0:0)  active:5120x1440 (not scaled) inset:0x0 flags(0°,) signal() levels:0714_0286 links:1 vbext:0 vbstretch:0 vbshrink:0 encodings(RGB,) bpc(10,) colorimetry(NativeRGB,) dynamicrange(TraditionalGammaSDR,) dsc(0x0 0.0bpp) }
WhateverGreen      igfx: @ (DBG) ] IGFX::wrapComputeTransformAndSetDimensions_Internal transform = { 5120,1440,5120,1440,5120,1440,20480,1 }
WhateverGreen      igfx: @ (DBG) ] IGFX::wrapValidateSourceSize result:true

Lilu_1.6.8_23.5 joevt.txt.zip

UHD 630 missing 5120x1440

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites