09:51zfnmxt: Hi. I'm trying to get nouveau + PRIME to work. Seems like xrandr can see the two cards fine: http://ix.io/1Lnm, and `xrandr --setprovideroutputsource nouvea Intel` adds a number of interfaces to the output of `xrandr`. Yet, when I try to activate the newly added `HDMI-1-1` interface (`xrandr --output HDMI-1-1 --auto`) I get no output.
10:00karolherbst: zfnmxt: what's the status of the output?
10:01zfnmxt: The status?
10:02karolherbst: well, whatever xrandr is printing
10:02zfnmxt: I also just tried `xrandr --setprovideroffloadsink nouveau Intel` and then `DRI-PRIME=1 glxinfo` and it actually fails and says the nouveau driver can't be loaded :(
10:02zfnmxt: karolherbst: Disocnnected.
10:03karolherbst: did you had the nvidia driver installed in the past?
10:04karolherbst: the nouveau driver not being able to be loaded is kind of messy :/ could be that the mesa drivers aren't correctly installed?
10:04karolherbst: check what's inside /usr/lib64/dri/
10:04zfnmxt: I'm able to get it to load when I switch my laptop to discrete graphics mode in the BIOS
10:05karolherbst: there should be a nouveau_dri.so file
10:05karolherbst: ohhh, mhhh
10:05karolherbst: sure it's nouveau and not llvmpipe?
10:05zfnmxt: I don't have /usr/lib64 :D
10:05zfnmxt: I'm on NixOS so things are a bit funky wunky
10:05karolherbst: ehhh, understood
10:06zfnmxt: I do have a nouveau_dri.so file, though.
10:06karolherbst: LIBGL_DEBUG=1 DRI_PRIME=1 glxinof
10:07zfnmxt: and `lsmod` turns up nouveau too, if that's at all informative
10:08karolherbst: mhh, that's expected, otherwise the xrandr stuff would have failed already
10:09karolherbst: I am wondering why the mesa driver doesn't load :/
10:10karolherbst: yeah... I think I know what's up
10:11karolherbst: zfnmxt: can you pastebin your dmesg output as well?
10:11karolherbst: it's probably runpm messing up (we have a workaround/fix for it in the pipeline)
10:12karolherbst: zfnmxt: you could try to boot with nouveau.runpm=0 and see if things starting to work then... but sadly the GPU is always on and battery lifetime will be bad
10:12karolherbst: but maybe better than in dedicate only mode
10:13karolherbst: yeah... the PCIe device is dead
10:13zfnmxt: I'd really prefer for it to be dynamic. It's like 2 hours vs. 8 hours of battery life on my laptop :(
10:13karolherbst: which is kind of the runpm bug we have
10:13karolherbst: zfnmxt: uff, mhh, sure... but without compiling a new kernel you won't be able to use the nouveau gpu for now (except with nouveau.runpm=0)
10:14zfnmxt: I'll try it, sec
10:19zfnmxt: karolherbst: nouveau.runpm=0 didn't fix it :(
10:19zfnmxt: How could I address it with a new kernel?
10:19karolherbst: what laptops is it?
10:19zfnmxt: Thinkpad X1 Extreme
10:19karolherbst: lenovo p52 or something?
10:19zfnmxt: Close :D
10:20zfnmxt: I really wish they had just wired one port to the intel card =/
10:20karolherbst: x1 is just a pimped p52 or something, no?
10:20zfnmxt: P52s, I think
10:20zfnmxt: But I'd say the p52s is the pimped one, x1 is cheaper more consumer-y version
10:21karolherbst: yeah.. wiring all to the intel GPU usually makes that stuff much simplier
10:22zfnmxt: I managed to get bumblebee to work with propietary drivers, and then you can pipe the output of the intel card using intel-virtual-output...but it was really laggy.
10:24zfnmxt: I'm not sure if I have mesa, tbh.
10:29karolherbst: zfnmxt: do you have the 2560 x 1440 display?
10:30zfnmxt: karolherbst: No, it's 1920x1080.
10:30karolherbst: but yeah.. with bumblebee things are a bit sucky.. although you shoul be able to meet the bandwidth in order to not fall that much behind the actual rendering
10:31karolherbst: so if the game renders at 60fps it shouldn't be laggy
10:31zfnmxt: No, it's just the output mirroring.
10:31karolherbst: ohh mhhh :/
10:31zfnmxt: All I care about is getting an external monitor to work, not doing any graphics intensive anything
10:31karolherbst: ohhhh, that part
10:31karolherbst: right.. that's annoying with bumblebee, true
10:32zfnmxt: I've read that performance is better for that using nouveau with bumblebee
10:32zfnmxt: But couldn't get that to work either so...
10:32zfnmxt: Basically, nothing works :D
10:32karolherbst: zfnmxt: mind sharing your dmesg booted with nouveau.runpm=0?
10:32zfnmxt: Yeah, have to add the parameter back in again. Sec.
10:37karolherbst: okay.. interesting
10:38karolherbst: zfnmxt: and you said that in dedicated only mode the GPU is usable just fine?
10:38zfnmxt: Yeah, works fine with nouveau.
10:38karolherbst: mhhh, sadly this is the second bug we see on a few GPUs and it's more annoying to deal with as it involves signed firmware :/
10:39karolherbst: but interesting that it works in dedicated only mode
10:40karolherbst: skeggsb might know something
10:40karolherbst: Lyude noticed this as well?
10:40zfnmxt: Does nouveau let you control the power/performance of the GPU? One of my big gripes with going dedicated-only (when I was using propietary drivers) was that the GPU would constantly switch into performance mode and spin the fans up at the slightest load
10:41HdkR: Just use Maxwell2+ to always be locked in to the best powersaving mode possible ;)
10:41karolherbst: zfnmxt: not on pascal gpus
10:42karolherbst: it's more or less locked down behind signed firmware we've not gotten yet
10:42karolherbst: so even if we knew how to change the perf states, the hardware doesn't allow us to do it
10:42karolherbst: yeah.. it's silly
10:42karolherbst: started with the gm20x GPUs where we are not allowed to change the fan speeds without signed firmware......
10:43karolherbst: but changing voltage and clocks? sure, that's fine...
10:44HdkR: Theoretically getting more and more locked down after each generation. Maybe it'll eventually end up like adreno where you need a signed shader to kick the 3D engine out of secure mode :P
10:44zfnmxt: What about something like one of those cheapo USB-to-VGA adapters?
10:44karolherbst: well, content industry doesn't care as long as they get what they request :p
10:44zfnmxt: Could someting like that conceivable work?
10:44karolherbst: nvidia is just big enough so they can't just require anything
10:45karolherbst: zfnmxt: mhhh, probably? no idea how those work internally
10:45zfnmxt: Must have some sort of GPU type thing on them, dunno
10:45zfnmxt: Guess I'l look around and use iffy bumblebee for now
10:45karolherbst: zfnmxt: ohh wait, I remember that skeggsb was pushing out some changes regarding secboot
10:46karolherbst: no idea if that has any effects on your gpu though
10:46zfnmxt: Honestly, I'm guessing my GPU problems are likely due to incompetence on my part
10:46zfnmxt: Basically everything involved right now is foreign to me, on top of whihc NixOS adds a layer of strangeness/complexity
10:46karolherbst: no idea in what kernel those changes will land though
10:46karolherbst: but should be "soonish"
10:47karolherbst: 5.4 the latest I guess
10:47karolherbst: but probably 5.3 or even backported
10:47zfnmxt: Well I'll keep trying every now and then :D
10:47karolherbst: zfnmxt: well, those are known issues you are running in, it's just messy to fix those as it's more a fight against the hardware
10:49zfnmxt: Hm, seems like a USB adapter might actually work
10:50zfnmxt: And would solve all my problems. Gonna try that.
10:50zfnmxt: Thanks for your help, though, karolherbst :D
14:26Lyude: zfnmxt, karolherbst: I believe I have seen that before actually, on one of my friend's Xaomi machines
14:26karolherbst: 1050ti is a gp107 afaik
14:27imirkin_: zfnmxt: could just boot with nouveau.noaccel=1 -- should get the screens going, maybe
16:09kreyren: Is it sane to use nouveau on GTX780m ?
16:12karolherbst: kreyren: should be alright
16:14kreyren: karolherbst, Currently having problems with optimus not switchning GPU correctly https://gist.github.com/Kreyren/d476876d29e1fec1db8226dc1b4789a2 more info?
16:14kreyren: none was able to help so far and i suspect it beeing nouveau issue
16:15karolherbst: kreyren: nouveau isn't loaded
16:15kreyren: how do i load it?
16:15karolherbst: it should load automatically
16:15karolherbst: but maybe there is some blacklisting stuff going on
16:15karolherbst: but you can always "modprobe nouveau"
16:16karolherbst: but it's a 870m
16:16karolherbst: but it should be fine as well
16:19kreyren: karolherbst, invoked `modprobe nouveau` and system halted, investigating
17:45cyberpear: zfnmxt: I was able to get that card working w/ nouveau w/ the "off then on again" patch by karolherbst (I've got a P1, which is ~identical to the X1 Extreme)
17:46karolherbst: but okay
18:12zfnmxt: cyberpear: What's the "off then on again" patch?
18:20zfnmxt: Setting "nouvea.noaccel=1" seems to have helped.
18:20zfnmxt: xrandr now sees the connected HDMI cable, but it crashes if I try to activate an output.
18:21imirkin_: pastebin xorg log
18:21imirkin_: iirc it might require copy accel for reverse prime if you're using the nouveau ddx
18:21zfnmxt: http://ix.io/1Lqn that's what I'm seeing right now
18:22zfnmxt: Sec on the xorg log
18:22imirkin_: DRI_PRIME=1 foo is not going to do anything useful
18:22imirkin_: you've explicitly disabled acceleration
18:23imirkin_: try uninstalling xf86-video-nouveau
18:23imirkin_: er wait, you have an explicit xorg config?
18:24zfnmxt: No. My xorg is generated by my OS.
18:24imirkin_: if so, tell the "nouveau" one to use Driver "modeset"
18:24imirkin_: well wtvr - whoever generates it ... tell that thing to use Driver "modeset" here.
18:24zfnmxt: I'll try, it's actually not so simple to do so on my OS
18:24zfnmxt: Might have to modify the xserver package, sec.
18:24imirkin_: well just uninstall xf86-video-nouveau -- perhaps that'll convince it not to do that...
18:24zfnmxt: Yeah, I'll try modeset.
18:25imirkin_: in a reverse prime configuration, xf86-video-nouveau does little good, and apparently is less tolerant of lack of accel
18:26karolherbst: imirkin_: maybe it would make sense for us to probe that and bail if we have no accel enabled?
18:26imirkin_: or just fix it...
18:26imirkin_: i doubt it's difficult to do - just not a case that was considered
18:27karolherbst: I think that's because we require shaders to run, don't we
18:27imirkin_: not for reverse prime
18:27karolherbst: ahhh, right
18:27imirkin_: for reverse prime i'm sure we just use the copy engine
18:27imirkin_: and for regular rendering, we support NoAccel just fine
18:27karolherbst: yeah.. make sense
18:27imirkin_: (falling back on ... whatever is the thing in X that does the software impl)
18:28karolherbst: but do we actually have means to query the driver if accel is actually enabled? or should we just try to allocate a context and fallback to the NoAccel path if that fails?
18:28imirkin_: we try to allocate an object and it fails.
18:28karolherbst: that's probably what's already happening, no?
18:29imirkin_: we just don't handle this scenario with reverse prime somewhere
18:29karolherbst: should be fixable, I might just go ahead and try to figure that out
18:30imirkin_: patches welcome =]
18:30karolherbst: next month will be super busy though, so I gotta be fast :D
18:30imirkin_: i expect it'd take me ~an afternoon of fiddling
18:31karolherbst: yeah.. shouldn't take me too long either, just a lot of stuff going on right now
18:31imirkin_: i'm hoping i'll have HDR going by end of this month.
18:31imirkin_: that should be a nice waste of time :)
18:31karolherbst: apparently I managed to convince somebody to join us for an internship and now I have to take care of stuff and help the intern out starting next month :)
18:34zfnmxt: It sorta works with modesetting! :D
18:35zfnmxt: `xrandr --output HDMI-1-1 --auto` correctly shows my mouse cursor...and a bunch of corrupted gibberish as the background.
18:36zfnmxt: I tried `xrandr --output HDMI-1-1 --same-as eDP1` (eDP1 is the internal display) and don't get a signal then.
18:36imirkin_: check to see if there are any errors in dmesg
18:36zfnmxt: http://ix.io/1Lqx since you know much better than me :)
18:37imirkin_: somebody was talkign about issues with the intel ddx + reverse prime, although i assumed it would only happen with multiple reverse-primed monitors
18:37imirkin_: that's all fine
18:37imirkin_: can you try using modeset on intel as well, see if that makes a difference?
18:38zfnmxt: imirkin_: I actually did that by accident before, but I wasn't able to issue a `xrandr --setprovideroutputsource` in that case because both gpus get the same name (namely, `modesetting`).
18:38imirkin_: xrandr --setprovideroutputsource 1 0
18:38imirkin_: that always works
18:38zfnmxt: Okay, brb!
18:38imirkin_: (almost always. you could do some really weird shit to make it not work. don't do that.)
18:42zfnmxt: Now the external monitor displays a frozen image of what was on screen when `xrandr --output HDMI1-1 --auto` was run, with an updating mouse cursor again.
18:42imirkin_: i wonder if accel really is needed
18:42zfnmxt: Boo :(
18:42imirkin_: or something indirectly accel-related
18:42imirkin_: that's lame =
18:43zfnmxt: Does that kernel parameter even matter if I don't even have the nouveau driver?
18:44zfnmxt: i.e., I owuldn't get differnet reuslts if I removed the parameter and tried with modesetting again, right?
18:47imirkin_: yes, it matters
18:53zfnmxt: Yeah, didn't work with modesetting + no param. Startx just hung.
18:53zfnmxt: Well, maybe I'll have better luck with that patch the guy with the P1 was talking about :)
18:54zfnmxt: Thanks for your help, imirkin_
20:53zfnmxt: karolherbst: Any idea what cyberpear was referring to with the "off then on again" patch?
20:54karolherbst: zfnmxt: https://github.com/karolherbst/linux/commits/runpm_fixes
20:57zfnmxt: karolherbst: Thanks, gonna try it :D
22:03zfnmxt: karolherbst: The patch fixed `DRI_PRIME=1 glxinfo`
22:03karolherbst: zfnmxt: even if you call it several times?
22:03imirkin_: ideally offloading should work too
22:03karolherbst: zfnmxt: did you boot with nouveau.runpm=0 still?
22:04imirkin_: i mean output slaving
22:04zfnmxt: Yeah, seems like it works.
22:04zfnmxt: karolherbst: No I didn't
22:04karolherbst: it helps on my laptop as well, we had bad luck with a few other ones sadly
22:04zfnmxt: `xrandr --setprovideroutputsource` still seems a bit kaput, doesn't show anyhting but my mouse again
22:04karolherbst: the runpm stuff still works, but the secboot part still messes up
22:04zfnmxt: ...is there any chance that could be due to my WM?
22:05karolherbst: zfnmxt: but do external displays work?
22:05karolherbst: normally you don't have to do any xrandr calls anymore
22:05karolherbst: desktop set it up just fine these days
22:06zfnmxt: Oh, I'll try that real quick
22:07zfnmxt: xrandr doesn't even see the HDMI port without --setprovideroutputsource still.
22:07imirkin_: that's expected.
22:07zfnmxt: Oh, maybe I'm confused based on what karolherbst said, then.
22:07karolherbst: right.. but sometimes desktop environments set it up correctly
22:07karolherbst: I think gnome does it
22:07karolherbst: plasma might as well
22:07zfnmxt: Ah, right. I just use xmonad, so none of that
22:07imirkin_: yeah, sometimes the desktop environment will (effectively) run that
22:08imirkin_: the fancy ones tend to
22:08zfnmxt: Let me try running gnome, just to see if it works
22:08karolherbst: yeah... makes sense that all desktop environments do that :p
22:08karolherbst: but... would be nice to not having to do it at all
22:09karolherbst: and with wayland it is even more annoying as compositors have to implement that feature as well
22:10zfnmxt: I have no plans to move to wayland any time soon :D
22:15zfnmxt: Gnome works.
22:15zfnmxt: Must be something with xmonad.
22:16imirkin_: are you maybe doing something weird?
22:16zfnmxt: Aren't I always :P?
22:16imirkin_: can you try xrandr --output HDMI-1-1 --auto --right-of eDP-1 or whatever?
22:16zfnmxt: My xmonad config is pretty vanilla, though.
22:16zfnmxt: I mean, I tried `xrandr --output HDMI-1-1 --same-as eDP-1`
22:16imirkin_: try right-of.
22:16zfnmxt: Shouldn't that just mirror things without issue?
22:17imirkin_: try right-of :p
22:17zfnmxt: Alright, gotta switch back to xmonad!
22:22zfnmxt: Well,it sorta worked. Right-off made it behave as if the monitor was to the right of the laptop display in terms of the mouse, but background was all corrupt and stuff still.
22:22zfnmxt: Let me fiddle with my WM. Maybe have to do some special multi-monitor stuff.
22:22imirkin_: odd. X shoudl just be making one big happy image.
22:23hagbard: Hi, I have a Quadro P2000 and I'm trying to drive a pair of NEC PA272W's at 2560x1440. These displays do 2560x1440@60Hz over displayport. The first display always gets limited to 1920x1080, whereas the second works properly at 2560x1440. When I enable debugging, I see a message suggesting the first one is imposing a pixelclock limit or something. I've verified the EDID is being read correctly. Any thought
22:23imirkin_: hagbard: yeah. "weird" :)
22:24imirkin_: can you detail how these are connected to your GPU?
22:25hagbard: A seperate display port cable to each LCD. One in DP-1, the next in DP-2. If I swap the cables, then affected monitor swaps as well.
22:25imirkin_: perhaps cable is bad? DP requires "link training", so if we only link train to lowest level, that's not enough for that resolution
22:25hagbard: Pardon, if I swap the monitors between DP-1 and DP-2, the affected one is the one connected to DP-1. If I switch to DP-3 and DP-4, DP-3 is affected/.
22:26hagbard: The problem seems to affect the first discovered, active port.
22:26imirkin_: what if you plug the DP-1 cable into DP-3
22:26hagbard: I've tried swapping cables as well as swapping between the DP and mDP ports on the LCD.
22:26imirkin_: and leave the DP-2 one in place
22:27hagbard: Assuming DP-2 is still connected, then DP-2 is affected.
22:27imirkin_: i see
22:27hagbard: This is the message from dmesg:
22:27hagbard: [ 6556.636027] [drm:drm_mode_prune_invalid [drm]] Not using 2560x1440 mode: CLOCK_HIGH
22:27imirkin_: can you load nouveau with .... nouveau.debug=disp nouveau.debug=i2c nouveau.debug=aux
22:27imirkin_: er, sorry
22:28imirkin_: can you load nouveau with .... nouveau.debug=disp,i2c,aux
22:28hagbard: is it alright if I unload noveau and modprobe it with debug=disp,i2c,aux or should I reboot?
22:28imirkin_: reloading nouveau is possible, but be careful... let me give you a link to some instructions
22:29imirkin_: hrmph. nouveau.freedesktop.org is down. :(
22:30imirkin_: see "Deactivating KMS and unloading Nouveau"
22:30imirkin_: you don't have to kill ttm/etc... just unbind the console, rmmod nouveau, insmod nouveau
22:31zfnmxt: The nouveau driver should let me power off the nvidia gpu when I'm not using an external display, right?
22:32imirkin_: zfnmxt: it should do this automatically
22:32imirkin_: you can check /sys/something/vgaswitcheroo
22:32imirkin_: it should say DynOff
22:33hagbard: Oh, one possible useful/unuseful detail - the nvidia binary drivers detect the displays correctly. I'm trying nouveau because I was getting strange errors from the nvidia driver when using OpenGL.
22:33karolherbst: I usually check with cat /sys/bus/pci/devices/0000\:01\:00.0/power/runtime_status
22:33imirkin_: hagbard: ok. good to know the hw is good.
22:34zfnmxt: imirkin_: yeah, I know, but it's stuck on DynPwr :(
22:34imirkin_: zfnmxt: is one of the outputs on? then it'll stay on
22:35zfnmxt: imirkin_:Fresh xserver, didn't touch the outputs with `xrandr` yet and the HDMI cable is unplugged
22:35imirkin_: merely being attached in X is not enough to keep it on.
22:35imirkin_: did you boot with nouveau.runpm=0? :)
22:35zfnmxt: Nope :(
22:36hagbard: imirkin_: I've reloaded with the debug string, and there are two odd errors.
22:36hagbard: [ 7205.925629] nouveau 0000:91:00.0: disp: 0x00005ed1[ ]: INIT_GENERIC_CONDITON: unknown 0x07
22:36hagbard: [ 7221.308976] nouveau 0000:91:00.0: gr: intr 00000040
22:37hagbard: Running debian 4.19.0-5-amd64
22:37imirkin_: INIT_GENERIC_CONDITION is fine
22:37imirkin_: that's fully expected
22:37imirkin_: can you pastebin dmesg?
22:38zfnmxt: imirkin_:uh, me or hagbard
22:39imirkin_: hagbard: ---^
22:39hagbard: imirkin_: Yes, presently. I'd like to reboot so it's not full of garbage.
22:39imirkin_: (watch it start working on reboot...)
22:40hagbard: Well, that'd make my day if it did.
22:47hagbard: imirkin_: Is it possible you meant nouveau.debug="disp=debug,i2c=debug,aux=debug" as described on https://nouveau.freedesktop.org/wiki/KernelModuleParameters/ as the string you described above doesn't appear to elicit any extra debugging.
22:48imirkin_: hagbard: =debug is implied
22:49imirkin_: (i think? maybe not?)
22:49zfnmxt: imirkin_:Hm, so it only goes to DynOff if I unplug my laptop :P
22:49imirkin_: hagbard: hm, yeah. you'er right. have to stick the =debug's in. sorry :(
22:49zfnmxt: From the AC adapter, that is.
22:49imirkin_: zfnmxt: could be. this is all controlled by ACPI.
22:49zfnmxt: That's how it behaves on Windows too.
22:50zfnmxt: Okay, cool. All issues sorted except for Xmonad :D
22:50zfnmxt: A good day of progress!
22:50zfnmxt: It's still insane to me that some random patch from 2017 fixed the issue D:
22:50zfnmxt: Thanks for your help, karolherbst and imirkin_ !!
22:51karolherbst: well, that's the beauty of random patches
22:54zfnmxt: karolherbst: I don't know anything about this stuff, but why haven't you submitted you submitted a PR (or whatever happens with linux) for the patch?
22:54karolherbst: I did, but we have no idea why that works and if it has any negative impacts on other cards
22:55karolherbst: and fixing something without having any understanding what the actual issue was is always a bad sign
22:55hagbard: imirkin_: https://paste.debian.net/1087313/
22:56zfnmxt: Aha, I see.
22:58imirkin_: why are the bw requirements for the two heads so different?
22:58hagbard: I have no idea.
22:58hagbard: They're identical panels.
22:58imirkin_: can you add drm.debug=0x1e
22:58imirkin_: in addition to the other thing
22:59hagbard: I'm curious if the BIOS/POST procedure is preconfiguring the heads somehow? I was considering rebooting with no monitors attached.
22:59imirkin_: mmmmaybe, but for a secondary gpu, it wouldn't
22:59imirkin_: although wait, it's primary
22:59hagbard: Yes, it's the primary and only.
22:59imirkin_: do you have fbcon disabled?
23:00hagbard: No, I don't.
23:00imirkin_: DRM: allocated 2560x1440
23:00imirkin_: right, i was looking for that line. missed it somehow.
23:05imirkin_: ok, so this is the problem
23:06imirkin_: nouveau 0000:91:00.0: DRM: display: 4x162000 dpcd 0x11
23:06imirkin_: perhaps related to drm:drm_dp_dpcd_access [drm_kms_helper]] Too many retries, giving up. First error: -6
23:06imirkin_: note how the second display has:
23:06imirkin_: nouveau 0000:91:00.0: DRM: display: 4x270000 dpcd 0x11
23:07imirkin_: unfortunately this is all well above my paygrade. skeggsb to the rescue! --^
23:09hagbard: imirkin_: good eye. Thank you.
23:09imirkin_: it could be not waiting for the aux channel to actually come up when it should
23:10imirkin_: it could be the monitor being out-of-spec-slow to respond, and by the time the first one times out, the second one is ready
23:11hagbard: There are the messages earlier up about using a 40ms delay instead of 10ms on bus 0002
23:11hagbard: pardon, "monitoring devices" must be like a hwmon chpi?
23:11imirkin_: something like that, yeah
23:11imirkin_: more generally, various i2c devices
23:12imirkin_: i thought some of the dp-aux stuff came out as i2c
23:12imirkin_: but there's other totally unrelated things that come out as i2c as well
23:12hagbard: I have an idea. I have a third display here, I'll plug that in the first connector and reboot.
23:14hagbard: Would you hazard drm_kms_helper's dp_aux_i2c_* variables might be worth fiddling with?
23:14imirkin_: btw, note that even in a perfect world, nouveau's perf will be WAY below nvidia's
23:14imirkin_: because we can't change gpu clocks, and it boots to lowest
23:14imirkin_: mmmmaybe? i didn't kow those existed.
23:15hagbard: Understood. And, with all respect, nvidia's driver has served me very well for years. But, at the moment, I don't need much acceleration, but I do need reliable 2D.
23:15hagbard: parm: dp_aux_i2c_speed_khz:Assumed speed of the i2c bus in kHz, (1-400, default 10) (int)
23:15hagbard: parm: dp_aux_i2c_transfer_size:Number of bytes to transfer in a single I2C over DP AUX CH message, (1-16, default 16) (int)
23:15imirkin_: thing is ... modern 2D uses the 3D engine a lot
23:16imirkin_: yeah, unfortunately i know nothing about the details of dp-aux
23:16imirkin_: i know it's a sideband data channel... that's about it :)
23:17hagbard: Using the nvidia drivers, I get a bucket of the following in dmesg along with X stalling for 20s:
23:17hagbard: [514975.175461] NVRM: Xid (PCI:0000:91:00): 69, Class Error: ChId 0009, Class 0000902d, Offset 000008b0, Data ffffff8a, ErrorCode 00000004
23:17imirkin_: ah yes, everyone's favorite, Xid errors
23:17imirkin_: in the 2d class, no less!
23:18imirkin_: on the bright side, it recovers :)
23:18hagbard: the 902d class, no less.
23:18imirkin_: 902d = nvc0+ 2d class
23:18hagbard: I see.
23:19hagbard: Do you mean 2D as in two-dimensions or is hexadecimal 0x2d?
23:19imirkin_: (GF100_2D = 0x902d)
23:19imirkin_: both =]
23:19hagbard: DMA errors. Neat.
23:20imirkin_: *97 = 3d, *2d = 2d, *c0 = compute
23:20hagbard: oh, you're way ahead of me.
23:21imirkin_: i've been playing this game a bit longer.
23:21hagbard: I can tell; I'm impressed.
23:22hagbard: What's the meaning of ChId?
23:22imirkin_: i'm much better versed in the 2d/3d engine than in all this display gunk :)
23:22imirkin_: probably channel id?
23:22imirkin_: (what is a channel, you ask?)
23:23imirkin_: it's basically a separate virtual memory "thing" ... iirc
23:23imirkin_: which is also a holder for command submission, data objects, etc
23:23hagbard: because what the world really needs, is more levels indirection?
23:24imirkin_: well, these GPUs have evolved a bit since the voodoo2 days...
23:24imirkin_: they're basically full computers which happen to be accessible via the PCI bus
23:24imirkin_: they have their own VM, context switching, you-name-it
23:25hagbard: I can imagine.
23:25imirkin_: modern ones (like your pascal board) even allow VM faults to be handled by the CPU
23:26imirkin_: so yeah. lots of indirection for everyone.
23:26hagbard: Alright, well, this is novel. I plugged in 4k monitor as DP-1, and my regular two as -2 and -3. The 4k comes up correctly, the first of the pa272w gets limited, and the second is fine.
23:28hagbard: here, I'll post a dmesg.
23:28hagbard: I don't know if it matters, but these panels are kinda goofy. They do 30bit color among other things.
23:28imirkin_: so ... we try to do 10bpc if we can
23:28imirkin_: i wonder if that logic's a bit off
23:29imirkin_: (i'm trying to do bringup of HDR, so it's likely i'll be mucking with those bits soon enough...)
23:30imirkin_: some dp logic here: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nvkm/engine/disp/dp.c
23:33hagbard: imirkin_: I had to use pastebin.com, https://pastebin.com/U31XZF9p
23:33ajmitch: have a nice long weekend?
23:33hagbard: imirkin_: It's odd that it only affects the first LCD, but not the second. It's like there's an un-cleared, uninitialized flag or something.
23:34imirkin_: from that dmesg, actually looks like the third is affected
23:34imirkin_: i.e. DP-3
23:34imirkin_: what if, while it's running, you unplug the "broken" monitor and plug it back in?
23:35imirkin_: anyways, i gtg. hopefully skeggsb will pipe up with some helpful words of advice.
23:38hagbard: If anyone speaks ot imirkin when he gets back, he's brilliant.
23:39RSpliet: yeah, he's a treasure
23:40karolherbst: hagbard: might be that Lyude is able to help out with DP related issues as well
23:40karolherbst: but yeah.. usually replugging the display helps to some degree