ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
dliviu has quit [Quit: Going away]
dliviu has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
i509vcb has joined #dri-devel
Company has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
alanc has quit [Remote host closed the connection]
pcercuei has quit [Quit: dodo]
alanc has joined #dri-devel
riteo has joined #dri-devel
flynnjiang has joined #dri-devel
mbrost has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
yyds has joined #dri-devel
Daanct12 has joined #dri-devel
anujp has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
sudeepd_ has quit [Ping timeout: 480 seconds]
krushia has joined #dri-devel
<alyssa>
mareko: seems to be worth 3% on glmark2 -bjellyfish on agx. oof.
mbrost has quit [Ping timeout: 480 seconds]
iive has quit [Quit: They came for me...]
The_Company has joined #dri-devel
davispuh has quit [Ping timeout: 480 seconds]
anujp has quit [Ping timeout: 480 seconds]
anujp has joined #dri-devel
<Company>
is there a way to wait on multiple GLsyncs?
<Company>
trying to port code that uses vkWaitForFences() and I'm wondering if there's an equivalent or if I need to track myself which of the fences is the oldest one
<HdkR>
Company: Commands are executed sequentially, to wait on multiple you can just wait on a "newer" one and it will ensure all the previous ones are done as well
<Company>
yeah
<HdkR>
Can't pick and choose like vkWaitForFences
<Company>
I just don't track which one is the newest one yet
<gfxstrand>
Or you can just wait on them all in sequence
<gfxstrand>
Not great but it works.
<gfxstrand>
There's no multi-wait if that's what you're asking
<Company>
I only want one to trigger
<HdkR>
If you also only care about the latest then just have some global atomic that you store to :P
<Company>
I'll just order my syncs myself
<gfxstrand>
Please don't roll your own timeline semaphores
<Company>
and then know which one to wait on
<gfxstrand>
Yeah, ordering them is a good idea
<Company>
just wanted to make sure I need to do the work
<DemiMarie>
@_oftc_randevouz:matrix.org:
Marcand_ has joined #dri-devel
Leopold has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
sudeepd has joined #dri-devel
Marcand_ has quit [Ping timeout: 480 seconds]
<DemiMarie>
sorry, did not mean to post that message
<dwfreed>
fortunately IRC only saw you attempting to hilight them
bmodem has joined #dri-devel
anujp has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
i-garrison has quit [Remote host closed the connection]
i-garrison has joined #dri-devel
lemonzest has quit [Quit: WeeChat 4.2.1]
lemonzest has joined #dri-devel
<tjaalton>
gfxstrand: ah, thanks
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
The_Company has quit [Remote host closed the connection]
sudeepd has quit [Ping timeout: 480 seconds]
i-garrison has quit []
<airlied>
Lynne: reproduced it, will try and get some time to debug it
Duke`` has joined #dri-devel
Dark-Show has joined #dri-devel
i-garrison has joined #dri-devel
dorcaslitunya has joined #dri-devel
Haaninjo has joined #dri-devel
fab has joined #dri-devel
Marcand_ has joined #dri-devel
glennk has joined #dri-devel
<Lynne>
thanks
<Lynne>
it's possible it's an ffmpeg issue, as I can replicate it on nvidia
dorcaslitunya has quit [Remote host closed the connection]
yyds_ has joined #dri-devel
yyds has quit [Ping timeout: 480 seconds]
Kayden has joined #dri-devel
Marcand_ has quit [Ping timeout: 480 seconds]
Marcand_ has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
dorcaslitunya has joined #dri-devel
rossy has quit [Remote host closed the connection]
rossy has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
<airlied>
Lynne: ah yeah if nvidia screws up the same it could be, might be something like tchar was pondering being a problem
Marcand_ has quit [Ping timeout: 480 seconds]
davispuh has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
sgruszka has joined #dri-devel
warpme has joined #dri-devel
itoral has joined #dri-devel
vliaskov has joined #dri-devel
davispuh has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
i509vcb has quit [Quit: Connection closed for inactivity]
junaid has joined #dri-devel
jkrzyszt has joined #dri-devel
fab has quit [Quit: fab]
JohnnyonFlame has quit [Read error: Connection reset by peer]
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
warpme has quit []
vliaskov has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
hansg has joined #dri-devel
lplc has quit [Quit: WeeChat 4.0.4]
Dark-Show has quit [Remote host closed the connection]
Dark-Show has joined #dri-devel
lplc has joined #dri-devel
lplc has quit [Remote host closed the connection]
fab has joined #dri-devel
dorcasli_ has joined #dri-devel
dorcaslitunya has quit [Read error: Connection reset by peer]
<sima>
jfalempe, yeah sorry I was not up to date on m-l reading, will try to do that
<jfalempe>
sima: no problem, and thanks for helping me on this.
mripard has joined #dri-devel
<pq>
grillo_0, if you or Louis happen to wonder why I'm not replying to VKMS/IGT discussions, I'm currently going through the new KMS color pipeline UAPI series, and I have limited time per day for KMS in general. UAPI and color spec stuff tend to take precedence for me.
javierm has left #dri-devel [#dri-devel]
javierm has joined #dri-devel
javierm has left #dri-devel [#dri-devel]
javierm has joined #dri-devel
hikiko has joined #dri-devel
<javierm>
jfalempe: did you agree with tzimmermann on the drm_fb_blit_from_r1() vs drm_pixmap in the format conversion helpers ?
<javierm>
sorry that I didn't take a look to those two series yet. I'll try to do it tomorrow that's when I've more time for reading the m-l
<tzimmermann>
javierm, these helpers will for now go into the panic code and we'll figure out something later
frankbinns1 has joined #dri-devel
<javierm>
tzimmermann: Ok
<javierm>
tzimmermann: and makes sense, to move things forward
frankbinns1 has quit [Remote host closed the connection]
hikiko has quit []
<jfalempe>
javierm, tzimmermann: yes I moved them back in drm_panic, that's the main change of the v10
<javierm>
jfalempe: cool
bmodem has quit [Ping timeout: 480 seconds]
lplc has joined #dri-devel
frankbinns has joined #dri-devel
lplc has quit []
lplc has joined #dri-devel
bmodem has joined #dri-devel
lplc has quit []
lplc has joined #dri-devel
Daanct12 has quit [Quit: WeeChat 4.2.1]
dejavuaround has joined #dri-devel
dejavuaround was kicked from #dri-devel by ChanServ [You are not permitted on this channel]
lynxeye has joined #dri-devel
guru_ has joined #dri-devel
oneforall2 has quit [Ping timeout: 480 seconds]
triggeredit has joined #dri-devel
DodoGTA has quit [Quit: DodoGTA]
the_sea_peoples has quit [Remote host closed the connection]
the_sea_peoples has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
DodoGTA has joined #dri-devel
u-amarsh04 has quit []
<triggeredit>
The results what i know from the past and today about my investigation done about abuse in my life, that americans like united states people, considered the power on earth are surprisingly enough not active in the abuse hitting the top of the ranks in the world, they did not manage to extend that conspiracy behind or over the ocean for some reason that is not known to me. I hypothesize that maybe they live too good for that and have better
<triggeredit>
ways to deal, generally this appears as a fact that they seem not to be a part of the abuse, even though they started to mark those antigen antbody systems and made the alien conferences initially. And on different years i have gotten the same result. One of the few areas the terror is not spreading to or extending to.
warpme has joined #dri-devel
triggeredit was kicked from #dri-devel by ChanServ [You are not permitted on this channel]
<sima>
mripard, ack but I guess you pushed already :-)
<sima>
mripard, I guess time to enable gitlab ci and figure out how to compile test on at least x86-64, arm64 and arm ...
<mripard>
yeah, it's been pushed already :)
<sima>
well first gitlab ci I guess and see what all falls apart, before we try clever tricks with generating kconfigs with max coverage automatically
warpme has quit [Read error: Connection reset by peer]
itoral has quit [Remote host closed the connection]
junaid has quit [Ping timeout: 480 seconds]
Leopold___ has joined #dri-devel
Leopold_ has quit [Ping timeout: 480 seconds]
<mripard>
sima: arm doesn't always catch those kind of errors, for some reason it didn't this time for example
<mripard>
archs like m68k always seem to catch them, but I'm not sure it's something we want to have
<sima>
hm 32bit x86 reliably catches 64bit divisions, or I thought so
<sima>
or has 32bit arm given up and just added the gcc intrinsics?
<sima>
*built-ins
<mareko>
alyssa: if alpha=1 allows you to disable blending, then you should get better perf with disabled blending unless your hw does that automatically
Leopold___ has quit [Ping timeout: 480 seconds]
<alyssa>
mareko: I don't have blending hardware ;-)
tarceri__ has quit [Remote host closed the connection]
tarceri__ has joined #dri-devel
andrjohns has joined #dri-devel
dorcasli_ has joined #dri-devel
junaid has joined #dri-devel
junaid has quit []
dorcaslitunya has quit [Ping timeout: 480 seconds]
andrjohns has quit [Remote host closed the connection]
ghishadow_ has joined #dri-devel
<sima>
jfalempe, do you want me to type up the irqsave/restore stuff or you'll do it? I think it's a good idea
<sima>
just means we need to add the irqflags as a return value to _lock and as a parameter to _unlock
<sima>
jfalempe, also re ogness questions: the issue is if an irq handler runs within drm_panic_lock section
<sima>
and then we die in there, so instead of just a handful of instructions in drm code, the critical section becomes the entire interrupt handling including bottom halves
<sima>
so _much_ more, and hence a good idea to use the irqsave/restore versions
ghishadow has quit [Ping timeout: 480 seconds]
<jfalempe>
sima: I can do the irqsave/restore change, I just didn't know if it was necessary to do so.
happiestguy has joined #dri-devel
<sima>
jfalempe, btw did you see the discussion around kmsg_dumper? I really think that's the interface we should use instead of the panic notifier you're using in v9
<sima>
since that seems to be for arch/platform code to add additional information to dmesg before all the final dumping happens
<sima>
so it's a bit too early and will mean we dump incomplete data
<jfalempe>
sima: The problem with kmsg dumper is that you don't have the panic reason, you only get the tons of kernel logs, which I'm not interested in.
<sima>
jfalempe, why?
robmur01 has quit [Read error: Connection reset by peer]
<sima>
like that's the stuff we should dump I thought ...
<jfalempe>
my vision is to have a simple message for users, and then put additionaly debug data through qr code.
ghishadow has joined #dri-devel
<jfalempe>
for example if you want to have a correctly formated stack trace in the qr code, the kmsg dumper is not that good, because everything is already formatted through printk.
<sima>
jfalempe, so if you want the panic reason then I think the right way is to add that to kmsg_dump
<sima>
that is still not entirely the entire panic dmesg, but at that point it's no longer our problem
<javierm>
sima: but that still wouldn't get us the nice QR code that jfalempe wants to add, right ?
<sima>
jfalempe, the other issue with qr codes is that at least the standard ones contain way less information than what you can simply print as dmesg output on even just a hd screen resolution
robmur01 has joined #dri-devel
<sima>
javierm, years ago when we discussed qr it sounded nice, but has some practical hurdles
<jfalempe>
sima, if you compress a bit you can put a lot of things in a qr code.
<sima>
you need a special qr decoder to pack enough stuff into it
<sima>
jfalempe, yeah but then you can't just decode the stuff with a smartphone because it's binary
<jfalempe>
it's a link to a website, so you can decode it there.
<jfalempe>
and open a bug with the right info attached.
<sima>
jfalempe, the other issue is that even if you do the qr code, the panic notifier is _still_ the wrong callback, since the qr code needs the kmsg_dump hook
fab has quit [Quit: fab]
<pq>
jfalempe, hopefully the actual data will not reach the web server before decoding and inspection? For privacy reasons.
<sima>
jfalempe, I'm confused, if you put a link into the qr code, how do you put the dmesg in there too?
<jfalempe>
sima: it's easier to get the stack trace, and hw info directly than parsing the kmsg dump
<pq>
so loading a web page with JavaScript to decode it is fine, if you can stop the data from going over internet.
<sima>
jfalempe, definitely don't parse dmesg, just dump it
<sima>
I'm confused ...
<sima>
like if drm panic has opinions about what to dump at panic times
<sima>
then we're in a bikeshed I'm not going to be in
<sima>
and if dmesg is not containing the right stuff, _that_ needs to be fixed
<sima>
not repainted in the drm panic code
<sima>
otherwise bugs filed with drm panic and bugs filed with e.g. pstore are completely different
<sima>
and might be the exact same bug
<javierm>
jfalempe: I agree with sima that as a first step just dumping the kernel log buffer content just as formatted by printk
<javierm>
then doing more fancy stuff could be a follow-up
<jfalempe>
ok, I just find dmesg too cluttered, and prefer to have a stack trace, and hw info separately
ghishadow_ has quit [Ping timeout: 480 seconds]
<sima>
yeah we could try to make sure the panic reason is retained as the first line, just in case
<sima>
although usually that doesn't contain much useful stuff if all the other things have scrolled away due to lack of resolution
<sima>
very often the dmesg line right before the panic is the real hint for what's gone wrong
<sima>
or the backtrace/register state afterwards
kts has joined #dri-devel
<sima>
I don't think I ever took the panic reason into account really beyond "it's dead"
<jfalempe>
yes it's not that usefull, but it's short, and won't confuse users I think.
<sima>
so what I think we want is to dump dmesg, and then try to dump as much as possible of that
<sima>
jfalempe, yeah but it's also no use in practice
<happiestguy>
i think still you could find a way to make smartphone decode capable qr codes, technically possible to do with bluetooth too, i know you say qr codes are camera based, but send the stream over bluetooth if needed, theres not such phone lacking bluetooth.
<javierm>
jfalempe: usually users either can parse the output of just upload a picture for others to make sense of it :)
<javierm>
*or just
<jfalempe>
sima: ok I will change that to kmsg_dump if that the standard way to raise bugs, that makes sense
<sima>
jfalempe, maybe I'm still missing the goal you have perhaps, but yeah for now I'd just dump as much of the bottom end of dmesg as you can from a kmsg_dump hook that only runs for panics
<sima>
since that's also what pstore and the other panic dumpers use that try to make the panic debug info available somewhere else than a kernel console
<sima>
so if it's the wrong thing, it should at least be consistently wrong like all the others
<sima>
iirc john ogness talked about reworking that entire flow that no matter whether it's a kmsg_dumper or the new kernel console with the safe locking (with a fixed serial driver or something like that), you should get the same dmesg output
<jfalempe>
at least you can compare it with other panic reports. we may revisit when drm_panic will be ubiquitous.
<sima>
jfalempe, kmsg_dump would also give us the option of dumping an oops
<sima>
which does destroy the output buffer state in cases where userspace still continues to run, but sometimes the kernel is already too dead to actually debug what's going on
<javierm>
but agree that as a first step just dumping the dmesg log makes sense
wv[m] has joined #dri-devel
<sima>
javierm, that's not the same kind of info in the qr code as we discussed in the past for linux
<sima>
for linux the real debug info is the dmesg, and there's no convenient database to map that to something more meaningful really
<jfalempe>
sima: yes but usually with oops you can still use the graphics, if we repaint the screen it might filcker and not be that useful ?
<sima>
the panic reason is definitely not comparable
<sima>
jfalempe, yeah, therefore only as an option
<digetx>
pepp: thanks! though virtio-comment ML isn't related to this channel, hoped you could reply to the email :)
<sima>
jfalempe, javierm so adding the panic reason as the very first line to make sure it's not scrolled away does sound like a good idea after a bit of digging around
<sima>
but I think the way to do that is by adding it to kmsg_dumper, so that we can do both in one go
<jfalempe>
sima, one of the useful panic reason, is when it fails to mount / because you messed up your drive/ramdisk.
heat has quit [Remote host closed the connection]
<sima>
yeah there's some that are good info, but usually the screen should be big enough that you still see that line
heat has joined #dri-devel
<sima>
infuriatingly the last line in dmesg repeats the panic reason, but that's printed _after_ kmsg_dump
<sima>
so maybe the right fix is to move kmsg_dump further down
<jfalempe>
also qr code in window's BSOD doesn't contain any debug info. it's just a static link to their support website.
<sima>
yeah already replied to javierm that this isn't really what we want
<sima>
jfalempe, I think it has enough to include the error reason, but windows has an actual list and not just a string that people randomly decide on when they merge another panic() call
<javierm>
sima: panic reason just before kmsg_dump makes sense regardless indeed, since that's useful for serial too
<sima>
javierm, yeah ...
<sima>
javierm, the entire panic code after kmsg_dump(PANIC) is very much yolo anyway ...
<karolherbst>
does anybody have patches to share for basic HDMI 2.1 support in drm? Like... edid parsing and everything which doesn't require the approval of the HDMI dudes?
<javierm>
jfalempe: there are also tools like ./scripts/decode_stacktrace.sh that people use
<javierm>
which a picture would be harder but I guess there are ocr command line tools to get the text
<jfalempe>
yes that's why I prefer qrcode, than fbcon dmesg output.
<sima>
jfalempe, like on really low-res screens it's quite likely that the top part of the panic output won't show up, but not really anything we can do for that :-/
<sima>
javierm, all the various tools is why we should get out unchanged dmesg
<sima>
whether that's screen or qr code or whatever
<jfalempe>
fbcon panic dump on 4K display, is not that easy to read either.
<javierm>
sima: yeah, agreed
<sima>
jfalempe, you can set a bigger font, but at least it's all there
Nefsen402 has quit [Remote host closed the connection]
bl4ckb0ne has quit [Remote host closed the connection]
emersion has quit [Remote host closed the connection]
sudeepd has quit [Read error: Connection reset by peer]
<javierm>
jfalempe: or take a picture and zoom in :)
<jfalempe>
javierm: ;)
Nefsen402 has joined #dri-devel
emersion has joined #dri-devel
bl4ckb0ne has joined #dri-devel
fab has joined #dri-devel
psykose has quit [Remote host closed the connection]
psykose has joined #dri-devel
Company has quit [Quit: Leaving]
anujp has joined #dri-devel
anujp has quit [Ping timeout: 480 seconds]
anujp has joined #dri-devel
kzd has joined #dri-devel
Rusty_Almighty has joined #dri-devel
ninjaaaaa has quit [Ping timeout: 480 seconds]
simondnnsn has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
guludo has quit [Ping timeout: 480 seconds]
guludo has joined #dri-devel
yyds has quit [Remote host closed the connection]
happiestguy has quit [Quit: Leaving]
rcf has quit [Quit: WeeChat 3.8]
rcf has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
anujp has quit [Ping timeout: 480 seconds]
dorcasli_ has quit [Remote host closed the connection]
junaid has joined #dri-devel
simondnnsn has quit [Ping timeout: 480 seconds]
ninjaaaaa has joined #dri-devel
simondnnsn has joined #dri-devel
anujp has joined #dri-devel
Duke`` has joined #dri-devel
heat is now known as Guest2760
heat has joined #dri-devel
Guest2760 has quit [Ping timeout: 480 seconds]
anujp has quit [Ping timeout: 480 seconds]
anujp has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
simon-perretta-img has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
Dark-Show has quit [Remote host closed the connection]
Dark-Show has joined #dri-devel
warpme has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
simondnnsn has quit [Ping timeout: 480 seconds]
ninjaaaaa has quit [Ping timeout: 480 seconds]
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
ninjaaaaa has joined #dri-devel
junaid has quit [Remote host closed the connection]
simondnnsn has joined #dri-devel
ghishadow has left #dri-devel [#dri-devel]
warpme has quit []
* zmike
sits down to fix more cts tests
sgruszka has quit [Quit: Leaving]
manospitsid has left #dri-devel [#dri-devel]
<agd5f>
karolherbst, you need the HDMI spec for most of that
<karolherbst>
why though?
<jessica_24>
hey @pq, did you get a chance to check the latest revision of the solid fill IGT tests (https://patchwork.freedesktop.org/series/127900/)? just wanna make sure I addressed all your comments
<agd5f>
karolherbst, it's part of the spec
<karolherbst>
well.. what if I check what a different open source driver is doing instead?
simon-perretta-img has joined #dri-devel
junaid has joined #dri-devel
<karolherbst>
like.. the edid-decode thing actually decodes all the relevant FRL bits, and nvidias open driver also does HDMI 2.1
<karolherbst>
so I don't see a reason why we'd need to read the spec for anything (or ask for permission)
<DemiMarie>
just because the HDMI 2.1 spec isn’t available doesn’t mean that you can’t figure out how it works
<karolherbst>
there is nothing to reverse engineer?
<karolherbst>
I just check how other open source drivers supporting HDMI 2.1 do it?
<karolherbst>
but the point is really just if any work we'd need in drm core has been done and if people have patches for it
warpme has joined #dri-devel
<karolherbst>
of course there will be bits which you might the spec for, but I specifically asked for the ones you don't
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
sudeepd has joined #dri-devel
sudeepd has quit []
sudeepd has joined #dri-devel
<zmike>
mareko: almost done fixing all these tests your opt pass broke
<DemiMarie>
agd5f: is there any part of HDMI 2.1 that userspace needs to care about?
<DemiMarie>
agd5f: what about just only shipping DisplayPort and expecting the OEM to provide an adapter if they care about HDMI?
simon-perretta-img has quit [Ping timeout: 480 seconds]
<DemiMarie>
karolherbst: I hope there is enough to get the uAPI right, because otherwise there are serious problems 😢.
<karolherbst>
there are no uapi relevant bits
<karolherbst>
why would userspace even care?
LinuxHackerman has left #dri-devel [#dri-devel]
warpme has quit []
<zamundaaa[m]>
Userspace might care about the auto low latency thing
<zamundaaa[m]>
But personally all I want with it is to have it always be enabled
<DemiMarie>
karolherbst: I thought EDID is parsed in userspace/
<zamundaaa[m]>
Demi: userspace always gets the full edid, there's no specifics that would be part of uAPI
<DemiMarie>
zamundaaa: I see
<karolherbst>
zamundaaa[m]: heh... I wonder if there are any drawbacks...
<karolherbst>
but for now, I just want users to allow using 4K@120 modes :D
<zamundaaa[m]>
karolherbst: it'll disable some processing on the TV side. For me that's a plus, but I could imagine some users wanting that processing to happen for video playback
simondnnsn has quit [Ping timeout: 480 seconds]
<karolherbst>
yeah fair..
ninjaaaaa has quit [Ping timeout: 480 seconds]
<karolherbst>
but it would be a new drm property or something, right?
<karolherbst>
nothing we really need knowledge from the HDMI spec
<zamundaaa[m]>
Yeah
<karolherbst>
for us (nouveau/nvidia) all the link training is done in firmware, so I don't really see what I need to know besides "this is the FRL the link supports" and "I want this FRL speed to be set and do please link train and give me the result" :D
<DemiMarie>
karolherbst: would it be feasible to implement native context support for Nouveau?
ninjaaaaa has joined #dri-devel
simondnnsn has joined #dri-devel
<agd5f>
I don't know that I can really say much without exposing details of the spec
<airlied>
karolherbst: yeah just go ahead and make it work, intel only enables it via lspcon chips, so should be similiar enough to what nouveau needs
<airlied>
but nouveau needs a lot of work in that area afaik
<airlied>
since I don't think it handles bpp yuv/rgb etc stuff properly at all
fab has quit [Quit: fab]
fab has joined #dri-devel
<karolherbst>
yeah.. probably it doesn't :D
<airlied>
so for nouveau it add a bunch of display handling that doesn't exist first afaik
fab has quit []
<karolherbst>
yeah.. though for now I just want to know if I can get the faster links working and to drive higher refresh rates