#dri-devel on 2022-11-10 — irc logs at oftc.irclog.whitequark.org

2022-08-14 19:45 ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar

00:07 Leopold has quit [Remote host closed the connection]

00:18 pcercuei has quit [Quit: dodo]

00:19 <daniels> mirko: I’m afraid you have to do it in the application

00:36 ybogdano has joined #dri-devel

00:56 yuq825 has joined #dri-devel

01:02 mbrost_ has joined #dri-devel

01:05 mbrost has quit [Ping timeout: 480 seconds]

01:11 mbrost_ has quit [Ping timeout: 480 seconds]

01:14 enunes has joined #dri-devel

01:25 mbrost has joined #dri-devel

01:29 <macromorgan> would this be the right IRC to discuss panel drivers?

01:32 co1umbarius has joined #dri-devel

01:33 columbarius has quit [Ping timeout: 480 seconds]

01:37 <airlied> macromorgan: yes most likely

01:38 <macromorgan> would it be possible to get a review of 2 that I submitted upstream? It's the last piece of hardware before I can close the book on a series of handheld devices.

01:40 <macromorgan> one is very straight-forward, I basically copied an existing driver that I'm very familiar with (the Elida KD35T133) and changed the init sequence and drm modes. That's this one here: https://lore.kernel.org/dri-devel/20221028205009.15105-4-macroalpha82@gmail.com/

01:41 <macromorgan> The other is a bit odd... it's the only panel (that I can see) of it's kind in the kernel, whereby commands are sent via SPI but data is sent via DSI. There's a few where commands are sent via SPI and data via DPI which I used as a guide: https://lore.kernel.org/dri-devel/20220926164333.7485-3-macroalpha82@gmail.com/

01:51 rotationmatrix has quit [Quit: Leaving]

01:53 rotationmatrix has joined #dri-devel

01:59 <mirko> macromorgan: feel free to tell me which channel would be suited better - got it from the MAINTAINERS file within the DRM project

01:59 alyssa has left #dri-devel [#dri-devel]

02:00 <mirko> daniels: hm, that's unfortunate, especially since the HW supports it natively and it's not just code maintenance re this particular setup, but also computing overhead in software :/

02:03 <mirko> macromorgan: ah, probably your question was totally unrelated to what I was saying - nevermind then..

02:21 <mirko> x

02:25 karolherbst has quit [Remote host closed the connection]

02:28 karolherbst has joined #dri-devel

02:44 mbrost has quit [Ping timeout: 480 seconds]

03:03 ngcortes has quit [Remote host closed the connection]

03:04 ybogdano has quit [Ping timeout: 480 seconds]

03:10 enunes has quit [Quit: ZNC - https://znc.in]

03:15 enunes has joined #dri-devel

03:52 aravind has joined #dri-devel

04:15 YuGiOhJCJ has joined #dri-devel

04:17 mbrost has joined #dri-devel

04:27 <DemiMarie> daniels: is there some reason that KMS cannot do a 180 degree rotation?

04:31 dreda has quit [Ping timeout: 480 seconds]

04:46 rmckeever_ has joined #dri-devel

04:52 rmckeever has quit [Ping timeout: 480 seconds]

04:53 rmckeever_ has quit []

04:55 dreda has joined #dri-devel

04:55 dreda is now known as Guest1030

05:26 lemonzest has quit [Quit: WeeChat 3.6]

05:38 bmodem has joined #dri-devel

06:06 kts has joined #dri-devel

06:15 Duke`` has joined #dri-devel

06:17 Scorpi_ has quit [Remote host closed the connection]

06:17 Scorpi has joined #dri-devel

06:22 bgs has joined #dri-devel

06:29 fab has joined #dri-devel

06:30 kts has quit [Quit: Leaving]

06:34 Duke`` has quit [Ping timeout: 480 seconds]

06:47 kts has joined #dri-devel

06:54 pa has quit [Ping timeout: 480 seconds]

07:04 mszyprow has joined #dri-devel

07:04 mbrost has quit [Read error: Connection reset by peer]

07:06 mbrost has joined #dri-devel

07:13 srslypascal has quit [Remote host closed the connection]

07:13 srslypascal has joined #dri-devel

07:14 mbrost has quit [Ping timeout: 480 seconds]

07:17 itoral has joined #dri-devel

07:20 fab has quit [Quit: fab]

07:21 dcz_ has joined #dri-devel

07:28 bgs has quit [Remote host closed the connection]

07:37 pa has joined #dri-devel

07:46 heat has quit [Ping timeout: 480 seconds]

07:52 fab has joined #dri-devel

07:54 danvet has joined #dri-devel

07:55 srslypascal has quit [Remote host closed the connection]

07:55 srslypascal has joined #dri-devel

07:57 gouchi has joined #dri-devel

07:58 gouchi has quit []

08:05 tzimmermann has joined #dri-devel

08:05 rasterman has joined #dri-devel

08:10 frieder has joined #dri-devel

08:13 tursulin has joined #dri-devel

08:20 MajorBiscuit has joined #dri-devel

08:26 rgallaispou has joined #dri-devel

08:26 MajorBiscuit has quit [Quit: WeeChat 3.6]

08:34 frieder has quit [Quit: Leaving]

08:34 frieder has joined #dri-devel

08:35 MajorBiscuit has joined #dri-devel

08:38 mvlad has joined #dri-devel

08:40 srslypascal has quit [Remote host closed the connection]

08:40 srslypascal has joined #dri-devel

08:40 <linusw> macromorgan: I try to review display drivers sometimes

08:41 swalker__ has joined #dri-devel

08:43 swalker_ has joined #dri-devel

08:44 swalker_ is now known as Guest1047

08:49 swalker__ has quit [Ping timeout: 480 seconds]

08:53 <linusw> macromorgan: I went in and reviewed it.

08:54 <linusw> daniels, DemiMarie: rotation in HW can be done by the display itself in many cases, and then you could use e.g. custom DT props to make it happen.

08:55 <linusw> but in general it would be nice if KMS supported 90/180/270 degrees rotation because vendors use it a lot, sometimes in the panel itself, sometimes in the display controller.

08:55 lynxeye has joined #dri-devel

08:56 jkrzyszt has joined #dri-devel

08:57 <clever> linusw: as an example, the 2d scanout hardware on the rpi has h-flip and v-flip flags, so it can trivially do a 180 degree rotation and mirroring, but 90/270 require an extra transposer step, that writes the frame to ram and then does scan-out a second time

08:57 <linusw> clever: yeah that's in the display controller then

08:58 <clever> but, i dont think kms has any way to advertise that 90/270 are more expensive

08:58 <clever> and if your already using the 3d core for composition, rotating your vertex data first would drastic reduce memory bandwidth

08:58 <linusw> I guess it falls back to the old 2D acceleration problem space that nobody really want to touch :/

08:59 <clever> the 2d scanout core can also do composition for you

08:59 <clever> its more of a sprite only gpu

08:59 <linusw> aha so it does a bit of blitting and blending and rotating

08:59 <clever> up to ~300 sprites can be defined, each with its own addr, stride, pixel format, hflip, vflip, and alpha

08:59 TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]

08:59 TMM has joined #dri-devel

09:00 <clever> yep

09:00 <clever> it supports sprite wide alpha, and per-pixel alpha

09:00 <clever> both pre-multiplied alpha, and not

09:00 <linusw> on the MCDE they have a separate block "B2R2" for "blit blend rotate rescale" that I currently don't use at all.

09:00 <clever> but there is only a ~5 scanline FIFO between the composition core, and the actual output PHY's

09:01 <clever> if you have too many sprites packed within a few scanlines, it can fall behind and fail to meet the timing deadlines

09:01 <linusw> clever: I suppose you could use it for cursor acceleration? Or do we support that with KMS (I'm a bit rusty)

09:01 <clever> linux enforces a max of 32 sprites via kms, because its using bit masks to track some state

09:01 <linusw> aha

09:01 <clever> and yeah, i believe a lot of stuff assumes you can only do 3 sprites, 1 framebuffer, 1 pointer, 1 Xvideo overlay

09:02 Lucretia has quit [Remote host closed the connection]

09:02 <clever> so things like wayland generally ignore the kms composition, and instead do it all in GL

09:02 <linusw> that seems to be the trend...

09:02 <clever> the rpi composition is also not really able to do depth testing inteligently

09:02 <clever> it just takes every sprite in the list, and draws them into the FIFO, in order

09:03 <clever> if a pixel is covered by 5 sprites, it fetches 5 sprites worth of data from ram, and draws over it 5 times

09:03 <clever> and youve now wasted memory bandwidth on pixels you cant see

09:03 <clever> if its just a mouse pointer, thats fine

09:03 <linusw> I guess you read this https://lwn.net/Articles/881827/

09:04 <linusw> it kind of sums up the situation, it's a lot of ... lose ends

09:04 <clever> https://www.youtube.com/watch?v=u7DzPvkzEGA

09:04 <clever> but when you have this many sprites, all of them being down-scaled, the memory bandwidth can saturate, and it glitches because it cant generate pixels fast enough

09:05 <clever> but part of that i think was my fault, it was also under-clocked severely

09:05 <clever> to figure out what the relationship is between clock and limits

09:05 <clever> hadnt seen that link before, but ive picked up things while talking to many people over the yeas

09:05 <clever> years*

09:06 <clever> linusw: the rpi compositor can also deal with pixel format conversions, sprites can also be in YUV420 format, and it will automatically convert to rgb

09:07 <linusw> I think the problem as it stands is 2D accelerators are a bit "on the side"

09:07 <linusw> People have happily been merging them into the media subsystem though!

09:07 <linusw> I don't know if standard userspace can even make use of that.

09:08 <clever> another problem, is that while the rpi is able to composite a list of sprites and write it to ram, and linux exposes that as a write-back port in kms

09:08 <clever> its part of the same "graphics card", and only the current DRM master (xorg) can use it

09:08 <clever> so nobody can actually use it

09:09 <linusw> For rotation etc there is things like drivers/media/platform/sunxi/sun8i-rotate

09:10 <clever> Xorg is also another source of problems, it expects all images to be rgb

09:10 <clever> so a video player has to do software yuv->rgb conversions, and cant just pass a yuv frame to the kms layer

09:10 <clever> but i hear that at least for fullscreen playback with vlc on the rpi, it grabs a DRM lease, so it can start slinging raw YUV to kms

09:11 <linusw> I think the media subsystem has the ambition to accelerate video streams, such as deinterlace or format conversions though, using accelerators

09:12 <clever> yeah, rpi has been moving a lot of that into v4l mem2mem devices

09:12 <linusw> oh sweet

09:12 <clever> the h264 encode/decode is still driven by the blob, but there are now v4l wrappers around that

09:12 <linusw> but yeah in general it is a bit "throw the problem over the fence" to media instead of integrating properly

09:12 <clever> so userland doesnt need to know the blob api

09:13 <linusw> thats neat

09:13 mszyprow has quit [Read error: Connection reset by peer]

09:13 <clever> bcm2711 (pi4) has h265 decode only, to my surprise, it got proper source on the linux side

09:13 <clever> the blob doesnt support it!

09:13 mszyprow has joined #dri-devel

09:14 <clever> the ISP (image sensor pipeline) is involved in many things, and is (in)directly used by 3 v4l classes

09:14 <clever> it can do yuv<->rgb conversions, which shows up as a dedicated v4l device

09:14 <clever> it can do the full bayer->yuv and all the fancy camera processing, as a dedicated v4l device

09:15 <clever> and h264 encoding, requires 2 copies of every frame, one at half-res, with a wonky tiling format, the h264 blob drivers use the ISP to generate that pair

09:15 <clever> motion estimation runs on the half-res frame

09:15 <javierm> clever: can drm leases be used to allow other processes to use those besides Xorg?

09:15 <clever> i believe so

09:15 <MrCooper> karolherbst: I'm hitting a failure compiling rusticl_mesa_inline_bindings_wrapper.c.o, it can't find valgrind.h (for src/util/simple_mtx.h) because the header file path from valgrind.pc isn't set

09:15 grayshade[m] has joined #dri-devel

09:16 <MrCooper> clever: FWIW, a Wayland compositor is in a much better position to use such HW capabilities than Xorg

09:16 <clever> javierm: https://www.x.org/wiki/Events/XDC2017/packard_drm_lease.pdf a random hit from google, that explains some things about drm leases, in the use-case of head-mounted displays

09:16 Lucretia has joined #dri-devel

09:17 <clever> MrCooper: i still need to try wayland, but i hear it lacks desktop screen capture, which will mess with a lot of screen-sharing i do for work

09:17 <javierm> clever: yes, I'm familiar with the concept of drm leases. Not with the rpi display controller

09:17 <MrCooper> clever: you hear incorrectly :)

09:17 <clever> maybe its changed since i last heard

09:18 <MrCooper> it's out of scope for Wayland itself, but it can work in a Wayland session via XDG portals and PipeWire

09:18 <clever> javierm: on the rpi hardware, there is 3 channels on the hardware compositor, each channel gets its own list of drm planes to render, some sources say only the 3rd channel can do transposition (90/270 rotations), but my own investigations also say all 3 channels can do write-back

09:19 <clever> javierm: but on the vc4, each channel is limited to driving certain video outputs

09:19 <clever> https://github.com/librerpi/rpi-open-firmware/blob/master/docs/pixelvalve.txt#L18-L33

09:20 <clever> vc4 has 3 HVS(hardware compositor) channels and 3 pixel valves (crtc like), and each PV is hard-wired to 2 outputs (but only one can be active on a given PV)

09:20 <clever> so if your using hdmi, you must use PV2, and vec(pal/ntsc) must be disabled

09:21 <clever> vc6 (bcm2711/pi4) still has 3 HVS channels, but now has 5 PV's, and complex mux with partial coverage on each (lines 27-33)

09:22 <clever> pv0(dsi0/dpi) and pv3(vec/ntsc/pal) can only be driven by a single hvs channel, but all other outputs can be driven by any hvs channnel

09:24 <javierm> clever: I see. So then yes, drm leases could allow other processes to use the different channels of the HW compositor

09:24 <clever> the current master just has to allow it

09:25 <javierm> clever: exactly. Is the master who leases the resources

09:25 <clever> i'm still fuzzy on exactly what your allowed to do when you have a lease

09:25 <clever> can you change the resolution of an output? or only update the planes on the output?

09:32 frieder has quit [Quit: Leaving]

09:32 frieder has joined #dri-devel

09:33 <javierm> clever: good question, I don't know either. And the documentations isn't clear about that AFAICT: https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#drm-display-resource-leasing

09:34 <clever> javierm: as another random example, the DPI video out on the rpi, is just a 24bit wide bus, hsync+vsync, slap some DAC's on and boom its vga

09:35 <clever> but, you can also abuse that as a way to just play 24bit samples at a defined rate, for bit-banging protocols or SDR stuff

09:35 <clever> https://github.com/librerpi/rpi-tools/blob/master/utils/kms-test.cpp#L24-L55

09:35 <clever> this code uses the DRM api to emit up to 24 uart streams at once, fully hardware accelerated

09:36 <javierm> clever: ah! I remember now you mention that would use that to hook some servos? Or am I misremembering?

09:36 <clever> however, if Xorg is running, you run into the same problem, and i havent tried adding drm leases to it yet

09:36 <clever> yeah, this could also generate 24 PWM streams for servo's

09:36 <clever> just change the bit patterns in the "framebuffer"

09:37 <javierm> clever: haha, yeah. I remembered correctly then. That was so cool, controlling servos using "images"

09:37 <clever> this current code relies on config.txt to configure the video timing parameters

09:37 <clever> but if i use a DRM api that lets me set the front/back porch and all that stuff, i can tune it at runtime

09:38 <clever> javierm: i got the idea from https://bellard.org/dvbt/

09:38 <clever> thats abusing a VGA DAC to transmit DVB-T signals

09:39 <javierm> clever: I see. Reminded me of https://hackaday.com/2022/04/01/making-your-own-technically-hdmi-oled-monitor/

09:40 <clever> ah, thats abusing the EDID lines, which are just i2c

09:40 <clever> vga also has edid, and can do the same

09:40 pcercuei has joined #dri-devel

09:41 <javierm> clever: exactly

09:45 <clever> > A ‘lease’ is a contract between the lessor and lessee that identifies which resources may be controlled by the lessee.

09:45 <clever> javierm: i would assume that you could lease out a crtc, and then the other program can change resolutions

09:46 <clever> but i would need to do testing to see what the api actually allows, and what Xorg allows

09:46 <javierm> clever: that's my assumption as well. But it's not stated explicitly and I remember someone mentioned that there were some constraints on the leased resources

09:46 <clever> i remember every single object across all types having a unique id within the entire device

09:59 jfalempe has quit [Read error: Connection reset by peer]

09:59 jfalempe_ has joined #dri-devel

10:09 vliaskov has joined #dri-devel

10:18 Haaninjo has joined #dri-devel

10:31 ahajda has joined #dri-devel

10:35 kts has quit [Quit: Leaving]

10:40 YuGiOhJCJ has quit [Remote host closed the connection]

10:40 YuGiOhJCJ has joined #dri-devel

10:54 pa has quit [Ping timeout: 480 seconds]

11:05 devilhorns has joined #dri-devel

11:12 itoral has quit [Remote host closed the connection]

11:18 Jeremy_Rand_Talos__ has quit [Remote host closed the connection]

11:18 Jeremy_Rand_Talos__ has joined #dri-devel

11:24 frieder has quit [Quit: Leaving]

11:25 frieder has joined #dri-devel

11:29 jfalempe has joined #dri-devel

11:34 jfalempe_ has quit [Ping timeout: 480 seconds]

11:38 Leopold_ has joined #dri-devel

11:39 MrCooper has quit [Quit: Leaving]

11:39 Leopold___ has joined #dri-devel

11:40 MrCooper has joined #dri-devel

11:41 mszyprow_ has joined #dri-devel

11:43 mszyprow has quit [Remote host closed the connection]

11:50 frieder has quit [Quit: Leaving]

11:50 frieder has joined #dri-devel

11:55 pcercuei has quit [Quit: brb]

11:58 <zamundaaa[m]> clever: the other program can indeed change the mode. It can do whatever it wants with the drm resources given to it

11:59 mszyprow_ has quit [Remote host closed the connection]

11:59 mszyprow_ has joined #dri-devel

12:03 Akari has quit [Ping timeout: 480 seconds]

12:10 kts has joined #dri-devel

12:13 Jeremy_Rand_Talos_ has joined #dri-devel

12:13 Jeremy_Rand_Talos__ has quit [Remote host closed the connection]

12:13 hansg has joined #dri-devel

12:37 lygstate has joined #dri-devel

12:39 mszyprow_ has quit [Remote host closed the connection]

12:39 mszyprow_ has joined #dri-devel

12:41 devilhorns has quit []

12:47 jrayhawk has quit [Quit: irssi upgrade]

12:47 jrayhawk has joined #dri-devel

13:00 kts has quit [Quit: Leaving]

13:02 pcercuei has joined #dri-devel

13:08 srslypascal is now known as Guest1072

13:08 srslypascal has joined #dri-devel

13:09 pcercuei has quit [Quit: brb]

13:10 jrayhawk has quit [Ping timeout: 480 seconds]

13:13 jrayhawk has joined #dri-devel

13:13 sysescool_ has joined #dri-devel

13:14 sgruszka has joined #dri-devel

13:15 Guest1072 has quit [Ping timeout: 480 seconds]

13:15 frieder has quit [Quit: Leaving]

13:15 frieder has joined #dri-devel

13:20 sysescool has quit [Ping timeout: 480 seconds]

13:29 pzanoni has quit [Ping timeout: 480 seconds]

13:30 <macromorgan> linusw: Thank you very much. I'll make the necessary changes and resubmit.

13:39 <karolherbst> ian not online on IRC? :(

13:52 <daniels> karolherbst: he's on OFTC, just not in this channel

13:52 <karolherbst> I see.. nvm, I left a comment on the MR now :)

13:52 <karolherbst> apparently I have to wire up rusticl + iris for CI 🙃

14:02 Akari has joined #dri-devel

14:06 yuq825 has left #dri-devel [#dri-devel]

14:12 sysescool__Linux has joined #dri-devel

14:13 <MrCooper> karolherbst: speaking of rusticl, did you see my message this morning?

14:14 <karolherbst> probably not

14:14 <karolherbst> where did you send it?

14:14 <karolherbst> ohh

14:14 <karolherbst> that one

14:14 <karolherbst> *sigh*

14:14 <karolherbst> yeah a user reported that yesterday

14:14 <karolherbst> it's one of the things I wanted to fix today

14:16 <MrCooper> cool

14:17 JohnnyonFlame has joined #dri-devel

14:18 sysescool_ has quit [Ping timeout: 480 seconds]

14:25 YuGiOhJCJ has quit [Quit: YuGiOhJCJ]

14:28 frieder has quit [Remote host closed the connection]

14:29 frieder has joined #dri-devel

14:30 <danvet> tzimmermann, do you need someone (i.e. me) to look through your damage worker streamlining, and not just bikeshed?

14:30 <danvet> from a quick look it makes sense

14:32 pcercuei has joined #dri-devel

14:38 Leopold___ has quit []

14:51 <karolherbst> huh, how can I get the include paths of a dependency object in meson?

14:56 <daniels> karolherbst: https://mesonbuild.com/Reference-manual_returned_dep.html suggests 'no'

14:57 <karolherbst> yeah uhm.. that's bad then

14:58 <karolherbst> dcbaker: so I need to be able to pass a dependency object to bindgen, but can't because it doesn't support it

15:01 <tzimmermann> danvet, please do if you have the time. it's supposed to reduce the overhead and latency a bit. nothing critical, but more than bikeshed

15:01 MrCooper has quit [Remote host closed the connection]

15:02 MrCooper has joined #dri-devel

15:02 fab has quit [Quit: fab]

15:03 MrCooper has quit [Remote host closed the connection]

15:04 MrCooper has joined #dri-devel

15:05 fxkamd has joined #dri-devel

15:12 ybogdano has joined #dri-devel

15:14 aravind has quit [Ping timeout: 480 seconds]

15:14 MrCooper has quit [Remote host closed the connection]

15:16 rasterman has quit [Quit: Gettin' stinky!]

15:16 sgruszka has quit [Ping timeout: 480 seconds]

15:19 <ajax> do we really need all the meson gallium-* options to start with the word "gallium"?

15:20 <ajax> there's not another vdpau in the tree

15:20 <psykose> but there might be :)

15:20 rasterman has joined #dri-devel

15:20 <ajax> we should prefix all the options with mesa- then

15:21 <ajax> wouldn't want to confuse people about whether they were configuring mesa or swiftshader or clvk or something

15:24 rasterman has quit []

15:24 <psykose> ?

15:25 <jenatali> Sarcasm (I hope)

15:25 <ajax> taking the "but there might be" logic to an absurd conclusion, yes

15:30 rasterman has joined #dri-devel

15:34 hansg has quit [Quit: Leaving]

15:41 MrCooper has joined #dri-devel

15:42 lygstate_ has joined #dri-devel

15:43 lygstate has quit [Read error: Connection reset by peer]

15:46 fab has joined #dri-devel

15:49 lemonzest has joined #dri-devel

16:04 tursulin has quit [Ping timeout: 480 seconds]

16:10 ybogdano has quit [Quit: The Lounge - https://thelounge.chat]

16:11 heat has joined #dri-devel

16:14 Duke`` has joined #dri-devel

16:15 tzimmermann has quit [Quit: Leaving]

16:17 ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]

16:25 mszyprow_ has quit [Ping timeout: 480 seconds]

16:28 pa has joined #dri-devel

16:40 ahajda has joined #dri-devel

16:41 ybogdano has joined #dri-devel

16:46 ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]

16:58 bmodem has quit [Ping timeout: 480 seconds]

17:00 pzanoni has joined #dri-devel

17:01 sgruszka has joined #dri-devel

17:04 mbrost has joined #dri-devel

17:08 Leopold_ has quit [Remote host closed the connection]

17:09 Leopold_ has joined #dri-devel

17:18 Guest1047 has quit [Remote host closed the connection]

17:19 rgallaispou has quit [Read error: Connection reset by peer]

17:20 <jenatali> lygstate: I'm not comfortable signing off on tree-rearranging changes. You'll need to find other reviewers. I'll stick to my corner of Windows of D3D-mapping drivers

17:24 lygstate_ is now known as lygstate

17:25 <lygstate> jenatali: Any one you'd like to suggest?

17:25 <jenatali> Not sure who'd be the right person to look, but I don't think it's me

17:26 <lygstate> Hope someone take a look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19629

17:33 kts has joined #dri-devel

17:34 kem has quit [Ping timeout: 480 seconds]

17:36 pa- has joined #dri-devel

17:40 bgs has joined #dri-devel

17:41 pa has quit [Ping timeout: 480 seconds]

17:43 kem has joined #dri-devel

17:45 alanc has quit [Remote host closed the connection]

17:46 alanc has joined #dri-devel

17:50 sgruszka has quit [Remote host closed the connection]

17:52 lemonzest has quit [Quit: WeeChat 3.6]

17:54 nchery has quit [Remote host closed the connection]

17:54 nchery has joined #dri-devel

17:55 MajorBiscuit has quit [Ping timeout: 480 seconds]

17:56 frieder has quit [Remote host closed the connection]

18:03 kem has quit [Ping timeout: 480 seconds]

18:04 lynxeye has quit [Quit: Leaving.]

18:11 mvlad has quit [Remote host closed the connection]

18:13 kem has joined #dri-devel

18:16 jkrzyszt has quit [Ping timeout: 480 seconds]

18:18 lynxeye has joined #dri-devel

18:24 <DavidHeidelberg[m]> ajax: Hey. Would you be ok to have Alpine build with EGL only?

18:28 <bl4ckb0ne> +1 for alpine in the ci

18:29 lynxeye has quit [Quit: Leaving.]

18:35 bgs has quit [Remote host closed the connection]

18:36 epoll has quit [Ping timeout: 480 seconds]

18:40 Haaninjo has quit [Read error: Connection reset by peer]

18:43 Haaninjo has joined #dri-devel

18:46 pa has joined #dri-devel

18:46 epoll has joined #dri-devel

18:47 pa- has quit [Ping timeout: 480 seconds]

18:51 <psykose> is there a benefit to it aside from slightly reducing the build time

18:52 <bl4ckb0ne> catching some compilation issue, i had to fix missing headers more than once

19:13 TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]

19:13 TMM has joined #dri-devel

19:29 gouchi has joined #dri-devel

19:42 danvet has quit [Ping timeout: 480 seconds]

19:51 swick[m] has joined #dri-devel

19:59 <vsyrjala> robclark: abhinav__: there are a few reviewed msm patches in https://patchwork.freedesktop.org/series/100393/ do you want to take them or should i push them into drm-misc-next?

20:04 <robclark> vsyrjala: probably drm-misc-next is fine, unless abhinav__ can think of anything they might conflict with

20:09 mhenning has joined #dri-devel

20:11 ngcortes has joined #dri-devel

20:18 Jeremy_Rand_Talos_ has quit [Remote host closed the connection]

20:18 Jeremy_Rand_Talos_ has joined #dri-devel

20:19 fab has quit [Quit: fab]

20:22 rotationmatrix has left #dri-devel [#dri-devel]

20:26 warpme____ has quit []

20:33 kts has quit [Quit: Leaving]

20:34 <macromorgan> is there a list somewhere of the MIPI panel manufacturer codes? Not that it matters but reading panel ID I get 30 00 00 (assume 30 is the manufacturer maybe?)

21:07 <vsyrjala> are those just oui?

21:20 rmckeever has joined #dri-devel

21:23 <gildekel> Hello all. First time chatter here. I work on the ChromeOS graphics team, displays.

21:23 <gildekel> Currently dealing with an issues on MTK devices where the internal panel connectors are not at the top of the connector list. I have a patch in-flight to fix this on MTK (https://patchwork.freedesktop.org/patch/511177/?series=110773&rev=2).

21:23 <gildekel> But I was wondering if, at this point, it wouldn't make sense to one-up this sort the connectors in drm-core?

21:23 <gildekel> It seems like Intel and MSM already use the same solution, and with my patch, if approved, we may have a case to turn this to the default behavior. Thoughts?

21:35 mszyprow_ has joined #dri-devel

21:40 mszyprow_ has quit [Remote host closed the connection]

21:40 mszyprow_ has joined #dri-devel

21:42 <gildekel> msm usage: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/msm/msm_drv.c#n483

21:42 <gildekel> Intel usage: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/i915/display/intel_display.c#n8130

21:43 <gildekel> hwentlan: I have never ran into similar issues in AMD. My intuition tells me there is some effort to order internal panels at the top of the connector list in AMD drivers, but I couldn't verify (still figuring out my way here). Do you happen to know if that's the case?

21:48 oneforall2 has quit [Quit: Leaving]

21:48 <gildekel> hwentlan_: I have never ran into similar issues in AMD. My intuition tells me there is some effort to order internal panels at the top of the connector list in AMD drivers, but I couldn't verify (still figuring out my way here). Do you happen to know if that's the case?

21:49 oneforall2 has joined #dri-devel

21:49 <gildekel> (ugh. sorry for the spam. I am bad at this 😔)

21:52 jfalempe has quit [Quit: Leaving]

22:00 <ajax> gildekel: drivers/gpu/drm/drm_modeset_helper.c:drm_helper_move_panel_connectors_to_head()

22:01 <ajax> hah, only i915 calls it. charming.

22:02 mirko has quit [Quit: leaving]

22:03 <ajax> i'd say do it by default, yeah

22:04 <ajax> i can't think of a good reason not to, and i really dislike the "here's a helper you can call to DTRT" pattern when the "don't do anything special and it'll DTRT" pattern is available

22:06 Duke`` has quit [Ping timeout: 480 seconds]

22:13 gouchi has quit [Remote host closed the connection]

22:14 ngcortes has quit [Read error: Connection reset by peer]

22:14 gouchi has joined #dri-devel

22:14 Duke`` has joined #dri-devel

22:18 bgs has joined #dri-devel

22:25 bgs has quit [Remote host closed the connection]

22:28 dcz_ has quit [Ping timeout: 480 seconds]

22:30 Duke`` has quit [Ping timeout: 480 seconds]

22:47 nchery has quit [Ping timeout: 480 seconds]

22:51 gouchi has quit [Quit: Quitte]

23:02 rmckeever_ has joined #dri-devel

23:08 rmckeever has quit [Ping timeout: 480 seconds]

23:08 gouchi has joined #dri-devel

23:08 gouchi has quit [Remote host closed the connection]

23:15 mbrost_ has joined #dri-devel

23:15 mbrost has quit [Remote host closed the connection]

23:15 pzanoni has quit [Remote host closed the connection]

23:15 pzanoni has joined #dri-devel

23:17 rasterman has quit [Quit: Gettin' stinky!]

23:28 nchery has joined #dri-devel

23:28 Haaninjo has quit [Quit: Ex-Chat]

23:51 pzanoni has quit [Quit: pzanoni]

23:53 <airlied> hmm functions in llvmpipe do not seem to make lux faster :-P

23:55 pcercuei has quit [Quit: dodo]

23:55 <karolherbst> heh

23:56 <airlied> goes down to 61 on the scene

23:56 <airlied> but at least functions seem to work

23:57 <karolherbst> nice

23:57 <karolherbst> do the other benchmark compile?

23:58 <airlied> seems to compile, awaiting some output