sghuge has quit [Remote host closed the connection]
mehdi-djait3397165695212282475 has joined #dri-devel
sghuge has joined #dri-devel
tomba has quit [Quit: ZNC 1.9.0+deb2build3 - https://znc.in]
tomba has joined #dri-devel
phasta has joined #dri-devel
bolson has quit [Ping timeout: 480 seconds]
vliaskov_ has joined #dri-devel
vliaskov__ has joined #dri-devel
vliaskov_ has quit [Ping timeout: 480 seconds]
<tursulin>
sima: Thanks, I'll have a look. Wrt unit tests they start with basic for now so we get something for start.
lynxeye has joined #dri-devel
<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.
<pq>
otherwise new thread replies are not found if they don't already match the search
<pq>
sima, thanks!
jkrzyszt has joined #dri-devel
siak_ has joined #dri-devel
siak has quit [Remote host closed the connection]
siak_ has quit [Read error: Connection reset by peer]
siak has joined #dri-devel
Surkow|laptop has quit [Ping timeout: 480 seconds]
danilo has joined #dri-devel
dakr has quit [Read error: Connection reset by peer]
Surkow|laptop has joined #dri-devel
<pepp>
sima, stsquad: yup, looks interesting
<pepp>
btw I'll send a v8 of the drm sched events series after discussing it with tursulin
odrling has quit [Remote host closed the connection]
<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
azerov has joined #dri-devel
rasterman has joined #dri-devel
hansg has joined #dri-devel
KAL9000 has quit [Ping timeout: 480 seconds]
Guest9443 has quit [Read error: Connection reset by peer]
fab has joined #dri-devel
phasta_ has joined #dri-devel
phasta__ has joined #dri-devel
phasta has quit [Read error: Connection reset by peer]
phasta_ has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
rcf has quit [Quit: WeeChat 4.4.2]
<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
<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
<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
<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)
<javierm>
tzimmermann: a "panel" is subjective too I would say
<tzimmermann>
i think so
<tzimmermann>
but why isn't ssd130x a DRM panel driver?
<javierm>
a bridge is more concrete, the SSD2825 discussed is a RGB -> MIPI DSI bridge
<javierm>
tzimmermann: in the Sitronix case, there are 3 ST* panel drivers and 2 ST* drivers in tiny
<tzimmermann>
i don't understand any of this either; don't ask me :)
<javierm>
in the panel I got, there are st7567 I2C and SPI variants so it make sense to also split in 3 files
<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
<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)
<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
<tzimmermann>
but i really don't have a good answer to this
<javierm>
tzimmermann: probably then will go with a drivers/gpu/drm/sitronix/ for this driver
<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
<sima>
but that only really makes sense if you reuse the same panel driver somewhere else behind a "real" bridge or "real" display driver
<sima>
iirc we've talked about this way back when tiny landed and just shrugged
<sima>
I'd start worrying if it makes sense to share code and not before
Kayden has quit [Quit: Leaving]
Kayden has joined #dri-devel
tango_ has quit [Ping timeout: 480 seconds]
u-amarsh04 has joined #dri-devel
tango_ has joined #dri-devel
airlied_ has joined #dri-devel
dolphin has quit [Quit: Leaving]
airlied has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: brb]
<mlankhorst>
sima: push dmemcg fixes through drm-misc-fixes?
pcercuei has joined #dri-devel
airlied has joined #dri-devel
airlied_ has quit [Ping timeout: 480 seconds]
mehdi-djait3397165695212282475 has joined #dri-devel
<sima>
mlankhorst, I'd expect tejun to pick those up?
<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)
<javierm>
tiny doesn't really have a meaning and there could be panel or bridge drivers that are also implemented as a single file
epoch101 has joined #dri-devel
<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
croissant has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
ADS_Sr has quit [Remote host closed the connection]
<sima>
javierm, yeah tiny is just small single-file drm_device drivers
<sima>
since panel and bridge are somewhere else
fomys has quit []
fab has quit [Quit: fab]
alyssa has left #dri-devel [#dri-devel]
fab has joined #dri-devel
fab is now known as Guest9453
haaninjo has joined #dri-devel
hansg has joined #dri-devel
vedm_ is now known as vedm
mehdi-djait3397165695212282475 has quit [Ping timeout: 480 seconds]
bolson has joined #dri-devel
Guest9453 has quit [Ping timeout: 480 seconds]
croissant has joined #dri-devel
hansg has quit [Ping timeout: 480 seconds]
alyssa has joined #dri-devel
<alyssa>
sima: airlied: btw, what's the merge criteria for drm-fourcc's?
<alyssa>
specifically for modifiers that are imported/exported across userspace processes, but not otherwise handled by the kernel in any way
<alyssa>
(and don't imply any kernel code except reserving the #define itself)
<daniels>
alyssa: it's ... more lax than I originally thought
<daniels>
I believe an OSS user is no longer mandatory, just a description which is at least as good as those around it
<alyssa>
daniels: ..in a good way or a bad way?
<alyssa>
fair enough
<alyssa>
(an OSS user is easy, an in-tree upstream user is.. not)
<daniels>
riic?
<alyssa>
I'd be lying if I said I wasn't considering it
<daniels>
:(
<alyssa>
I don't think anybody wants that though
croissant has quit [Read error: Connection reset by peer]
croissant has joined #dri-devel
gfxstrand has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
<sima>
alyssa, daniels it should be documented even what exactly is needed, iirc ack by all relevant stakeholders
<sima>
meaning both mesa and proprietary vendor team, if both exists and care
<sima>
but explicitly no open source user
<sima>
for modifiers
<sima>
for fourcc it's just "reasonable good consensus among interested people"
<sima>
since some are specific for video or display