NVIDIA 515.76

[XV-02]

On Oryp7, fractional scaling is not working broadly:

The external monitor frequently has a mismatch between rendered mouse position and logical mouse position when fractional scaling is applied to the onboard panel.

Additionally, when the external monitor is scaled by a non whole factor (1.25x or 125%, for example, instead of 2x or 200%) windows are larger than available screen real estate. Full-screened or tiled windows will frequently spill outside of the visible screen boundary. However, they comply to the logical display boundaries, as the mouse can move beyond the visible boundary and interact in the logically present but non-visible space.

In display settings, at sufficiently disparate scaling, the external monitor will sometimes arbitrarily default to sharing a border with the top of the onboard panel, and changing settings further can default to being "attached" only at a corner with the onboard panel. While this doesn't cause any irreparable issues, it is possible to strand the mouse on one display or the other, which is a significant source of headaches when trying to interact with software such as display settings - components of which require mouse interaction - if they're on the other display. This is particular to trying fractional scaling though, and doesn't occur with the standard scaling options or when adjusting resolutions.

[XV-02]

Checking against our current - 515.65 - driver release, aforementioned issues are not a regression in behaviour. Still, noteworthy. I would not recommend treating it as a blocking issue given the capricious nature of fractional scaling at present, and the fact it isn't a regression.

[XV-02]

A more serious issue: 515.76 doesn't seem to be recognizing USB-C Displayport hotplug. This is a regression, as Integrated graphics mode will prompt for hybrid when Displayport over USB-C is attached under 515.65. With 515.76 this is not the case.

Scratch that. It's merely slower. Not by a lot, but by enough that I got tripped out by it a couple times.

[XV-02]

With the current 5.19.16 kernel release there is a regression in behaviour on laptops when booting with lid open and HDMI attached. The system hangs after receiving the decryption password, and sits at "cryptswap: crypdata: set up successful"

This happens both on and off battery. This persists if the HDMI connection is pulled once it has reached this state. I would note that, if I hit esc at decrypt screen, the TTY is displayed on the attached monitor, not the built-in panel. And it claims to successfully process to the point of starting account services.

Oddly, desktop also seems to have issues with booting with HDMI attached monitors. exhibiting similar behaviour of stalling after decryption.

[XV-02]

The aforementioned behaviour is also persisting with the 6.0.2 kernel.

This was present on an 11th gen Intel laptop (Oryp8), and a 13th gen Intel desktop (Mira B3 w/ 13th Gen Intel & 30 series GPU)

Intel13GenMiraB3DmesgLog.log Intel13GenMiraB3JournalLog.log Oryp8DmesgLog.log Oryp8JournalLog.log

From some brief research, I've seen reports of similar issues on Arch and Fedora - All the reported issues have been with post 5.19.8 kernels of some description.

From about 5 days ago, Ubuntu 22.10 appears to have issues as well. https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-515/+bug/1993056

None of the issues I've found have been specifically the same. But it does seem there might be somewhat broad issues.

---

Edit: added more notes.

https://forums.developer.nvidia.com/t/bug-report-black-x11-screen-and-partial-lockup-when-upgraded-to-515-76-and-dual-rtx3060/228912/6

This seems to be a general 515.76 bug report. I did note in the comments a snippet of log which was familiar. In the Oryp8 Journalctl log, the following is present (and quite similar to a few excerpts in the linked thread):

Oct 20 16:07:25 pop-os kernel: nvidia-modeset: WARNING: GPU:0: Unable to read EDID for display device ViewSonic VP2770 SERIES (HDMI-0)
Oct 20 16:08:29 pop-os kernel: nvidia-modeset: WARNING: GPU:0: Unable to read EDID for display device HDMI-0
Oct 20 16:09:17 pop-os kernel: nvidia-modeset: ERROR: GPU:0: Idling display engine timed out: 0x0000c67d:0:0:1119
Oct 20 16:09:25 pop-os kernel: nvidia-modeset: ERROR: GPU:0: Idling display engine timed out: 0x0000c67e:0:0:1128
Oct 20 16:09:33 pop-os kernel: nvidia-modeset: ERROR: GPU:0: Idling display engine timed out: 0x0000c67e:1:0:1128

[leviport]

I'm confused by that. I have 515.76 on my oryp9 and the mira-r3 with a 1070, and both look fine. The oryp9 is connected to a second display via USB-C, and the mira-r3 is connected to a single display via HDMI. What am I doing wrong?

[XV-02]

I looks like it might be specific to HDMI on post-pascal architectures from snooping about. I did also note this link, which may be helpful:

https://github.com/NVIDIA/open-gpu-kernel-modules/issues/380

[jackpot51]

These regressions will require 520 to resolve. For now, we will support Linux 6.0 with a patch to the previous 515 driver: #168