01:20xmnm: I see there are a few opengl over vulkan projects, has anyone tried them? I see at least zink, glove and vkgl
01:26HdkR: Considering VKGL is dead and Glove is targeting ES, zink will be the best of the tree at some point
01:27HdkR: best of the three*
01:27jekstrand: Kayden, anholt_: So, my attempt to drop noise busted 4 GLSL parser tests. :-(
01:27xmnm: I didn't know VKGL was dead. I guess maybe at some point I'll be able to run exanima with zink and see if anything changes
01:27jekstrand: Is there a way I can make a built-in function that's just a bunch of constants that explicitly fails to compile if it's put in a constant expression?
01:28jekstrand: Is there a flag I can set on the function signature or something?
01:29xmnm: hmm loks like arch's mesa package doesn't include zink
01:30Kayden: I thought that built-in functions of constant values was always allowed
01:32jekstrand: noise seems to be explicitly called out as not
01:32jekstrand: even though that doesn't make sense even with older GLSL
01:33jekstrand: Maybe I can add a quick check
01:42jekstrand: Kayden: I added a thing.
02:03Kayden: seems like that maintains the current behavior of the compiler
02:04Kayden: that looks ok to me with a commit message
02:56imirkin: jekstrand: maybe dfdx has it too?
04:30xmnm: regarding the trouble game, I asked a friend who has the game as well as an rx 580 card and a r9 270, polaris runs the game at ~200fps, the r9 270 runs it at 6fps, so similar to what I experience
04:30xmnm: the 39 270 is a sea islands card, just like my amd hd 7770
04:30xmnm: so it's possible only sea islands cards are affected
04:31xmnm: he also has an r9 280 and will test that as well in a while
05:10jekstrand: Kayden: I was going to just squash it in
05:14Kayden: oh, sure
05:14Kayden: feel free to keep the R-b
05:16xmnm: I just noticed I said sea islands, but they are southern islands instead
05:17xmnm: and the r9 280 behaves the same
05:17xmnm: I wonder if sea islands cards have the same problem
05:20jekstrand: Kayden: Cool. We'll see where my GLSL bug goes. If the GLSL people decide they're ok with us constant-folding noise(), I can write another patch to drop the special case.
05:50airlied: danvet: the drm-misc-next PR diffstat has mm/slob.c | 2 +
05:50airlied: and mm/slab.c
05:50airlied: I'll was going to pull it now, but I'm outta time, will dig into a bit more tomorrow, it's likely harmless noise
05:51airlied: just in case you happen across tzimmermann wondering what we are doing with it
06:00xmnm: so finally I was able to boot into radeon!, removing xf86-video-ati wasn't taking all the xorg files with it, but after removing it manually I was able to load radeonw ithout a hitch. unfortunately, the game performs the same under radeon
06:04xmnm: I'm unsure of where I should report this, I believe the problem is with radeonsi, and only some cards but I don't actually have any proof of it
06:15danvet: airlied, I think that was me
06:16danvet: airlied, fd7cb5753ef49964ea9db5121c3fc9a4ec21ed8e
06:16danvet: properly acked by akpm for merging through drm in 5.8
06:16danvet: I'll remind tzimmermann when he shows up
06:19danvet: airlied, or want a new pull summary?
07:04airlied: danvet: nah it's fine, thanks for trakcing it down
09:38pinchartl: robher: quick question about DT bindings. can the maintainers section contain mailing lists ?
09:39pinchartl: I'm thinking about a vendor that has set up a mailing list for upstream maintenance
09:54MrCooper: kusma: since you're working on documentation, can you maybe work with Brian to get https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3771 merged?
09:59kusma: MrCooper: Hmm, I haven't seen that one yet, I'm currently not working so much on the content as I'm working on mechanically converting it, though...
10:00ChrisLane: Is there a user-facing IRC channel for mesa? Hoping to get some help with performance issues.
10:00MrCooper: kusma: k, never mind, thanks for taking a look
10:01kusma: MrCooper: I'll keep an eye on it, because I might have to adjust my converter once it lands anyway ;-)
10:01kusma: MrCooper: Thanks for the heads-up :)
10:02MrCooper: ChrisLane: this channel should be OK for that
10:02ChrisLane: MrCooper: Okay thanks
10:13ChrisLane: I'm running a laptop an nvidia 860M graphics card and Arch Linux 5.6.5-arch3-1, mesa 20.0.4, Wayland 1.18.0, wlroots 0.10.0, sway 1.4.
10:13ChrisLane: Prior to switching to mesa and wayland, I ran nvidia drivers in X. As an example I'll use Minecraft for performance (the same occurs for glxgears etc.), I used to get well over 100fps and now I get ~30fps.
10:13ChrisLane: I've tried running with `vblank_mode=0 DRI_PRIME=1`, this helps a small amount.
10:13ChrisLane: Also compiling/running with the git versions of all the above (besides linux) has no effect.
10:13ChrisLane: I took a look at https://mesa3d.org/perf.html and most of the suggestions seemed like things I could not alter, though I did try `MESA_NO_DITHER`, there was no effect.
10:13ChrisLane: I'm unsure what else to try.
10:16ChrisLane: glxgears with and without DRI_PRIME, you can see it ends up having worse performance with DRI_PRIME https://gist.github.com/ChrisLane/8fdc59da76602c8ec9a7910128149ae7
10:17pq: ChrisLane, do you still have *any* bits of the NVIDIA proprietary driver installed? They won't allow you to use the GPU for rendering with Sway I believe. You'd have to use Nouveau all the way.
10:18pq: that is, the kernel driver and the Mesa (GL) driver. The concept of an Xorg driver does not exist with Wayland.
10:20pq: ChrisLane, check glxinfo. I bet it says "llvmpipe", which is a software GL renderer.
10:21ChrisLane: Nothing related to nvidia in `dmesg`. The only package installed referencing nvidia is "libvdpau", a dependency of "ffmpeg"
10:21pq: Do you have Nouveau installed then?
10:22pq: should be a kernel module as well as a Mesa component
10:22ChrisLane: No reference to llvmpipe in glxinfo
10:22pq: I don't know nvidia cards anymore, so I can't say how well nouveau supports your specific card.
10:23pq: ChrisLane, what's the "renderer string" in glxinfo?
10:25ChrisLane: nouveau kernel module is installed and loaded
10:26ChrisLane: w/o DRI_PRIME: OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 4600 (HSW GT2)
10:26ChrisLane: w DRI_PRIME: OpenGL renderer string: NV117
10:26pq: sounds like it's all good then
10:26pq: why do you think you have a problem?
10:27ChrisLane: I've been assuming it's just a lack of performant support for my card since it's fairly old
10:28pq: quite probably, but also probably not just because it's old
10:28ChrisLane: But the jump down in performance was unexpectedly large
10:29pq: you'd have to ask Nouveau people about that - maybe someone here wakes up
10:29ChrisLane: *fingers crossed
10:30pq: personally I'd be happy the card works at all, but it has been long time since I had an NVIDIA card
10:30pendingchaos: ChrisLane: with nouveau, nvidia gpus have have to be reclocked manually
10:30pendingchaos: did you do that? performance won't be as good as the nvidia driver but it's much better afaik
10:31ChrisLane: Hmm I think I read about that at some point but no, I haven't done that yet
10:31ChrisLane: Will take a look into that now
10:46tomba: danvet: I'm trying to use drmm_kzalloc() for tidss's encoder, but obviously I'm doing something wrong: https://pastebin.ubuntu.com/p/YbKwGmkTFn/ . If I read it right, the encoder is freed via drm_dev_put(), but then used in drm_mode_config_cleanup() which happens after the free.
10:48tomba: danvet: this is with drm-misc-next and your devm_drm_dev_alloc series on top. any thoughts on where I go wrong
10:48danvet: tomba, yeah that part doesn't work yet
10:49tomba: danvet: ah =)
10:49danvet: my idea for these is a combo macro/helper which allocates the containing struct with drmm
10:49danvet: and also sets up a cleanup action
10:49danvet: and drm_*_cleanup will then remove it from the list
10:50danvet: so drm_mode_config_cleanup won't hit the freed memory
10:50danvet: drm_mode_config_cleanup will still be needed for some of the other objects like if you have any leftover drm_fb or properties and stuff like that
10:52danvet: tomba, so right now all you can do is clean up any of your own stuff with drmm_
10:52danvet: but not yet anything with overlap
10:52danvet: or at least not anything with overlap with drm_mode_config_cleanup
10:53danvet: tomba, I think we'll also need a drmm_kzalloc where you can supply the cleanup callback
10:53danvet: to avoid a bit too much silly allocations
10:55tomba: danvet: is the HW supposed to be accessible even after the standard devm_* cleanup has been done? I guess not, everything should be disabled already at that point, right?
10:55danvet: devm_ is for cleaning up hw
10:55danvet: drmm_ for cleaning up the software/interface side of things
10:56danvet: that's at least the idea
10:56danvet: mmap() atm unsolved, I'm just pretending that doesn't exist :-/
10:56tomba: danvet: ok... then I guess tidss doesn't have any "own stuff" to be handled
10:56danvet: yeah that's more for rendering drivers with exported dma_fence or dma_buf
10:56danvet: or lots of other fun stuff
10:57danvet: althought the refcounting for dma_fence/buf isn't fixed yet
11:18ChrisLane: pendingchaos: With glxgears I can reclock all the way up to the highest setting for the best performance. With Minecraft, anything other than the lowest(original) setting makes the system hang, I switch to another tty and attempt a reboot and then get a kernel panic.
11:18ChrisLane: So no luck there :/
11:20ChrisLane: Highest clock for gpu still didn't beat intel on glxgears though O_o
11:22imirkin: glxgears on a remote gpu is largely a measure of pci-e speed
11:22imirkin: (or of vsync rate, depending on whether you're syncing to vblank or not)
11:31pq: ChrisLane, IOW, glxgears rarely measures what you are actually interested in.
11:32ChrisLane: Demonstrated the correct effects that I'd expect from bumping the clock speeds at least
11:32ickle: unless you are interested in how fast can you push a buffer through the system
11:33ChrisLane: Even still, clocks screwed up my system running something more taxing
11:51imirkin: ChrisLane: increasing pstate tends to bump up pcie speed =]
11:51imirkin: you can check this with lspci
11:51imirkin: it'll go from a 2.5GT/s link to 8.0GT/s
11:51imirkin: (more T/s = more glxgears frames!)
11:52imirkin: (look under "LnkSta" for the current value)
11:55malice: imirkin: How many -v's do I have to pass to get this?
11:55imirkin: 2, i think
11:55malice: 87818 frames in 5.0 seconds = 17563.439 FPS
11:55imirkin: malice: lspci -vv -d 10de:
11:55imirkin: have to be root
11:55imirkin: (or run it as root)
11:55malice: Ah root
11:56imirkin: for example: https://hastebin.com/gakeqitesa.cs
11:56imirkin: you can see that it's capable of 8GT/s, but only currently at 2.5GT/s
11:56imirkin: due to the high level of awesomeness of my motherboard
11:58imirkin: the pcie speeds are specified as part of the pstate, so depending on the actual board, it may or may not happen
11:58imirkin: however i think it's quite common for laptops
12:12baedert: Hey, https://gitlab.gnome.org/GNOME/gtk/-/issues/2646 this looks like a problem inside mesa, has anyone seem something similar before?
12:14imirkin: doesn't ring a bell
12:15imirkin: baedert: is it easy to run just the one test?
12:16baedert: imirkin: Yes, but I can't reproduce, I'd have to ask the reporter
12:16imirkin: oh goodie.
12:26malice: Does anyone else sometimes randomly see some random horizontal lines?
12:28ccr: it's just the reality matrix glitching .. oh, you mean on a monitor?
12:30imirkin: as an aside, The Matrix came out in 1999 - 21 years ago.
12:31MrCooper: yeah, blew my mind when we watched it again last year
12:43malice: ccr: Yeah, monitor
12:56Moiman: malice: tearing?
12:57malice: Moiman: No, short white horizontal line on my terminal, black background
12:57malice: But I've seen it on firefox too, and on multiple gpus, even quite old ones
12:57malice: In entirely different hw setups
12:57malice: Including monitor
13:00imirkin: the only common factor is you? :)
13:00imirkin: i start liking ccr's explanation...
13:05malice: Really? Noone else seen it? Hmm
13:14robher: pinchartl: I suppose your case would be ok. I just don't want to see maillists which are covered by the directory location.
14:08ccr: malice, nothing that I've ever seen brings to mind a "short white line". I've seen things, though .. CGA "update noise", rendering bugs, and a loose DVI-cable causing some rather interesting "pixel noise".
14:19malice: ccr: Well, it might be gray or multiple shades of gray, not 100% sure, but it's always horizontal
14:20danvet: tzimmermann, https://paste.debian.net/1141851/ does this look correct?
14:20danvet: just checked, void* pointer arithmetic is indeed a gcc extension
14:21tzimmermann: danvet, it looks correct, but it's ugly code :)
14:21danvet: well you asked for it
14:22tzimmermann: danvet, :D
14:22tzimmermann: i think you should just keep the patch as-is
14:22danvet: tzimmermann, or just the ddev_ prefix?
14:23danvet: or want to do that yourself?
14:23tzimmermann: danvet, if you want to change something, than maybe the ddev_
14:23danvet: I'm not enthusiastic, since I might typo so better to let CI check it again
14:23danvet: so that would mean merging earlieast tomorrow
14:23danvet: or I could just start applying
14:24tzimmermann: if we really care, we should have a bikeshedding session on dri-devel on how to name the drm_device variables
14:24danvet: anyway quick compile check of the diff looked ok, so right now is the time to stop the git rebase fun
14:25danvet: hm I think I'll do the grocery run now, then I'll either send out a respin or start applying
14:25tzimmermann: whatever you prefer
14:26tzimmermann: danvet, BTW sorry about missing the changes to core mm on the PR
14:26danvet: no worries on that
14:26danvet: dim script should dump the diffstat somewhere, that helps with stuff like that
14:26danvet: but generally it's huge
14:27danvet: maybe we should have a filter for "stuff not maintained in drm.git" so it sticks out more
14:27danvet: maybe even pre-fill that in the template
14:27danvet: e.g. "following patches touch code outside of drm.git:" + list of oneline commit summaries
14:28tzimmermann: danvet, hmm. could be helpful.
14:28tzimmermann: it showed me a gitk window of all patches. i could have seen the information there
14:29danvet: only issue is that we're adding new stuff to drm.git (outside of drivers/gpu) so this is a bit tricky
14:29danvet: either outdated or I have no idea how to program with just looking at MAINTAINERS
14:30tzimmermann: one question but dim tooling: is there a way of aborting the pull-request command at any stage?
14:30danvet: and some of these additions are tricky, e.g. fbdev is in drm-misc
14:30danvet: but not all in drivers/video is fbdev
14:30danvet: hit ^C?
14:31danvet: or run it with --dry-run
14:31tzimmermann: danvet, ok. it's that easy.
14:31danvet: but it's not perfectly idempotent
14:31danvet: since a lot fewer people use it, the maintainer tools are definitely a lot less polished :-/
14:31tzimmermann: i was worried that ^C only aborts the current step, but the overall script keeps running
14:32danvet: tzimmermann, so for the programmatic check for "outside stuff" I think you'll need
14:33danvet: collect the directory/file entries of all MAINTAINERS entries that point at drm-misc.git
14:33danvet: if a patch is entirely contained within these, it's good
14:33danvet: if something sticks out, it must be annotated
14:33danvet: (or maybe we should add a new entry)
14:33danvet: but that's a bit a thing to type up
14:34danvet: has the upshot though that it should also work for drm-intel
14:34danvet: and so would make j4ni happy I think
14:39tzimmermann: so it's 1) grep MAINTAINERS for drm paths, 2) match each patch against that list 3) filter out those patches that touch additional files
15:04ElBarto: eric_engestrom: xexaxo1: thanks for your reviews, I think everything should be good now
15:16Putti: malice, I saw an youtube video titled "worst graphics card ever" or something like that which was built on a bread board and there was similar issue. The cause was (as far as I recall) that the bread board connector acted as a capacitor meaning it charged some electricity in itself, and since the pixel data is sent as a voltage spike that occur every few nanoseconds the extra capacitance caused by the "massive" amount of metal in the
15:16Putti: bread board connector caused missing some of the pixels because the voltage wouldn't change fast enough. The video has better explanation of this.
15:16Putti: malice, so given this have you tried another cable?
15:16Putti: a shorter one maybe
15:16imirkin: he said he's seen this across hw setups and monitors
15:17imirkin: but all with the same cable? heh.
15:17Putti: maybe also some big magnet in the environment could cause this
15:17imirkin: i expect computers don't work too well inside an MRI machine...
15:20malice: Putti: Seen this on vga too, currently displayport
15:20malice: Also hdmi
15:21Putti: malice, okay but separeta cables? there are converters for those..
15:21malice: There's actually like not a single common component between all these systems left
15:21malice: Except maybe my wooden table
15:21malice: It's really not a big thing, it only lasts like one frame or something, and fairly rare, was just wondering if anyone else has had that
15:22Putti: I don't remember ever seeing that
15:22malice: As I've had it with two separate igpus and an rvii :P
15:22Putti: malice, and different PSU?
15:22imirkin: malice: except the MRI machine this is all happening inside? :)
15:22malice: imirkin: Well, that too :D
15:26imirkin: malice: back in the VGA days, could you see 60hz monitors blink?
15:26imirkin: (rather, in the CRT days)
15:27malice: imirkin: Idk, I was a kid back then :P
15:27imirkin: 60hz monitors gave me a headache pretty swiftly ... had to go to 85hz
15:27imirkin: anyways, maybe you just have very fast eye reaction times or something
15:28Putti: malice, also picked up from the video: all white pixel means voltage occuring so still thinking maybe some external interference from the environment.
15:28Putti: that is with vga
15:28malice: imirkin: Reacting to what tho? It's a flat color, and a random few white pixels horizontally
15:28imirkin: i don't have a great theory
15:28malice: Gotta be at least a full frame probs :P
15:28Putti: malice, are they in the same horizontal line?
15:29malice: Putti: I'm not sure if same spot, but it looks quite similar usually
15:29malice: But it's really quick, don't have time to examine
15:30Putti: haha, okay. This would be a fun mystery to solve.
15:30malice: But it's really quite rare
15:30malice: I notice this maybe like once a week or so
15:30imirkin: do you see it in non-monitors?
15:30malice: Might occur more often, but yeah
15:31malice: imirkin: Never noticed at least
15:31imirkin: there's gunk that's usually settled at the bottom of the eye, but in various conditions it can float around
15:31imirkin: which causes "shooting stars" to appear
15:31malice: Haven't seen that, but these lines are always horizontal on my monitor
15:31malice: And like one pixel high
15:34malice: I'm not sure I've seen it on windows, I have a vague memory that I may have, but can't be 100% sure
15:34malice: If I have, then it's probably unlikely to be a software issue?
15:35malice: But I mean
15:35malice: Windows is always artifacting and crashing and blackscreening and rebooting
15:38ccr: anti-midas touch? :P
15:40imirkin: there's a great quote in "Inside Llewyn Davis" about that...
15:40malice: Yes, everything I touch breaks
15:40Putti: malice, https://askubuntu.com/questions/258899/random-white-pixels-on-screen well other people have this too
15:41Putti: maybe not exactly the same you have?
15:41imirkin: something along the liens of "you're like king midas's idiot brother, everything you touch turns to shit"
15:41malice: Putti: This looks like a different, far worse issue
15:41malice: imirkin: Haha :D
15:41imirkin: [it's a really good movie, if you haven't seen it]
15:42imirkin: [quite sad, imo, but really good]
15:43Putti: malice, one more question: has this happened ever on a brand new display?
15:43malice: Putti: Yes
15:43Putti: maybe like 1-2 weeks old
15:43malice: Idk, pretty new, but idk if it happened right when I got it
15:43Putti: maybe all hardware die eventually
15:43malice: The other one was from 2006 tho
15:45malice: Btw, noone here has anything to do with amd windows drivers, right?
15:47malice: Eh, I'd imagine not
16:06xmnm: hello, I'd like to know if there's some way to determine what's causing low performance in a game, to open a bug report to keep track of the issue, I think that the problem might be radeonsi, but don't really have anything to back me up. Exanima, the game, plays at 12fps while cpu usage remains %10, gpu 3%, and there's low ram and vram usage. I saw this happen in my computer with an amd hd 7770 (southern islands), asked a friend to
16:06xmnm: test and he didn't have the issue on an rx 580, but had it with his r9 270 and r9 280 (both southern islands cards), this is the only things I really have to go by, I don't know what to try to get useful information
16:15imirkin: xmnm: probably #radeon is a good start. you can also file a bug at gitlab.freedesktop.org/mesa/mesa
16:16xmnm: the thing is I'm not sure what part of the stack is having problems so I didn't want to move before being relatively sure
16:17xmnm: but I will ask again on radeon, thank you
16:17MrCooper: we can always move the issue as needed, but Mesa is the most likely
16:20xmnm: whenever gitlab decides to finish loading I'll look int creating an account
16:21MrCooper: you can log in with credentials from a number of other services FWIW
16:22xmnm: but it still needs to load first, life on 2g isn't a fast life
16:23imirkin: yeah, gitlab is extremely heavy unfortunately
16:23imirkin: i can barely use it on my desktop
16:25xmnm: well, carrier isn't collaborating with me, I'll have to retry later
16:29imirkin: xmnm: i hear gigabit is nice :)
16:29imirkin: i guess not too common in .ve though =/
16:31zf: I suspect we don't actually need to flip, but I'll have to check that
16:31zf: whoops, wrong channel
16:31xexaxo1: ElBarto: sorry to bother you again - gitlab seems unhappy "Fast-forward merge is not possible. Rebase the source branch onto master to allow this merge request to be merged." can you please see my comment and rebase
16:32xmnm: imirkin, you'd be very lucky to even have 10 megabit down
16:32xmnm: and I'd be very lucky to have my broadband connection fixed after 3 months of nothing
16:33imirkin: yeah, it was a tongue in cheek comment before i looked up where you were coming from
16:33xmnm: I don't mind at all
16:33xmnm: don't worry
16:34imirkin: i don't know too much about the situation there, but i know it's not great, and the current COVID-19 situation couldn't have improved matters
16:34xmnm: I wouldn't be surprised if we were the only country that got more expensive gas after covid
16:35imirkin: not what one might expect from a gas exporter...
16:35xmnm: that's what gas shortage does to you, but I guess I should end this off-topic conversation!
16:39ElBarto: xexaxo1: yeah I'm on it
16:46dcbaker: I noticed since I got back from vacation I have to manually trigger all cI jobs in mesa, is this expected or is something wrong with my setup?
16:47ElBarto: ElBarto: hope my comment anwser your question (and the next one)
16:47ElBarto: xexaxo1: ^
16:47imirkin: dcbaker: expected
16:47imirkin: someone changed it semi-recently to avoid unnecessary runs
16:48hakzsam: dcbaker: it's mostly for reducing bandwidth and then save money
16:49hakzsam: only Marge automatically launches pipelines now
17:06dcbaker: ah, that makes sense
17:11MrCooper: I posted about it to mesa-dev, but I guess you missed that due to being away
17:22Lyude: if I had two patches for drm-misc, the first of which is a small fix with a Cc for firstname.lastname@example.org, and the second of which isn't a fix and just does some cleanup (but probably won't apply without the first patch), how should I push them to drm-misc? should they both go to drm-misc-fixes or something else?
18:21krh: Kayden: yeah +1 to load/store_reg
18:30pinchartl: robher: thanks a lot for the quick dt schema check fix, very appreciated
18:31robher: pinchartl: np!
18:33pinchartl: robher: how painful do you think it would be to convert graph.txt to yaml ?
18:34pinchartl: I've briefly talked to mripard about it, and we're both scared :-)
18:36robher: pinchartl: Probably the worst part is handling with and without unit-addresses
18:37pinchartl: is the fact that the ports node is optional a big issue too ?
18:38robher: pinchartl: yeah, just another combination...
18:39robher: pinchartl: I've not worried about it too much as dtc already checks much of what a schema would.
18:40robher: pinchartl: what we really need is a meta-schema for what device schemas need to define or not define.
18:41pinchartl:needs to look into what meta-schemas are used for
18:41robher: pinchartl: device schemas shouldn't need to worry about #address-cells or #size-cells for example.
18:41robher: pinchartl: the schema for the schema. :)
18:43robher: pinchartl: they're 'fun' because the json-schema vocabulary are also the properties.
18:44pinchartl: so the meta-schema will make sure that no yaml bindings file handle #address-cells in the ports node, while #address-cells will be validated by the graph.yaml schema ?
19:05robher: pinchartl: right.
19:15emersion: vsyrjala: do you have plans to resurect https://lists.freedesktop.org/archives/dri-devel/2019-June/221902.html ?
19:16emersion: vsyrjala: one of our users is hitting a bug of not being able to configure their screen independently, which both have the same serial and an unstable connector ID (it's a dock)
19:16emersion: vsyrjala: https://github.com/swaywm/sway/issues/5226
19:17gitbot: swaywm issue 5226 in sway "Multi Monitor setup - same ID and Serial?" [Open]
19:18emersion: as always, i can provide user-space for this
19:29vsyrjala: no plans atm
19:55Lyude: :(, seanpaul - I think we need to consider either reverting 6bb0942e8f46 ("drm/dp_mst: Remove single tx msg restriction.") or only activating multi-tx conditionally based on dp quirks
19:56Lyude: I just noticed that it completely breaks the lenovo USB-C MST hub I've got here
19:56Lyude: that + amd's experience with multi-tx breaking things + the DP 2.0 spec saying not to use multi-tx
19:57Lyude: tbh though, the problem with activating it via quirk i'd imagine is that we can't use multi-tx if anything in the path down to a mstb doesn't support it
19:59Lyude: also, yikes, why does this hub send RSNs after every payload allocation o.O
20:04anholt_: seeing a bunch of timeouts from collabora lava right now
20:04anholt_: tomeu, daniels ^
20:15daniels: anholt_: eating dinner but will look after. can you link me to a job quickly please?
20:17hakzsam: yes, got some CI failures
22:26Gongjin: Is anyone here familar with wifi drivers?
22:26Gongjin: I am attempting to connect tothe internet via a ethernet cable on an intel ethernet device and it is not detecting the cable connection.
22:27anholt_: this is a channel for graphics.
22:27kisak: Hello Gongjin, this channel is primarily a graphics-oriented channel, you might have some luck over at #linux-wireless
22:28Gongjin: Ah thanks kisak.
22:30daniels: anholt_: sorry to have not got back to you. if it's still having issues - caused by physical link problems with our office we can't resolve from home - please just merge an immediate disable with my A-b
22:30anholt_: seems to have quieted down this afternoon
22:31daniels: cool. we're trying to change fibre provider, but kind of tough rn
23:04airlied: karolherbst: so what's needed to land the structirzer? review, is anyone signed up?
23:04airlied: I don't think it should just live in a branch if it's not changing
23:05Lyude:realizes we might be missing a bunch of basic retraining for mst ._.
23:13karolherbst: airlied: reviews, yes
23:14karolherbst: airlied: It seems that everybody agrees it's working as expected though
23:15karolherbst: maybe we can start with the vtn changes I made and get this at least done arleady
23:15karolherbst: and then we can clean up the pass together or so
23:15karolherbst: the original author doesn't seem to be around anymore, which is quite sad
23:17karolherbst: airlied: uhh.. I see I don't have the actual newest version for odd reasons, but I think only comments were added
23:17karolherbst: will look into it tomorrow then
23:18airlied: karolherbst: I assume review is just asking jekstrand a lot :-P
23:18karolherbst: mhh, seems like there are some functional changes as well
23:19karolherbst: anyway, I'll deal with that tomrrow
23:19karolherbst: jekstrand: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2401
23:19jekstrand: Oh, that....
23:19karolherbst: no point into looking into the pass yet as I still need to update it to the latest version...
23:19karolherbst: shouldn't be much though
23:21karolherbst: heh.. I have an idea..
23:25karolherbst: jekstrand: the code should contain a lot more comments though, so hopefully it's much easier to follow... but I guess revieweing that with no knowledge on what's actually going on there will be challanging
23:25karolherbst: we just ack it
23:25karolherbst: the pass I mean, the rest we can properly review
23:25karolherbst: but the pass itself won't break stuff... so
23:26jekstrand: I don't know that I like just ACKing a control-flow structurization pass....
23:26karolherbst: but only clover would use it
23:27karolherbst: anyway, I would also prefer a proper review
23:27airlied: and clover is currently useless without it :-P
23:27karolherbst: I just think it might get super hard to convince somebody to do it
23:28karolherbst: and my knowledge about structurizing is basically knowledge I got from my "oh, let me try this, it might work.. oh it broke" approach
23:28karolherbst: luckily the other patches are wy easier to understand I hope
23:30karolherbst: airlied: I have an idea, we can convince the others who need this as well to do that for us :p
23:30karolherbst: they are equally guilty of procrastination, just that I got lucky to get pinged about a proper one :D