01:08chilversc: hi, I was reading the optimus docs on https://nouveau.freedesktop.org/wiki/Optimus/ does this work with wayland?
02:05imirkin: chilversc: stuff like "optimus" is up to the compositor to support. i believe most do.
02:05imirkin: [wayland compositor, that is]
12:14chilversc: So how do I configure optimus with wayland? The guide on the site keeps discussing xrandr which doesn't work with wayland.
12:15chilversc: xrandr --listproviders, says there are 0 providers
12:56karolherbst: chilversc: it should just work
12:56karolherbst: but the compositor needs to implement support for it
13:21chilversc: currently it doesn't seem to detect when I connect an external monitor
13:22karolherbst: grep . /sys/class/drm/card*/status
13:22chilversc: I had that working in the past on f29, but I suspect I was using bumblebee, which seems to be deprecated in favour of prime
13:24chilversc: that's the intel, connected to the built in display
13:24chilversc: that is incorrect, because it is connected
13:24karolherbst: yeah, so it's probably some kernel issue
13:24chilversc: so is the solution here to just install the official nvidia driver?+
13:25karolherbst: nvidia doesn't support display offloading
13:25chilversc: any idea where to go next with this then?
13:25karolherbst: what kernel are you running on?
13:26karolherbst: that's.... old
13:26karolherbst: you might want to update your system
13:26karolherbst: chances are the issue was already fixed
13:26chilversc: ah wait, I might need to reboot, as I only recently installed this system
13:26karolherbst: ahh, makes sense
13:26karolherbst: check with ls /boot if there is a newer kernel though
13:27karolherbst: 5.5.10 is the newest or so
13:27chilversc: so hopefully if I reboot after completing dnf update it will just work
13:27karolherbst: it might not though, but it's pointless to debug on an EOLed kernel
13:28chilversc: cool, I was trying to check everything was configured / installed but the instructions on the site were a dead end because they keep telling me to use xrandr which is useless under wayland
13:28karolherbst: yeah.. all of that is not needed under wayland
13:34chilversc: Yup, that does just work. That's one thing that page doesn't really mention is that this is all built in to the latest kernel.
13:34chilversc: As last time I installed this system there were a lot of manual hoops to making this work
13:35karolherbst: chilversc: well, it should have worked with an older kernel, but bugs happen
13:35karolherbst: and yeah.. if using open source drivers bumblebee was never a good option
13:36karolherbst: but also the prime bits took a bit to implement.. oh well
13:40chilversc: yeah, its just awkward because when it not working and you search you get a lot of old information at the moment
13:41chilversc: I think that page could do with a note about wayland (i.e. the xrandr steps won't work) and a note that this is built into the latest kernels (maybe include a revision number) to help with the confusion from old instructions
13:43chilversc: though once you are on the latest kernel this is a much better experience from when I first had to get optimus working about 4 years ago
13:47karolherbst: chilversc: yeah.. but on modern systems it also should just work. But yeah, instructions could be updated
13:49chilversc: yup, its more for people like me who were used to this being difficult so go looking up how to configure it before realising there's nothing needed any more
16:11chilversc: great, my monitors went to sleep when it entered the lock screen and now its forgotten that the other monitor exists
16:11gnarface: heh, i hate it when that happens
16:12chilversc: yeah, now how to I re-enable it?
16:12gnarface: oh, i don't know. it's probably up to your login manager?
16:12chilversc: it's back to saying /sys/class/drm/card1-HDMI-A-1/status:disconnected
16:12chilversc: which isn't true
16:13chilversc: with optimus
16:13gnarface: hmmm, then i really don't know
16:13gnarface: sorry :(
16:13chilversc: the hdmi port is connected to the dedicated card
16:13chilversc: I suspect the kernel powered down the card in sleep and has forgotten to power it back up
16:14gnarface: that's possible, but i've also had issues where login managers just screw up and place the login panel on the sleeping screen instead of the one that woke up
16:14chilversc: naw, the other monitor doesn't show up any more in the display settings
16:15chilversc: and from that output it thinks there's no monitor connected when there is
16:16chilversc: so /sys/class/drm/card1/device/power/runtime_status says error, is that an issue?
16:17gnarface: lol probably, but that's just a guess
16:21RSpliet: chilversc: the first source of information is your kernel log. The GPU may have shat itself in the process of resuming from suspend, usually that's where it hides the evidence
16:26chilversc: looks like something went wrong, thats from journalctl
16:28RSpliet: Yeah that's a clear problem. The log starts a little bit too late. Could you include the log messages from the moment your *start* suspend?
16:29RSpliet: Anything after the first backtrace on nouveau is probably noise (or propagation of errors rather. Usually if you fix the first one, you fix the whole lot)
16:30chilversc: can't see anything in the logs about the suspend itself
16:30chilversc: there's nothing in the logs before that except the periodic wifi suplicant, and me disconnecting my blutooth headset
16:31chilversc: so it seems to have gone into D3 without an issue
16:31RSpliet: Even if you go into D3cold without issues you get some messages of proud drivers telling you they succeeded
16:32chilversc: nope, ?D3 pattern not found, prior to that line
16:33RSpliet: I'll leave the actual bug-chasing to karolherbst by the way, he's most knowledgeable on the topic. I'm just making sure he has all the possible information when he wakes up ;-)
16:33chilversc: closest hint I have is this line: Mar 28 15:54:50 localhost.localdomain NetworkManager: <info> [1585410890.8749] device (wlp3s0): supplicant interface state: inactive -> disabled
16:33karolherbst: RSpliet: lol...
16:33RSpliet: That's not kernel log, that's just journalctl interleaving everything and the kitchen sink
16:34karolherbst: could be some dpms messup
16:34karolherbst: ohh heh
16:34karolherbst: yeah, the gpu is dead no
16:34RSpliet: karolherbst: ACPI Error: Aborting method \_SB.PCI0.PGON due to previous error (AE_AML_LOOP_TIMEOUT)
16:34RSpliet: That's a dead giveaway :-D
16:35karolherbst: chilversc: booting with nouveau.runpm=0 will fix it but kills battery lifetime
16:35karolherbst: we have a fix though and it will most likely be merged soon and backported
16:35chilversc: well this could be it, it matches my GPU https://bugs.freedesktop.org/show_bug.cgi?id=94725
16:35RSpliet: karoleherbst: This is for a D3cold cycle I believe
16:35karolherbst: chilversc: ignore most of those bugs, they are all duplicates
16:36karolherbst: RSpliet: no, the firmware just has to deal with a turned off GPU
16:36karolherbst: which.. in loops with never changing values doesn't play out well
16:36chilversc: The see also links to https://bugzilla.kernel.org/show_bug.cgi?id=156341
16:36karolherbst: yeah, and the discussion there is worthless
16:36karolherbst: I've created a new one at some point
16:37karolherbst: most of the time they poke into the firmware to figure out what's wrong, and people did this over and over again
16:37chilversc: so just need to keep an eye on when that makes it into a kernel update
16:38karolherbst: yeah.. hopefully with 5.7
16:38karolherbst: dunno what skeggsbs plans are
16:38chilversc: yeah, really wish nVidia would release the specs on optimus, I heard rumor about them open sourcing some of their drivers?
16:38karolherbst: there are open sourced bits
16:38karolherbst: like the nvidia-uvm module
16:38RSpliet: karolherbst: agreed. All I wanted to do is emphasise (in the light of your "kills battery life" comment) that this isn't the D3Hot thing that we use for powersaving when the laptop is on, but this is an actual suspend-to-RAM->resume cycle of the whole laptop. Make sure we're on the same page :-)
16:39karolherbst: ahh, I see
16:40RSpliet: Or... that's the impression I got from chilversc. Now I'm questioning myself though
16:40chilversc: so even with runpm=0, I might still get this issue when the laptop goes to sleep through inactivity?
16:41karolherbst: just your killed battery lifetime
16:41karolherbst: ignoring random bugs though
16:41karolherbst: there can always be bugs
16:41chilversc: so when the laptop sleeps/suspends itself the GPU will still be powered down?
16:42chilversc: or would I need to actually shut down if I go to lug this thing around to avoid it heating up in a bag?
16:43karolherbst: well, if your system is suspended, it is suspended ;)
16:44karolherbst: it's only affecting the GPU when it's idling
17:40hessophanes: imirkin: One followup question: Is there anything I could do that would be helpful? Some devel branch I could test, obtaining somre more i2c diagnostics, dumping system descriptor tables...?
17:41imirkin: hessophanes: i have the memory timeline of a goldfish... remind me what your issue was?
17:43imirkin: oh yeah, the weird i2c errors?
17:43imirkin: on a TU117 or something?
17:44imirkin: you should try a boot with nouveau.debug=i2c=trace,aux=trace,disp=trace drm.debug=0x1e
18:56hessophanes: Aaah, thank you, I'll definitely try that and report back if the results look useful.
19:00imirkin: well, they won't look useful, it'll just be a ton of information
19:01imirkin: which will then need to be analyzed by someone
19:01imirkin: my theory is that we're off somewhere in i2c-land
19:01imirkin: there have been a few changes over the eons to how it works