ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<alyssa>
so maybe texwrap doesn't test what I think it does.
pallavim has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
frankbinns1 has quit [Remote host closed the connection]
psykose has quit [Remote host closed the connection]
psykose has joined #dri-devel
pallavim has joined #dri-devel
psykose_ has joined #dri-devel
psykose has quit [Ping timeout: 480 seconds]
agd5f has quit [Read error: Connection reset by peer]
pcercuei has quit [Quit: dodo]
ybogdano has joined #dri-devel
dfip^ has joined #dri-devel
elongbug has quit [Read error: Connection reset by peer]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
RhineDevil has quit [Remote host closed the connection]
RhineDevil has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
aravind has joined #dri-devel
Danct12 has joined #dri-devel
kimbro has joined #dri-devel
kimbro has quit []
Nyaa has joined #dri-devel
<Nyaa>
the big endian girl has been summoned lol
<Danct12>
hi big endian
<Danct12>
where's little endian, did you invite them?
<Nyaa>
lol
bmodem has joined #dri-devel
RhineDevil^ has joined #dri-devel
RhineDevil has quit [Ping timeout: 480 seconds]
pallavim has quit [Ping timeout: 480 seconds]
dfip^ has quit [Remote host closed the connection]
pallavim has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
pallavim has quit [Ping timeout: 480 seconds]
Danct12 has quit [Remote host closed the connection]
Company has quit [Quit: Leaving]
jewins has quit [Ping timeout: 480 seconds]
rmckeever has joined #dri-devel
flibit has quit []
flibitijibibo has joined #dri-devel
tzimmermann has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
bgs has joined #dri-devel
Sachiel has quit [Read error: No route to host]
kts has joined #dri-devel
bgs has quit [Remote host closed the connection]
Sachiel has joined #dri-devel
djbw has quit [Read error: Connection reset by peer]
Danct12 has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
fab has quit [Quit: fab]
danvet has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
djbw has joined #dri-devel
Major_Biscuit has joined #dri-devel
rgallaispou has joined #dri-devel
tursulin has joined #dri-devel
sgruszka has joined #dri-devel
RhineDevil^ has quit [Remote host closed the connection]
RhineDevil^ has joined #dri-devel
<tzimmermann>
danvet, your fbdev proposal is what i had in mind, sort of
<danvet>
ah I guess then we just talked past each another yesterday, it happens :-/
<tzimmermann>
we interpret the prefered_bpp parameter not as raw bpp, but as color-mode value similar to video=
<tzimmermann>
yeah
<tzimmermann>
i'll make a patchset and test a bit
fab has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
frytaped has joined #dri-devel
agd5f has joined #dri-devel
frytaped has quit [Quit: WeeChat 3.6]
lynxeye has joined #dri-devel
Danct12 has joined #dri-devel
sarahwalker has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest431
dcz_ has joined #dri-devel
rasterman has joined #dri-devel
sarahwalker has quit [Ping timeout: 480 seconds]
mvlad has joined #dri-devel
<danvet>
tzimmermann, I just noticed that there's a bunch of drivers with preferred_depth = 32
* danvet
sighs
<tzimmermann>
yeah. that makes no sense unless they what argb8888
<tzimmermann>
danvet, are you on the latest drm-tip?
<tzimmermann>
because i cleaned that up IIRC
<tzimmermann>
it was in the recent patchset that caused the current troubles
<tzimmermann>
logicvc legitimatelly set 32 bit. the others not su much
<Lynne>
grr, the whole **point** of the vulkan API is flexibility
<Lynne>
yet the video API is horridly limiting because it wants to know which codecs, right down to the profile and level, an image would be used
<danvet>
6f9f15e63de607ffbe621d33e8c8d49481e1e845 <- this really should be in fbdev code :-)
<tzimmermann>
danvet, the problem is that bpp==24 is legitimate if you want rgb888
<danvet>
yeah I know, we need mode_config.preferred_format
<danvet>
but also need a stopgap for the regression, since this broke a ton of drivers
<tzimmermann>
let me get my patchset done and discuss there. i'm having trouble following and getting things done
<danvet>
I'm out this lunch/afternoon
<tzimmermann>
danvet, i'll send out an RFC patch now, so that you can comment
Danct12 has quit [Remote host closed the connection]
Sachiel_ has joined #dri-devel
<tzimmermann>
sent
Sachiel has quit [Ping timeout: 480 seconds]
<danvet>
tzimmermann, I'm confused ... we need a minimal regression fix
<danvet>
because afaics you've broken every single driver that doesn't set mode_config.preferred_depth
<danvet>
and we need to fix that asap with the most minimal patch
<danvet>
not more refactoring and rfc, that stuff is for later
<tzimmermann>
in that case, set XRGB8888 unconditionally
<tzimmermann>
let me try to minimize
<danvet>
adding yet another slightly funny way to select formats doesn't sound like a good short term fix, because it'll probably change/break something else
dviola has joined #dri-devel
<danvet>
imo there's two options a) revert, start over by sorting the color mess first b) most minimal fix (the thing I sketched is probably close)
<danvet>
anything that tries to sort out this mess for real is probably way too much
<danvet>
for the regression fix
<danvet>
because atm more than half the kms drivers we have look like they're broken
<danvet>
(all the drivers which don't set mode_config.preferred_depth)
<danvet>
and we need a minimal fix for just that
<tzimmermann>
the RFC patch i send out fixes this problem already.
<tzimmermann>
it does not rely in preferred_depth any longer
<tzimmermann>
i can try to minimize the amont of changes
<tzimmermann>
but i think, it is what we want
<tzimmermann>
and it still works with the odd cases of 16/15 and 32/24
<danvet>
imo the long term direction should be drm_fourcc for all internal interfaces
<danvet>
so both preferred_bpp for fbdev and for mode_config.preferred_depth
<danvet>
anything else is just not wellspecificied enough
<danvet>
also xrgb8888 default needs to take host byte order hack into account probably
<danvet>
so this is all really tricky and needs care imo, and way too much for a regression fix
<danvet>
plus you don't handle vc4 correctly
Didgy has quit [Quit: Connection closed for inactivity]
<tzimmermann>
for host-byte order. can we use FORMAT_HOST_XRGB8888 unconditionally?
<tzimmermann>
danvet ^
<tzimmermann>
or does it need that flag thing
<danvet>
drm_driver_legacy_fb_format()
<tzimmermann>
make sense
<danvet>
I think it needs the flag thing
<danvet>
not sure
<tzimmermann>
and why does not not handle vc4 correctly?
<danvet>
oh you ditch preferred_depth outright
<danvet>
so that should work
<tzimmermann>
simpledrm/ofdrm may run on 15-bit frambuffers. so they have that special case. we can put that into a helper later
<tzimmermann>
danvet, updated patch is out
<mripard>
tzimmermann: I think your patch is broken on ofdrm, I guess you want s/sdev/odev/ ?
<danvet>
and more refactoring/rework/driver changes are for later
<danvet>
not opposed to more work, just not as regression fix
<danvet>
hm this could again go wrong badly
<tzimmermann>
ok, i now made sure that ofdrm is being build
<tzimmermann>
danvet, wouldn't your patch return things like argb8888?
<danvet>
yeah :-)
<danvet>
tzimmermann, entirely different idea, but maybe better long term
<danvet>
1) add mode_config.preferred_format as a fourcc (0 means first try mode_config.preferred_depth, otherwise legacy xrgb8888)
<danvet>
2) if that is set, use that directly as the right format in fbdev helpers fallback code, ignore all the preferred_bpp and preferred_depth confusion we have
<danvet>
3) set that in ofdrm and simpledrm
<danvet>
4) revert your patch
<danvet>
and then eventually long slog to move all other drivers over to that fourcc thing
<tzimmermann>
that's not minimal :)
<danvet>
yeah
<danvet>
well, do 4) first and then 1-3 to fix simpledrm/ofdrm
<danvet>
then it's more minimal
<tzimmermann>
setting a fourcc code as default certainly makes sense in the longer term
<danvet>
I just feel like trying to make sense out of this legacy mess without breaking one of the 100 or so kms drivers we have is impossible
<danvet>
so just leave legacy mess as it was last year, and outrigh replace it with something simple we can understand
<tzimmermann>
i'm pretty sure that my patch is now fairly small and covers all cases
<danvet>
i.e. single fourcc
<danvet>
tzimmermann, minimally needs v3 to explain that's it's a regression, Fixes: tag, why things broke and how it's getting fixed
<danvet>
and then cc the msm reporters too for tested-by I guess
<tzimmermann>
ok
<danvet>
if mripard can also add a t-b I guess that might be good enough?
<danvet>
but I'm really not sure
<danvet>
imo the mode_config.preferred_format is the way to go long term
<tzimmermann>
danvet, you'll be out later today? with fixes: and t-b:s added, can i add your a-b to the patch. i'd like to get it merged today
rmckeever has quit [Quit: Leaving]
<danvet>
yeah a-b me
<tzimmermann>
thanks
<danvet>
I'm trying to think a bit what mode_config.preferred_format should look like
<tzimmermann>
ok
<tzimmermann>
it still has to be optional, i guess.
<tzimmermann>
with a default of xrgb8888
<danvet>
yeah
<tzimmermann>
fbdev should be able to override it via function argument
<danvet>
but I think it shouldn't be too hard to rip out mode_config.preferred_depth
<tzimmermann>
(for cases like vc4)
<tzimmermann>
i hope so
<danvet>
and then in the next step, rip out the function argument from most drivers for fbdev or so
<danvet>
and the remaining few pass a fourcc instead of bpp
<danvet>
I think that might work as a refactoring approach
<danvet>
since I tried to fix this mess a few times and got stuck over the years
<tzimmermann>
actually, i think we're close already. that format-selection code was the worst part
<danvet>
yeah for cmdline->fourcc conversion
<danvet>
I'm not sure it's entirely right, since essentially we should have a list of fbdev helper supported formats
<danvet>
and walk that, intersected with whatever the driver wants
<danvet>
but I guess fbdev for now doesn't support that much really so meh
<mairacanal>
tzimmermann, I'll test on the rpi and vkms
<tzimmermann>
thank you
RhineDevil^ has quit [Ping timeout: 480 seconds]
<mairacanal>
tzimmermann, I'm getting "[drm] unsupported color mode of 0" on the vc4 and vkms. is this suppose to happen?
nchery has quit [Read error: Connection reset by peer]
<tzimmermann>
mairacanal, one minute. that one check got lost.
MrCooper has quit [Remote host closed the connection]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
MrCooper has joined #dri-devel
<tzimmermann>
mairacanal, thanks a lot for testing. an updated patch is out. it should resolve the problem. it was just cosmetically
JohnnyonFlame has quit [Read error: Connection reset by peer]
ngcortes has quit [Read error: Connection reset by peer]
devilhorns has quit []
<shadeslayer>
kusma: re assert before calling align64, that sounds a lot more invasive than my change :(
<shadeslayer>
I don't understand why there's so much friction to move to a data type that would be able to handle both uint32_t and uint64_t
<kusma>
Because it makes the code slower
<kusma>
shadeslayer: Really? You said you identified two call-sites... Adding two asserts doesn't sound very invasive?
<shadeslayer>
I found 2 on casual inspection, I didn't go through every single align64 call
<kusma>
Right. Then what's the problem?
<kusma>
What are you trying to solve here? Is there a problem with the current code?
<shadeslayer>
Well, adding asserts before the call doesn't prevent future proof'ing align64 calls from accepting out of bounds alignments?
<shadeslayer>
I don't think there's a bug at the moment, but I'm just trying to make sure we don't run into issues for the future because of mis matched types
<kusma>
I'm not following. Do we need future proofing? Currently, the code is clear about not supporting passing 64-bit alignments... Shouldn't we be getting warnings if we throw away bits without explicit casts here?
<shadeslayer>
I didn't see any when downcasting from the uint64_t to a uint32_t in the current code, so I'm not sure ...
<kusma>
Right, but what I think Marek is saying (and if he's not, then I would be saying it), is that this is not a realistic problem.
<kusma>
There should be no reason for code to try to align to that large values...
<shadeslayer>
okay, I suppose I'll just drop that change then
<kusma>
If you add those asserts, I suspect that nobody is going to get confused about this in the future ;)
Akari has quit [Quit: segmentation fault (core dumped)]
<shadeslayer>
kusma: since it's not realistic ... I'll just not bother :P
<kusma>
Sure 🤷
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
pcercuei has joined #dri-devel
camus has quit []
logiblue69 has joined #dri-devel
<mripard>
danvet: unfortunately, I won't be able to test it today
zehortigoza has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
mvlad has joined #dri-devel
sgruszka has quit [Remote host closed the connection]
aravind has quit [Ping timeout: 480 seconds]
<DavidHeidelberg[m]>
mupuf: lol, sorry I clicked on Marge at exactly moment u did "D
<DavidHeidelberg[m]>
everything seems to be green + it solves -gsplit-dwarf bug for s390x (used in core dumps MR)
<DavidHeidelberg[m]>
lygstate: Hey! I seen you been improving mingw, what do you think about trying some useful linker (anything except ld.bfd)? I cc'd you on the issue, it would help me a lot with split debug builds :)
fxkamd has joined #dri-devel
agd5f has joined #dri-devel
agd5f has quit [Remote host closed the connection]
agd5f has joined #dri-devel
kts has quit [Quit: Leaving]
<MrCooper>
tzimmermann: FYI, there were working Linux OpenGL drivers before OpenGL 2.0 was a thing (and we didn't use them only for glxgears :)
Lucretia has quit [Read error: Connection reset by peer]
Lucretia has joined #dri-devel
kts has joined #dri-devel
Major_Biscuit has quit []
Akari has joined #dri-devel
fxkamd has quit []
jewins has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
rgallaispou has joined #dri-devel
pallavim has joined #dri-devel
fab_ has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
bgs has joined #dri-devel
fab_ is now known as Guest455
logiblue69 has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
Guest455 has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
alyssa has left #dri-devel [#dri-devel]
logiblue69 has joined #dri-devel
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
logiblue69 has quit [Ping timeout: 480 seconds]
mbrost_ has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
<tzimmermann>
MrCooper, i know. i began C programming with 3dfx+mesa+linux back then :)
<MrCooper>
then you know there are lots of OpenGL 1.x apps
logiblue69 has joined #dri-devel
Daanct12 has quit [Remote host closed the connection]
<tzimmermann>
of course. my point in that mail was that it's all long gone. there's nothing in those old drivers that cannot be done in software today.
<tzimmermann>
(it would be somewhat cool to have a modern drm 3d driver for 3dfx or matrox, though.)
ybogdano has quit [Ping timeout: 480 seconds]
* ccr
pokes a crumbly G200 with a long stick.
fab has joined #dri-devel
<KitsuWhooa>
I ran extreme tux racer on my S3 Savage IX relatively recently before the old drivers got ripped out from mesa :p
<ccr>
I remember trying to get S3 Virge DX-something work under Utah-GLX. it was so slow that software rendering GLQuake was way faster. :)
<KitsuWhooa>
I think for me it's faster than using the CPU on that laptop
<KitsuWhooa>
That said, the original S3 Virge was rightfully called a decelerator :p
<ccr>
indeed
ybogdano has joined #dri-devel
nchery has joined #dri-devel
logiblue69 has quit [Remote host closed the connection]
logiblue69 has joined #dri-devel
mbrost has joined #dri-devel
srslypascal is now known as Guest460
srslypascal has joined #dri-devel
<MrCooper>
tzimmermann: "there's nothing in those old drivers that cannot be done in software today" is doubtful, such old GPUs tend to be paired with weak CPUs
mbrost has quit [Ping timeout: 480 seconds]
<KitsuWhooa>
extremely weak ones indeed :p
Guest460 has quit [Ping timeout: 480 seconds]
jewins has quit [Ping timeout: 480 seconds]
jluthra has quit [Remote host closed the connection]
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
sarnex has quit [Read error: Connection reset by peer]
sarnex has joined #dri-devel
<tzimmermann>
MrCooper, maybe reply to the emails, so that your comments won't get lost
mbrost has quit [Ping timeout: 480 seconds]
Guest431 has quit [Remote host closed the connection]
* MrCooper
not sure he cares enough
tzimmermann has quit [Quit: Leaving]
<danvet>
tzimmermann, so I pondered this all a bit more, and I think we have 2 more complications to think through for a long term approach
<danvet>
a) drivers which don't really support addfb2 (or are crap at it, I think we have a few problems there)
<danvet>
and b) big endian
<danvet>
they're kinda related :-)
<danvet>
mairacanal, ^^ I think I need to come up with an addfb format validation for non-atomic drivers too
<danvet>
eae06120f1974 only plugged one half of this mess
<mairacanal>
danvet, I can add this idea of validation for non-atomic drivers on the todo list
<mairacanal>
and thanks for the feedback about framebuffer_check()!
Akari has quit [Quit: segmentation fault (core dumped)]
kts has quit [Quit: Leaving]
ice9 has joined #dri-devel
<ice9>
on hybrid graphics laptop while using the intel driver; if the laptop is left locked for sometime, the screen doesn't turn on again, sometimes the whole laptop freezes and I have to hard reset from the power button; this doesn't happen if using nvidia's driver; any idea?
mbrost has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
well, asahi is passing texwrap. i do not understand why.
<HdkR>
Hand waving magic
<alyssa>
Ohhh
<alyssa>
I hate C
<alyssa>
init_float_texture is fixing up the border colours to match the base format
<alyssa>
so texwrap doesn't check the 0.5 vs 1.0 case
<jenatali>
Why is that a problem with C?
<alyssa>
jenatali: see the impl of init_float_texture in texwrap
<alyssa>
I get what's happening now
<alyssa>
it's just
<alyssa>
extremely subtle
<alyssa>
and very C.
<alyssa>
also, I don't see any coverage of ASTC + GL_CLAMP_TO_BORDER in either dEQP or piglit, yeet
jkrzyszt has joined #dri-devel
heat has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
gouchi has joined #dri-devel
mbrost has quit [Remote host closed the connection]
<gekret005>
as far as I'm aware there needs to be set some timings to fit 144hz into the 1.2dp which this graphics card configuration doesn't take automatically
<HdkR>
xrandr output in the comment of the gist
<HdkR>
Also edid
<gekret005>
need something like "Modeline "2880x1600_144" 730.575 2880 2888 2920 2960 1600 1700 1708 1714 +HSync -VSync"
<gekret005>
no idea how display timings work personally
alyssa has quit [Quit: leaving]
<HdkR>
Theoretically the edid should have that same information but since the displays aren't used by x11, modeline doesn't make much sense
lemonzest has quit [Quit: WeeChat 3.6]
Sachiel_ is now known as Sachiel
<agd5f>
gekret005, it's possible the device doesn't like the reduced blanking timing even if the GPU were to use it
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
<danvet>
sravn, if lee/daniel ack for merging the backlight stuff through drm-misc, do you plan to apply them too?
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
mbrost has joined #dri-devel
rmckeever has joined #dri-devel
Lucretia has quit []
<gawin>
bonjour, what would you say to putting some shaders from gles 2.0 CTS into shaderdb? iirc CTS has ok license(?)
<gawin>
I mean elemental stuff which often ends with workaround on older hardware/mobile (so no stuff like loops)
<gawin>
(recently I've caused trivial regression on r300 and unfortunately shaderdb didn't catch this)
Lucretia has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
<DavidHeidelberg[m]>
robclark: Hey, do you have in mind any config option which needs to be enabled to get adreno working on 6.1.x? we've already enabled the CONFIG_MSM_* but that doesn't seems to be enough
<robclark>
hmm, olddefconfig has more or less always worked for me with only one or two exceptions
<robclark>
but if you've got dmesg I could look
bluebugs has joined #dri-devel
<sravn>
danvet: I will take care, but Lee is usual good at taking care pending review from Daniel.
<sravn>
I am resurrecting an old patchset of mine that replaces direct use of fb_blank with helpers in many more places. If I can get is in shape I plan to post it this weekend.
pallavim_ has joined #dri-devel
pallavim has quit [Ping timeout: 480 seconds]
agd5f has quit [Read error: Connection reset by peer]
Duke`` has quit [Ping timeout: 480 seconds]
agd5f has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
dcbaker: trying to figure out the sanest way to run clang-format as a lint in meson
<alyssa>
this does the right thing -- print success if it passes, prints a detailed error if not
<alyssa>
Just unsure how to integrate `clang-format-14 --Werror --dry-run` into meson in a reasonable way, with the following considerations
<alyssa>
1. running in meson means devs get feedback before submitting an MR (so assuming people build-test their patches, reviewers should never have a style nit ever again)
<alyssa>
2. running in meson means that CI checks it as part of the regular build-testing without any gitlab-ci changes
<alyssa>
3. need a way to disable the linting to avoid adding a dev dependency on clang-format for distros who just want to build but not modify
<alyssa>
4. should use the normal build system smarts to avoid relinting files that haven't changed (so there's no increased build time in an asymptoptic sense)
<alyssa>
seems like it should be easy meson glue, but IDK meson as well as I'd like
<alyssa>
meson likes to invoke the compiler itself so I'm trying to figure out how to sneak clang-format in there and pretend it's a compiler that doesn't produce build artefacts
<alyssa>
meson's clang-format integration is solving a different problem (reformatting vs linting)
lstrano has joined #dri-devel
dcz_ has quit [Ping timeout: 480 seconds]
sghuge has quit [Remote host closed the connection]
ice9 has quit [Ping timeout: 480 seconds]
sghuge has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<alyssa>
unless meson really doesn't want to work that way architecturally
jernej_ has quit [Ping timeout: 480 seconds]
jernej has joined #dri-devel
<dcbaker>
alyssa: Is it clang-format or clang-tidy that meson just automatically runs if a .clang-tidy exists in the root directory?
<dcbaker>
I guess that only gives you a run target which changes files in place...
<dcbaker>
but you want a target that can run as a test...
<dcbaker>
we should fix that
<dcbaker>
on to your actual question
<dcbaker>
I'll write a quick gist of how I'd approach this
<alyssa>
oh, I see the clang-format-check on there now "intended to be used by CI"
<alyssa>
one of the proposed solutions was checking clang-format in CI, which I guess meson gives clang-format-check to do
<alyssa>
however I think we agreed that it's probably better to do the check as part of the regular build, so contributors get feedback immediately
<alyssa>
(I don't feel strongly but meh)
<alyssa>
what I'm really trying to do is make the on-boarding process as easy as possible
<alyssa>
in the past, trying to find the code style doc or mimicking existing code and then getting nitpicked when your patches aren't quite right ... is not fun
<alyssa>
in the present, having clang-format but not knowing you're supposed to use it and then the reviewer telling you to install clang-format ... is better but not great
<alyssa>
but everyone writing a patch has to (presumably) compile that patch before submitting it
<alyssa>
if the act of compiling the patch is enough to check for formatting and give instructions on how to get setup properly before the patch even leaves the developer's machine, that's probably ideal from a UX standpoint
<dcbaker>
which runs clang-format as a unit test?
<alyssa>
ahahaha that's brilliant, thank you :)
<alyssa>
although
<alyssa>
hm
<dcbaker>
I did write that such that it will just silently skip if clang-format is not installed
<alyssa>
right, and also that only runs if you actually `meson test`
<alyssa>
which ... well, I don't :-p
<alyssa>
if it turns out that trying to run the lint on dev machines is unreasonable, then ok, I guess we'll do that (or the existing meson clang-format-check) in CI
<dcbaker>
We honestly should have a meson lint or ninja -C builddir lint pass
<dcbaker>
yeah, but it's a run-target, so you ahve to do ninja -C builddir clang-format-check
<dcbaker>
and if you have multiple linters (say whenever I give the same treatment to rustfmt) then you'd have to run two passes
<alyssa>
right ok
<alyssa>
I guess there are two separate issues here
<dcbaker>
You cold use a custom_target I guess
<alyssa>
one is enforcing the lint in CI and the other is onboarding
<dcbaker>
which, is kinda mean, but...
<alyssa>
for #1 the existing stuff is fine and maybe just .gitlab-ci is the way to go
<alyssa>
for #2 maybe trying to automate this entirely is unreasonable and having a "How to contribute to Panfrost" document on docs.mesa3d.org that includes a blurb on clang-format is the best way to go
<alyssa>
minus the whole "people don't read" thing
mbrost has quit [Ping timeout: 480 seconds]
<dcbaker>
maybe a git commit hook?
<alyssa>
a hook to run the lint? that might be a reasonable compromise, yeah
<alyssa>
and that neatly avoids the distro problem
<alyssa>
(since you don't run the hook if you're just building and not trying to contribute upstream)
<alyssa>
It does duplicate the commit hook + `meson lint` in CI but that's probably maybe ok
<dcbaker>
I think ideally we would add a meson lint command upstream, which would make the CI + hook burden lower. You could just have the CI and the hook call call into meson lint, which would be very cheap to maintain
<alyssa>
*nod*
* dcbaker
will go write an issue and add it to his every growing backlog of things to do
<alyssa>
mood
gawin has quit [Quit: Konversation terminated!]
jfalempe has quit [Quit: Leaving]
<alyssa>
starting to write the gitlab ci changes needed
<alyssa>
hitting the "whoops need to add clang-format to the container" step >>
<alyssa>
oh and here's a "fun" problem... clang-format-14 isn't in bullseye
<alyssa>
let's see if -13 has any "interesting" breaking changes