00:01 imirkin: on-chip software is insecure by default, since it can't be updated to fix any problems discovered.
00:02 c_nix: that too
00:11 imirkin: so if i'm going to have to deal with closed firmware, i definitely prefer it to be uploadable
00:12 mattst88: the thing about not caring about non-free software if it's not updateable is a little bit of mental gymnastics
00:13 mattst88: but, one of the goals of free software is to be able to modify software for your own needs
00:13 mattst88: so I can kind of see why if it's not possible to update it, you might just not care about it
00:13 mattst88: which is, I guess where GPLv3 comes in
00:14 c_nix: in Stallman's reasoning if he executes on his machine process of loading proprietary firmware on the device its the same as installing windows for example
00:15 c_nix: see https://www.fsf.org/news/freebios.html for example
00:23 imirkin: windows runs on cpu. firmware runs on secondary device.
00:27 shadow: imirkin: I get what you're saying about messing with a value that is being calculated, though it's just arbitrary which part I am messing with. I have it down to link_bw=74000 without error, and link_bw=74300 shows errors. If we don't override link_bw then the other variables can be suspect, like link_nr
00:28 shadow: I freely admit to not know what I'm doing :)
00:29 shadow: 1.62ghz, 2.7ghz, 5.4ghz, 8ghz possible values so the math is off somewhere else but I need a starting point
00:30 imirkin: on your setup, only 1.62 and 2.7 btw
00:30 imirkin: 5.4 is with DP 1.2, and 8 with DP 1.3
00:33 shadow: thanks
00:33 imirkin: (DP 1.2 was supported starting Kepler. dunno what supports DP 1.3, if anything)
00:41 shadow: 74200 error, 74100 good. link_nr is 4 so... 296800 error and 296400 good hmm
00:42 shadow: nouveau 0000:01:00.0: DRM: nv50_dp_mode_valid() link_nr, link_bw, clock, bpc: 4, 74100, 296703, 10
00:48 shadow: if that mode is causing the error and I'm avoiding it, I don't know for sure that there aren't modes somewhere between that one and the lower bandwidth mode that is working that might also give an error
00:55 shadow: imirkin: by the numbers only it could be 2 lanes at 2.7ghz or 4 lanes at 1.62ghz total wild guess there
00:59 shadow: the calc for the good xrandr mode 154.280MHz * (10bpc * 3 rgb) / 10 = 462840 which is less than 2*2.7Ghz (540000) and 4*1.62GHz (648000), but also excludes the problem mode 296.703MHz * (10bpc * 3 rgb) / 10 = 890109
01:00 shadow: that might be chasing the wrong side of the maths
01:02 shadow: is it any more or less likely that it is link_bw=16200 and link_nr=4; or link_bw=27000 and link_nr=2 ; ?
01:20 shadow: hmm overriding link_nr=2 doesn't seem to be enough
01:21 imirkin: so ... 10bpc isn't actually supported on the G92 as far as i can tell
01:21 imirkin: so trying to compute these bandwidths with 10bpc is impractical
01:22 imirkin: the ANX9805 encoder chip can support 10bpc according to the docs, but i don't think things are hooked up in the scanout to make it happen
01:22 shadow: how to know if 10bpc is "working" would I be able to see anything?
01:25 shadow: also note this BenQ EX3501R monitor has a setting for DP1.4 or 1.1
01:26 shadow: it's been set to the device default DP1.4
01:28 imirkin: i think you need DP1.4 for variable refresh rates
01:28 imirkin: does it support that?
01:29 imirkin: er, what's it called ...
01:29 imirkin: gsync / freesync
01:29 shadow: this monitor should it's supposed to be baked in with the AMD one FreeSync
01:29 imirkin: right. so that's part of DP 1.4
01:29 imirkin: probably controls whether that shows up in EDID or not
01:29 imirkin: the other thing that DP 1.2+ enables is MST
01:29 imirkin: dunno if that monitor has any "DP out" ports
01:30 shadow: it has audio and USB outputs, inputs are DP DP HDMI USBC(DP)
01:30 shadow: not thunderbolt tho
01:33 imirkin: ok. well some monitors support that (e.g. my Dell U2415's do)
01:37 shadow: what is the purpose of that calc dividing by 10
01:37 shadow: clock = mode->clock * (connector->display_info.bpc * 3) / 10;
01:46 shadow: if link_nr=1 and link_bw=162000 I think this calc works out though
02:08 shadow: oh 1.62GHz and stored value is 162000 so divide by ten is because stored value is not 1620000
02:08 shadow: unit 10's of MHz got it
02:43 imirkin: shadow: the DP encoding is 10 bits per byte, iirc
02:44 imirkin: 8/10 encoding it's called? i forget.
03:13 shadow: bpc shouldn't swing the calc I just wrote out all possible outcomes for the good mode and bad mode I'm interested in, the compatible scenarios are either 1.62GHz DP x4 lanes, or 2.7GHz DP x2 lanes. Going to test to be sure practice meets theory.
03:15 imirkin: or 2.7x4 :)
03:16 shadow: imirkin: 2.7x4 would allow that bogus mode though
03:16 imirkin: the mode isn't bogus
03:16 imirkin: but the freq seems to be too high given that we have to double it
03:16 imirkin: (otherwise you end up with blue, somehow)
03:17 shadow: okay, well I'm just going by the ERROR message to kernel that happens when that "bad to me" mode gets selected
03:17 shadow: is that mode supposed to work? otherwise how else would it get rejected if not limiting the DP bandwidth and lane calc
03:18 imirkin: something like that
03:18 imirkin: however that failure has nothing to do with DP
03:18 imirkin: it has to do with the core capabilities of the thing
03:18 imirkin: there's a max clock value which can be written
03:18 imirkin: and that's that
03:18 shadow: where's that?
03:18 imirkin: we apparently don't know what that is. i'm guessing it's 330mhz (i.e. 165mhz before doubling)
03:19 shadow: I'll go test it if it helps :)
03:19 imirkin: since that's the max you can do over dual-link DVI
03:19 imirkin: (165mhz per link)
03:32 shadow: where would we try setting the max clock value then
03:39 imirkin: hm?
03:40 imirkin: the clock is set here: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/dispnv50/head507d.c#L289
03:40 imirkin: that's first value that follows the 0x0804 evo_mthd
03:41 imirkin: that's the INVALID_ARG you see at 0c04 (since it's 0x0804 + 0x400 coz it's the second head)
03:44 shadow: oh, I'm lost. :| I want to try with a limit like you suggest but not sure how to do that in code
03:45 imirkin: right
03:45 imirkin: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nouveau_connector.c#L1060
03:45 imirkin: so that's the function that determines if a mode is valid or not
03:45 imirkin: oh, i see. that's why you were looking at dp_mode_valid. makes sense.
03:45 imirkin: er, nv50_dp_mode_valid.
03:46 shadow: yeah... well I tried my best so far
03:46 imirkin: anyways, i'd just stick a thing in nv50_dp_mode_valid to say if the mode clock is > 165mhz, then bail
03:46 shadow: ok
03:46 imirkin: i.e. mode->clock
03:46 imirkin: it's all in khz, so > 165000
04:08 shadow: imirkin: that does seem to work!
08:21 linkmauve: “00:42:34 imirkin> anyways, not sure anyone's tried a VR headset with nouveau”, I can try, but I expect it will fail exactly like with any other output at displaying things other than fbcon.
08:26 raket: Im happy i have this old sandybridge-e cpu with 40 PCI-E 2.0 lanes. I connected a GM200 as primary and GK110 as secondary, ofcourse bios didn't understand a thing but when nouveau kernel module was loaded it displays on the GK110 ... :-)