00:18pl44c: I'm trying to get an external monitor to turn on from my w530
00:18pl44c: I switched outputs and then went back but it won't pick up the signal
00:18pl44c: I'm using the dock displayport
00:19pl44c: and wayland
00:19pl44c: it's happened pretty consistently
00:19pl44c: currently I'm on kernel 5.0.2
00:32imirkin: "switched outputs"?
00:36pl44c: imirkin: on the monitor
00:36pl44c: I switched which device it was on
00:37imirkin: by adjusting a cable
00:37imirkin: or by switching inputs using the internal switcher
00:37pl44c: no on the monitor panel
00:37imirkin: anything in dmesg?
00:38imirkin: how is the monitor connected to the dock? what is the resolution of the monitor?
00:39pl44c: imirkin: https://dpaste.de/0ZT6/raw dock is connected via displayport male to male cable to a 433835U dock on the 1st dp connector slot
00:39pl44c: the resolution is 1920x1200
00:40imirkin: pl44c: i mean how is the monitor connected to the doc?
00:40pl44c: imirkin: it's connected displayport, sorry made a typo
00:40pl44c: no adapters or conversion
00:41imirkin: sounds like we're supposed to redo link training when it switches
00:41imirkin: but don't
00:41imirkin: or something
00:41imirkin: sorry, this is above my paygrade :)
00:41pl44c: would DVI to hdmi be more stable?
00:42pl44c: I guess I could try it
00:42imirkin: DP is very finicky
00:42imirkin: if it goes through the dock, probably not though
00:42imirkin: since the dock is DP
00:43pl44c: dock has both dvi and dp
00:43imirkin: it's a DP dock.
00:43imirkin: if it has other outputs, they're just DP <-> DVI or whatever active adapters
00:43imirkin: as far as the gpu is concerned, it's all just DP
00:45karolherbst: uff, if it's a dock it is probably DP-MST stuff
00:45karolherbst: we had some bugs related to that, but I thought those were fixed in 5.0?
00:45karolherbst: maybe Lyude knows something?
00:46karolherbst: pl44c: sometimes there are some runpm issues left and nouveau doesn't really get triggered... maybe booting with nouveau.runpm=0 could make that much more stable, but then the GPU is always powered on
00:47karolherbst: I know that Lyude is looking into those kind of issues
00:47pl44c: karolherbst: pretty sure with coreboot the optimus isn't supported so the gpu already is always on
00:47pl44c: wouldn't be much of a loss if any
00:49pl44c: it's why I got a slice battery
00:50karolherbst: mhh, well, that's kind of annoying
00:50karolherbst: because with DP you are kind of guarenteed to get ACPI involved
00:50karolherbst: but mhh, without optimius you usually don't need it
00:51karolherbst: imirkin: hotplugging events through ACPI
00:51karolherbst: you know, if the GPU is off, no other way to notify the OS
00:51imirkin: oh, you mean HPD in the presence of runpm?
00:52karolherbst: yeah.. we kind of set a lot of stuff up for that
00:52karolherbst: I am just not sure what happens with coreboot here
00:52karolherbst: maybe they implement the methods kind of
00:52karolherbst: or maybe not
00:52karolherbst: anyway, this could confuse nouveau a lot
00:53karolherbst: we stop polling if we runtime suspend the GPU and setup the ACPI handlers
00:53imirkin: ok. i actually didn't realize that ACPI was implicated in that. but i've not really looked at how runpm works.
00:53karolherbst: well, how else if not ACPI ;)
00:53imirkin: [obviously acpi is involved in actually making runpm happen - i know that much..]
00:54imirkin: i dunno - some WoL type situation?
00:54karolherbst: would be messy, no?
00:54imirkin: WoL is part of the PCI standard.
00:54karolherbst: well, but the device can't be in D3cold for it to wor
00:54karolherbst: because, how?
00:55imirkin: WoL allows a computer that's off to be turned on by a PCI card.
00:55imirkin: i'm sure something could be worked out to allow a GPU to signal to the host that it should turn on for hpd.
00:55karolherbst: yeah.. but it doesn't get handled by the device
00:55imirkin: the device sends the signal
00:56karolherbst: WoL is kind of an interrupt setup against the firmware
00:56karolherbst: and you essentially just configure the PIN on the device
00:56imirkin: it's a pci device that remains powered during system off state
00:57imirkin: and can indicate to the system that it should turn on via ... some pci mechanism.
00:57karolherbst: it could have been like this in older systems, but on modern ones ACPI is involved
00:57imirkin: [allegedly, so that network administrators could turn on people's systems at night to perform updates]
00:58karolherbst: but yeah.. I forgot about the older PCI based implementations
00:58karolherbst: but these days all of that is ACPI stuff
00:58imirkin: nowadays it's actually back to PCI core
00:58imirkin: but yeah, still acpi involvement
00:59karolherbst: well, of course you need PCI for the signal to actually arrive :)
00:59karolherbst: anyway, for display outputs we have something similiar
01:00karolherbst: and nouveau has to handle some ACPI events in case the GPU is turned off
01:01pl44c: now the monitor didn't even initalize
01:01karolherbst: imirkin: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/nouveau_display.c?h=v5.2-rc3#n361
01:01pl44c: so I didn't bother to change outputs
01:02imirkin: karolherbst: fun
01:02karolherbst: yeah.. ask Lyude about how much fun all of this was to fix :p
01:30pl44c: yeah dvi to hdmi gives no issues
01:31pl44c: funny how dp to dvi to hdmi works better than just dp > dp
01:31imirkin: probably because the dp is terminated at the dock
01:31imirkin: which remains always on
01:32imirkin: while the monitor does something funny
01:33pl44c: I see
01:34pl44c: no I don't suppose this is also the place to ask about why when passing the k2000m to a vm it produces no output from the dock or the video card?
01:34pl44c: *now I don't
01:35imirkin: the vbios is probably in acpi, and the vm doesn't get it?
01:36pl44c: I tried passing it to the vm though rom file=path/to/file
01:36pl44c: do I need to in ovmf?
01:36imirkin: that won't work
01:36imirkin: the vbios isn't the full pci rom
01:38pl44c: imirkin: so the rom from the bios image isn't what I want?
01:39imirkin: is this for nouveau, or for like windows?
01:39pl44c: for vfio but it's in the context of a nvidia card so I'd figure I ask here
01:39imirkin: i undrstand
01:39imirkin: but in the vm
01:39imirkin: is it windows?
01:39pl44c: was going to do windows yeah
01:40imirkin: so yeah, you'd need to convince it to load that vbios
01:40pl44c: I should see the ovmf splash still right?
01:41imirkin: (what's ovmf?)
01:42pl44c: imirkin: the uefi firmware
01:42imirkin: then no
01:42imirkin: it'd rely on having a GOP driver to do display
01:51pl44c: do I need to modify the rom to get the display to work in the vm then?
01:55imirkin: the rom is more than just the vbios
13:28rhyskidd: karolherbst: rock solid on my gp107 after at least a week with your runpm series and secboot patch. thanks
13:32diogenes_: Hello guys, i use DRI_PRIME=1 with games but powertop still shows nvidia as not being used:
13:32diogenes_: 0.0% PCI Device: NVIDIA Corporation GK107M [GeForce GT 650M]
13:33diogenes_: is that ok?
14:15karolherbst: rhyskidd: \o/
14:15karolherbst: diogenes_: ignore powertop
14:16karolherbst: diogenes_: check with glxinfo
14:16karolherbst: powertop only estimates all of that anyway
14:37diogenes_: karolherbst, thanks, glxinfo is showing all as it should.
14:44pl44c: imirkin: oh so it's not at all the same kind of rom that the vm is looking for
15:37imirkin: pl44c: it's kind of the same kind of rom, just not exact the same :)
15:41pl44c: imirkin: is there a way to covert it to what is needed for the vm to display?
15:57imirkin: a way? probably
15:57imirkin: no clue how, esp not with uefi
15:57pl44c: I found this, would this be what I want?
15:59imirkin: sssomething like that
15:59imirkin: as those instructions suggestion, fiddling is going to be required
16:16pl44c: alright I attempted to update the rom, what's the safe way to unload nouveau
16:16pl44c: so I can load vfio-pci
16:21imirkin: pl44c: https://nouveau.freedesktop.org/wiki/KernelModeSetting/
16:21imirkin: unbinding the vtconsole is very important.
16:21imirkin: but it might not be bound if it's a secondary gpu
16:27pl44c: imirkin: it still tells me nouveau is in use
16:27imirkin: is it? :)
16:27imirkin: cat /sys/kernel/debug/dri/.../clients
16:30pl44c: 0 and 1 have xwayland and logind but 1 and 129 which I'm assuming are the nvidia card only have logind
16:31imirkin: so logind is using it.
16:32imirkin: no logind here...
16:35pl44c: any idea how to make logind let go of the nvidia?
16:35imirkin: kill -9 :p
16:36pl44c: but it's the same pid as the one on the intel gpu and I thought logind did some stuff necessary for wayland
16:36imirkin: but it'll let go of nvidia.
16:36imirkin: it'll also let go of a lot of other things
16:36imirkin: but since you're using it, you've let go of sanity a long time ago
16:37pl44c: systemd or wayland?
16:38pl44c: the process was replaced by a zombie
16:38imirkin: thank you for choosing systemd as your init system. we appreciate that you have a choice of init systems, and you appear to have made the wrong one.
16:39pl44c: is duvan the only well maintained systemdless distro?
16:39imirkin: gentoo seems well-enough maintained
16:39pl44c: but compiling everything is for nerds :p
16:40pl44c: I used to use gentoo
16:40imirkin: yeah, and making your own bios rom to feed to a vm is definitely not.
16:40pl44c: stopped as it made me crazy with useflags and making sure I only had what i needed
16:40pl44c: spent to much time on it
16:41imirkin: yeah, can't be too anal about it, otherwise yeah, disaster
16:41imirkin: but it's helped me to keep idiocy like pulse off my system
16:41pl44c: sadly I need pulse for the garbage I do which pulse probably wasn't designed for but I use it for it anyway :p
16:42pl44c: systemd can go though
16:44pl44c: alright guess I'll reboot to test the rom
16:44pl44c: thanks poetering
16:48pl44c: and the rom doesn't work rip
17:32imirkin: skeggsb: thoughts? https://hastebin.com/zalisetegi.css
17:32imirkin: also saw some code 0xd
17:33imirkin: seemed to happen esp when switching formats
17:43karolherbst: imirkin: it kind of would be cool to have a decoder for it
17:44imirkin: well, the methods are defined in the nvidia headers
17:44imirkin: however the question is more about ... why :)
17:50karolherbst: my assumption is just, that if the debug message has more information, that it's easier to see what's wrong... or maybe not
17:50karolherbst: anyway, might make it faster to debug those issues
17:51imirkin: having a decoding for codes would be nice, but i dunno that we have that
17:52imirkin: i.e. why is the state invalid :) seems valid to me!
17:52imirkin: but the hw tends to win such arguments =/
17:53karolherbst: yeah, sadly
18:36imirkin: i'm going to try sticking it into core instead of base...
18:36imirkin: oh wait. i can't. gr.
20:55imirkin: skeggsb: if i drop the 0x80000000 bit from the red2red entry (i.e. owner = base), then no errors. but also no csc transform.
20:59imirkin: skeggsb: fwiw this is my current thing: https://hastebin.com/risojexibo.cs
21:00imirkin: i wonder if it only happens for some formats...
21:01imirkin: i also wonder if those CSC controls do exist in core contrary to the docs