similar to: HDMI pixel clock limits

https://bugs.freedesktop.org/show_bug.cgi?id=91236 Bug ID: 91236 Summary: [NVC3] Passive DP to HDMI adapter cannot use pixel clocks greater than 165 MHz Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium

These patches are adding support for outputting 2560x1440 at 56 over HDMI. This needs a pixel clock of 225 MHz which was not supported before. This was tested in a dual monitor setup with a GF114 (GTX 560 TI) and one HDMI monitor running with 2560x1440 at 56 and one DVI monitor running with 1920x1200 at 60. This still needs testing on other graphics cards and with dual link DVI. There is no

https://bugs.freedesktop.org/show_bug.cgi?id=93405 Bug ID: 93405 Summary: nouveau: Xorg crashes sooner or later in 3840x2160 mode Product: xorg Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component:

Video and input drivers Subgroups and projects on gitlab does not list modesetting DDX, presumably because it's not packaged separately from the server. Where's the right place to report a modesetting DDX bug that manifests only on an NVidia GPU? Directly against the server https://gitlab.freedesktop.org/xorg/xserver? Here are some particulars: How can I tell whether this should be

These patches are adding support for outputting 2560x1440 at 56 over HDMI. This needs a pixel clock of 225 MHz which was not supported before. This was tested in a dual monitor setup with a GF114 (GTX 560 TI) and one HDMI monitor running with 2560x1440 at 56 and one DVI monitor running with 1920x1200 at 60. This still needs testing on other graphics cards and with dual link DVI. There is no

On Fri, Aug 3, 2018 at 8:19 AM, Karol Herbst <kherbst at redhat.com> wrote: > v2: clean up left over comments > don't overwrite hdmimhz parameter > cap to 297MHz > > Signed-off-by: Karol Herbst <kherbst at redhat.com> > --- > drm/nouveau/dispnv50/disp.c | 5 +++++ > drm/nouveau/nouveau_connector.c | 15 ++++++++++----- >

Thank you for your quick reply. I have a Gigabyte GT-730 2GB card hooked directly via a high quality HDMI cable to a 65 inch Samsung curved screen LCD 4K monitor. I'm not sure what I am looking for in dmesg and xorg log. Please advise. I have built the 3.19.8 kernel and enabled frame buffer support. I can see 7 out of the 8 penguins when I boot. My ultimate goal is to be able to boot to

This removes user control to force a hdmimhz. Given the vast variety of hardware and display configurations out there, I don't see how a patch like this won't blow up in our faces. I'm not saying we shouldn't do it -- we should attempt to respect the various maximums in the vbios, but until we get a solid handle on things, we should allow more user-configurability, not less, for

Hi List, I'm stuck how to get a dual head monitor solution to work with Nouveau, running openSUSE 13.1 on my hp8710w mobile workstation equipped with a Nvidia graphical card. Beyond the built-in WUXGA display, an external WQHD monitor is connected to the HDMI port on the graphical card and/or to the dual link DVI-D on a hp docking station. To compare with SLED11/Nvidia driver running in

I got 1920x1200 at 59.95Hz via DVI and 3840x2160 at 60.00Hz via HDMI at the same time with the proprietary nvidia driver. I get flickering on the 1920x1200 at 59.95 with the nouveau driver (it doesn't flicker if I lower it to 1920x1080 at 59.96). Any idea why? proprietary: $ xrandr Screen 0: minimum 8 x 8, current 5760 x 2160, maximum 32767 x 32767 DVI-D-0 connected primary 1920x1200+0+0

On Fri, Feb 28, 2020 at 11:06 AM Felix Miata <mrmazda at earthlink.net> wrote: > Video and input drivers Subgroups and projects on gitlab does not list modesetting > DDX, presumably because it's not packaged separately from the server. Where's the > right place to report a modesetting DDX bug that manifests only on an NVidia GPU? > Directly against the server

I installed C7 along with MATE desktop... My monitor is a 4K unit but when I goto the System -> preferences -> hardware -> Displays there is selection for the 4K display. It stops at 1920x1080. The var log x file shows the 4K resolutions in the file so that is good. How do I get the selections for 4K to show up? Thanks, Jerry

From: Hauke Mehrtens <hauke at hauke-m.de> Without this patch a pixel clock rate above 165 MHz on a TMDS link is assumed to be dual link. This is true for DVI, but not for HDMI. HDMI supports no dual link, but it supports pixel clock rates above 165 MHz. Only activate Dual Link mode when it is actually possible and requested. Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de>

From: Hauke Mehrtens <hauke at hauke-m.de> Without this patch a pixel clock rate above 165 MHz on a TMDS link is assumed to be dual link. This is true for DVI, but not for HDMI. HDMI supports no dual link, but it supports pixel clock rates above 165 MHz. Only activate Dual Link mode when it is actually possible and requested. Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de>

On Sat, 31 Jan 2015 12:21:07 -0500 Lamar Owen wrote: > I like the full-size DisplayPort connector the best of any video > connector I've dealt with, Thanks! I'm waiting to see if my current monitor actually dies. It's an Asus 1920x1200 monitor that I like rather a lot, but it occasionally acts a bit flaky when coming back out of sleep mode. (The screen fills with a white

https://bugs.freedesktop.org/show_bug.cgi?id=95334 Bug ID: 95334 Summary: GM107 with 2560x1440 display on HDMI selects suboptimal resolution 1920x1080 Product: xorg Version: 7.7 (2012.06) Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium

On 05/06/2017 12:38 PM, Ilia Mirkin wrote: > The information comes from the EDID blob supplied by the monitor. > Presumably hwinfo has a primitive EDID parser, which is where that > information comes from. A more complete EDID parser is available at > > https://cgit.freedesktop.org/xorg/app/edid-decode/ > > For example, > > $ ./src/edid-decode/edid-decode

On Fri, Aug 3, 2018 at 4:08 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > On Fri, Aug 3, 2018 at 8:19 AM, Karol Herbst <kherbst at redhat.com> wrote: >> v2: clean up left over comments >> don't overwrite hdmimhz parameter >> cap to 297MHz >> >> Signed-off-by: Karol Herbst <kherbst at redhat.com> >> --- >>

On Fri, Jul 15, 2016 at 12:41:49PM -0400, Ilia Mirkin wrote: > On Fri, Jul 15, 2016 at 12:36 PM, Peter Wu <peter at lekensteyn.nl> wrote: > > On Fri, Jul 15, 2016 at 12:10:23PM -0400, Ilia Mirkin wrote: > >> On Fri, Jul 15, 2016 at 9:12 AM, Peter Wu <peter at lekensteyn.nl> wrote: > >> > Hi, > >> > > >> > Here are two patches to fix

v2: clean up left over comments don't overwrite hdmimhz parameter cap to 297MHz Signed-off-by: Karol Herbst <kherbst at redhat.com> --- drm/nouveau/dispnv50/disp.c | 5 +++++ drm/nouveau/nouveau_connector.c | 15 ++++++++++----- drm/nouveau/nouveau_encoder.h | 4 ++++ 3 files changed, 19 insertions(+), 5 deletions(-) diff --git a/drm/nouveau/dispnv50/disp.c