2021-07-02 10:19:25 |
Werner Sembach |
bug |
|
|
added bug |
2021-07-02 10:21:04 |
Werner Sembach |
description |
SRU Justification:
Impact:
On some setups, while the monitor and the GPU support display modes with pixel clocks of up to 600MHz, the connector might not. This prevents RGB encoding for 4k60Hz, but YCbCr420 encoding might still be possible. However, which color mode is used is decided before the pixel clock capabilities are checked, causing the check to fail and discarding 4k60Hz from the list of possible display modes.
Fix:
This patch fixes the problem by retrying to find a display mode with YCbCr420 enforced and using it, if it is valid. It's very similar to a patch submitted to amdgpu which fixed the same problem.
Testcase:
Find a PC with a current Intel iGPU, but only a hdmi 1.4 output. Connect a 4k@60Hz display supporting YCbCr420 encoding to the hdmi port. Without the patch the maximum that can be set via xrandr is 3840 × 2160 30Hz. With the Patch 3840 × 2160 60Hz can be selected which will use YCbCr420 automatically.
Patchset already got accepted upstream for linux-next:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eacba74d4d561ea6487d944417526e1b025cbebd
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=84d95f77f4aea3f22a486cd04777afd4ab0f0ea5
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=388b863509f76f6a5ecedd7ffdaf184aa813241e
and needs only a minor modifications to apply to ubuntu-focal/hwe-5.8
Commit-hashes:
eacba74d4d561ea6487d944417526e1b025cbebd
84d95f77f4aea3f22a486cd04777afd4ab0f0ea5
388b863509f76f6a5ecedd7ffdaf184aa813241e |
SRU Justification:
Impact:
On some setups, while the monitor and the GPU support display modes with pixel clocks of up to 600MHz, the connector might not. This prevents RGB encoding for 4k60Hz, but YCbCr420 encoding might still be possible. However, which color mode is used is decided before the pixel clock capabilities are checked, causing the check to fail and discarding 4k60Hz from the list of possible display modes.
Fix:
This patch fixes the problem by retrying to find a display mode with YCbCr420 enforced and using it, if it is valid. It's very similar to a patch submitted to amdgpu which fixed the same problem.
Testcase:
Find a PC with a current Intel iGPU, but only a hdmi 1.4 output. Connect a 4k@60Hz display supporting YCbCr420 encoding to the hdmi port. Without the patch the maximum that can be set via xrandr is 3840 × 2160 30Hz. With the Patch 3840 × 2160 60Hz can be selected which will use YCbCr420 automatically.
Patchset already got accepted upstream and reached the torvalds tree:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eacba74d4d561ea6487d944417526e1b025cbebd
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=84d95f77f4aea3f22a486cd04777afd4ab0f0ea5
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=388b863509f76f6a5ecedd7ffdaf184aa813241e
and needs only a minor modifications to apply to ubuntu-focal/hwe-5.8
Commit-hashes:
eacba74d4d561ea6487d944417526e1b025cbebd
84d95f77f4aea3f22a486cd04777afd4ab0f0ea5
388b863509f76f6a5ecedd7ffdaf184aa813241e |
|
2021-07-02 15:45:20 |
Werner Sembach |
description |
SRU Justification:
Impact:
On some setups, while the monitor and the GPU support display modes with pixel clocks of up to 600MHz, the connector might not. This prevents RGB encoding for 4k60Hz, but YCbCr420 encoding might still be possible. However, which color mode is used is decided before the pixel clock capabilities are checked, causing the check to fail and discarding 4k60Hz from the list of possible display modes.
Fix:
This patch fixes the problem by retrying to find a display mode with YCbCr420 enforced and using it, if it is valid. It's very similar to a patch submitted to amdgpu which fixed the same problem.
Testcase:
Find a PC with a current Intel iGPU, but only a hdmi 1.4 output. Connect a 4k@60Hz display supporting YCbCr420 encoding to the hdmi port. Without the patch the maximum that can be set via xrandr is 3840 × 2160 30Hz. With the Patch 3840 × 2160 60Hz can be selected which will use YCbCr420 automatically.
Patchset already got accepted upstream and reached the torvalds tree:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eacba74d4d561ea6487d944417526e1b025cbebd
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=84d95f77f4aea3f22a486cd04777afd4ab0f0ea5
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=388b863509f76f6a5ecedd7ffdaf184aa813241e
and needs only a minor modifications to apply to ubuntu-focal/hwe-5.8
Commit-hashes:
eacba74d4d561ea6487d944417526e1b025cbebd
84d95f77f4aea3f22a486cd04777afd4ab0f0ea5
388b863509f76f6a5ecedd7ffdaf184aa813241e |
SRU Justification:
Impact:
On some setups, while the monitor and the GPU support display modes with pixel clocks of up to 600MHz, the connector might not. This prevents RGB encoding for 4k60Hz, but YCbCr420 encoding might still be possible. However, which color mode is used is decided before the pixel clock capabilities are checked, causing the check to fail and discarding 4k60Hz from the list of possible display modes.
Fix:
This patch fixes the problem by retrying to find a display mode with YCbCr420 enforced and using it, if it is valid. It's very similar to a patch submitted to amdgpu which fixed the same problem.
Testcase:
Find a PC with a current Intel iGPU, but only a hdmi 1.4 output. Connect a 4k@60Hz display supporting YCbCr420 encoding to the hdmi port. Without the patch the maximum that can be set via xrandr is 3840 × 2160 30Hz. With the Patch 3840 × 2160 60Hz can be selected which will use YCbCr420 automatically.
Prerequistie:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3c4442aa22878091f16c8d9592f5f5b6a94d1556
Patchset already got accepted upstream and reached the torvalds tree:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eacba74d4d561ea6487d944417526e1b025cbebd
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=84d95f77f4aea3f22a486cd04777afd4ab0f0ea5
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=388b863509f76f6a5ecedd7ffdaf184aa813241e
and needs only a minor modifications to apply to ubuntu-focal/hwe-5.8
Commit-hashes:
3c4442aa22878091f16c8d9592f5f5b6a94d1556
eacba74d4d561ea6487d944417526e1b025cbebd
84d95f77f4aea3f22a486cd04777afd4ab0f0ea5
388b863509f76f6a5ecedd7ffdaf184aa813241e |
|
2021-07-05 14:17:14 |
Werner Sembach |
description |
SRU Justification:
Impact:
On some setups, while the monitor and the GPU support display modes with pixel clocks of up to 600MHz, the connector might not. This prevents RGB encoding for 4k60Hz, but YCbCr420 encoding might still be possible. However, which color mode is used is decided before the pixel clock capabilities are checked, causing the check to fail and discarding 4k60Hz from the list of possible display modes.
Fix:
This patch fixes the problem by retrying to find a display mode with YCbCr420 enforced and using it, if it is valid. It's very similar to a patch submitted to amdgpu which fixed the same problem.
Testcase:
Find a PC with a current Intel iGPU, but only a hdmi 1.4 output. Connect a 4k@60Hz display supporting YCbCr420 encoding to the hdmi port. Without the patch the maximum that can be set via xrandr is 3840 × 2160 30Hz. With the Patch 3840 × 2160 60Hz can be selected which will use YCbCr420 automatically.
Prerequistie:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3c4442aa22878091f16c8d9592f5f5b6a94d1556
Patchset already got accepted upstream and reached the torvalds tree:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eacba74d4d561ea6487d944417526e1b025cbebd
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=84d95f77f4aea3f22a486cd04777afd4ab0f0ea5
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=388b863509f76f6a5ecedd7ffdaf184aa813241e
and needs only a minor modifications to apply to ubuntu-focal/hwe-5.8
Commit-hashes:
3c4442aa22878091f16c8d9592f5f5b6a94d1556
eacba74d4d561ea6487d944417526e1b025cbebd
84d95f77f4aea3f22a486cd04777afd4ab0f0ea5
388b863509f76f6a5ecedd7ffdaf184aa813241e |
SRU Justification:
Impact:
On some setups, while the monitor and the GPU support display modes with pixel clocks of up to 600MHz, the connector might not. This prevents RGB encoding for 4k60Hz, but YCbCr420 encoding might still be possible. However, which color mode is used is decided before the pixel clock capabilities are checked, causing the check to fail and discarding 4k60Hz from the list of possible display modes.
Fix:
This patch fixes the problem by retrying to find a display mode with YCbCr420 enforced and using it, if it is valid. It's very similar to a patch submitted to amdgpu which fixed the same problem.
Testcase:
I personally tested on a Clevo NV40MB, but generally: Find a PC with a current Intel iGPU, but only a HDMI 1.4 output. Connect a 4k@60Hz display supporting YCbCr420 encoding to the HDMI port. Without the patch the maximum that can be set via xrandr is 3840 × 2160 30Hz. With the Patch 3840 × 2160 60Hz can be selected which will use YCbCr420 automatically.
Prerequisite (included in this email patchset as 1/4):
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3c4442aa22878091f16c8d9592f5f5b6a94d1556
Patchset already got accepted upstream and reached the torvalds tree:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eacba74d4d561ea6487d944417526e1b025cbebd
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=84d95f77f4aea3f22a486cd04777afd4ab0f0ea5
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=388b863509f76f6a5ecedd7ffdaf184aa813241e
and needs only a minor modifications to apply to ubuntu-focal/hwe-5.8
Commit-hashes:
3c4442aa22878091f16c8d9592f5f5b6a94d1556
eacba74d4d561ea6487d944417526e1b025cbebd
84d95f77f4aea3f22a486cd04777afd4ab0f0ea5
388b863509f76f6a5ecedd7ffdaf184aa813241e |
|
2021-07-15 15:55:26 |
Kleber Sacilotto de Souza |
nominated for series |
|
Ubuntu Hirsute |
|
2021-07-15 15:55:26 |
Kleber Sacilotto de Souza |
bug task added |
|
linux (Ubuntu Hirsute) |
|
2021-07-15 15:55:31 |
Kleber Sacilotto de Souza |
linux (Ubuntu Hirsute): status |
New |
In Progress |
|
2021-07-15 15:56:02 |
Kleber Sacilotto de Souza |
nominated for series |
|
Ubuntu Groovy |
|
2021-07-15 15:56:02 |
Kleber Sacilotto de Souza |
bug task added |
|
linux (Ubuntu Groovy) |
|
2021-07-15 15:56:07 |
Kleber Sacilotto de Souza |
linux (Ubuntu Groovy): status |
New |
In Progress |
|
2021-08-06 21:08:57 |
Kelsey Steele |
linux (Ubuntu Hirsute): status |
In Progress |
Fix Committed |
|
2021-08-17 14:41:46 |
Ubuntu Kernel Bot |
tags |
|
verification-needed-hirsute |
|
2021-08-18 10:09:03 |
Ubuntu Kernel Bot |
linux (Ubuntu): status |
New |
Incomplete |
|
2021-08-27 12:57:04 |
Werner Sembach |
tags |
verification-needed-hirsute |
verification-done-hirsute |
|
2021-09-07 13:53:28 |
Launchpad Janitor |
linux (Ubuntu Hirsute): status |
Fix Committed |
Fix Released |
|
2021-09-07 13:53:28 |
Launchpad Janitor |
cve linked |
|
2020-26541 |
|
2021-09-07 13:53:28 |
Launchpad Janitor |
cve linked |
|
2021-3653 |
|
2021-09-07 13:53:28 |
Launchpad Janitor |
cve linked |
|
2021-3656 |
|