David Woodhouse
2025-Apr-07 20:09 UTC
Re: [6.13.6 stable regression?] Nouveau reboot failure in r535_gsp_msg_recv()
On 7 April 2025 20:51:50 BST, Timur Tabi <ttabi at nvidia.com> wrote:>On Mon, 2025-04-07 at 20:41 +0100, David Woodhouse wrote: >> Yes. The proprietary driver (570.133.07) did manage to light up the >> external monitor over USB-C/DP. >> >> It was utterly unusable, as I couldn't make it do 100% scaling on the >> external screen and 200% on the high-DPI laptop screen, and my attempts >> to do so (just using the GNOME control panel) ended up with weird >> effects and wrong scaling and the mouse pointer not really taking >> effect in the place I thought it was pointing... but setting that >> aside, yes. The display *did* light up. > >I don't know anything about capabilities of our driver w.r.t. scaling, but >what happens if you try to keep everything at 100%? > >It's possible what you're trying to do is just not supported by GNOME, >Wayland, Xorg, and/or our driver. > >> > If the proprietary driver works just fine, then we know that it's a >> > bug/limitation in how Nouveau talks to GSP-RM.? One of the Nouveau devs >> > can >> > help with that. >> >> Is the first step there to try beta testing the r570 update? > >So here's the problem. If the proprietary driver doesn't work, then there's >no hope for Nouveau working. ?That's because the GSP-RM firmware that >Nouveau depends on *is* the Nvidia proprietary driver. > >I hate to say this, but you're going to have to work with your laptop vendor >and/or Nvidia support to get the proprietary driver working first.It *was* working, as long as I could tolerate it being scaled to 200% like the internal display. It *did* light up the external display just fine.
Timur Tabi
2025-Apr-08 15:59 UTC
[6.13.6 stable regression?] Nouveau reboot failure in r535_gsp_msg_recv()
On Mon, 2025-04-07 at 21:09 +0100, David Woodhouse wrote:> It *was* working, as long as I could tolerate it being scaled to 200% like > the internal display. It *did* light up the external display just fine.Ok, the only thing I can think of is to do a bisect between 6.13.4 and 6.13.6 to determine the commit that broke it.