03:20airlied: karolherbst: do you have any generic pointer stuff done at all?
03:20airlied: or anyone else looked at it
03:27imirkin_: i know karolherbst was complaining about it a whole lot
03:52jenatali: airlied: I hadn't even considered it since we weren't planning 2.0 until you mentioned it... but then you made me think about it. I think we probably *could* do it but we'd probably have to put load/store conditionals at any access to a generic pointer
03:54imirkin_: fat pointers were always proposed as the solution to that
03:54airlied: yeah fat pointers always seems to be the answer, put the type into the pointer with t6he pointer
03:56jenatali: Yep, we're already doing 32bit offset + 32bit buffer ID... but we don't need a full 32 bits of buffer ID so yeah just stuff a type in the top bits
07:03tomeu: anholt_: for now I'm focused on reaching parity with the coverage in virglrenderer CI, so we can drop that and have a single CI setup for both mesa and virglrenderer
07:05tomeu: EGL and GLX would be good at some point
08:26bbrezillon: karolherbst: do you plan to submit a proper patch/MR for https://gist.github.com/karolherbst/b531ecb00b59a1e59847737bdfb7b255 or should I go ahead and do it?
09:15bnieuwenhuizen: danvet: timeline syncobj for radv: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5600
09:15karolherbst: airlied: nope
09:15karolherbst: airlied: I have ideas on how to implement it
09:16karolherbst: it's more of an architecture problem than anything else really
09:16karolherbst: and requires driver changes if you care about perf
09:17karolherbst: bbrezillon: ahh yeah.. you can just submit that one.. the patch itself is probably fine
09:25karolherbst: bbrezillon: but I think you can remove the comment
09:26karolherbst: but if you want I can also do it.. I just didn't have a local patch for it either
09:30danvet: bnieuwenhuizen, nice
09:30danvet: I guess I should rub that in with jekstrand
09:32danvet: bnieuwenhuizen, just scrolled through all the patches, looks very reasonable
09:32danvet: I expected more surgery with the submit thread
09:33bnieuwenhuizen: danvet: we had some submit system for the timeline semaphore with "legacy" syncobj already so that was half the work work done already
09:34bnieuwenhuizen: the main thing where things turned a bit nasty wrt kernel UABI is https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5600/diffs?commit_id=c5269c0dd02e6aa5703d54331b9d5a8024ea742c#66ee922e608a3ade5886426cc8edec338d132e28_1436_1517
09:35danvet: bnieuwenhuizen, hm why did you need the submit thread already?
09:35bnieuwenhuizen: but that seems like something that we can improve by just adding a flag to the submit ioctl. Will try after this lands
09:35danvet: oh cs ioctl fails if not all fences have been submitted yet?
09:36bnieuwenhuizen: danvet: yeah, which we have a flag for, the annoying part is that we need to reset binary semaphore as part of the submit (the thread may also slightly delay the submission of a binary syncobj signal, meaning we could pick up the old fence in a binary syncobj if we don't reset)
09:37bnieuwenhuizen: we didn't have the thread but we had code for storing submissions in memory and tracking dependencies for our timeline semaphore on top of binary syncobj implementation
09:37danvet: yeah that's awkward
09:49bbrezillon: karolherbst: actually I reworked it a bit
09:49bbrezillon: to address the comment ;)
10:31bbrezillon: karolherbst: can SpvCPacked be set on a struct member?
10:32karolherbst: bbrezillon: only on strcuts
10:32karolherbst: what would it mean for anything else?
10:32karolherbst: but mhh.. yeah.. the question of nested structs is indeed a valid one
10:33karolherbst: from the wording it sounds like it's not propagated through its members
10:33karolherbst: "Apply to a structure type, to marks it as "packed", indicating that the alignment of the structure is one and that there is no padding between structure members."
10:34karolherbst: and I think this patch is doing exactly this :p
10:35bbrezillon: yep, but the CL spec is unclear on what's expected
10:35bbrezillon: "In the following example struct my_packed_struct's members are packed closely together, but the internal layout of its smember is not packed"
10:36bbrezillon: sorry, that's not the quote I wanted to paste
10:36HdkR: Sounds like it is trying to match C spec for mismatched packing qualifiers with nested structs
10:37bbrezillon: "Specifying this attribute for structand uniontypes is equivalent to specifying the packedattribute on each of the structure or union members."
10:37bbrezillon: meaning that we can specify packed on members of a struct
10:38karolherbst: bbrezillon: yeah.. but we can ignore the CL spec :p
10:38karolherbst: we do what the spir-v stuff is saying
10:38karolherbst: and if there is a bug it's probably in the llvm to spir-v conversion then
10:39karolherbst: but it doesn't seem to address it
10:39karolherbst: so I'd just follow what the spir-v spec is saying
10:40karolherbst: but the clc spec is saying this: "Specifying this attribute for struct and union types is equivalent to specifying the packed attribute on each of the structure or union members."
10:40karolherbst: but.. then again
10:40karolherbst: why would we care?
10:40karolherbst: that's a problem clang and the spirv-llvm-translator need to solve
10:42bbrezillon: so I tried https://gist.github.com/bbrezillon/78ebbd9a71f178fe3e978e268d79eb32
10:42bbrezillon: and llvm-translator indeed solves that for us
10:42bbrezillon: marking the bar struct packed, and adding padding
10:59sfoo: danvet: hi, I have a kernel regression where the first bad commit was written by you. I filed a bug report here: https://bugzilla.kernel.org/show_bug.cgi?id=208179
10:59sfoo: Is there anyone else I should report this bug to to get it fixed? Can you tell whether it's a bug in amdgpu or in generic DRM code?
11:04danvet: sfoo, hm
11:13danvet: sfoo, I'm confused, this is supposed to work ...
11:13danvet: can you run a few test patches on top of the first broken kernel?
11:14sfoo: danvet: yes
11:20danvet: sfoo, https://paste.debian.net/1153467/ something like this as a first step
11:20danvet: repro, then grab dmesg
11:21danvet: still compiling here
11:21danvet: on top of the first broken commit
11:21danvet: reading the code we should be cleaning up dev->master before the lastclose callback runs
11:21danvet: so I'm very confused why that doesn't all work
11:21danvet: and if lastclose runs well there shouldn't be any other master around
11:22danvet: sfoo, compiler is still running, might have misplaced a comma or so :-)
11:23danvet: sfoo, oh also pls try to grab dmesg before and after doing the vt switch to restore stuff
11:40sfoo: danvet: https://paste.debian.net/1153469/
12:00danvet: sfoo, I'm baffled, it's the wrong way round!
12:00danvet: I'll add more debug output
12:03danvet: sfoo, https://paste.debian.net/1153471/ now with backtraces and more debug prints
12:04danvet: maybe this tells me what I'm not seeing in the code
12:29sfoo: danvet: https://paste.debian.net/1153472/
12:31danvet: sfoo, -amdgpu or -modesetting driver for Xorg?
12:34sfoo: danvet, how do I check?
12:35sfoo: I think it's amdgpu
12:35danvet: there's some Xorg logfile somewhere
12:35danvet: but I never remember how to get at it with journalctl
12:35danvet: before that it was in /var/log usually
12:38danvet: sfoo, I need to ponder this a bit more, not sure how to fix this
12:38sfoo: ~/.local/share/xorg/Xorg.0.log: [ 15.792] loading driver: amdgpu
12:38danvet: MrCooper, any ideas? essentially we cannot let drm take priority over fbdev, because that breaks for sfoo
12:39danvet: otoh we have people who want to exactly let drm take precedence over fbdev, so you don't have fbcon showing up at random points just because :-/
12:48MrCooper: danvet: not sure what this is all about, sorry
12:49danvet: sfoo, can I have your mail address or something for patches?
12:49danvet: I need to think this through some more
12:49danvet: MrCooper, regrets and backwards uapi compatibility at all costs
12:49danvet: MrCooper, I have an idea, I'll cc you on the kernel patch
12:49danvet: well 1 revert + 1 fix
12:49MrCooper: sounds good
12:51sfoo: danvet: you can see my email address by clicking my name on the bugzilla bug report (s..@fastmail)
12:52danvet: sfoo, also maybe your entire Xorg.log
12:52danvet: sfoo, hm need to find my login, but should work too
12:52danvet: I need to check whether you're using logind fd passing or not
12:52danvet: sfoo, ok got your mail
12:54sfoo: I'm now running a stable kernel, 5.7.4. Is the Xorg.log of this good, or do you want the Xorg.log when running the broken commit?
13:09sfoo: danvet: X.org.log for tty1 user: https://paste.debian.net/1153476/
13:09sfoo: danvet: X.org.log for tty11 user: https://paste.debian.net/1153477/
13:14sfoo: I took these logs with the patched kernel after reproducing the bug
13:48danvet: sfoo, just wanted to check whether you're using system-logind for handling all this
13:48danvet: otherwise there'd have been a gapin hole in my theory of what's going on :-)
14:00sfoo: danvet: i am using systemd, yes
14:10agd5f_: how do you mark an issue as duplicate in gitlab?
14:14MrCooper: agd5f_: write "/duplicate <target issue>" in an issue comment (note that it'll only work if you have sufficient privileges in both source & destination project)
14:14MrCooper: check the preview for whether it picked up the command and target issue correctly
14:15agd5f_: MrCooper, thanks
14:17FireBurn|Home: airlied: Just spotted the following build error on your drm-next branch: https://pastebin.com/MK0MUW7n
14:18FireBurn: agd5f_ you might be interested in that too as it's in amdgpu
14:18agd5f_: FireBurn, it's a merge conflict
14:18MrCooper: agd5f_: np
14:18agd5f_: there are various patches for it on the list
14:28TheRealJohnGalt: Suggestions on the best way to increase SSBO limit (GL_MAX_COMPUTE_SHADER_STORAGE_BLOCKS) on radeonsi?
14:32danvet: sfoo, typed up the patch, can you pls test and tell me whether it worked or not?
14:32danvet: sfoo, applies on current upstream, so need to test there
14:32danvet: the _force function got renamed
14:40sfoo: danvet: I'll test on top of v5.8-rc2
14:55sfoo: danvet: it works :-)
15:03vsyrjala: edid/dispid patches looking for review: https://patchwork.freedesktop.org/series/77700/
15:07ickle: [ 23.412649] i915 0000:00:02.0: drm_WARN_ON(kref_read(&obj->state->ref) != 1)
15:07ickle: [ 23.413661] WARNING: CPU: 3 PID: 321 at drivers/gpu/drm/i915/display/intel_global_state.c:58 intel_atomic_global_obj_cleanup+0xb5/0xd0 [i915]
15:10vsyrjala: we has full logs?
16:00ickle: just the warn
16:07danvet: pinchartl, still planning to review latest version of the vblank_reset patch?
16:23anarsoul: hey folks
16:24anarsoul: I've just got XPS 15 with OLED screen and it turns out that OLED screens do not have backlight, so intel_backlight doesn't control brightness
16:24anarsoul: archlinux wiki suggests to use hacks like icc-brigthness to adjust brightness on OLED screens
16:25anarsoul: but it's a hack and requires working X11 or wayland compositor
16:25anarsoul: is it feasible to add brightness control using color profile into i915 driver?
16:27Lyude: anarsoul: fwiw I am looking into adding support for the intel-specific backlight interface to i915
16:28Lyude: that's likely what you need to control brightness, also have you tried i915.enable_dpcd_backlight=1
16:28Lyude: the standard vesa interface might work
16:28anarsoul: I haven't tried this option yet
16:29anarsoul: 'xrandr --brightness' works fine though
16:29Lyude: def would try this first, we currently have to detect dpcd backlight brightness using a list of edids which is a lot less then ideal, but I think we can autodetect things normally once we've got support for both the vesa and intel backlight interfaces
16:29anarsoul: but I haven't looked into how it's implemented yet
16:29Lyude: anarsoul: oh? that's, interesting
16:30Lyude: you sure it's you're using the right backlight device?
16:30anarsoul: there's only one backlight device
16:30anarsoul: and it does nothing
16:30Lyude: really weird that xrandr does something
16:30anarsoul: OLED screens don't have backlight
16:30Lyude: anarsoul: yes, but the OLED laptops I have still expose the brightness interface through dpcd
16:31anarsoul: OK, I'll give it a try
16:31Lyude: j4ni: btw ^
16:31anarsoul: in an hour or so, I have a meeting in few mins
16:32Lyude: I was thinking of working on backlight stuff today so I'll go back and see if I can take a look at the brightness patches for this lee shawn posted a while back now that I've actually got some specs for this
16:34j4ni: anarsoul: the interface was named "backlight" way before oled became popular
16:35j4ni: I don't know how xrandr --brightness would work if the interface under /sys/class/backlight does not work
16:37MrCooper: anarsoul Lyude j4ni: xrandr --brightness just tweaks the gamma ramp (so lowering brightness with that potentially introduces colour banding)
16:38Lyude: so it probably looks like it's changing brightness (and might even have the same effect) but isn't
16:39anarsoul: Lyude: if I understand correctly that's the way to change perceived brightness on OLED screens
16:39j4ni: mmh, so I think the intel ddx did have a fake property for brightness that actually changed brightness via sysfs
16:40j4ni: anarsoul: it's _a_ way, but likely not the best way
16:40Lyude: anarsoul: I don't think so, everything I've seen has said it's either a combo of dpcd and pwm or just dpcd, and there's about three different interfaces (amd's proprietary one, intel's proprietary one, and the VESA standard interface) for doing it
16:41anarsoul: j4ni: OK
16:41j4ni: anarsoul: typically you have some way of sideband communication to the panel to change the brightness. on eDP that would be DP AUX or DPCD
16:41anarsoul: Lyude: I see
16:41Lyude: anarsoul: I don't think so, everything I've seen has said it's either a combo of dpcd and pwm or just dpcd, and there's about three different interfaces (amd's proprietary one, intel's proprietary one, and the VESA standard interface) for doing it
16:41Lyude: sorry-didn't mean to send that twice
16:41anarsoul: Lyude: I assume only VESA standard is implemented atm?
16:42Lyude: anarsoul: correct, note that we don't detect it automatically though because there's a number of panels that advertise support for it, but don't actually appear to work with it (my current theory is that said panels probably do work properly with the proprietary intel interface)
16:42imirkin_: anarsoul: changing the gamma ramp reduces the dynamic range of each pixel from 8-bit to ... lower
16:42imirkin_: e.g. if you change it to 50%, the dynamic range is reduced to 7-bit
16:43imirkin_: the panel should also support a way of doing this without reducing the dynamic range, at least not below 8-bit per color
16:43Lyude: so my current gameplan is to make it so we try detecting intel backlight support first, fallback to vesa backlight control if possible second, then fallback to pwm if all else fails
16:43Lyude: and i -think- that will get automatic detection working for the majority of panels out there
16:43j4ni: anarsoul: Lyude: also, "VESA standard" is an insanely complicated mess for such a superficially simple thing
16:44j4ni: which leads to deviating ways for panels to indicate support for various things
16:44Lyude: j4ni: yeah it's a bit crazy but after reading through it, it mostly makes sense
16:45j4ni: Lyude: I guess it's mostly to be able to keep the panel controller side simple, and move the complexity to the source, i.e. the driver
16:45anarsoul: Lyude: sounds good. If you need any help with coding or testing - ping me
16:45Lyude: j4ni: yeah that's my thought as well
16:45Lyude: anarsoul: np, if that module option works btw feel free to send a patch to add your panel to the quirk list as a temporary bandaid
16:46anarsoul: I hate having non-functional hardware in my laptop :)
16:46MrCooper: imirkin_: right, though these days the gamma table output tends to have at least 10 bpc
16:48j4ni: obviously i915 driver covers the PWM output; that's PWM in our hw. stuff gets more complicated when it's the OEM adding all sorts of hardware that we (as in i915 developers) don't have specs or control over
16:49anarsoul: Lyude: are there any patches for proprietary intel interface?
16:49thaytan: what an interesting coincidence that I'm sitting here installing Fedora 32 on a new HP laptop with an OLED screen
16:50malice: thaytan: They have oled laptops? O:
16:50Lyude: anarsoul: yeah, lee shawn posted them a while ago but no one approved them because it didn't really give any kind of description of what the backlight interface was there for
16:50thaytan: malice, the Spectre x360 - previous gen and this new one
16:50Lyude: anarsoul: sec
16:50malice: Oled in monitors when?
16:51Lyude: anarsoul: patchwork
16:52Lyude: I don't think we realized at the time that got posted that we actually needed to support both interfaces for things to work
16:53Lyude: anarsoul: if your panel doesn't work with the vesa interface but works with the other one let me know, that'd definitely be something that would be good for us to test
16:55thaytan: I think this laptop has an SDC OLED - I think most, if not all, OLED laptop panels are Samsung AMOLEDs right now
16:55thaytan: I'll test the i915.enable_dpcd_backlight=1 param now
16:56Lyude: there's a few others out there, I've seen a few other vendors
16:57Lyude: also, if I get time today I'll try to work on those backlight patches (otherwise I'll try to get at them tommorrow)
16:57anarsoul: xps 15 has SDC OLED panel
16:57anarsoul: at least edid says so
17:00Lyude: anarsoul: btw, might need to remove the quirk they use in that patch. Not entirely sure why that's there seeing as there seems to be a capability bit they check on the dpcd
17:01thaytan: Lyude, i915.enable_dpcd_backlight=1 has no effect on this Spectre x360
17:03Lyude: thaytan: good to know, mind downloading https://gitlab.freedesktop.org/lyudess/auxrw/blob/master/auxrw.py and getting me the output of auxrw r <edp_auxdev_path> 300-3ff along with the edid for your panel?
17:05thaytan: I can - but I don't know what an auxdev path is :)
17:05Lyude: thaytan: try all of them until you get something that looks like it has data in it? :P
17:05Lyude: it's probably the first one
17:05thaytan: in /dev/drm_dp_aux ?
17:06danvet: glisse, do you have some time to help someone who's not seeing the problem?
17:07danvet: I have no idea what I even changed to upset lockdep in xfs like that
17:07anarsoul: Lyude: mine is here: https://gist.github.com/anarsoul/352f79eb820fc27ab9d4e4947d88561d
17:07anarsoul: (haven't tried module param yet, I can't reload laptop atm)
17:08thaytan: Lyude, https://pastebin.com/s1CMxJsC
17:11Lyude: thaytan: yep-yours definitely supports the intel one and not the vesa one, nice to have confirmation on this being a thing finally :)
17:11Lyude: thaytan: also, what kernel version did you try that kernel parameter on?
17:12thaytan: the boot log mentions to try it
17:12thaytan: "Panel advertises DPCD backlight support, but VBT disagrees."
17:12Lyude: thaytan: mind showing me your boot log for a sec just so I can double check you're not running one of the kernel versions where I broke that module parameter by accident? :P
17:14thaytan: Lyude, https://gist.github.com/thaytan/23de80bac1726f14c57a1d3a86a97cb1
17:15thaytan: 2 boots in there, oops
17:16Lyude: thaytan: ok yeah, so your panel does have broken vesa controls like we thought
17:18thaytan: Lyude, I've been spoilt with too many years of perfectly working hardware, so this seems fair
17:18thaytan: I'm still copying things onto it, but will be able to build a kernel and test patches after tomorrow
17:19thaytan: it's the end of my day here now though
17:25anarsoul: Lyude: how do you tell whether it supports either interface by looking at this dump? Is there a spec somewhere?
17:25Lyude: anarsoul: barely, I only have a couple of pngs with register descriptions on them that a vendor sent me
17:26Lyude: I don't know of any public docs for it unfortunately
17:26anarsoul: I see
17:26anarsoul: what about my panel then?
17:31Lyude: anarsoul: would basically be the same process
17:32anarsoul: I mean does it support either interface?
18:19anarsoul: Lyude: i915.enable_dpcd_backlight=1 didn't help
18:19Lyude: anarsoul: gotcha
18:19anarsoul: should I try the patches?
18:20Lyude: anarsoul: yeah, and make sure to remove the quirk bits so it actually activates on your panjel
18:29anarsoul: i.e. replace it with if (1)?
18:37Lyude: anarsoul: yep
19:02anarsoul: Lyude: is there standalone i915 driver tree somewhere so I don't have to compile whole kernel?
19:03karolherbst: airlied: btw.. do you think you'll have time to implemeng generic pointers? It's not complicated.. just annoying
19:04Lyude: anarsoul: I don't believe so, no
19:04airlied: karolherbst: it's probably something I could get to, once I get over landing the GL work
19:05karolherbst: airlied: but to be honest, I'd skip all optional 3.0 features for now :/ generic points though are just ugh...
19:06karolherbst: so short list of things which needs to be done
19:06jenatali: Isn't that optional for 3.0?
19:06karolherbst: 1. pointer conversion intrinsic (global to local/shared/private and vice versa)
19:06karolherbst: 2. pass to lower it to an if ladder for hw not supporting native conversions
19:06karolherbst: 3. vtn sutff :po
19:07karolherbst: the lowering needs an encoding though...
19:07karolherbst: and this makes it so annoying
19:07airlied: karolherbst: yeah it's just my goal is to gt intel's sycl stack running rahter than CL3.0 at present :-P
19:07karolherbst: airlied: on what driver?
19:07airlied: karolherbst: mesa :-P
19:07karolherbst: we could _require_ suppotrting native conversions
19:07karolherbst: would make it quite easy
19:08airlied: karolherbst: I've got basic lvl0 on anv
19:08karolherbst: on nv hardware we can map local and shared memory into the global address space
19:08airlied: but the sycl needs spir-v genericpointer support
19:09Lyude: is vblank->inmodeset always going to be non-zero whenever vblanks have been disabled with drm_crtc_vblank_off()?
19:09karolherbst: yeah.. then I'd go with requiring address space translations
19:09karolherbst: and if somebody really needs lowering code, they can add it then
19:09jenatali: +1, if we were to support generic address space we'd want to get the conversion ops in the backend
19:09karolherbst: airlied: and we would need a pass to follow pack the phi nodes to decide which address modes are valid
19:10karolherbst: and place conversions in a smart way
19:10karolherbst: so if all phis end up being one type, we skip conversions
19:10karolherbst: but if they can be different things, we just convert to global
19:10jenatali: karolherbst: I'd hope the frontend compiler is smart enough to do that
19:10karolherbst: jenatali: spir-v
19:10jenatali: Yeah, but the frontend frontend that compiled from a source language
19:10karolherbst: so we can't rely on the frontend compiler
19:11jenatali: Sure, but a dumb frontend can generate suboptimal code, doesn't mean you need to chase the phis to optimize it
19:11karolherbst: jenatali: spir-v has native support for generic pointers, so we need to be able to consume those and handle it
19:11karolherbst: and you can have if/else trees asigning from different address spaces
19:11jenatali: karolherbst: Agree you need to support it, just doesn't need to be optimal
19:12karolherbst: so you could end up with a phi node pointing to the same or different ones.. so we just need to be able to deal with it..
19:12danvet: Lyude, why do you need to look at that stuff?
19:12karolherbst: anyway. the derefs _have_ an address space encodded
19:12karolherbst: so that shouldn't be a huge issue
19:12airlied:hasn't woken up, but you two know way more about this than I currently do :-P
19:12anarsoul: Lyude: what tree should I use? drm-misc?
19:12karolherbst: airlied: maybe I give it a shot actually
19:13karolherbst: I just didn't want to do it because an if ladder requires a silly pointer format
19:13karolherbst: but if we ignore that.. it becomes simple
19:13airlied: karolherbst: put it on the post-structirzer list
19:13anarsoul: Lyude: the patch doesn't apply onto Linus' tree
19:14karolherbst: yeah.. I should really get to the structurizer stuff next
19:14airlied: but I'll add it to my things to dig into more list,
19:14anarsoul: looks like it's too old :\
19:14karolherbst: would just be cool if somebody would help me cleaning up the lowering pass :D
19:14anarsoul: OK, I'll patch it manually later tonight
19:15airlied: karolherbst: what does the lowering pass need? cleanups from review?
19:15karolherbst: the vtn change I will do myself, and I don't even think it's that much required... but will toy around with completly rewriting it
19:15karolherbst: airlied: essentially yes
19:15karolherbst: alyssa left some comments
19:15karolherbst: and some I dealt with already
19:16jenatali: If one of you does add generic pointer support, I'd love to review it, though I probably won't catch if you don't tag me, I haven't been monitoring upstream MRs really
19:17karolherbst: jenatali: you can subscripe to labels
19:17karolherbst: wait.. let me check how again
19:18karolherbst: jenatali: https://gitlab.freedesktop.org/mesa/mesa/-/labels
19:18jenatali: Yeah, found it
19:18karolherbst: let me subscribe to the clover+opencl one myself :D
19:18karolherbst: only had nouveau for now
19:19karolherbst: jenatali: and I think you just get an email or something then
19:19jenatali: Yeah makes sense
19:26anarsoul: Lyude: is your auxrw.py tool supposed to work for write?
19:26Lyude: anarsoul: it should
19:26anarsoul: I tried to change 0x354 but it has no effect
19:26Lyude: anarsoul: you might need to program the source oui at a specific point before the panel is link trained
19:27anarsoul: how do I do that?
19:27Lyude: anarsoul: would need to add something into i915 or do it when the screen's off, I'm not entirely sure tbh
19:28anarsoul: does the patch do that?
19:29anarsoul: yeah, it does
19:29sravn: pinchartl: 21 bridge related patches applied - see mail. Good to get this far
19:39imirkin_: MrCooper: well, even if the gamma table is 10bpc, if the on-the-wire values are 8bpc, you still lose dynamic range. presumably with an OLED panel it'd support 10 or 12bpc, but whether the linux driver actually avails itself of such bpc-ness is another question
19:54ajax: imirkin_: not unknown for the display controller to temporally dither in that situation
20:18Lyude: Is there a reason for using the irqsave/irqrestore variants of spin_lock() in code where you're guaranteed to always have irqs enabled (vs. using the _irq() variants)
20:20airlied: the save/restore variants I think are only for when you might be taking the lock in an irq context
20:21Lyude: airlied: cool, that's what I figured :). Was wondering since I need to add some calls to drm_crtc_vblank_off() that would block and noticed we're using irqsave/irqrestore variants, but I just confirmed there's no drivers in tree that actually call drm_crtc_vblank_off() in irq context (everything is either in legacy modesetting callbacks, atomic_disable callbacks, or driver init)
20:30anholt_: today I learned: you can disable gitlab's keyboard shortcuts under the ? dropdown in the upper right.
20:47anarsoul: Lyude: looks like intel_dp_aux_init_backlight_funcs() is not called at all for me in 5.7.5 :\
20:47anarsoul: any ideas where to look?
20:48Lyude: anarsoul: I'm not sure tbh, btw backlight stuff is next up on my todo list if you just want me to let you know when I have patches to try
20:57pinchartl: sravn: nice!! thanks a lot
20:59Lyude: airlied (or anyone else here with knowledge of legacy modesetting): any idea why drm_legacy_vblank_pre/post_modeset() appear to modify vblank->inmodeset outside of lock?
21:02anarsoul: ah, got it working, it was bailing out early, before my trace
21:03anarsoul: Lyude: the patch worked for me
21:05Lyude: anarsoul: awesome! :D
21:10anarsoul: are you planning to resubmit it?
21:10Lyude: anarsoul: yeah-I just want to get the nouveau crc stuff I'm working on out of the way first and fix another issue my gf is hitting in xwayland on her machine, so I can get to it in the next day or two
21:11Lyude: there's a lot of laptops that need this so it's pretty high up on my todo list
21:11anarsoul: sounds good
21:11anarsoul: feel free to ping me in IRC if you need some testing
21:11Lyude: sure thing, thanks!
21:12anarsoul: and please add me to CC when you submit the patch :)
22:02Lyude: danvet: hm, will probably end up sending the patch tommorrow so don't worry about it (if you haven't already gone to bed)
22:07danvet: Lyude, probably should have, didn't manage yet :-/
22:07Lyude: ah, gotcha
23:58anholt_: tomeu: did you ever encounter "apitrace dump" returning nothing?