06:04 shadow: nouveau 0000:01:00.0: disp: outp 02:0d16:0301: link rate unsupported by sink
06:04 shadow: I think that's after the display goes to sleep and then wakes up later
06:06 imirkin: probably gnome trying to set some crazy mode
06:06 imirkin: or ... dunno
06:07 shadow: when tweaking gnome display settings from 30Hz to 59.97Hz, and then back to 30Hz
06:08 shadow: nouveau 0000:01:00.0: disp: ERROR 4 [INVALID_ARG] 84 [] chid 0 mthd 0c04 data 0089c20c
06:08 imirkin: you said the 59.97hz one works though, no?
06:08 shadow: it does show output yes
06:08 imirkin: so other than that INVALID_ARG, any problems with it?
06:09 shadow: not visually it's just these slowdowns (I guess from nouveau?)
06:09 imirkin: oh hm
06:09 shadow: it looks great
06:09 imirkin: how do the slowdowns appear?
06:09 imirkin: like ... what slows down?
06:11 shadow: I can move the GUI mouse pointer freely, but text i/o and changing window focus goes in 10-15 second spurts
06:11 imirkin: huh, interesting
06:11 imirkin: so maybe the invalid arg _is_ complaining about something real
06:12 imirkin: shadow: and when connecting over HDMI, presumably none of those "high" modes work either?
06:13 shadow: imirkin: certainly the 3440x1440 is not a possible selection from gnome display settings with that DP->HDMI connection correct
06:14 imirkin: hm, odd.
06:14 imirkin: @30, it should fit ... can you pastebin xrandr --verbose again, with the @30 mode selected?
06:15 shadow: yes, with the DP cable it was https://hastebin.com/otakowocoz.css
06:16 imirkin: shadow: ok yeah, 154.28 mhz. i figure we should set a 165mhz max for pior.
06:16 shadow: removing the DP cable and attaching the HDMI->DP cable I see the modes from DP cable until I try to change modes and then gnome display settings updates its list of modes only after trying to set a mode
06:16 shadow: ok! will happily test any patches :)
06:16 imirkin: odd that this @30 mode wouldn't go through hdmi
06:17 imirkin: might be missing from the edid? that'd be odd though.
06:17 shadow: the Raspberry Pi4 drives the display 3440x1440@30Hz via HDMI
06:17 imirkin: hm ok
06:19 shadow: actually, I might be mistaken about Raspberry Pi 4
06:19 shadow: I'm looking closer into it right now
06:21 shadow: Raspberry Pi4 actually lacks the ultrawide mode so no 3440x1440 in fact
06:23 shadow: imirkin: xrandr --verbose from rpi4 https://hastebin.com/owopajahec.sql
06:23 imirkin: shadow: yeah, rpi4 seems to allow up to 300mhz, so you get everything.
06:23 imirkin: errr
06:23 imirkin: no you don't
06:23 imirkin: you get 4k@30
06:23 imirkin: but no 3440x1440@30
06:24 shadow: agree
06:24 imirkin: what's the native screen size?
06:24 imirkin: is it 4k? or the other thing?
06:24 shadow: native is 3440x1440@30Hz I think
06:24 shadow: ahh
06:24 shadow: 100Hz
06:24 shadow: I can't make my brain work right
06:25 imirkin: DTD 3: 3440x1440 99.982 Hz 43:18 150.972 kHz 543.500 MHz
06:25 shadow: yes that one
06:25 imirkin: that edid doesn't show a 3440x1440@30 mode
06:25 imirkin: only @60 and @100
06:26 imirkin: and those are all higher than 165mhz, which is why you don't see them on the G92, and higher than 300mhz which is why you don't see them on rpi4
06:26 shadow: good explanation. thank you
06:27 shadow: where does gnome display settings get 3440x1440@30Hz from
06:27 imirkin: from the EDID advertised over DP
06:27 imirkin: (they're different EDID's)
06:27 shadow: ah okay
06:28 imirkin: https://people.freedesktop.org/~imirkin/edid-decode/
06:28 imirkin: just paste the hex stuff into the left side, hit process, and enjoy
06:28 imirkin: or grab the cmdline tool from https://git.linuxtv.org/edid-decode.git/
06:28 imirkin: (or perhaps it's packaged for your distro)
06:37 shadow: imirkin: where would we clamp that maximum, I could try some values and see if I still get errors at some lower bound
06:47 imirkin: shadow: nouveau_connector.c maybe?
06:47 imirkin: there's a get_tmds_link_bandwidth() function iirc
06:47 imirkin: (going by memory)
06:49 shadow: imirkin: good memory!
06:50 imirkin: but it's all a bit tricky
06:50 imirkin: you want to do it based on the encoder type, i guess
06:51 shadow: I'd like to try clamping it to some low bound maximum, and see what happens over a few days if there's still errors
07:01 shadow: let's try 165MHz (return 165000 early in get_tmds_link_bandwidth() )
07:14 shadow: still seeing "nouveau 0000:01:00.0: disp: ERROR 4 [INVALID_ARG] 84 [] chid 0 mthd 0c04 data 0089c20c" at boot right after fbcon: nouveaudrmfb
07:17 shadow: imirkin: returning 165000 early get_tmds_link_bandwidth does not appear to have any affect on modes being set
07:18 shadow: 3440x1440 (0xb3) 319.750MHz -HSync +VSync *current +preferred
07:20 shadow: going to go deeper on it and try short circuiting nouveau_connector_mode_valid()
07:54 shadow: got it to do something different. Modes are limited for DP connected BenQ to some lower modes that it won't display, but errors are gone and it doesn't try those funky modes at system boot.
07:55 shadow: moving on to some bigger values to see where it fails
08:31 shadow: clock = clock * (connector->display_info.bpc * 3) / 10;
08:31 shadow: what a gem.
08:32 shadow: that's from linux 5.7.1 so... it's not up to date
08:36 shadow: gets moved to nv50_dp_mode_valid() hmm
09:32 RSpliet: It is, like... merged. Congrats skeggsb and karolherbst.
09:35 karolherbst: :)
09:35 karolherbst: I will probably rework the entire QMD stuff though, which could be fun
14:33 imirkin: shadow: yeah, i think that function isn't called for DP
14:33 imirkin: but it's something adjacent to that
14:34 imirkin: the other thing is the DP clock, which is actually separate from the modeline clock
14:34 imirkin: it's used to determine the DP bandwidth requirements to figure out what to do for link training
19:49 shadow: imirkin: limiting the DP clock bounding with a hack I got the system to run without nouveau errors at boot, also no errors overnight, that's with laptop and BenQ screen at native res extended display config. I got lost with the changes between linux 5.7.1 and upstream linux-next so I'm going to try some more values on linux-next booting to see where it breaks? I think
19:52 imirkin: well ... the values only matter as far as accepting or rejecting a particular modeline
19:52 imirkin: since you only have certain modelines available, your ability to test is somewhat limited
19:53 imirkin: e.g. if you only have a 100mhz and 300mhz modelines, you won't be able to tell if the limit is really 150, 200, or 250 mhz
19:53 shadow: agree
21:51 shadow: nv50_dp_mode_valid() link_nr=4 link_bw=270000 bpc=10 only the clock changes ; what is link_nr?
21:51 shadow: trying to understand the calculation clock = mode->clock * (connector->display_info.bpc * 3) / 10;
21:52 shadow: I added some debug info print to get link_nr link_bw clock and bpc
21:52 shadow: why '3' ?
21:52 shadow: RGB?
21:53 imirkin: yep
21:53 imirkin: bpc = 10? should be getting clamped down...
21:53 imirkin: i guess i failed? or you don't have my patch?
21:53 shadow: imirkin: working fine without the clamp patch tho
21:53 imirkin: wellll
21:55 shadow: linux-next (torvalds) git and bcd1d5f2_depth_only_supported_on_G94plus.patch, no superclamp, and some debug statements I'm trying
21:57 imirkin: well, the clamp is needed to compute the correct bandwidth for link training
22:35 c_nix: hello, is any VR headset supported?
22:40 imirkin: is there anything driver-specific with VR headset support?
22:40 imirkin: it's just a weird monitor as far as the video card is concerned, no?
22:41 c_nix: dunno, im fresh to the topic - I read some texts and it seems that it has something to do with gpu
22:42 c_nix: research in progress and I asked on #vronlinux
22:42 imirkin: anyways, not sure anyone's tried a VR headset with nouveau
22:42 imirkin: but that also means no one's complained about anything not working :)
22:44 c_nix: btw how is nouveau in general? Havent been using nvidia crds in over a decade
22:45 c_nix: im thinking about building a PC and am consdering puting something more powerful than intel in it to process 3d graphic
22:46 imirkin: keep away from nvidia.
22:47 c_nix: so what to use for 3d?
22:47 imirkin: AMD
22:47 c_nix: umm
22:47 c_nix: but its all blobbed
22:47 imirkin: huh?
22:47 c_nix: no?
22:47 c_nix: it requires blobs
22:47 c_nix: afaik
22:48 imirkin: it also requires you to purchase the card
22:48 imirkin: the "blobs" are firmware uploaded to the GPU
22:48 imirkin: i consider that quite acceptable
22:48 c_nix: really? Icannot just steal it?
22:48 c_nix: I dont
22:48 imirkin: then stick away from intel and AMD CPU's as well
22:48 imirkin: stay away*
22:49 c_nix: intel runs with free software drivers
22:49 imirkin: since those also come with firmware blobs
22:49 imirkin: the CPU has firmware in it.
22:49 imirkin: it's closed firmware.
22:49 imirkin: so i guess not for you?
22:49 c_nix: yea it's in it - so it's not an issue
22:50 imirkin: ok, so if the GPU vendor sprung an extra couple $ to stick a ROM on the board to store the firmware - that'd be fine?
22:50 imirkin: but uploading it from the CPU on boot is not fine?
22:50 c_nix: yes
22:50 imirkin: then nvidia is also not for you.
22:50 imirkin: and i believe intel also has that "gup" firmware for their graphics stuff starting with gen9
22:51 imirkin: i sort of expect that VR headset will also come with user-uploadable firmware
22:53 imirkin: the last nvidia GPU for which nouveau has open firmware and doesn't _require_ any closed firmware to be uploaded is the GM107
22:53 imirkin: (GTX 750 Ti)
22:53 c_nix: thx
22:53 imirkin: starting with GM20x, it's all closed
22:54 imirkin: note that while slightly earlier, the GK110 is the most powerful GPU that nouveau supports without closed firmware.
22:54 imirkin: (GTX 780 / GTX 780 Ti)
22:54 c_nix: thanks a lot
22:55 imirkin: do note that these boards all come with a VBIOS burned into them
22:55 shadow: what is link_nr "link number?"
22:55 imirkin: and that VBIOS contains high-level opcodes that nouveau executes blindly
22:55 imirkin: shadow: number of DP lanes
22:55 imirkin: shadow: between 1 and 4
22:55 shadow: okay lane count
22:56 imirkin: (but not 3 ... heh)
22:56 shadow: do you think link_nr=4 makes sense for my system?
22:56 imirkin: shadow: iirc by default we try to use 4x lanes since that's what blob does
22:56 imirkin: link training is an art, not a science
22:56 shadow: ok
22:57 imirkin: i'll be honest - i have no clue what "link training" does or how it works
22:57 shadow: these all go into the calculation that affects rejecting modes, so I'm trying to work out if any of these values are sane and what is remaining that might be suspicious
22:58 imirkin: shadow: it's a bit awkward
22:58 imirkin: basically there's the highest lane count / bandwidth per link that both the sink and source support
22:58 imirkin: but the cable might be bogus and not actually be able to do it
22:58 shadow: ah
22:58 imirkin: link training is done at the very end, after you've selected a mode
22:58 imirkin: and it can fail
22:58 imirkin: there's nothing that can be done about it
22:58 imirkin: we just report back the link-status property
22:58 imirkin: and the compositor is supposed to see the change and pick a different mode.
23:00 shadow: just to pick one of these variables to that calculation which rejects modes, I've started in on nouveau_dp_detect() to override nv_encoder->dp.link_bw and bissecting values that show an ERROR in dmesg or don't show an error
23:01 shadow: nv_encoder->dp.link_bw = 27000 * dpcd[1];
23:01 shadow: dpcd[1] must be some value of 2 or higher I guess
23:01 shadow: maybe maybe not actually
23:02 shadow: anyhow I'm narrowing it down somewhat even if chasing my own tail
23:05 c_nix: imirkin: what are these opcodes responsible for? They interfere with environment outside graphic card?
23:05 RSpliet: imirkin: https://community.cadence.com/cadence_blogs_8/b/ip/posts/link-training-_2d00_-establishing-communication-between-displayport-source-and-sink-devices
23:06 imirkin: c_nix: initializing the GPU
23:07 RSpliet: I actually kinda get step 1. Step 2 is still magic to me.
23:07 c_nix: but they are exeecuted on the GPU if I understand correctly?
23:08 imirkin: they are executed on the CPU
23:08 c_nix: ah
23:08 c_nix: ok
23:08 imirkin: but they instruct the CPU to perform various MMIO/etc writes to the GPU
23:08 imirkin: (as well as some higher-level constructs)
23:10 RSpliet: c_nix: well, those initialisation scripts ("opcodes") are interpreted by nouveau running on the CPU. They're not x86(_64) code or anything.
23:11 c_nix: so its transparent what they do? Or its some alien gibberish?
23:11 imirkin: i mean ... "write random value X to random mmio reg Y"
23:11 imirkin: it's clear what it does
23:11 imirkin: but no clue why it does that
23:12 imirkin: but if you do it, then all is well, so ... can't complain
23:12 c_nix: ah, so it's nothing to male tin foil crowd worry?
23:12 c_nix: *make
23:12 RSpliet: Well, in a lot of cases we do know. Things like setting up the DRAM controller
23:12 imirkin: i already have no idea why uploading a sequence of bits to hardware for initialization is somehow "bad"
23:13 imirkin: so i'm probably not qualified to estimate what the tinfoil crowd worries about
23:13 c_nix: well it is when it makes nasty stuff happen
23:13 RSpliet: define nasty
23:13 imirkin: nasty stuff can happen just as much if those bits sit inside a ROM on the board
23:13 imirkin: or rather, the same nasty stuff.
23:13 imirkin: for any definition of nasty :)
23:14 c_nix: when it makes impossible to take a screenshot with sections of screen - it is nasty stuff happening
23:15 c_nix: when it creates backdoors into system - it is nasty etc
23:15 c_nix: think Intel ME
23:17 c_nix: anything that makes you not in control of your computing
23:17 RSpliet: Right. No, these scripts do not facilitate any of that. They don't run persistetly, they're "one-shot" hardware configuration scripts that aren't hardcoded onto the chip because OEMs can vary certain bits of the graphics card (e.g. brand/type of DRAM, number of display outputs)
23:18 c_nix: Thank you RSpliet thats what I had in mid. Much appreciated!
23:26 imirkin: c_nix: yes, but how is it different if such software comes in the ROM or is uploaded into the board?
23:26 imirkin: c_nix: in all cases, it's just software running on the GPU itself
23:26 imirkin: not on the CPU
23:27 imirkin: well, wtvr. i'll never understand why people worry about uploaded firmware.
23:27 imirkin: i understand why people worry about having open firmware
23:27 imirkin: but i don't see how method of delivery affects that
23:29 c_nix: for exaample some reason it that way https://www.fsf.org/blogs/community/201cthe-printer-story201d-redux-a-testimonial-about-the-injustice-of-proprietary-firmware
23:29 c_nix: there are also different reasonings
23:30 c_nix: depends on case
23:30 c_nix: and what firmware is responsible for
23:30 c_nix: and what can device access
23:32 c_nix: also some builtin firmware could be an issue too aswell - depends on what it do
23:32 c_nix: but thats a solid oftop
23:38 shadow: imirkin: so far link_bw=70000 is working, link_bw=75000 shows errors. I'm going to keep bissecting to get a more exact number.
23:39 imirkin: shadow: link_bw can't just be an arbitrary number
23:39 imirkin: only certain values exist ... 1.62ghz, 2.7ghz, 5.4ghz, and with the very latest DP, 8ghz
23:40 imirkin: c_nix: yes, closed firmware sucks. who cares if it's bundled in or has to be uploaded?
23:40 imirkin: like i said ... open vs closed firmware -- i get it
23:41 imirkin: whether the firmware is shipped on a ROM on the board or has to be uploaded by the CPU ... how does that matter
23:42 c_nix: you are in control of upload process - you may choose to not do so. Half the problem if you know what it does and what effects it brings
23:46 imirkin: much as you wouldn't if it were loaded off a ROM
23:46 imirkin: that was sitting on the board
23:46 imirkin: i don't see how the "open vs closed" discussion intersects the "rom vs cpu upload" discussion
23:47 c_nix: i dont care about open
23:47 c_nix: i care about free
23:47 imirkin: wtvr. "free vs closed" then.
23:47 imirkin: still doesn't intersect the other thing.
23:48 c_nix: in case of free it does
23:48 imirkin: why
23:48 imirkin: how is "closed and sitting on a rom" different from "closed and uploaded by cpu on startup"
23:49 c_nix: if its trivial transparent stuff - no one gives a fuck Stallman included. If it becomes nontrivial it's an issue.
23:50 c_nix: I came here with zero knowledge on how complicated issue witj firmware in case of graphic cards is.
23:50 c_nix: if that explains at least my motivation. I myself said I dont care as I have no influence on what is in the rom
23:51 c_nix: well I aftually could eventually flash it if it is possible and there are programators to do so
23:51 imirkin: let's assume it's a full OS which runs on the device in question
23:51 imirkin: since that's what it basically is in many cases
23:51 imirkin: (well, more like a RTOS)
23:52 imirkin: who cares if that RTOS is on the ROM or if the CPU sends it over...
23:54 c_nix: to me if there is proper separation and I can controll the space that my software is executed in w/o security leaks etc I dont care too much.
23:55 c_nix: in case in on chip firmware
23:55 c_nix: if its however loadable its just another proprietary software
23:55 c_nix: and I say no to such stuff
23:58 c_nix: If I can afford 100% free platform over one that has nonfree firmware on roms i would choose free one