ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
ngcortes has quit [Read error: Connection reset by peer]
<kode54> Another migration.
<kode54> ?
<kode54> Why is there now a migration every few weeks?
<airlied> it's the same one, just either retries or different stages of infrastructure pieces
<kode54> Oh, so this migration has just taken over a month now
<kode54> Sorry it’s causing so much trouble
JohnnyonFlame has joined #dri-devel
Kayden has joined #dri-devel
<benjaminl> yeah... gitlab is an operational nightmare even on my two-user instance. 1+ month for a upgrade of a large instance sounds about right
<benjaminl> my condolences to people working on this
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
yyds has joined #dri-devel
yyds has quit [Remote host closed the connection]
yyds has joined #dri-devel
swick[m] has joined #dri-devel
kunal_10185[m] has joined #dri-devel
krumelmonster has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
i509vcb has quit [Quit: Connection closed for inactivity]
i509vcb has joined #dri-devel
krumelmonster has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
crabbedhaloablut has joined #dri-devel
rz has quit [Remote host closed the connection]
rz has joined #dri-devel
kts has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
kts has joined #dri-devel
kts has quit []
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
Company has quit [Quit: Leaving]
BilalElmoussaoui[m] has joined #dri-devel
FloGrauper[m] has joined #dri-devel
kts has joined #dri-devel
Vin[m] has joined #dri-devel
<YuGiOhJCJ> hello, I am using the driver "intel" with the option "DRI" set to "crocus" in Xorg, it's working fine for OpenGL apps like "glxgears" but when I try Vulkan apps like "vkcube" I get an error saying that I should enable DRI3, indeed when I check the logs of Xorg, I see that only DRI2 is enabled, nothing about DRI3, how to set "DRI" to "crocus" and "DRI" to "3" at the same time in my /etc/X11/xorg.conf.d/92-intel.conf file please?
<airlied> don't use driver "intel"
<airlied> you shouldn't need an xorg.conf at all
<YuGiOhJCJ> I need a xorg.conf because I have an old xorg-server and a recent mesa, so xorg-server by default tries to load the deprecated "i965" file from the Amber branch which is not what I want because it is not anymore available on my computer, so I have to specify to use "crocus" in my xorg.conf, it is mandatory in my case
Duke`` has joined #dri-devel
<airlied> does your old X server have dri3 support?
<YuGiOhJCJ> is there an easy way to check that?
<airlied> xdpyinfo should show DRI2 and DRI3
<airlied> but anyways use modesetting instead of intel and it might just work
<YuGiOhJCJ> indeed DRI3 is missing with xdpyinfo, I only have DRI2
<YuGiOhJCJ> it's weird because I am using the exact same xorg-server version on another computer with and AMD graphics card and DRI3 is enabled I can see DRI3 with xdpyinfo and in the Xorg logs: "[ 24.323] (==) AMDGPU(0): DRI3 enabled" is it possible that DRI3 works with AMD but not with intel/crocus?
<airlied> ah yeah probably intel turns off dri3 for some reason
<airlied> the manpage says it should support all of them when you specify the name
<YuGiOhJCJ> yeah but the problem is that I already set "DRI" to "crocus" so I don't think I can set to "crocus" and "3" at the same time
<airlied> no but the manpage does say it should enable 3 if possible
<airlied> try changing it to 3 and use MESA_LOADER_DRIVER_OVERRIDE=crocus
<airlied> inside the session
<YuGiOhJCJ> wait, I only set it to 3, without loading "crocus" and it wotks! glxgears and vkcube are working at the same time
<YuGiOhJCJ> *works
<YuGiOhJCJ> I see the error in the Xorg logs trying to load the file "i965_dri.so" but I guess it tries to load something else after that
mbrost has quit [Ping timeout: 480 seconds]
<airlied> not sure the intel driver really uses the gl driver anyways, at least for dri3
<YuGiOhJCJ> do you understand this output? https://pastebin.com/tQttYEQ0
<YuGiOhJCJ> "crocus" is not used anymore so I am wondering what is used
<YuGiOhJCJ> but it's working fine, I am happy of the result, I am just wondering what happened exactly
<airlied> YuGiOhJCJ: the X server with intel driver will only use the GL driver for some dri2 stuff, if dri3 is working you probably won't notice any issues
ids1024[m] has joined #dri-devel
sima has joined #dri-devel
<YuGiOhJCJ> ok, I compared with the old output with intel/crocus: https://pastebin.com/G4TjEWkJ it seems that instead of "DRI driver: crocus" we have "DRI driver: i965", so I am not sure how the Xorg server is able to load the i965 driver because the file is missing, we see the error but yeah it's working like that
<airlied> as I said the X server doesn't matter unless you are using glamor, it's what get loaded on the client side that matters more
moben[m] has joined #dri-devel
fab has joined #dri-devel
<YuGiOhJCJ> what is weird is that if I don't specify "DRI" "3" in my xorg.conf file, then I only have DRI2 enabled and so "vkcube" is not working
<YuGiOhJCJ> in the man of the "intel" driver, it is said that "Default: All levels of DRI are enabled for configurations where it is supported." so I expected that DRI3 would be loaded by default
<YuGiOhJCJ> maybe it's because my Xorg server is old and has an obsolete behavior I don't know
nielsdg has joined #dri-devel
itoral has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
glennk has joined #dri-devel
i509vcb has quit [Quit: Connection closed for inactivity]
Duke`` has quit [Ping timeout: 480 seconds]
<RAOF> Hm. It seems like it's possible to get _every_ error return (EBUSY, EINVAL, EACCES) for an asynchronous non-modeset atomic commit even with entirely correct usage?
Leopold__ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
dviola has quit [Quit: WeeChat 4.1.0]
nicofee[m] has joined #dri-devel
KunalAgarwal[m][m] has joined #dri-devel
fab has quit [Quit: fab]
rasterman has joined #dri-devel
vliaskov has joined #dri-devel
sukrutb has quit [Ping timeout: 480 seconds]
kzd has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
gfxstrand has quit [Ping timeout: 480 seconds]
ficoPRO10 has joined #dri-devel
daniliberman[m] has joined #dri-devel
gfxstrand has joined #dri-devel
Vanfanel has joined #dri-devel
mvlad has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
Dark-Show_Pi4 has joined #dri-devel
linyaa has quit [Read error: Network is unreachable]
linyaa has joined #dri-devel
ManMower has quit [Remote host closed the connection]
ManMower has joined #dri-devel
Dark-Show has joined #dri-devel
Dark-Show_Pi4 has quit []
Dark-Show_RPi4 has joined #dri-devel
Dark-Show has quit []
alanc has quit [Ping timeout: 480 seconds]
dcbaker has joined #dri-devel
alanc has joined #dri-devel
ficoPRO10 has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
Dark-Show_RPi4 has quit []
exp80[m] has joined #dri-devel
AlaaEmad[m] has joined #dri-devel
Targetball[m] has joined #dri-devel
cmeissl[m] has joined #dri-devel
K0bin[m] has joined #dri-devel
halfline[m] has joined #dri-devel
dhirschfeld2[m] has joined #dri-devel
jtatz[m] has joined #dri-devel
sigmoidfunc[m] has joined #dri-devel
knr has joined #dri-devel
yuq825 has joined #dri-devel
q4a has joined #dri-devel
bylaws has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
ohadsharabi[m] has joined #dri-devel
lynxeye has joined #dri-devel
naheemsays[m] has joined #dri-devel
yshui` has joined #dri-devel
pcercuei has joined #dri-devel
sarahwalker has joined #dri-devel
gallo[m] has joined #dri-devel
nekit[m] has joined #dri-devel
nick1343[m] has joined #dri-devel
enick_702 has joined #dri-devel
masush5[m] has joined #dri-devel
itoral has quit [Remote host closed the connection]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
pankart[m] has joined #dri-devel
ofirbitt[m] has joined #dri-devel
ficoPRO10 has joined #dri-devel
hansg has joined #dri-devel
robertmader[m] has joined #dri-devel
enunes[m] has joined #dri-devel
YHNdnzj[moz] has joined #dri-devel
MotiH[m] has joined #dri-devel
undvasistas[m] has joined #dri-devel
JosExpsito[m] has joined #dri-devel
viciouss[m] has joined #dri-devel
anfanite396[m] has joined #dri-devel
tursulin has joined #dri-devel
Sumera[m] has joined #dri-devel
enick_185 has joined #dri-devel
Mershl[m] has joined #dri-devel
anarsoul|2 has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
doras has joined #dri-devel
pushqrdx[m] has joined #dri-devel
jenatali has joined #dri-devel
anarsoul has joined #dri-devel
rgallaispou has joined #dri-devel
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
mvchtz has quit [Quit: WeeChat 3.5]
DodoGTA has quit [Quit: DodoGTA]
djbw has quit [Read error: Connection reset by peer]
DodoGTA has joined #dri-devel
mvchtz has joined #dri-devel
T_UNIX has joined #dri-devel
<wv> I'm on imx53, seeming to have some issue with RGB565. I patched kernel so it only advertise RGB565. Also our application is only using RGB565 (cog webkit through WEBKIT_EGL_PIXEL_LAYOUT=RGB565), So I would assume that only 6 5 6 MSB's are used. However, it seems colors are changed at the display output (also 3 LSB's are changing). Display is connected via 24 bits to the LCD port. Is IPU still applying corrections?
glennk has joined #dri-devel
frieder has joined #dri-devel
mchehab_ has joined #dri-devel
<MrCooper> RAOF: EBUSY means there's still a pending commit for any CRTC which has state in the new commit; EACCES means a connector/plane CRTC_ID property has an invalid CRTC ID
<MrCooper> EINVAL should mean some invalid state in the commit, or a bug in the validation code
glennk has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
yyds has quit []
glennk has joined #dri-devel
yyds has joined #dri-devel
Haaninjo has joined #dri-devel
shashanks_ has quit [Remote host closed the connection]
<MrCooper> can Nvidia & Intel discrete GPUs scan out from system memory?
kwizart has joined #dri-devel
shashanks has joined #dri-devel
<MrCooper> benjaminl: this was a migration to a new cluster; upgrades to new GitLab versions normally seem pretty straightforward to us, from my PoV as someone who hasn't been actively involved in it
dv_ has joined #dri-devel
<sima> MrCooper, they can't even texture from system memory in many cases for reasons on intel iirc, much less scan out
<MrCooper> heh, that's rough
<tnt> So they can only copy to/from system memory and that's it ? Or can they do buffer/vertex data ... ?
<alyssa> tarceri: what driver hits th ntt thing
<alyssa> can't repro withthe shadr test on softpipe
<alyssa> (loop gets unrolled or something)
<alyssa> ok, repro'd by disabling unrolling
<alyssa> thanks
jdavies has joined #dri-devel
jdavies is now known as Guest4451
shashanks has quit [Remote host closed the connection]
<enunes> emersion: I tried to look at your branch for https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/327 but it seems to have disappeared with the gitlab issues, can you push again?
<emersion> oh right
glennk has quit [Ping timeout: 480 seconds]
<emersion> should be fixed now
Ella[m] has joined #dri-devel
kts has joined #dri-devel
tak2hu[m] has joined #dri-devel
<enunes> thanks
jasuarez has joined #dri-devel
samueldr has joined #dri-devel
<sima> tnt, iirc it's no using lossless compression (precompressed formats) and no using atomics or something like that
<sima> *precompressed formats are fine I meant
<tnt> sima: tx
Guest4451 has quit [Ping timeout: 480 seconds]
reactormonk[m] has joined #dri-devel
aradhya7[m] has joined #dri-devel
x512[m] has joined #dri-devel
ttayar[m] has joined #dri-devel
nyorain[m] has joined #dri-devel
glennk has joined #dri-devel
enick_991 has joined #dri-devel
dantob has joined #dri-devel
Anson[m] has joined #dri-devel
Quinten[m] has joined #dri-devel
ram15[m] has joined #dri-devel
EricCurtin[m] has joined #dri-devel
msizanoen[m] has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
Company has joined #dri-devel
<emersion> ty daniels!
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
Hazematman has joined #dri-devel
<daniels> np :)
shoffmeister[m] has joined #dri-devel
orowith2os[m] has joined #dri-devel
talcohen[m] has joined #dri-devel
AnuthaDev has joined #dri-devel
kts has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
isinyaaa[m] has joined #dri-devel
vdavid003[m] has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
yyds has quit [Remote host closed the connection]
hch12907 has joined #dri-devel
fab has quit [Quit: fab]
dviola has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
the_sea_peoples is now known as Guest4461
the_sea_peoples has joined #dri-devel
vidal72[m] has joined #dri-devel
Guest4461 has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
AnuthaDev has quit []
treeq[m] has joined #dri-devel
AnuthaDev has joined #dri-devel
ella-0[m] has joined #dri-devel
zzoon_OOO_till_03_Oct[m] has joined #dri-devel
<wv> does the kms driver of ipuv3 applies some color correction by default? It tends to change the pixels surrounding other colors (blue background, 1 white pixel, also pixels around the white one are not exact the blue as intended)
shashanks has joined #dri-devel
<lynxeye> wv: I'm not aware of any color correction being applied by default. If you want to dig more into this the place to look at is the IPU DP setup (ipu_dp_* functions in the kernel driver)
tomba has joined #dri-devel
<wv> lynxeye, but can this be explained by a color correction? We have background color #00005b , so some blueish. Then we put one white pixel #FFFFFF, and pixels around that white pixel (left/right/top/bottom) become #000052
<wv> is that what a color correction does? (I'm not familiar with that)
<pq> wv, where and how do you measure the resulting pixels?
<wv> our display output go to a FPGA, which takes in the values. Giving us the opportunity to read the values directly
<pq> what's is "display output"? HDMI signal?
<pq> wv, could it be that the signal is temporarily YCbCr at some point, perhaps even sub-sampled?
<lynxeye> pq: How do you fill the buffer? CPU writing into a dumb buffer or do you use the GPU?
<wv> display port
<wv> 24bit parallel
<pq> lynxeye's question was for wv I think
<wv> pq, I don't say that cannot be the case, I don't know. I know I only kept RGB565 as DRM_PLANE_FORMAT (by removing all others in the enum). So that would make only RGB565 goes through. I don't know where other color encodings would pop in?
<pq> in the DisplayPort signal
<pq> HDMI and I guess DisplayPort can negotiate a YCbCr format for the signalling. That's completely independent of the framebuffer format.
<wv> pq, can this be disabled?
<pq> wv, does your FPGA grabber not tell you what the format in signal is?
kts has joined #dri-devel
fab has joined #dri-devel
<wv> well, it's just 8 bits per color coming in (rgb), together with the pixelclock. If some encoding/decoding happens, should be earlier
<wv> it's a "fsl,imx-parallel-display"
<pq> I also thought DisplayPort is a serial, multi-lane, packet formatted signalling, not parallel. So I don't think you are actually using DisplayPort.
vliaskov has quit [Remote host closed the connection]
<pq> I don't think my guess of YUV 4:2:0 was right in that case.
<pq> wv, have you tried manually reading the FB after you wrote the white pixel to see if the unexpected values are already there?
<wv> pq, sorry, it's possible I'm wrong. I'm talking about the imx-parallel-display port, which is basically parallel port
<pq> I know nothing of such, unfortunately
<pq> is it intended to drive an LCD panel without... umm, a panel controller or something?
<pq> I'm just wondering if it already includes some hardware signal tuning for the panel analog parts.
<pq> or maybe contrast enhancement
<wv> pq, how can I take a dump of the fb? I just tried a dd of /dev/fb0, but that gives me a console dump, while on the screen I have my blue test thing
<pq> wv, well, how did you write the white pixel?
<wv> using wpewebkit
<pq> yikes
<pq> ok
<wv> but putting a browser dump image as background in weston, gives the same result
<pq> oh you have an image? then use any image viewing tool to check the pixel values
<pq> are they what you expect them to be?
<pq> e.g. geeqie, gimp, whatever
hansg has quit [Quit: Leaving]
glennk has joined #dri-devel
a-865 has quit [Quit: ChatZilla 0.17.1 [SeaMonkey 2.53.17.1/20230917131154]]
AnuthaDev has quit []
kelbaz[m] has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
Daanct12 has quit [Quit: WeeChat 4.1.0]
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
fkassabri[m] has joined #dri-devel
<lynxeye> wv: My bets would be on the KMS driver being innocent. Probably you get dithering in the GL driver with the RGB565 framebuffer.
<DavidHeidelberg> daniels: for the deqp_fraction of venus-lavapipe. Now it's 15, let's say we need 45 for the pre-merge to fit under 15 minutes.
gdevi has joined #dri-devel
<daniels> wouldn’t 30 be enough to halve it … ?
<DavidHeidelberg> But now, for nightly job 35 minutess * 15 (let's assume "DEQP_FRACTION: null"),, that's 8 hours. Maybe just FRACTION 10 would be enough to be around 1 hour?
<daniels> and yeah, sure
<DavidHeidelberg> daniels: I can try. But for the full job, I think we cannot do the "full job" :D
<DavidHeidelberg> until we get some super-fast runners
<daniels> heh, or shard it
<DavidHeidelberg> daniels: compromise, 35 to get closer to 15 minutes for pre-merge?
<daniels> sounds good
<DavidHeidelberg> daniels: 4 runners per 2 hours? isn't that bit much for venus?
kallisti5[m] has joined #dri-devel
<DavidHeidelberg> I'll start with fraction 10, timeout: 120m for nightly and fraction 35 for pre-merge
<DavidHeidelberg> and we'll see :)
znullptr[m] has joined #dri-devel
kwizart has quit [Quit: leaving]
<daniels> nice
kwizart has joined #dri-devel
yyds has joined #dri-devel
agd5f_ has joined #dri-devel
Tooniis[m] has joined #dri-devel
kts has joined #dri-devel
tomeu has joined #dri-devel
<wv> pq, dump is taken via inspector tool, but everything looks ok there
<wv> lynxeye, that would mean issue is somewhere in adreno?
agd5f has quit [Ping timeout: 480 seconds]
illwieckz has quit [Ping timeout: 480 seconds]
<daniels> wv: btw, you said earlier that you had RGB565 as the format, but the colour string doesn't seem like it would fit into 565?
<daniels> also, are you doing any scaling at any point?
<pq> wv, dithering is not a bug, it's an intentional feature. GL has controls to enable/disable it, but the app needs to use them.
<lynxeye> wv: IIRC GL has dithering default enabled, but most GPUs really only do dithering with reduced color depth formats like rgb565. If you don't want any dithering in GL you need to disable it via glDisable(GL_DITHER), which would be something wpe needs to set in your case.
<pq> wv, can you take a screenshot instead of a inspector tool dump? Maybe inspector tool renders the whole thing from scratch in a very different way?
<wv> daniels, yes, that's also our concern, that we see also the LSB's moving, while we would not expect that.
<wv> pq, that's what I tryed, but dumping the /dev/fb0 while there's a browser running, still dumps the console in stead of the browser
<wv> lynxeye, I'll have a look, thanks
<pq> wv, no, not /dev/fb, but... you'd need a display server to run the app on, not on bare KMS.
<pq> or, one of the horrible KMS screenshot hacks
AnuthaDev has joined #dri-devel
<pq> wv, btw. do you expect that when a 6-bit value is converted to 8-bit, it is simply padded with zeros?
<pq> if the meaningful bits are MSB, and LSB get added, then for pixel values it is common to replicate the MSB in the LSB in order to keep the "nominal" value more precise.
<pq> e.g. conversion from u8 in to u16 out would be out = (in << 8) | in, so you get non-zero LSB.
<wv> pq, that's an interesting remark... I was indeed expecting the values to be padded with zero's, but indeed, makes more sense to have some value in
<wv> nevertheless, that would not explain why pixels on top, bottom, left and right would change colors
<pq> true
<wv> lynxeye, is there a way to verify if htis dithering is truely enabled in my case?
<lynxeye> wv: Are you using the opensource GL drivers or closed blob one?
<wv> opensource mesa/freedreno
<lynxeye> wv: You can check if this condition is true (and you may hack out dithering there, to check the theory): https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/freedreno/a2xx/fd2_blend.c?ref_type=heads#L111
rasterman has quit [Quit: Gettin' stinky!]
Newbyte has joined #dri-devel
mbrost has joined #dri-devel
kzd has joined #dri-devel
<linyaa> what's the best channel to ask questions about CI infra?
<wv> lynxeye, thanks, trying it out
tdaapare has joined #dri-devel
yuq825 has left #dri-devel [#dri-devel]
glennk has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
<robclark> linyaa: I guess here or #freedesktop ?
tintou has joined #dri-devel
<wv> lynxeye, great, at first sight it seems it solved our issue!
<wv> so dithering seems to have been the issue
<wv> *our issue ;-)
AnuthaDev has left #dri-devel [#dri-devel]
mbrost has quit [Ping timeout: 480 seconds]
<lynxeye> wv: Note that dithering is quite useful with 16bit rendertargets, as it hides most of the color banding you would usually see with those low depth targets. So ideally you would only disable it in cases where you care about exact color reproduction.
hansg has joined #dri-devel
<wv> lynxeye, well, as a matter of fact we do as our fpga needs the exact values for our application.
<wv> but there' still something weird. If we put an image as background in weston-desktop, it's ok now
<wv> if we load the exact same image in webkit, there's still some difference in the pixels themselves, not the ones around at first sight. But something to lookin to later. Have to run for the kids now
<wv> thanks for the help so far!
Duke`` has joined #dri-devel
zzxyb[m] has joined #dri-devel
shalem has joined #dri-devel
hansg has quit [Read error: Connection reset by peer]
mbrost has joined #dri-devel
doraskayo has joined #dri-devel
Armote[m] has joined #dri-devel
illwieckz has joined #dri-devel
yyds has quit [Remote host closed the connection]
<hch12907> oh, gitlab.fd.o has ipv6 access now? that's pretty nice!
<DavidHeidelberg> 🥳
sukrutb has joined #dri-devel
sergi1 has joined #dri-devel
djbw has joined #dri-devel
DavidHeidelberg has quit [Remote host closed the connection]
DavidHeidelberg has joined #dri-devel
DavidHeidelberg has quit [Remote host closed the connection]
ficoPRO10 has quit [Ping timeout: 480 seconds]
mclasen has joined #dri-devel
mclasen has quit []
<MrCooper> karolherbst: do you know if Nvidia GPUs can scan out from system memory?
<karolherbst> no idea tbh
ryanneph has joined #dri-devel
DavidHeidelberg has joined #dri-devel
sarahwalker has quit [Remote host closed the connection]
ficoPRO10 has joined #dri-devel
rasterman has joined #dri-devel
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
glennk has joined #dri-devel
a-865 has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
apinheiro has quit [Quit: Leaving]
<mmind00> Hi all, can someone tell me if the patch at https://lore.kernel.org/all/20231023173718.188102-2-jonas@kwiboo.se/ adding some NV-something fourcc types is good to go?
<mmind00> While I can handle the driver changes well, I don't have enough experience in core drm-land and definitly don't want to mess up something that add uapi elements
zamundaaa[m] has joined #dri-devel
kos_tom has joined #dri-devel
<zamundaaa[m]> Sigh, looks like the matrix bridge was disconnected again
<zamundaaa[m]> emersion: do you know if the mst path (PATH property without the "mst:connectorid") is guaranteed to be unique on a given KMS node?
pp123[m] has joined #dri-devel
gouchi has joined #dri-devel
kwizart has quit []
kwizart has joined #dri-devel
egalli has joined #dri-devel
<emersion> zamundaaa[m]: pretty sure it's not
<emersion> there could be two identical docks on two different DP ports
<zamundaaa[m]> Is there at least some way to find out which DP port a connector is connected to?
<zamundaaa[m]> I guess I can still make it work without that as well, but it's more messy
<daniels> mmind00: go for it
<mmind00> daniels: hehe ... thanks for the vote of confidence, will do :-)
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
tursulin has quit [Ping timeout: 480 seconds]
<bl4ckb0ne> is there some tooling around to visualize the std140 layout?
jolan has quit [Quit: leaving]
jolan has joined #dri-devel
i509vcb has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
<gfxstrand> dcbaker: Any thoughts on NAK merging?
dv_ has quit [Quit: WeeChat 3.8]
<bl4ckb0ne> pahole for spirv would be the best
ajhalaney[m] has joined #dri-devel
<gfxstrand> I'm not aware of any
<alyssa> gfxstrand: r-b
<alyssa> :p
<Sachiel> NAK merging what?
<zmike> NAK
<bl4ckb0ne> cant even find a layout visualizer
i-garrison has quit []
* bl4ckb0ne adds it to the everlasting and growing todo list
i-garrison has joined #dri-devel
<ccr> what about ACK? or is it NAK on ACO -> ACK? :P
<kisak> AMD COmpiler Kompiler
frieder has quit [Remote host closed the connection]
<ccr> yo we heard you like compilers so ..
<alyssa> ccr: apple cool kompiler
<alyssa> or agx or asahi
<ccr> \o/
aura[m] has joined #dri-devel
<alyssa> :p
shalem has quit []
rasterman has quit [Quit: Gettin' stinky!]
Duke`` has quit [Ping timeout: 480 seconds]
siddh has joined #dri-devel
gouchi has quit [Remote host closed the connection]
MrSchmidt has joined #dri-devel
rgallaispou has left #dri-devel [#dri-devel]
djbw_ has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
djbw has quit [Ping timeout: 480 seconds]
kusma has joined #dri-devel
JohnnyonFlame has quit [Read error: Connection reset by peer]
Eighth_Doctor has joined #dri-devel
<emersion> zamundaaa[m]: sorry, not sure i get your question… you mean get the parent connector?
<zamundaaa[m]> yes
<emersion> zamundaaa[m]: have you seen my patch sent today on wayland-devel?
ngcortes has joined #dri-devel
<zamundaaa[m]> oh, I think I misunderstood that. So the parent connector is one of the always-existing connectors for a given KMS device?
<emersion> yes
<zamundaaa[m]> okay, then I could construct an actually-unique identifier by getting that connectors index or sth
<emersion> yeah…
<emersion> see ville's reply
<zamundaaa[m]> On the other hand, having two identical docks with two identical outputs that have the exact same EDID (or no EDID) connected to two DP ports is an edge case of an edgy edge case. Falling back to the connector name in such a case is probably ok
<zamundaaa[m]> emersion: well, that's annoying. I would've thought that at least for the always-existing connectors the order would be stable
ficoPRO10 has quit [Ping timeout: 480 seconds]
<emersion> me too…
<zamundaaa[m]> But, ignoring those special edge cases, mst minus parent connector should already be good enough for my use case
<zamundaaa[m]> Thanks for your help
<emersion> plz stable PATH prop for every connector…
co1umbarius has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
columbarius has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos_ has joined #dri-devel
Jeremy_Rand_Talos has quit [Read error: Connection reset by peer]
mbrost has joined #dri-devel
MrSchmidt has quit []
mbrost has quit [Ping timeout: 480 seconds]
DemiMarie has joined #dri-devel
DemiMarie is now known as Guest4514
mbrost has joined #dri-devel
Guest4514 is now known as DemiMarie
koike has joined #dri-devel
koike is now known as Guest4515
pcercuei has quit [Quit: dodo]
ryanneph has quit [Remote host closed the connection]
mbrost has quit [Ping timeout: 480 seconds]
ced117 has quit [Ping timeout: 480 seconds]
heat has quit [Read error: Connection reset by peer]
mvlad has quit [Remote host closed the connection]
RAOF_ has joined #dri-devel
crabbedhaloablut has quit []
RAOF has quit [Ping timeout: 480 seconds]
shashanks_ has joined #dri-devel
shashanks has quit [Ping timeout: 480 seconds]
<anholt> anyone have CTS fixes that have landed that they wish were in mesa ci? now's your chance to slip one in. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25872
<zmike> haha I was gonna ask if you got that one and then I clicked
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel