Closed kiendinh closed 4 years ago
Update: the screens showed Weston UI on a KabyLake NUC. However, the 4K screen only showed 1/4 of the display, which was equivalent to the 1920x1080 resolution of the fullHD screen. The remaining area was black.
Because GVT-g needs to share the planes onto different SOS and UOS, so we allocate the DDB evenly, which will control the bandwidth of GVT-g. On APL platform, in such situation, we cannot support 4K monitor on 3 pipes. So that's the current SW limitation.
And for your KBL-NUC with 4K monitor, can you upload the log of weston? it seems that the monitor can be detected successfully, but weston not display on the full screen. It seems that the weston in clone mode so that it need to display the lower resolution of two monitors. Can you connect two 4k monitors ? Thanks.
Please find in the attachment the weston logs of the KBL-NUC. I found it interesting that 4K display for the UOS, as reported above, still didn't work, but 4K for the SOS did work. Here's how:
The KBL NUC has two display ports: an HDMI and a USB Type-C, which I connected to the display via a USB type-C HDMI adapter. When the USB type-C was connected to 2K monitor, and the HDMI was connected to the 4K monitor, we would have the case reported above: UOS was only showed in 1/4 of the 4K monitor. Here are the weston logs: SOS weston log UOS weston log.log
When the USB type-C was connected to the 4K monitor, and the HDMI was connected to 2K monitor, the SOS was showed correctly @4K resolution, and the UOS was showed correctly @2K resolution. Here are the weston logs SOS weston log UOS weston log
So it seems the order of the monitor connection does affect the results. It's close to display in 4K. In both cases, only part of the 4K monitor information was shared to the UOS - resolutions equal or less than 1600x1200. Is there any restriction in the software which prevents the full info to be passed? Or is it the memory settings like gvt_low_gm_sz... need to be adjusted for higher resolution?
By the way, mouse cursor on UOS in both cases were invisible, though still functioned. It has already reported in this issue
Thanks.
@kiendinh , May I ask if your question still exists?
@Mingyuan18 I haven't checked it recently. However, since there was no further comments or answers from anyone, I assume that it still exists.
In AcrnGT, to support multiple monitors with multiple planes, we have to pre-reserve some resources, which make it impossible to support 4k displays on APL platform. So it's a known limitation of AcrnGT. Closing it.
There are problems on KBL too, @minhe1 indicated (in https://github.com/projectacrn/acrn-hypervisor/issues/682#issuecomment-405851456) that it may be a software limitation. Let's keep this open to track to a proper resolution (or feature implementation).
[External_System_ID] ACRN-3148
@kiendinh ,Suggesting to close it as "Won't Fix” .
@fuzhongl since this is a Won't fix issue/feature, could we close this git issue? @kiendinh if you have any further question/issue, feel free submit a new git issue, thanks.
@kiendinh Please try with gvt-d for 4K display, it is supported since v1.5 Close it as Won't fix because it is the limitation of gvt-g.
I've setup a system with ClearLinux (v23640) and ACRN (master@11e997a7) on the UP2 (APL), and connected a fullHD (1920x1080) monitor and a 4K display. The system has also setup so that Weston launches automatically. When native ClearLinux booted, the two displays showed Weston UI correctly. However, when booting with ACRN to the SOS, both of them only showed black screens. The issue only happened when there was a 4K display. The SOS showed up correctly if both displays were fullHD.
Here is the system setup information: UP2 Pentium Quad Core 8GB RAM & 64GB eMMC ClearLinux v23640 acrn-hypervisor (master@ 11e997a7) - built and installed manually - no code modification ClearLinux kernels:
Please find in the attachment the logs of dmesg and weston service in case of native ClearLinux and in case of SOS. weston_4k_sos.log dmesg_4k_sos.log weston_4k_native.log dmesg_4k_native.log