01:18 zf: oh shoot, that part is user error >_>
08:47 tursulin: sima: Thanks, I'll have a look. Wrt unit tests they start with basic for now so we get something for start.
09:21 pq: emersion, when doing 'lei up', in order to get new replies to an old thread, one must use --remote-fudge-time=4.weeks or whatever to get the "fetch whole thread" feature working.
09:22 pq: otherwise new thread replies are not found if they don't already match the search
09:28 pq: sima, thanks!
10:04 pepp: sima, stsquad: yup, looks interesting
10:04 pepp: btw I'll send a v8 of the drm sched events series after discussing it with tursulin
11:17 dolphin: Should we rewrite dim tool in Rust? /me hides
11:18 dolphin: First instinct on contributing an improvement is that it is a controlled chaos currently
11:53 emersion: i don't think rust is the right tool for this job
12:03 karolherbst: what kind of bindings does git currently support? python? Though there is a git module anyway, so maybe python would make sense?
12:05 dolphin: on semi serious note, I find Rust is a good fit for command line tools these days
12:06 dolphin: https://github.com/rust-lang/git2-rs/tree/master/examples
12:13 javierm: dolphin: same for me, lately I've been using rust to write CLI tools than in the past I would probably had done with python
13:22 javierm: tzimmermann: your question brought something that I was pondering about myself too. I don't think there's a convention on where drivers should be and it can make things quite confusing
13:22 DragoonAethis: dolphin: semi-same, it's nice until you get to the point where adding one more feature requires you to refactor for the borrow checker :P
13:23 tzimmermann: javierm, bridges go into bridge/, panels go into panel/, single-file drivers go into tiny/, the rest goes into a subdirectory. but you're right; the convention is fuzzy
13:23 javierm: tzimmermann: for example, I got a Sitronix st7567 LCD and wrote a driver for it, but we already have a few Sitronix drivers (for other chips from the same vendor)
13:24 javierm: tzimmermann: a "panel" is subjective too I would say
13:24 tzimmermann: i think so
13:24 tzimmermann: but why isn't ssd130x a DRM panel driver?
13:25 javierm: a bridge is more concrete, the SSD2825 discussed is a RGB -> MIPI DSI bridge
13:25 javierm: tzimmermann: in the Sitronix case, there are 3 ST* panel drivers and 2 ST* drivers in tiny
13:25 tzimmermann: i don't understand any of this either; don't ask me :)
13:25 javierm: in the panel I got, there are st7567 I2C and SPI variants so it make sense to also split in 3 files
13:26 javierm: so I could add a drivers/gpu/drm/sitronix/ sub-dir, but then we will have 5 drivers in other places for the same vendor
13:27 javierm: tzimmermann: just mentioning all this because you brought this topic in the ssd2835 patch-set thread and is something I asked myself this weekend :) (while working on the st7567 driver)
13:29 tzimmermann: there is "struct drm_bridge" and "struct drm_panel". drivers built upon these go into the respective directory. for multi-file drivers, you can add a new directory. you also move the existing st* drivers into your new directory. but if they don't share any code, there's little use
13:31 tzimmermann: but i really don't have a good answer to this
13:33 javierm: tzimmermann: probably then will go with a drivers/gpu/drm/sitronix/ for this driver
13:33 tzimmermann: there's always 'git mv' :)
13:48 javierm: tzimmermann: right :)
14:12 sima: javierm, tzimmermann I think some of the tiny drivers maybe should be panel drivers and some glue to make them standalone drivers if they're just sitting on an i2c/spi bus and nothing else
14:13 sima: but that only really makes sense if you reuse the same panel driver somewhere else behind a "real" bridge or "real" display driver
14:13 sima: iirc we've talked about this way back when tiny landed and just shrugged
14:14 sima: I'd start worrying if it makes sense to share code and not before
14:39 mlankhorst: sima: push dmemcg fixes through drm-misc-fixes?
14:49 sima: mlankhorst, I'd expect tejun to pick those up?
14:51 javierm: sima: IMO tiny drivers should be moved to per-vendor sub-dirs (either in drivers/gpu/, drivers/gpu/drm/panel/ or drivers/gpu/drm/bridge)
14:51 javierm: tiny doesn't really have a meaning and there could be panel or bridge drivers that are also implemented as a single file
14:52 javierm: sima, tzimmermann: I think that tiny started as "drivers that use the simple KMS pipeline" but we are even moving out of that and just use the atomic helpers instead
15:01 sima: javierm, yeah tiny is just small single-file drm_device drivers
15:01 sima: since panel and bridge are somewhere else
15:27 alyssa: sima: airlied: btw, what's the merge criteria for drm-fourcc's?
15:27 alyssa: specifically for modifiers that are imported/exported across userspace processes, but not otherwise handled by the kernel in any way
15:27 alyssa: (and don't imply any kernel code except reserving the #define itself)
15:28 daniels: alyssa: it's ... more lax than I originally thought
15:29 daniels: I believe an OSS user is no longer mandatory, just a description which is at least as good as those around it
15:29 alyssa: daniels: ..in a good way or a bad way?
15:29 alyssa: fair enough
15:29 alyssa: (an OSS user is easy, an in-tree upstream user is.. not)
15:32 daniels: riic?
15:33 alyssa: I'd be lying if I said I wasn't considering it
15:33 daniels: :(
15:34 alyssa: I don't think anybody wants that though
15:46 sima: alyssa, daniels it should be documented even what exactly is needed, iirc ack by all relevant stakeholders
15:47 sima: meaning both mesa and proprietary vendor team, if both exists and care
15:47 sima: but explicitly no open source user
15:47 sima: for modifiers
15:47 sima: for fourcc it's just "reasonable good consensus among interested people"
15:47 sima: since some are specific for video or display
15:50 sima: https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#open-source-user-waiver
16:05 alyssa: gotcha thanks
16:40 agd5f: can someone with admin rights for drm-misc take a look at this: https://gitlab.freedesktop.org/drm/misc/kernel/-/issues/60
16:42 agd5f: sima, daniels ^^^
16:57 mripard: agd5f: done
16:57 agd5f: mripard, thanks!
17:00 mripard: sorry for the delay
20:18 Lyude: <kendrafreakon> Lyude: would someone want to improve the GUD of mesa, have you got enough experience to do that your own? ← ?
20:20 Lyude: lumag: btw, about to go over your DP patches. Sorry it took a bit, had to deal with some family stuff yesterday
21:02 mlankhorst: sima: looks like we have to put it through the drm tree :)