Open patmagauran opened 4 years ago
Great to hear that you want to work on this!
The EDID is indeed the most critical issue that needs to be solved. The main problem with EDID is that I have tried all EDID-reading channels I found in the kernel code. It actually works inside GVT-g, but none of the channels return anything on my real hardware. You can re-enable the ReadEDID function and see what it does on your machine.
I must have missed something. Maybe some setup is needed to establish the I2C channel. Or maybe there are more EDID-reading channels than I've found.
More issues I've found on handling hardware combinations:
Update: I was able to setup my workspace and lo-and-behold it actually worked! Using direct passthrough, I had a full-resolution display on both a 4k@30 and 2560x1080@60 monitors. I do need to note however, that the 4k monitor required the 2nd timing descriptor because I only have an HDMI 1.4 port(max 4k@30). The code defaulted to the first descriptor, making an unusable signal. The code read the EDID values and they are correct to the monitors tested.
Meanwhile, I will look into the other issues you mentioned.
After doing some research, I believe my next step should be configuring support for displayport/eDP. It requires a different intialization sequence than HDMI.
Just though I'd give an update. I have successfully implemented eDP to work on my setup. It should work on other skylk+ platforms as well. I do believe DP may not work due to some quick changes I made while testing, but they should be easily fixed. Sadly, I cannot easily test DP with my laptop.(Possibly over USB-C, but that may not work with a VM in the first place).
As for implementing broader support, it appears that Most of the changes in sequence are between die size generations(Ex 22 vs 14 vs 10 nm). So this code should work for intel's Core products that are 14nm(Skylake, Kaby lake, Coffee Lake, Amber Lake, Whiskey Lake, Comet Lake).
As a note, A lot of the DP code is copy and pasted from the Linux Kernel, so I will need to work on the attributions.
Regarding EDID, why not read it on Linux from /sys/devices/pci/... and pass it to the VM via fw_cfg? The driver could read it, the same way it reads the opregion.
Was support for Comet Lake ever compiled and released anywhere? I'm trying to set up an OMVF MacOS VM with a passthrough iGPU and the rabbit hole has lead to this page.
I have successfully integrated much better hardware support on my fork of the repo. I also have a pre-compiled version. https://github.com/RotatingFans/i915ovmfPkg
I am looking to see if I can get this to work across a wider range of hardware. Looking at the code, it seems the two limitations that are present are the hardcoded EDID values and the hardcoded values for the GPU ports. I assume if we could actually read the full EDID values from the real display, that would improve compatibility greatly on the display side. On the GPU/CPU side, we would need to define the appropriate properties for each generation.
Looking at the linux kernel, it appears that is where most of the properties come from, and very few seem to be platform dependent.
So I would propose the following abilities of the code: