<javierm>
tomeu: I believe the latter wouldn't be needed if you have the former?
<tomeu>
well, at the end none of them were strictly needed for what I wanted
<tomeu>
oh, yes, you are right
<tomeu>
I first disabled fbcon, saw that some warnings were still spewed, then tried with a bigger hammer but left the previous
<javierm>
tomeu: yeah, I thought that was the case by looking at the commits history
<javierm>
that's why I wanted to point out
frieder has joined #dri-devel
frieder has quit []
tzimmermann has joined #dri-devel
<tomeu>
yep, thanks!
dcz_ has joined #dri-devel
fab has joined #dri-devel
rasterman has joined #dri-devel
frieder has joined #dri-devel
tursulin has joined #dri-devel
eukara has joined #dri-devel
<MrCooper>
repetitivestrain: DRM_VBLANK_RELATIVE with target 0 returns the MSC of the last vertical blank period (or possibly the current one, if it's ongoing)
<MrCooper>
repetitivestrain: the timestamp always corresponds to the end of the vertical blank period for the returned MSC
jkrzyszt has joined #dri-devel
Leopold_ has joined #dri-devel
Leopold_ has quit []
mvlad has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest2334
swalker__ has joined #dri-devel
Guest2334 has quit [Ping timeout: 480 seconds]
warpme____ has joined #dri-devel
lynxeye has joined #dri-devel
<javierm>
tzimmermann: reviewing Noralf's latest series I noticed that the gud driver open codes a lot of the logic I think you already handle in the drm_fb_blit() helper to do format conversion
<tzimmermann>
javierm, could be
<tzimmermann>
drm_fb_blit() is not really finished
<tzimmermann>
is there something in gud we could move into helpers?
<tzimmermann>
javierm, did you see my comment on the first patch? it could break something
<javierm>
tzimmermann: yeah, I saw it after reviewing the whole series :)
<javierm>
I missed that discussion between danvet and you. Or rather, I recall tha were some discussion here but didn't pay that much attention
<javierm>
tzimmermann: I think that part of that logic overlaps with drm_fb_blit()
<tzimmermann>
indeed
<tzimmermann>
i think we have to rework some of drm_fb_blit() first befoew we can convert gud
<tzimmermann>
for example, gud_is_bigendian() wraps a boolean. the better solution would define an format and set the DRM_FORMAT_BIG_ENDIAN flag on it.
<javierm>
tzimmermann: agreed. And also I need to understand what are the native formats for gud and what emulated formats it advertises
<javierm>
because we only want DRM_FORMAT_{X,A}RGB8888 + native as discussed the other day
camus has quit [Remote host closed the connection]
<tzimmermann>
exactly. IIRC the formats for gud depend on whatever the attached device supports
<javierm>
I see
<tzimmermann>
my plan roughly is: get the color/bpp fixed; fix the fbdev-format selection; weed out the unnecessary conversion helpers and formats; further clean up the helper's interfaces
<javierm>
tzimmermann: yup. Is the color/bpp series ready to get merged?
<tzimmermann>
it has an a-b from daniel and i'm waiting for you/noralf to give it a test
<tzimmermann>
the format-selection fix is semi-done
jfalempe_ has joined #dri-devel
jfalempe has quit [Read error: No route to host]
<repetitivestrain>
MrCooper: thanks, i guess maybe this is more of a question for #xorg-devel, but IIUC present_get_ust_msc in the X server is supposed to return the ID of the current or next frame, right?
frieder has quit [Quit: Leaving]
<javierm>
tzimmermann: I thought you were waiting for our test to "[PATCH 0/8] drm/mipi-dbi: Convert to shadow-plane helpers" or do you also want me to test "[PATCH 0/7] drm: Fix the color-depth/bpp confusion" ?
<javierm>
tzimmermann: I'm quite confident that won't break the ssd130x driver, but if you want I can test tomorrow. I don't have my rpi4 with the ssd1306 today with me
<repetitivestrain>
nvm
<repetitivestrain>
i see what it's supposed to do now
<tzimmermann>
you're right. i confused those two patchsets.
<tzimmermann>
the bpp fix is ready then
<javierm>
tzimmermann: cool
<tzimmermann>
i'll merge it ASAP
<javierm>
tzimmermann: great, thanks
pcercuei has joined #dri-devel
<danvet>
pinchartl, history digging question for you in [PATCH] dma-buf: Require VM_PFNMAP vma for mmap
<pinchartl>
danvet: you think I remember something I've done more than a week ago ? :-)
<pinchartl>
I'll have a look
MajorBiscuit has joined #dri-devel
<danvet>
pinchartl, I have high expectations
pendingchaos_ has joined #dri-devel
vliaskov has joined #dri-devel
pendingchaos has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
djbw has quit [Read error: Connection reset by peer]
apinheiro has joined #dri-devel
<karolherbst>
airlied: because it's not wired up yet
<karolherbst>
maybe I should...
<karolherbst>
just not really focusing on optional features atm
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
linkmauve has quit [Ping timeout: 480 seconds]
a1batross has quit [Ping timeout: 480 seconds]
ahajda has joined #dri-devel
mvlad has quit [Remote host closed the connection]
mvlad has joined #dri-devel
<dj-death>
someone has a list of package to install on ubuntu to compile mesa in 32bit?
<dj-death>
right now failing to found libdrm, even though libdrm-dev:i386 is installed
<dj-death>
ah got the wrong pkg-config path :(
<MrCooper>
dj-death: try "sudo apt -a i386 build-dep mesa"
<MrCooper>
maybe "apt-cache showsrc mesa | grep Build-Dep" can get you started then
digetx has quit [Ping timeout: 480 seconds]
danielle has joined #dri-devel
danielle has left #dri-devel [#dri-devel]
danisdgk has joined #dri-devel
ppascher has quit [Quit: Gateway shutdown]
danisdgk has quit [Remote host closed the connection]
ppascher has joined #dri-devel
Akari has quit [Quit: segmentation fault (core dumped)]
pochu has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
pjakobsson has joined #dri-devel
<DavidHeidelberg[m]>
dj-death: it's even more fun with pkgconf instead of pkg-config
pendingchaos_ is now known as pendingchaos
<Venemo>
hey
<Venemo>
maybe I'll get better luck asking this on a weekday
<Venemo>
can one of the NIR experts please catch me up on why VARYING_SLOT_VARxx_16BIT exists? I don't see why the normal slots couldn't be used instead
<Venemo>
mareko: what is the difference between a GLES and VK that makes GLES need this while VK works OK with 16-bit outputs without this?
kts has quit [Quit: Leaving]
<MrCooper>
mareko: there's now a bot which automatically adds the appropriate labels to MRs; if you set any labels yourself, the bot won't add any, even if you missed some
sul has quit [Ping timeout: 480 seconds]
sul has joined #dri-devel
heat has joined #dri-devel
heat_ has quit [Read error: No route to host]
kts has joined #dri-devel
yuq825 has quit []
<tzimmermann>
melissawen, you can 'dim cherry-pick' the commit into drm-misc-next
MajorBiscuit has quit [Ping timeout: 480 seconds]
<melissawen>
tzimmermann, cool, thanks!
<tzimmermann>
danvet, melissawen, we can also backmerge -rc6 into drm-next and backmerge into drm-misc-fixes
<tzimmermann>
might be the better option
<tzimmermann>
s/drm-misc-fixes/drm-misc-next
<danvet>
hm I thought airlied wanted to do that anyway
<danvet>
iirc some other reasons and annoying conflicts around already
<mripard>
tzimmermann: I think a backmerge would be better, it's already there in -rc5 and -rc6
<mripard>
there's no need to apply it twice
<danvet>
airlied, ^^ still planning to backmerge or simply forgot to push the tree?
<danvet>
mripard, yeah we have other reasons for backmerge iirc, there's the fbdev helper move vs nouveau fbdev generic helper conversion too
<tzimmermann>
-misc-next is still at -rc2. that's a bit old
<danvet>
iirc some other stuff too
<danvet>
I'll try and chat with airlied this evening, and if he doesn't do it I'll try to get it done tomorrow
<danvet>
have a few things in the morning though
<tzimmermann>
great, thanks
<melissawen>
ok, so I won't mess with that :)
pochu has quit []
MajorBiscuit has joined #dri-devel
fab has quit [Quit: fab]
MajorBiscuit has quit [Ping timeout: 480 seconds]
FireBurn has quit [Quit: Konversation terminated!]
FireBurn has joined #dri-devel
fab has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
<danvet>
I'll send that out with you on cc for pondering :-)
<Venemo>
mareko: thx
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
tursulin has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
Danct12 has joined #dri-devel
cmeissl[m] has quit []
mbrost has joined #dri-devel
swalker__ has quit [Remote host closed the connection]
mbrost has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
jeeeun8413 has quit []
i-garrison has quit [Read error: Connection reset by peer]
i-garrison has joined #dri-devel
sgruszka has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
darkbasic4 has quit [Remote host closed the connection]
caef^ has quit [Remote host closed the connection]
darkbasic4 has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
Dr_Who has quit [Read error: Connection reset by peer]
mbrost has joined #dri-devel
ccaione has joined #dri-devel
alyssa has joined #dri-devel
digetx has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
junaid has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
flibit has quit []
flibitijibibo has joined #dri-devel
<karolherbst>
are there any weird restrictions on the shared store/load instructions in RDNA/GCN? Like.. do they work in diverged work groups correctly or do they have any other weird restrictions? Seeing some weird behavior with shared atomics in workgroups bigger than 64
<karolherbst>
threads
hch12907 has quit []
<airlied>
danvet: going to backmerge rc6 today for the tegra next pull
JohnnyonFlame has joined #dri-devel
gouchi has joined #dri-devel
<karolherbst>
huh....
<karolherbst>
using "workgroup" instead of "workgroup-one-as" as the sync scope fixes my issue...
<danvet>
you're on cc, so you should have the next reply already
<danvet>
it smells a bit like camera stuff that's escaped somehow
JohnnyonF has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
<danvet>
the entire modifier design looks funny tbf
<danvet>
daniels, ^^ maybe you have some idea
digetx has joined #dri-devel
ybogdano has joined #dri-devel
<pendingchaos>
I don't know what "diverged work groups" means
<pendingchaos>
karolherbst: not really
<pendingchaos>
IIRC the difference between "workgroup" and "workgroup-one-as" is that "workgroup" invalidates unrelated (not LDS/shared) caches and waits for unrelated memory instructions in the subgroup to finish
<pendingchaos>
workgroups larger than 64 are split into multiple subgroups, so maybe the shader is missing some synchronization
<pendingchaos>
so all it should be doing is making the shader slower
<pinchartl>
danvet: I think it's related to codecs
<danvet>
pinchartl, yeah but for what? I thought adding drm fourcc/modifiers to v4l got stuck firmly
<danvet>
and people talking about mixing them up scares me
<pinchartl>
there's been a recent attempt to revive the idea of modifiers in V4L2
<pinchartl>
but regardless, I'm not entirely sure what all this is about
<danvet>
but drm modifiers or v4l2 modifiers
<danvet>
yeah me neither
<pinchartl>
they seem to need to bundle planes containing image data with planes containing metadata
mhenning has joined #dri-devel
Surkow|laptop has quit [Remote host closed the connection]
<danvet>
the modifier design itself is also pretty wasteful of bits, which isn't the best idea
psykose has joined #dri-devel
Surkow|laptop has joined #dri-devel
* kisak
sees the 22.3.0-rc4 git tag
<kisak>
looks like I don't need to bang my head against a wall this week
Haaninjo has joined #dri-devel
<lynxeye>
danvet: pinchartl: Doesn't look too odd to me. Most compression schemes require an additional metadat/tag plane. Also, though scary, we will eventually need to mix v4l2 and drm modifiers. There are some display engines out there which can directly scan out video codec tiled formats.
<danvet>
lynxeye, not the namespace
<danvet>
like mixing their use, sure, but not the namespace
<danvet>
you need a big translation table between them
<lynxeye>
danvet: Are you talking about the fourcc code or the modifier? It's unfortunate that we need to translate the fourcc code, requiring the same for a modifier would make modifier usage a lot more awkward.
<karolherbst>
alyssa: was there hardware you care about where the backend compiler need to know _if_ there is variable shared memory?
<danvet>
lynxeye, both, they come together
<danvet>
you can make v4l modifiers ofc
<karolherbst>
anyway.. mind want to look into !19855 and implement the new function, otherwise I'll do it at some point 🙃
<danvet>
but if you want drm modifiers, you need drm fourcc or the stuff doesn't make a lot of sense imo
<danvet>
v4l2_fourcc + drm_modifier sounds great, until you actually care about interop
<danvet>
then it's just a dumpster fire
<lynxeye>
danvet: If v4l2 and drm can't agree on a modifier then we lose the nice property of modifiers being totally opaque numbers for most userspace that actually needs to fit different APIs together.
<pinchartl>
danvet: I'd be all for using DRM 4CCs everywhere :-)
<danvet>
thing of drm_fourcce + drm_modifier as a 96bit format identifier thing
<danvet>
they only come split for historical reasons
<danvet>
lynxeye, the modifier alone is often meaningless
<danvet>
drm has 2 format identifier spaces
<danvet>
1. 32bit, legacy, just a drm_fourcc + driver magic for tiling
<danvet>
2. 96bit, (drm_fourcc, drm_modifier), not driver magic for data layout needed, supposed to facilitate interop
<lynxeye>
danvet: where do you see an issue in a v4l2 driver claiming support for v4l2 fourcc + shared drm modifier?
<danvet>
I'm not going to ack such modifiers
<danvet>
:-)
<danvet>
more seriously, the entire "fourcc is a standard" thing
<danvet>
it's not
<danvet>
so if you just put a random other number in the first 32bit
<danvet>
then if that number matches with the drm one, we're good
<danvet>
if it doesn't match, then you don't have interop
<danvet>
and the _entire_ point of (drm_fourcc, drm_modifier) is interop
<danvet>
not "hey we have a random other subsystem with it's own format identifier space and want to steal some ideas"
<danvet>
if you want interop, use drm format identifiers
Net147 has quit [Ping timeout: 480 seconds]
<danvet>
if you want something else, you don't get interop, and there's no point in using any part of the drm format identifier schema
<danvet>
ofc feel free to steal the encoding, or parts of it
<danvet>
but it's then a v4l thing, not interop compatible with drm format identifiers
<pinchartl>
modifier support in V4L2 will require new ioctls. I wonder if those should use DRM 4CCs. it may be awful to support in drivers though
<danvet>
some shared translation function should help with that
<danvet>
you dont' have to make it complete, only fill out what the current set of drm_fourcc enabled drivers need
<lynxeye>
Not talking about the fourcc. Modifier negotiation mostly works like this: 1. choose compatible format from both ends (here you need to translate between v4l2 and drm fourcc) 2. choose a modifier supported with that format on both ends (why can't we share the modifier here, while we have no incompatible other modifier namespace than the drm one).
<danvet>
which I guess should be manageable
psykose has quit [Ping timeout: 480 seconds]
<danvet>
lynxeye, the modifier alone is meaningless
<danvet>
it's a 96bit number
mbrost_ has joined #dri-devel
<lynxeye>
which is why you choose the format first
<danvet>
you can steal a few bits of the encoding and reuse those
<danvet>
but you wont get the same 96bit identifier with the interop that gives you
<danvet>
just something which is going to be maximally confusing
<danvet>
since often it's the same
<danvet>
except when it's not
<danvet>
and instead of having the drm_fourcc vs v4l2_fourcc compat glue in one place in the kernel
<danvet>
you have shitty versions of that all over the various userspaces
<danvet>
which I don't think is any good
<pinchartl>
danvet: I don't agree
<pinchartl>
if V4L2 gets modifier supports
<pinchartl>
we'll have to define modifiers, obviously
<pinchartl>
and I think it makes sense to have a single definition of modifiers in the kernel
<pinchartl>
instead of duplicating it
<pinchartl>
you won't get the same 96-bit value
<danvet>
yeah, but those come with drm_fourcc
<danvet>
not v4l2_fourcc
<danvet>
if you just comebine (v4l 4cc, drm_modifiers)
<pinchartl>
userspace won't be able to take the value from one device and pass it to another device
<pinchartl>
but we would have a single definition
<danvet>
you get a 96bit v4l2 format identifier space
<danvet>
which kinda looks like the 96bit drm format identifier space
<danvet>
but isn't
<danvet>
and that's going to maximally screw over userspace
mbrost has quit [Ping timeout: 480 seconds]
<danvet>
so if that's the goal, just make your own v4l2 modifier space too, then it's at least clear
<pinchartl>
that wouldn't be any way better
<danvet>
no
<lynxeye>
If v4l2 isn't going to adopt the drm fourccs you end up having the translation table in userspace, which is horrible, just as you said.
<danvet>
but clearer
<lynxeye>
shitty versions all over userspace
<danvet>
yeah imo the one option is v4l2 adopts drm format identifiers
<danvet>
and has a big compat table in the kernel so that drivers can use only one identifier space
<pinchartl>
danvet: can you help convincing the V4L2 maintainer ?
<danvet>
kinda like drm addfb gets translated to addfb2
<danvet>
pinchartl, nah
<danvet>
I'll just stop modifiers for v4l fourcc from getting added to drm_fourcc.h
<pinchartl>
there are *lots* of weird legacy formats in V4L2 that shouldn't be imported in DRM, so I'm not sure how that could be handled
<pinchartl>
for the commong RGB and YUV formats it should be fine
<pinchartl>
then there are the raw formats, those would be interesting
<lynxeye>
What's the problem with taking a (drm_fourcc, drm_modifier) tuple and translating it into a (v4l2_fourcc, drm_modifier) tuple for use with v4l2?
<danvet>
pinchartl, we have at least one of those in drm_fourcc too
<danvet>
there's some helpers to translate it into a more canonical form
heat_ has joined #dri-devel
<danvet>
it'll grow, since we'll keep screwing up and accidentally create some aliases in that 96bit space
<pinchartl>
and there are all the formats for compressed data, there's a bunch of video compression 4CCs
<pinchartl>
those could be imported in DRM in one go though
<danvet>
lynxeye, just that it's a (v4l2 4cc, v4l2 modifier) tuple
heat has quit [Read error: No route to host]
<pinchartl>
danvet: formats with modifiers are mostly useful for interop, if it's camera + CPU only there's little point in tiling
<danvet>
pinchartl, maybe that entire v42l_fourcc -> (drm_fourcc, modifier) should be an ioctl so userspace can use it
<pinchartl>
so if we add a DRM modifier for a format consumed by a DRM device
<danvet>
*use it too
<pinchartl>
what's wrong with using the same DRM modifier numerical value in V4L2 for the same format ?
<danvet>
I guess you can do that
<danvet>
but I expect there will be clashses
<pinchartl>
I'd understand a reluctance to accept DRM modifiers that are only used with V4L2 4CCs
<pinchartl>
for the case we're discussing, there's another problem if I recall correctly, the format being discussed requires 5 planes
<pinchartl>
and DRM only supports 4
<danvet>
uh
<danvet>
I think that's actually a bigger one
<pinchartl>
I think they work around it thanks to the fact that the 5th plane stores metadata used by the codec only, not by the display engine
<danvet>
because those 4 planes max are all over in vk/gl standars
<pinchartl>
but that's not great
<danvet>
I think at least
mbrost_ has quit [Ping timeout: 480 seconds]
<pinchartl>
the other option is to store metadata in a separate buffer instead, and bundle multiple buffers
<danvet>
pinchartl, still the same problem
<danvet>
iirc some afbc actually just puts the 2nd plane at a fixed offset into the first
<danvet>
because the spec doesn't allow you to program the stride/offset freely
<danvet>
so if that's the case, you don't need each plane as a real plane
<pinchartl>
not sure about this particular hardware
lynxeye has quit [Quit: Leaving.]
<pinchartl>
another thing we have to figure out is how to handle raw formats
<pinchartl>
for cameras, raw formats encode each pixel with a certain number of bits
<pinchartl>
(between 6 and 24 I believe, it keeps expanding)
<pinchartl>
without or without packing
<pinchartl>
e.g. RAW10 can be stored unpacked with each pixel in 2 bytes, or packed with 4 pixels in 5 bytes, or with a different device-specific packing
agd5f has quit [Remote host closed the connection]
<pinchartl>
packing could be expressed as a modifier
<pinchartl>
but then we have the colour filter array
<pinchartl>
CFA in short
<pinchartl>
also known as bayer filter (that's the most common type of CFA)
<pinchartl>
where each pixel has a tiny colour filter in front
<pinchartl>
bayer filters have one red, one blue and two green pixels in each 2x2 groups
<pinchartl>
they can be arranged as R G / G B, B G / G R, G B / R G or G R / B G
<pinchartl>
those are mapped to different 4CCs in V4L2, and I think in retrospect that it's a mistake
<danvet>
yeah this one promises a _lot_ of aliasing troubles
<pinchartl>
if you crop the image and move the crop rectangle by an odd number of pixels in any direction, you end up with a different 4CC
<pinchartl>
some if you flip or mirror the image
<pinchartl>
it's messy
<pinchartl>
it would have been much better to have raw formats independent of the CFA pattern, and convey the pattern out-of-band
<danvet>
yeah that sounds messy
<pinchartl>
if V4L2 used DRM 4CCs we could fix that in the new 4CCs, but the translation would be really messy
<danvet>
btw in drm RAW10 is R10
<danvet>
blame gl
<danvet>
pinchartl, for the odd shift problem
<pinchartl>
RAW10/R10 is just a naming issue, I can live with that
<danvet>
could we define the bayer pattern in terms of absolute offset instead of relative from logical (0,0) coordinate?
<pinchartl>
especially with raw and red both starting with R :-)
<pinchartl>
you could define them that way in the context of a camera
<pinchartl>
but when you write data to memory
<pinchartl>
that context is lost
agd5f has joined #dri-devel
<pinchartl>
you don't know how you've cropped to get that image
<pinchartl>
so the consumer would need to be provided the crop coordinates out of band
<danvet>
oh for actual cropping
<pinchartl>
which I think is worse than providing the pattern out of band
<danvet>
as in "you've used a blitter engine"
<pinchartl>
or you'd have to translate in userspace
<pinchartl>
not a blitter engine
<pinchartl>
you can crop in the camera itself
<danvet>
I was thinking more how in drm we have the fb dimensions
<pinchartl>
in lots of places actually
<danvet>
and then the scanout rectangle is selected out from that
<pinchartl>
analogue crop in the pixel array, digital crop in the sensor, in different parts of the ISP, ...
<pinchartl>
for framebuffer + scanout, yes, that would work
<pinchartl>
but along the camera pipeline, it wouldn't
<pinchartl>
also
<pinchartl>
most components in the pipeline don't care about the CFA pattern
<pinchartl>
usually there are a few blocks only that care
<danvet>
yeah I think for this it boils down to what's more natural for the overall pipeline
<pinchartl>
while lots of other blocks are pass-through
<pinchartl>
that's more related to media bus codes though, not pixel formats
<danvet>
treating it as a raw array with some metadata for the parts that care
<danvet>
or shuffling the presentation around in funny ways
<pinchartl>
(we've made the same mistake in media bus codes, they also encode the pattern)
<pinchartl>
if you get the pattern wrong you'll get weird colours, but no other bad effect
<pinchartl>
so I don't think the kernel has to validate that the pattern is correctly programmed along the pipeline
<pinchartl>
the responsibility of setting the right pattern on the consumer side based on what the camera produces could be entirely up to userspace, without kernel validation
<pinchartl>
it's a bit like colour spaces, we don't encode them in 4CCs, if userspace propagates them incorrectly it's not nice, but it's userspace's fault
sul has quit [Ping timeout: 480 seconds]
sul has joined #dri-devel
darkbasic4 has quit [Remote host closed the connection]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
darkbasic4 has joined #dri-devel
pcercuei has quit [Quit: brb]
pcercuei has joined #dri-devel
psykose has joined #dri-devel
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
junaid has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
neobrain[m] has quit []
mvlad has quit [Remote host closed the connection]
apinheiro has joined #dri-devel
rmckeever has joined #dri-devel
fab has quit [Quit: fab]
pcercuei has quit [Quit: brb]
epoll has quit [Ping timeout: 480 seconds]
dcz_ has quit [Ping timeout: 480 seconds]
epoll has joined #dri-devel
Net147 has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
psykose has quit [Remote host closed the connection]