Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for other hardware #2

Open
1 of 3 tasks
patmagauran opened this issue Jul 1, 2020 · 7 comments
Open
1 of 3 tasks

Support for other hardware #2

patmagauran opened this issue Jul 1, 2020 · 7 comments

Comments

@patmagauran
Copy link

patmagauran commented Jul 1, 2020

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:

  • Read Current GPU model and update appropriate properties
  • Read real EDID values
  • Use the above two to allow for greater variety of hardware combinations.
@HouQiming
Copy link
Owner

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:

  • Display interface branches: eDP / DP / HDMI / DVI / VGA each requires some different work on each hardware generation. Some of the interfaces may require a different way to read the EDID. It could be that I'm using the wrong one.
  • Pixel clock: each generation requires a different routine to compute and setup the pixel clock. This also interacts with EDID since the target pixel clock depends on some of its fields.
  • Power management: each generation seems to require a slightly different routine to power on the relevant parts of the chipset
  • GTT format: the GPU page table format changed from 32-bit to 64-bit in some generation. Skylake is 64-bit, older ones could have been 32-bit.

@patmagauran
Copy link
Author

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.

@patmagauran
Copy link
Author

After doing some research, I believe my next step should be configuring support for displayport/eDP. It requires a different intialization sequence than HDMI.

@patmagauran
Copy link
Author

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.

@Zeltinger
Copy link

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.

@zaptrem
Copy link

zaptrem commented Oct 5, 2020

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.

@patmagauran
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants