00:00 imirkin: that's obviously a pretty suboptimal state to be in
00:00 imirkin: but it rights a lot of wrongs =/
00:00 skeggsb: it's very odd the display would report the lower link capabilities that we (rightfully) follow
00:01 skeggsb: i'm not sure what we could be doing wrong to cause that
00:02 imirkin: skeggsb: what about the dpcd fetch errors?
00:02 skeggsb: oh, i missed that
00:02 imirkin: could it be some default value? (since all screens must support 4x162)
00:03 imirkin: (or at least i assume they do...)
00:03 skeggsb: i wouldn't mind seeing disp=trace,i2c=trace added to those debug options
00:07 imirkin: hagbard: --^
00:07 imirkin: skeggsb: btw, should https://github.com/skeggsb/nouveau/commit/bea403507dd0df8de4e0e5063690e066245ad9f1 have a else if (armw->ilut) instead of a plain else?
00:08 imirkin: er wait. your current logic covers it.
00:08 imirkin: nevermind =/
00:34 imirkin: skeggsb: success!!
00:35 imirkin: clearing the ctm in that else case was the thing to do. i'm going to redo this to move it out of xlut state.
00:35 imirkin: i.e. add a clr.ctm
00:36 imirkin: thanks for all the help =]
00:42 imirkin: skeggsb: what causes the data from one atomic state to get carried over to another if e.g. !modeset and !color_mgmt_changed?
00:43 imirkin: is it atomic_duplicate_state?
00:57 skeggsb: yeah, it is
01:00 imirkin: any objections to sharing functions between base and ovly?
01:01 imirkin: hm, actually i'm goign to punt on making csc work for the overlay
01:01 imirkin: speaking of ... did you think about dumping the alpha formats?
01:02 imirkin: (iirc i even sent a change to that effect)
01:03 skeggsb: sounds like we probably should based on what you said, yes
01:04 imirkin: ok. let me know if you want me to do more digging on that.
02:06 imirkin: skeggsb: hm, looks like getting CSC to apply on an overlay requires more than the completely obvious
02:07 skeggsb: what's the completely obvious?
02:08 imirkin: calling those same methods on 907e :)
02:08 imirkin: tried both with and without the high bit on red
02:08 imirkin: there must be an enable somewhere
02:09 imirkin: or the methods didn't get as called as i thought they would be :)
02:11 imirkin: i just hooked up those wndw funcs in ovly907e
02:11 imirkin: kinda assuming they'd get called?
02:15 imirkin: skeggsb: btw, where do you disable old planes?
02:16 imirkin: /* Disable plane(s). */
02:16 imirkin: for_each_new_plane_in_state(state, plane, new_plane_state, i) {
02:17 skeggsb: right there
02:17 imirkin: for_each_new_plane...
02:17 skeggsb: that's actually really confusing, it's the "new state for any modified plane"
02:17 imirkin: ahhhh
02:17 imirkin: yes, that's not intuitively obvious :)
02:17 skeggsb: yes, it irritates me often
02:18 imirkin: i'd call it for_each_plane_in_diff() or something
02:19 skeggsb: well, there's one which gives you the plane+old state too
02:21 imirkin: heh
02:21 imirkin: well, anyways, i'm not too fussed about the overlay planes not having ctm working
02:21 imirkin: fwiw, experimentally, the output lut does affect them
02:21 skeggsb: they overlays are useless anyway, so, whatever
02:22 imirkin: (input lut obviously doesn't, at least not configured the way we have it)
02:34 skeggsb: looks like nvd on gv100 supports the blending stuff we need for overlays btw
02:34 skeggsb: ie. what the class says, does actually exist
02:34 skeggsb: imirkin: ^^
02:35 imirkin: nice
02:35 skeggsb: i'll push something for that along with your "remove alpha formats" thing for evo
02:35 imirkin: btw - i updated my modetest branch with the degamma/ctm/gamma stuff: https://github.com/imirkin/drm/tree/formats
02:35 imirkin: sounds good.
02:36 skeggsb: i just need to make sure i chose the right math for it :P
02:36 imirkin: hehe
02:36 imirkin: 2 * 2 = 5
02:36 skeggsb: exactly
02:38 imirkin: you should also have the ctm enablement in your inbox for gf119:gv100
02:38 imirkin: i'm leaving gv100- enablement as an exercise to the reader ;)
02:39 skeggsb: i was about to ask where the stuff to hook up degamma_lut was to go with enabling it
02:39 skeggsb: apparently i already did that
02:39 skeggsb: but yeah, was just reading your patches :P
02:43 imirkin: the remainder on these LUTs is to enable the 1024-sized one
02:43 imirkin: i'll do that separately
12:11 zfnmxt: Well, new Thinkpad X1E nouveau issues. It locks up now randomly. I get some nouveau-related kernel trace stuff from journalct, but I don't understand it: http://ix.io/1LvF
12:11 zfnmxt: Any ideas?
12:15 zfnmxt: Guessing it has something to do with: `June 11 14:06:26 x1e kernel: nouveau 0000:01:00.0: Refused to change power state, currently in D3`. But there are all sorts of errors, so I don't know :D
12:49 zfnmxt: Setting nouvea.runpm=0 fixes it. Bummer, this thing just doesn't want to work properly.
13:20 karolherbst: zfnmxt: didn't you try out my git tree? or was that somebody else?
13:20 zfnmxt: karolherbst: That was me.
13:20 karolherbst: with that tree that should be fixed
13:21 zfnmxt: It happened with the patch applied :(
13:21 zfnmxt: I was thinking maybe tlp is messing with it?
13:21 karolherbst: ohh, you need more patches
13:21 karolherbst: not just the top one
13:22 zfnmxt: Oh!
13:22 karolherbst: the top 5
13:22 karolherbst: well, you can remove that short timeout one.. I thought I removed that already though
13:22 zfnmxt: Okay.
13:22 zfnmxt: Is it best to create a patch for each individually?
13:22 karolherbst: wait, I will repush the branch
13:23 zfnmxt: I actually don't really know how I'm supposed to create a ".patch". I just manually inserted your code into the current torvalds/linux repo and used `git format-patch`. :P
13:27 karolherbst: pushed
13:29 zfnmxt: Thanks :D
13:35 zfnmxt: karolherbst: top 4 now, right?
13:35 karolherbst: yeah
13:41 zfnmxt: Alright, got magit to just generate all the patches automatically for me :)
14:08 zfnmxt: karolherbst:I *think* it fixed it. :D
14:08 zfnmxt: Thanks for all your help, once again!
14:28 cyberpear: karolherbst: thanks for all your efforts to get the gp107 working. I'm glad to see progress on this front!
14:49 zfnmxt: karolherbst: Uh, I spoke too soon. I didn't realize that Gnome was running under Wayland. Under Xorg, the external display doesn't work at all, although xrandr sees it.
14:49 zfnmxt: But under Wayland it works perfectly.
14:50 karolherbst: okay.. but then it might be just some userspace issue
14:59 zfnmxt: karolherbst: Is "failed to get BO with handle -1" at all meaningful?
16:18 zfnmxt: Looks like this may be the issue: https://bugs.freedesktop.org/show_bug.cgi?id=100086 . I'm going to try that patch and hopefully it fixes it!
17:55 Lyude: karolherbst: did you guys still need help from me?
17:56 karolherbst: dunno
18:01 Lyude: erm-sorry
18:01 Lyude: this is regarding the DP stuff
21:25 zfnmxt: Well, got it work finally. Just downgraded to xorg 1.19 and switched both cards to the modesetting driver. *Shrug*
23:53 imirkin: skeggsb: i'm going to be adding a lot of color-related properties. just a heads-up, so you don't freak out.
23:53 imirkin: procamp settings and whatnot