You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Bazzite Game Mode missing 4K60 on NVIDIA: a source patch that worked for my 4:2:0-only TV
#1443
I had a 4K60 problem in Bazzite Steam Game Mode with an RTX 3060 Ti connected by HDMI through a Yamaha RX-V581 to a Samsung UN48JU6000. The unmodified driver offered 4K30, not a working 4K60 mode. This same cable/receiver/TV setup does 4K60 in Windows. KDE Desktop on X11 could also output 4K at 59.94 Hz; Game Mode was the problem.
The TV's EDID advertises 3840×2160/59.94 (VIC 97) only as YCbCr 4:2:0, with a reported 300 MHz maximum TMDS clock. In NVIDIA 615.71.09, I traced this setup's failure to two points in the open-module mode path: the DRM connector did not allow the EDID's 4:2:0-only mode, and the KAPI mode conversion did not retain its yuv420Mode requirement. The source patch below:
Allows YCbCr 4:2:0 modes on the HDMI DRM connector.
Matches the KAPI timing to the EDID mode and restores its 4:2:0 requirement.
Does that restoration beforeGetColorFormatAndColorRange() chooses the output format.
I tested the order, not just whether the mode appeared in a menu. Recovering 4:2:0 only during validation exposed 4K60, but selecting it froze the picture while UI sounds continued. Moving recovery ahead of color selection produced a visibly working 3840×2160/59.94 picture in Steam Game Mode. I confirmed the result on the TV and checked the active DRM timing. KDE Desktop also displays 59.94 Hz, though its X11 session could do that before the patch. The source change fixed Game Mode.
The fix is confirmed for this PC/receiver/TV on the tested driver; the question is how NVIDIA wants to implement it upstream. Tested on Bazzite 44, kernel 7.2.8-ogc5.1.fc44.x86_64, RTX 3060 Ti, NVIDIA open modules 615.71.09. The diff below is source code, not a universal RPM for other kernels or driver versions. I have not compared the same-version proprietary kernel module or captured an nvidia-bug-report.log.gz from the unmodified driver. Those missing comparisons do not change the observed result of the patched build; they limit claims about other driver flavors and hardware.
I am sharing the complete source diff so NVIDIA can review an upstream way to preserve this 4:2:0 metadata through the KAPI path. Other missing-4K60 reports may have different EDIDs and causes.
Six-file patch against NVIDIA 615.71.09
diff --git a/kernel-open/nvidia-drm/nvidia-drm-connector.c b/kernel-open/nvidia-drm/nvidia-drm-connector.c
index 77ec01a..4ab4c73 100644
--- a/kernel-open/nvidia-drm/nvidia-drm-connector.c+++ b/kernel-open/nvidia-drm/nvidia-drm-connector.c@@ -749,6 +749,10 @@ nv_drm_connector_new(struct drm_device *dev,
drm_connector_helper_add(&nv_connector->base, &nv_connector_helper_funcs);
+ if (nv_connector->type == NVKMS_CONNECTOR_TYPE_HDMI) {+ nv_connector->base.ycbcr_420_allowed = true;+ }+
nv_connector->base.polled = DRM_CONNECTOR_POLL_HPD;
if (nv_connector->type == NVKMS_CONNECTOR_TYPE_VGA) {
diff --git a/src/nvidia-modeset/include/nvkms-modepool.h b/src/nvidia-modeset/include/nvkms-modepool.h
index ee6f0be..f23a43b 100644
--- a/src/nvidia-modeset/include/nvkms-modepool.h+++ b/src/nvidia-modeset/include/nvkms-modepool.h@@ -57,6 +57,11 @@ NvBool nvValidateModeForModeset(NVDpyEvoRec *pDpyEvo,
NVT_VENDOR_SPECIFIC_INFOFRAME_CTRL *pVSInfoFrameCtrl,
NVT_EXTENDED_METADATA_PACKET_INFOFRAME_CTRL *pEmpInfoFrameCtrl);
+/* Recover a 4:2:0-only EDID mode before selecting output color. */+NvBool nvRecoverKapiYuv420Mode(NVDpyEvoRec *pDpyEvo,+ const struct NvKmsModeValidationParams *pParams,+ struct NvKmsMode *pKmsMode);+
const NVT_TIMING *nvFindEdidNVT_TIMING(
const NVDpyEvoRec *pDpyEvo,
const NvModeTimings *pModeTimings,
diff --git a/src/nvidia-modeset/interface/nvkms-api.h b/src/nvidia-modeset/interface/nvkms-api.h
index b48bfdd..3cbcdec 100644
--- a/src/nvidia-modeset/interface/nvkms-api.h+++ b/src/nvidia-modeset/interface/nvkms-api.h@@ -356,6 +356,7 @@ enum NvKmsModeValidationOverrides {
NVKMS_MODE_VALIDATION_REQUIRE_BOOT_CLOCKS = (1 << 16),
NVKMS_MODE_VALIDATION_MAX_ONE_HARDWARE_HEAD = (1 << 17),
NVKMS_MODE_VALIDATION_PREFER_HDMI_FRL_MODE = (1 << 18),
+ NVKMS_MODE_VALIDATION_KAPI_AUTO_YUV420 = (1 << 19),
};
/*!
diff --git a/src/nvidia-modeset/kapi/src/nvkms-kapi.c b/src/nvidia-modeset/kapi/src/nvkms-kapi.c
index 91b619e..0f0e46f 100644
--- a/src/nvidia-modeset/kapi/src/nvkms-kapi.c+++ b/src/nvidia-modeset/kapi/src/nvkms-kapi.c@@ -2526,7 +2526,8 @@ static void InitNvKmsModeValidationParams(
* XXX NVKMS TODO: Bug 200156338 is filed to delete NvModeTimings::RRx1k
* if possible.
*/
- params->overrides = NVKMS_MODE_VALIDATION_NO_RRX1K_CHECK;+ params->overrides = NVKMS_MODE_VALIDATION_NO_RRX1K_CHECK |+ NVKMS_MODE_VALIDATION_KAPI_AUTO_YUV420;
}
static int GetDisplayMode
diff --git a/src/nvidia-modeset/src/nvkms-modepool.c b/src/nvidia-modeset/src/nvkms-modepool.c
index 59dfd37..8228313 100644
--- a/src/nvidia-modeset/src/nvkms-modepool.c+++ b/src/nvidia-modeset/src/nvkms-modepool.c@@ -1922,7 +1922,11 @@ const NVT_TIMING *nvFindEdidNVT_TIMING
* configuration of pTiming would match pModeTimings.
*/
(pModeTimings->yuv420Mode ==
- GetYUV420Value(pDpyEvo, pParams, pTiming))) {+ GetYUV420Value(pDpyEvo, pParams, pTiming) ||+ ((pParams->overrides & NVKMS_MODE_VALIDATION_KAPI_AUTO_YUV420) &&+ pModeTimings->yuv420Mode == NV_YUV420_MODE_NONE &&+ GetYUV420Value(pDpyEvo, pParams, pTiming) !=+ NV_YUV420_MODE_NONE))) {
return pTiming;
}
}
@@ -2040,9 +2044,16 @@ static NvBool ConstructModeTimingsMetaData(
}
- /* Validate yuv420. */- if (modeTimings.yuv420Mode !=- GetYUV420Value(pDpyEvo, pParams, &timing)) {+ /* The DRM KAPI omits YUV420 metadata. Only for KAPI requests,+ * recover the GPU/display-specific format from the EDID mode. */+ const enum NvYuv420Mode requiredYuv420Mode =+ GetYUV420Value(pDpyEvo, pParams, &timing);+ if ((pParams->overrides & NVKMS_MODE_VALIDATION_KAPI_AUTO_YUV420) &&+ modeTimings.yuv420Mode == NV_YUV420_MODE_NONE &&+ requiredYuv420Mode != NV_YUV420_MODE_NONE) {+ modeTimings.yuv420Mode = requiredYuv420Mode;+ }+ if (modeTimings.yuv420Mode != requiredYuv420Mode) {
return FALSE;
}
@@ -2116,6 +2127,23 @@ done:
return TRUE;
}
+/* The KAPI mode loses the EDID-only YUV420 flag. Restore it before+ * the modeset chooses an output color format, not only during validation. */+NvBool nvRecoverKapiYuv420Mode(NVDpyEvoRec *pDpyEvo,+ const struct NvKmsModeValidationParams *pParams,+ struct NvKmsMode *pKmsMode)+{+ EvoValidateModeFlags flags;++ if (!(pParams->overrides & NVKMS_MODE_VALIDATION_KAPI_AUTO_YUV420) ||+ pKmsMode->timings.yuv420Mode != NV_YUV420_MODE_NONE) {+ return TRUE;+ }++ return ConstructModeTimingsMetaData(pDpyEvo, pParams, pKmsMode,+ &flags, NULL, NULL, NULL);+}+
/*!
* Validate the NvKmsMode.
*
@@ -2157,7 +2185,8 @@ NvBool nvValidateModeForModeset(NVDpyEvoRec *pDpyEvo,
}
if (!ValidateModeTimings(pDpyEvo,
- pKmsMode,+ (kmsMode.timings.yuv420Mode !=+ pKmsMode->timings.yuv420Mode) ? &kmsMode : pKmsMode,
&flags,
pParams,
&dummyInfoString,
diff --git a/src/nvidia-modeset/src/nvkms-modeset.c b/src/nvidia-modeset/src/nvkms-modeset.c
index f51f97b..4edf009 100644
--- a/src/nvidia-modeset/src/nvkms-modeset.c+++ b/src/nvidia-modeset/src/nvkms-modeset.c@@ -198,6 +198,7 @@ nvGetHwModeTimings(const NVDispEvoRec *pDispEvo,
{
NVDpyEvoPtr pDpyEvo;
NVDpyAttributeColor dpyColor = { };
+ struct NvKmsSetModeOneHeadRequest recoveredRequestHead;
if (nvDpyIdListIsEmpty(pRequestHead->dpyIdList)) {
return TRUE;
@@ -209,6 +210,20 @@ nvGetHwModeTimings(const NVDispEvoRec *pDispEvo,
return FALSE;
}
+ /* KAPI conversions discard the EDID YUV420 mode. Recover it before+ * GetColorFormatAndColorRange reads the mode, so output is YCbCr420. */+ if ((pRequestHead->modeValidationParams.overrides &+ NVKMS_MODE_VALIDATION_KAPI_AUTO_YUV420) &&+ pRequestHead->mode.timings.yuv420Mode == NV_YUV420_MODE_NONE) {+ recoveredRequestHead = *pRequestHead;+ if (!nvRecoverKapiYuv420Mode(pDpyEvo,+ &recoveredRequestHead.modeValidationParams,+ &recoveredRequestHead.mode)) {+ return FALSE;+ }+ pRequestHead = &recoveredRequestHead;+ }+
if (!GetColorFormatAndColorRange(pDispEvo, apiHead, pRequestHead,
&dpyColor)) {
return FALSE;
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I had a 4K60 problem in Bazzite Steam Game Mode with an RTX 3060 Ti connected by HDMI through a Yamaha RX-V581 to a Samsung UN48JU6000. The unmodified driver offered 4K30, not a working 4K60 mode. This same cable/receiver/TV setup does 4K60 in Windows. KDE Desktop on X11 could also output 4K at 59.94 Hz; Game Mode was the problem.
The TV's EDID advertises 3840×2160/59.94 (VIC 97) only as YCbCr 4:2:0, with a reported 300 MHz maximum TMDS clock. In NVIDIA
615.71.09, I traced this setup's failure to two points in the open-module mode path: the DRM connector did not allow the EDID's 4:2:0-only mode, and the KAPI mode conversion did not retain itsyuv420Moderequirement. The source patch below:GetColorFormatAndColorRange()chooses the output format.I tested the order, not just whether the mode appeared in a menu. Recovering 4:2:0 only during validation exposed 4K60, but selecting it froze the picture while UI sounds continued. Moving recovery ahead of color selection produced a visibly working 3840×2160/59.94 picture in Steam Game Mode. I confirmed the result on the TV and checked the active DRM timing. KDE Desktop also displays 59.94 Hz, though its X11 session could do that before the patch. The source change fixed Game Mode.
The fix is confirmed for this PC/receiver/TV on the tested driver; the question is how NVIDIA wants to implement it upstream. Tested on Bazzite 44, kernel
7.2.8-ogc5.1.fc44.x86_64, RTX 3060 Ti, NVIDIA open modules615.71.09. The diff below is source code, not a universal RPM for other kernels or driver versions. I have not compared the same-version proprietary kernel module or captured annvidia-bug-report.log.gzfrom the unmodified driver. Those missing comparisons do not change the observed result of the patched build; they limit claims about other driver flavors and hardware.I am sharing the complete source diff so NVIDIA can review an upstream way to preserve this 4:2:0 metadata through the KAPI path. Other missing-4K60 reports may have different EDIDs and causes.
Six-file patch against NVIDIA 615.71.09
All reactions