16:29 maccraft123: imirkin: hey guess what doesn't work!
16:29 imirkin_: everything?
16:30 maccraft123: 1600x1200@85Hz on my CRT
16:30 maccraft123: it does support that resolution and refresh rate
16:30 imirkin_: trinitron?
16:30 maccraft123: but when i try to switch to it, i have blank display
16:30 maccraft123: it is flatron f900p i got today
16:31 imirkin_: brand new, i'm sure :p
16:31 imirkin_: pastebin xrandr --verbose
16:31 imirkin_: and is there anything in dmesg after the attempted switch?
16:32 maccraft123: https://bpaste.net/P7WA
16:33 imirkin_: ok, so this is what edid reports: https://hastebin.com/fuzipedite.pl
16:33 imirkin_: and indeed, 1600x1200@85 is listed.
16:33 imirkin_: this is on the MCP77?
16:33 maccraft123: mcp78
16:34 imirkin_: wtvr, those are like the same. ok
16:34 imirkin_: so the only thing that i can imagine is that there's a RAMDAC limit on the IGP. seems unlikely though.
16:35 imirkin_: would have to look at the vbios ... but i don't really have time
16:38 maccraft123: gpu limit
16:39 maccraft123: on laptop it works fine
16:48 imirkin_: ok. ideally we shouldn't even let you try to do this and reject the mode
16:48 maccraft123: uhh
16:48 imirkin_: but i'm guessing that we haven't done this properly for the tesla+ series
16:48 maccraft123: why
16:48 imirkin_: if it's above some hardware limit
16:56 imirkin_: hmmm ... https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nouveau_connector.c#L1055
16:56 imirkin_: in theory there should be a maxfreq in your dcb
16:57 imirkin_: maccraft123: can you put up your vbios somewhere? /sys/kernel/debug/dri/0/vbios.rom
16:57 maccraft123: cat: /sys/kernel/debug/dri/0/vbios.rom: No such file or directory
16:57 imirkin_: try harder?
16:58 maccraft123: gimme a sec
16:59 imirkin_: hrmph. https://nvidia.github.io/open-gpu-doc/DCB/DCB-4.x-Specification.html#_device_specific_information
16:59 imirkin_: looks like either the max frequency was removed in DCB 4, or it was never there =/
16:59 maccraft123: can this be public?
17:01 maccraft123: imirkin_: curl -e robots=off https://bpaste.net/raw/7PTA | strings | base64 -d | xz -d > ./vbios.rom
17:01 imirkin_: heh
17:01 maccraft123: md5sum 0625d5b18c58cf574dc6b7944a2bc2b0
17:01 imirkin_: i like the |strings bit
17:02 maccraft123: i could have used a od -c | awk '{print $2 $3 $4 $5 $6}'
17:03 imirkin_: i'm getting invalid input for base64
17:04 maccraft123: are you running exact command?
17:04 imirkin_: no, but i shouldn't need to ...
17:05 imirkin_: i grabbed the file
17:05 imirkin_: which looks base64-encoded
17:05 maccraft123: then run the exact command
17:05 imirkin_: and base64 -d doesn't work on it
17:06 imirkin_: i've verified that wget grabbed the file correctly.
17:07 imirkin_: so ... something odd going on.
17:07 maccraft123: just run the exact command. strings *is* needed
17:22 imirkin_: then you did something weird. sigh.
17:22 imirkin_: ok yeah, works now.
17:23 imirkin_: is base64 seriously getting tripped up by the trailing space?!
17:24 imirkin_: or the \r\n?
17:24 maccraft123: thats why strings are in place
17:25 imirkin_: dos2unix fixes it too, and is less cryptic
17:26 imirkin_: weak, base64... weak.
17:26 imirkin_: DCB 0: type 0 [ANALOG] I2C 0 heads 0 1 CONN 0 [0x00] conntag 0 LOCAL OR 0 maxfreq 300000kHz
17:26 imirkin_: so .... we know that the max is 300mhz
17:27 imirkin_: whereas the clock on the 1600x1200@85 mode is 229.5mhz
17:27 imirkin_: so that should all fit quite nicely.
17:27 imirkin_: so either someone is lying about something
17:27 imirkin_: does that VGA cable have ferrite beads?
17:28 maccraft123: yep
17:28 imirkin_: =/
17:28 maccraft123: same cable and same crt work fine on laptop
17:28 imirkin_: yeah
17:29 imirkin_: and 300mhz sounds right, whereas 200mhz would sound way too low for a limit on that era of chip
17:29 maccraft123: my room in 10 years https://pbs.twimg.com/media/EQBp34tW4AAI8Mc?format=jpg&name=large
17:30 imirkin_: that's jrayhawk's right?
17:30 maccraft123: https://twitter.com/CompAesthetics/status/1225095537575239682/photo/1
17:30 imirkin_: i have a feeling he put up an image that looked a lot like that a long while back
17:31 imirkin_: maybe it wasn't quite as tidy as this one
17:32 imirkin_: or maybe it's just an image that has been making the internet rounds
18:04 maccraft123: imirkin_: i burned myself on radiator of southbridge on my board
18:04 maccraft123: can it burn?
18:04 maccraft123: 87°
18:05 imirkin_: 87 degC is pretty toasty to the touch...
18:05 maccraft123: looks like i have to set up another fan
18:39 jrayhawk: maccraft123, imirkin_: Yeah.
18:44 jrayhawk: https://www.omgwallhack.org/home/jrayhawk/img/hovel/20160926_004.jpg and https://www.omgwallhack.org/home/jrayhawk/img/hovel/20160926_009.jpg are somewhat closer to the modern setup.
18:45 imirkin_: jrayhawk: you don't even see the code anymore? :)
18:46 imirkin_: xlock -mode matrix is fun :)
18:49 jrayhawk: Sadly my GM204GLM is super flaky about outputting to more than two CRTCs and my modern Skylake motherboard doesn't take well to me hotswapping extra video cards onto its PCIe busses.
18:50 imirkin_: hrmph, GM204 should support 4 just fine
18:50 imirkin_: assuming they're not like 8k screens or whatever
18:50 imirkin_: AMD makes chips that can output to 6 screens btw
18:50 imirkin_: (not to mention better supported)
18:51 jrayhawk: Nah, they're pretty reasonably low-res CRTs. I think something is wrong with the USB-C displayport detection logic on this board.
18:51 imirkin_: oh yeah, USB-C should lead to some good times...
18:55 jrayhawk: On older kernels I used to be able to do it if I plugged them in and set up CRTCs for them in a very specific order. On Linux 5.4 I am lucky if they detect only once and only briefly on each reboot.
18:56 imirkin_: with nouveau presumably?
18:56 jrayhawk: Yeah.
18:59 jrayhawk: Also it is a big pain in the butt to translate between Xorg/RANDR output names and KMS names for 12 monitors.
18:59 imirkin_: =/
19:00 imirkin_: well, i expect you can get skeggsb to help you out with the modesetting troubles
19:00 imirkin_: (i'd be happy to help, but there's just not a lot i can do)
19:00 karolherbst: ufffffffff
19:01 karolherbst: jrayhawk: are you insane? :D I wouldn't even dare to try such a setup
19:01 jrayhawk: That would be a prescient term for me, yes.
19:02 karolherbst: jrayhawk: regarding the output names. Normally GUI interfaces can do monitor detection.. no idea if arandr supports it, but it's worth a try
19:02 imirkin_: call me crazy, but i don't think jrayhawk is an arandr kind of person :)
19:02 karolherbst: arandr can also create a xrandr command line afiak
19:03 karolherbst: well.. sure, but... ;)
19:03 karolherbst: maybe we should add such a feature to xrandr so xrandr can print the name on each display :D
19:04 karolherbst: it's an X client already anyway
19:04 imirkin_: like the "identify" function? :)
19:04 karolherbst: does xrandr have anything like that?
19:05 jrayhawk: The central problem is that of the three of RANDR, Xinerama, and acceleration, I can choose any two, and essentially every window manager AFAICT still uses Xinerama for CRTC reckoning. My two ways around this are to either use RANDR 1.4 output providers, which are way too slow at this scale, or switch to Zaphod mode, in which case I am manually translating the output names in an oldschool explicit
19:05 jrayhawk: xorg.conf.
19:05 imirkin_: jrayhawk: pretty sure xinerama + acceleration is out, unless you mean iglx
19:05 karolherbst: jrayhawk: depending on the GPU, you can increase the pcie bandwidth, but yeah.. I guess prime still sucks here
19:05 imirkin_: jrayhawk: i think WMs are supposed to provide xinerama hints
19:05 imirkin_: e.g. WindowMaker does
19:06 karolherbst: imirkin_: for fun reasons, nvidia + xinerama does acceleration...
19:06 imirkin_: true.
19:06 imirkin_: i mean with "mainline"
19:06 karolherbst: ohh, sure
19:06 karolherbst: I am wondering why that was never implemented
19:06 karolherbst: probably -ENOTIME
19:06 jrayhawk: Or, actually, I guess, it's two of the three of RANDR, Xinerama, and multi-SCREEN (multi-framebuffer) support.
19:06 imirkin_: right.
19:07 karolherbst: If anybody would ask me, I'd be in for rendering local to the GPU and desktop migration and stuff
19:07 karolherbst: but.. the rework required for that
19:07 karolherbst: I've heard that with wayland all of that is way easier to achieve actually
19:08 jrayhawk: I have, admittedly, not tried Wayland.
19:10 jrayhawk: I always assumed that smoothly integrating multiple framebuffers by any means other than randr-provider-style shadow buffers would not be within its scope.
19:11 karolherbst: well wayland was created to fix unfixable things in X, but compositors also implement multiple display stuff.. sadly the compositors have to do a lot more themselves though
19:11 karolherbst: and you usually rely on OpenGL to work
19:12 karolherbst: _but_ the display situation could be better
19:12 karolherbst: at least it might be worth a try
19:13 loonycyborg: I bet compositors would appreciate vulkan instead of opengl
19:16 karolherbst: they would if they could
19:27 jrayhawk: Alternatively, if someone knows of a tiling window manager that supports both of 1) multiple SCREENs (offhand, only ancient codebases do, such as NotIon, ratpoison, and very old versions of awesome) and 2) CRTC reckoning with RANDR instead of Xinerama, do let me know.
19:28 imirkin_: WindowMaker nominally does, but i ran into trouble with multiple screens =/
19:28 imirkin_: i don't remember what the trouble was
19:47 maccraft123: jrayhawk: i3.
20:34 Lyude: skeggsb, any idea what the "code" that's provided from disp error interrupts on turing corresponds to? (specifically looking at [ 1571.178200] nouveau 0000:22:00.0: disp: chid 1 stat 00005080 reason 5 [INVALID_STATE] mthd 0200 data 00000001 code 0000002d)
20:44 skeggsb: that one has something to do with the LUT... i don't know specifically what, i don't have info on those after volta, but i've hit it before
20:45 Lyude: aha
20:45 Lyude: i was right!
20:45 skeggsb: my notes from turing bring-up say something to do with LUT ctxdma not being set when it should be
20:45 Lyude: i was double right! :)
20:45 skeggsb: it has to be active on turing except in very specific circumstances
20:45 skeggsb: if the window is
20:46 Lyude: yeah, I figured as much
22:36 andres: With 5.6 post the drm merge, should a turing mobile GPU support external displays connected to it?
22:41 andres: https://gist.github.com/anarazel/cf66b945cf6e6772807af20d6c53ed03 is what I get, pretty similar to 5.5.
23:03 Lyude: skeggsb: do you have any idea if changing the flexible wndw ownership requires a full modeset with gv100+ or not?
23:04 Lyude: asking since we don't actually have this implemented in the driver yet, but it might actually matter for CRC readback apparently
23:11 skeggsb: Lyude: nfi, i haven't played with it yet, gv100 doesn't support it though, it *has* to be wired as it is
23:11 skeggsb: tu10x apparently does, but i haven't tried
23:26 imirkin_: andres: yes, it should. i think it's saying that nothing is connected on any of the connectors. is anything connected, and if so, how?
23:26 imirkin_: you seem to have an unknown connector type 48 ... hopefully not usb-c?
23:31 andres: imirkin_: There's a monitor connected on HDMI. xrandr, after a setprovideroutputsource, shows multiple outputs, but I think they may just be copies of the internal display.
23:32 imirkin_: andres: well, you have to do setprovideroutputsource, otherwise the secondary gpu isn't hooked up...
23:32 imirkin_: andres: pastebin xrandr --verbose
23:32 andres: The laptop has two usb-c ports, but nothing connected to them.
23:33 andres: I assume those are the "unknown connector type 48" - but given I don't need them (for now), that should be "harmless"?
23:33 imirkin_: i assume they are too.
23:34 andres: (logging out so I start x after having loaded nouveau, to slightly simplify the scenario)
23:35 imirkin_: eDP = 0x47
23:35 imirkin_: 0x61 = HDMI_1 (as opposed to 0, whatever the diff there is)
23:36 imirkin_: 0x71 = USB-C. So i guess 0x48 is ... USB-C-ish somehow?
23:36 imirkin_: 0x48 = DisplayPort (Mini) External Connector
23:37 Lyude: that's not usb-c... that's literally just the smaller form of DisplayPort
23:37 Lyude: which, probably should just be treated identically. but I've been seeing that on a lot of systems without any mDP ports
23:37 imirkin_: but it's "inside" usb-c, which is how it comes out on the external GPU
23:37 Lyude: ahhhh
23:37 imirkin_: i'm guessing.
23:37 imirkin_: see list below https://nvidia.github.io/open-gpu-doc/DCB/DCB-4.x-Specification.html#_connector_table_entry
23:37 andres: imirkin_: https://gist.github.com/anarazel/3919c72a7bd86fb1d8d360c5d191d02c
23:38 andres: That's xrandr from after set the setprovideroutputsource, and also from before.
23:38 imirkin_: is that the --verbose output? i was looking for the edid
23:38 andres: Oh, sorry.
23:38 imirkin_: anyways, looks like HDMI-1-1 should be fine
23:38 imirkin_: it's not turned on, you can do that with e.g. xrandr --output HDMI-1-1 --left-of eDP-1 --auto
23:39 andres: Updated.
23:40 imirkin_: yeah, those are definitely different monitors...
23:40 andres: 1920 x 1080 is not actually the external monitor's resolution.
23:41 imirkin_: https://hastebin.com/renadatoto.sql
23:41 imirkin_: hm yeah, should be 2560x1440
23:41 imirkin_: but it does have a 1920x1080 mode
23:42 Lyude: sweet, now that I managed to get modesetting going far enough on turing to let me test things with >1 head, I managed to figure out that crc readback on heads > 1 was broken and have now fixed it :)
23:42 andres: It displays an error about resolutions right now.
23:42 imirkin_: it = the monitor?
23:42 Lyude: turns out we always need a wndw that's bound to the head we're doing CRC readback from set as the CRC controlling wndw channel
23:43 imirkin_: Lyude: that seems ... somewhat logical.
23:43 andres: imirkin_: Correct, the external monitor.
23:43 imirkin_: otherwise what are you getting the crc of
23:43 andres: Disabling / enabling shows a picture, but it's frozen, except for the mouse cursor.
23:44 imirkin_: andres: mind including the output of "grep . /sys/class/drm/card*-*/modes" ?
23:46 andres: imirkin_: Updated gist. Also got a WARNING about "DRM: bo 00000000a246bb11 pinned elsewhere: 0x00000002 vs 0x00000004"
23:46 andres: Also added the stacktrace to the gist.
23:46 imirkin_: andres: that's why you're getting a stuck picture :)
23:47 Lyude: imirkin_: well the thing is the controlling channel doesn't really control where you're getting the CRC from. See; nvidia's CRC readback has a concept of "tags" where a tag is supposed to correspond to the nth update you made on a specific evo/nvdisplay channel. On everything before volta, you only can choose between core/base/ovly as the controlling channel (we always set it to core because we care about
23:47 Lyude: what CRC matches up with what vblank, not which channel update it corresponds to) so we just always set it to core and completely ignored it.
23:47 Lyude: volta only lets you select a window, and I guess it error checks that window so we need to set it even though we don't care at all about the tags
23:47 imirkin_: andres: ok, so for some reason we're rejecting all the modes higher than 1920x1080
23:48 imirkin_: based on my knowledge of things, i can't see an immediate reason for that. even without HDMI2.0 (which may or may not be supported on turing by nouveau), you should have a max frequency of 297mhz, which is more than enough for the 2560x1440 mode
23:48 imirkin_: as for why you get that "pinned elsewhere" thing ... j'accuse skeggsb!
23:48 imirkin_: skeggsb: see top of https://gist.github.com/anarazel/3919c72a7bd86fb1d8d360c5d191d02c -- gem_dmabuf_release -> fail
23:49 imirkin_: with some kind of reverse prime fun
23:49 imirkin_: andres: xorg log might actually have a reason, if you can pastebin that
23:49 andres: Is it meaningful that xrandr shows modes for eDP-1-4, even though as far as I know there's no additional output connected (except for eDP-1 and HDMI-1?
23:50 imirkin_: andres: those modes come from something weird. but it's disconnected, so ...
23:51 andres: And there's no EDID for it, yet it shows all those modes - thats why I was wondering earlier whether it somehow confuses outputs.
23:52 imirkin_: unlikely.
23:52 andres: updated gist with xorg log
23:53 imirkin_: andres: oh. right. no accel = no reverse prime.
23:53 imirkin_: that explains why you get the stuck picture.
23:54 imirkin_: so ... you need firmware. that's not out yet for TU117
23:55 imirkin_: it doesn't explain why you don't see the high mode.
23:55 andres: Too bad.
23:55 imirkin_: that xorg log clearly shows a 2560x1440 mode
23:56 imirkin_: and then it's very clearly not in the overall list.
23:56 imirkin_: this will require debugging =/
23:57 imirkin_: if you'd like to do that, try setting drm.debug=0x1e (you can do this live through /sys) and then unplug / replug the monitor
23:58 imirkin_: and pastebin dmesg