search for: hdmimhz

...ne S_IRUSR 00400 #define S_IRGRP 00040 #define S_IROTH 00004 $ ls -l /sys/module/nouveau/parameters/ total 0 -r--r--r--. 1 root root 4096 Apr 10 17:43 config -r--r--r--. 1 root root 4096 Apr 10 17:43 debug -r--r--r--. 1 root root 4096 Apr 10 17:43 duallink -r--r--r--. 1 root root 4096 Apr 10 17:43 hdmimhz -r--r--r--. 1 root root 4096 Apr 10 17:43 ignorelid -r--r--r--. 1 root root 4096 Apr 10 17:43 modeset -r--r--r--. 1 root root 4096 Apr 10 17:43 noaccel -r--r--r--. 1 root root 4096 Apr 10 17:43 nofbaccel -r--r--r--. 1 root root 4096 Apr 10 17:43 runpm -r--r--r--. 1 root root 4096 Apr 10 17:43 tv_di...

...g-team at lists.x.org While my Nvidia G96GLM [Quadro FX 770M] yields 3840x2160 at 30 well under Windows 7 certain problems appear when trying to make use of that mode under nouveau/Linux. The 3840x2160_23.00 mode described in Bug 93405 works well also with the G96GLM; here even without any nouveau.hdmimhz parameter. A 3840x2160 at 30 mode appears automatically as soon as I specify nouveau.hdmimhz=297. However when I select it the external monitor turns white with a black bar at the bottom instead of showing the correct screen content. Trying predefined modelines by cvt, gtf or the arachnoid modeli...

...(ignorelid, nouveau_ignorelid, int, S_IRUSR); MODULE_PARM_DESC(duallink, "Allow dual-link TMDS (default: enabled)"); int nouveau_duallink = 1; -module_param_named(duallink, nouveau_duallink, int, 0400); +module_param_named(duallink, nouveau_duallink, int, S_IRUSR); MODULE_PARM_DESC(hdmimhz, "Force a maximum HDMI pixel clock (in MHz)"); int nouveau_hdmimhz = 0; -module_param_named(hdmimhz, nouveau_hdmimhz, int, 0400); +module_param_named(hdmimhz, nouveau_hdmimhz, int, S_IRUSR); struct nouveau_encoder * find_encoder(struct drm_connector *connector, int type) -- 2.9.2

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:

Can you try something very simple - unplug the cable, and plug it back in, while the TV is on, and set to the HDMI input? That should ensure that the SCDC write can go through at modeset time. You can also force nouveau to avoid any modes that require scrambling by booting with nouveau.hdmimhz=340. Cheers, -ilia On Tue, Aug 6, 2019 at 1:15 PM James <bjlockie at lockie.ca> wrote: > > I was going to buy a new cable and I came across this description: > >Category 2 Certified HDMI wire supports resolutions up to 4Kx2K (UHD) > @30 Hz > > https://www.cnet.com/h...

..._named(ignorelid, nouveau_ignorelid, int, 0444); MODULE_PARM_DESC(duallink, "Allow dual-link TMDS (default: enabled)"); int nouveau_duallink = 1; -module_param_named(duallink, nouveau_duallink, int, 0400); +module_param_named(duallink, nouveau_duallink, int, 0444); MODULE_PARM_DESC(hdmimhz, "Force a maximum HDMI pixel clock (in MHz)"); int nouveau_hdmimhz = 0; -module_param_named(hdmimhz, nouveau_hdmimhz, int, 0400); +module_param_named(hdmimhz, nouveau_hdmimhz, int, 0444); struct nouveau_encoder * find_encoder(struct drm_connector *connector, int type) diff --git a/dr...

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 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 ++++++++++----- > drm/nouveau/nouveau_encoder.h | 4 ++++ > 3 files changed, 19 inserti...

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>

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...

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 actual possible. Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de> Signed-off-by: Ilia

...8 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c index 7b557c354307..28d7b42cd666 100644 --- a/drivers/gpu/drm/nouveau/nouveau_connector.c +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c @@ -363,19 +363,11 @@ module_param_named(hdmimhz, nouveau_hdmimhz, int, 0400); struct nouveau_encoder * find_encoder(struct drm_connector *connector, int type) { - struct drm_device *dev = connector->dev; struct nouveau_encoder *nv_encoder; struct drm_encoder *enc; - int i, id; - - for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) { -...

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/dr...

...HDMI 2 cable I get 4096x2160 at 30Hz (there is no 60Hz option). 3840x2160 at 59.9685Hz gives me no signal. > That should ensure > that the SCDC write can go through at modeset time. > > You can also force nouveau to avoid any modes that require scrambling > by booting with nouveau.hdmimhz=340. > > Cheers, > > -ilia > > On Tue, Aug 6, 2019 at 1:15 PM James <bjlockie at lockie.ca> wrote: >> >> I was going to buy a new cable and I came across this description: >>> Category 2 Certified HDMI wire supports resolutions up to 4Kx2K (UHD) >&gt...

...31/5.5.5 kernel bad > > http://fm.no-ip.com/Tmp/Linux/Xorg/xorg.0.log-gt218-stw-modesetting-OOR-0x1e > http://fm.no-ip.com/Tmp/Linux/Xorg/gt218-dmesg-stw.txt Those HDMI mode clocks are too high against the nominal single-link 165MHz TMDS. You can set your own maximum with nouveau.hdmimhz=300 (for example) to allow it. I believe the connectors aren't rated for that though. The commit which fixed this is commit d1084184789d677df4e9c110f38cb3f3d709195d Author: Ben Skeggs <bskeggs at redhat.com> Date: Wed May 29 09:58:18 2019 +1000 drm/nouveau/kms: disallow dual-link...

From: Ville Syrjälä <ville.syrjala at linux.intel.com> Changes from the previous version mainly involve Danoie's suggestion of hiding the drm_encoder_find() in the iterator macro. I also polished the msm and tilcdc cases a bit more with another small helper. Cc: Alex Deucher <alexander.deucher at amd.com> Cc: amd-gfx at lists.freedesktop.org Cc: Ben Skeggs <bskeggs at

...rlaced modes on DP connectors if the GPU would otherwise display garbage or EVO timesout. It also adds experimental detection of the HDMI clock limit we currently hard limit depending on the GPU generation. Starting with GF110 GPUs, we can retrieve the limit directly from the GPU and may make the hdmimhz parameter obsolete. Testing this series with 2560x1440 or higher capable displays via HDMI would be much appreciated, especially in cases where the hdmimhz option is required to drive certain resolutions and is made obsolete with this. Karol Herbst (6): kms/nv50: move nv50_mstm out of the dp un...

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> >> --- >> drm/nouveau/dispnv50/disp.c | 5 +++++ >> drm/nouveau/nouveau_connector.c | 15 ++++++++++----- >> drm/nouveau/nouveau_encoder.h | 4 ++++ >&...

On 2019-08-06 12:32 p.m., Ilia Mirkin wrote: > Hi James, > > I semi-recently added support for HDMI 2.0 (in 4.20+, so you're good), > which is why you got 60Hz in the first place. In order for the high > rates to work, something called "scrambling" must be enabled. This is > done by 2-party agreement between the sink and the source. The sink > will inform the

...#39;systemctl suspend' my integrated LVDS display comes up fine while an external HDMI monitor stays black with 'no signal'. As far as tested the VGA output of my G96M will resume without a problem. I have tested the following kernel parameters in addition to a plain boot with nouveau.hdmimhz=225: * acpi_sleep=s3=bios: resumes well but HDMI stays without a signal * acpi_sleep=s3_mode: crash on resume with total blackscreen of LVDS as well as HDMI, a hard reset is the only way out. * acpi_sleep=s3_bios,s3_mode: same as s3_mode kernel version: 4.5.0-rc1-ARCH #2 SMP nouveau version of the...