similar to: [PATCH RFC] drm: Add update_native_mode callback to connectors

Subject: [PATCH] drm/nv04: fix null pointer dereferences of native_mode nv_connector->native_mode is not set when no modes were found for the connector, so its existence can't be assumed. In nv04_dfp_mode_fixup, reject the mode if GPU scaling is enabled but native mode is not known. In nv04_dfp_mode_set, use clock value from nv_encoder->mode instead of nv_connector->native_mode. If

Higher layers tend to add a lot of modes not actually in the EDID, such as the standard DMT modes. Changing this would be extremely intrusive to everyone, so just force the scaler more often. There are no practical cases we're aware of where a LVDS/eDP panel has multiple resolutions exposed, and i915 already does it this way. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110660

http://bugs.freedesktop.org/show_bug.cgi?id=23295 Summary: nouveau KMS: null pointer dereference if native mode is not found Product: xorg Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at

On Wed, 26 Jun 2024, Ma Ke <make24 at iscas.ac.cn> wrote: > In nouveau_connector_get_modes(), the return value of drm_mode_duplicate() > is assigned to mode, which will lead to a possible NULL pointer > dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. > > Signed-off-by: Ma Ke <make24 at iscas.ac.cn> > --- >

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 3d1890ef8023e61934e070021b06cc9f417260c0 ] Under certain circumstances, encoder atomic_check() can be entered without adjusted_mode having been reset to the same as mode, which confuses the scaling logic and can lead to a misprogrammed display. Fix this by checking against the user-provided mode directly. Link:

On Sun, 26 May 2019 at 08:41, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > > Higher layers tend to add a lot of modes not actually in the EDID, such > as the standard DMT modes. Changing this would be extremely intrusive to > everyone, so just force the scaler more often. There are no practical > cases we're aware of where a LVDS/eDP panel has multiple resolutions >

The original commit adding that check tried to protect the kenrel against a potential invalid NULL pointer access. However we call nouveau_connector_detect_depth once without a native_mode set on purpose for non LVDS connectors and this broke DP support in a few cases. Cc: Olaf Skibbe <news at kravcenko.com> Cc: Lyude Paul <lyude at redhat.com> Closes:

Now that we've added the hooks that we've needed for this and used them in i915, let's add one more hook (which I could use some feedback on, I'm not sure if it's worth maybe just reworking how we do mode pruning in nouveau instead...) and start using this in our mst ->mode_valid callback to filter out impossible to set modes on MST connectors. Lyude Paul (2):

In order to be able to use bpc values that are different from what the connector reports, we want to be able to store the bpc value we decide on using for an atomic state in nv50_head_atom and refer to that instead of simply using the value that the connector reports throughout the whole atomic check phase and commit phase. This will let us (eventually) implement the max bpc connector property,

It seems it was only locking up in the context of nouveau_hw_save_vga_fonts, when it actually did something (because the console wasn't already in graphics mode). Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- drivers/gpu/drm/nouveau/nouveau_hw.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_hw.c

Realized when I moved nouveau over to using the atomic DP MST VCPI helpers that I forgot to ensure that we clamp the BPC to 8 to make us less likely to run out of bandwidth on a topology when enabling multiple displays that support >8 BPC - something we want to do until we have support for dynamically selecting the bpc based on the topology's available bandwidth, since userspace isn't

This patch series adds TV-out modesetting support to the KMS implementation. I've tried to test it on all the hardware I've got at hand (that is nv11, nv17, nv34, nv35, nv40, nv4b) with every possible output combination; I believe it has reached a mergeable state, however it depends on some commits from drm-next that haven't got into Linus' tree yet, if you agree to merge this

While the way we find the associated connector for an encoder is just fine for legacy modesetting, it's not correct for nv50+ since that uses atomic modesetting. For reference, see the drm_encoder kdocs. Fix this by removing nouveau_encoder_connector_get(), and replacing it with nv04_encoder_get_connector(), nv50_outp_get_old_connector(), and nv50_outp_get_new_connector(). v2: * Don't

On Wed, Feb 17, 2010 at 10:42:43AM +0100, Daniel Mack wrote: > Fix the following compile time error: > > drivers/built-in.o: In function `nouveau_connector_detect': > /home/daniel/src/linux/jup/linux-2.6/drivers/gpu/drm/nouveau/nouveau_connector.c:243: undefined reference to `acpi_lid_open' > > Signed-off-by: Daniel Mack <daniel at caiaq.de> > Cc: David Airlie

Reviewed-by: Lyude Paul <lyude at redhat.com> Will push this upstream in just a moment, thanks! On Thu, 2024-06-27 at 10:27 +0800, Ma Ke wrote: > In nouveau_connector_get_modes(), the return value of > drm_mode_duplicate() > is assigned to mode, which will lead to a possible NULL pointer > dereference on failure of drm_mode_duplicate(). Add a check to avoid > npd. > >

https://bugs.freedesktop.org/show_bug.cgi?id=75620 Priority: medium Bug ID: 75620 Assignee: nouveau at lists.freedesktop.org Summary: [NVAA] nouveau: tearing regression QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: All Reporter: alexanders83 at web.de

https://bugs.freedesktop.org/show_bug.cgi?id=90423 Bug ID: 90423 Summary: [NVAA]: Shutdown (poweroff) get stuck when runtime PM is enabled Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component:

- Use driver level (0x2) for NV_DEBUG instead of all levels - Create a NV_DEBUG_KMS for KMS level (04) and use them in modesetting code - Remove a few odd NV_TRACE calls and replace with NV_DEBUG_KMS Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_bios.c | 12 +++++----- drivers/gpu/drm/nouveau/nouveau_connector.c | 8 +++---

To start off: this patch series is less work to review then it looks - most (but not all) of the nouveau related work has already been reviewed elsewhere. Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM

Next version of https://patchwork.freedesktop.org/series/48596/ . Made some important changes to the refactoring patch, but everything else is the same. Lyude Paul (5): drm/nouveau: Check backlight IDs are >= 0, not > 0 drm/nouveau: Move backlight device into nouveau_connector drm/nouveau: s/nouveau_backlight_exit/nouveau_backlight_fini/ drm/nouveau: Cleanup indenting in