07:28 <DPA> I need some directions regarding the problem that ro->kms_fd isn't taken into account, which can lead to the allocation of BOs on the wrong device, here:

07:28 <DPA> https://gitlab.freedesktop.org/DPA/mesa/-/blob/master/src/gallium/winsys/etnaviv/drm/etnaviv_drm_winsys.c#L107

07:28 <DPA> https://gitlab.freedesktop.org/DPA/mesa/-/commit/cf923e7ebccf5857b5f8804dd78378f583bfba18

07:28 <DPA> Or I could make it also check kms_fd. Or I could restructure some things to keep the pipe_screens as consolidated as possible like so:

07:28 <DPA> What is the prefered way to solve this? I could just remove the hash_table and always make it call screen_create.

07:28 <DPA> There are probably still a lot of other possible solutions, but what is the right thing to do?

08:09 <austriancoder> DPA: can you provide some more background information? what device, gpu, use case...?

08:12 <austriancoder> DPA: kms device is used for scanout buffers and renderonly lib (renderonly_create_kms_dumb_buffer_for_resource(..)) is responsible for importing a dumb buffer from kms device

08:22 <DPA> austriancoder: On the librem 5 devkit, with this MR applied: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3449

08:22 <DPA> There are 2 kms devices on there, mxsfb for the lcd screen, and dcss for hdmi. kmsro calls etna_drm_screen_create_renderonly with the appropriate kms_fd, here:

08:22 <DPA> https://gitlab.freedesktop.org/DPA/mesa/-/blob/master/src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c#L45

08:22 <DPA> https://gitlab.freedesktop.org/DPA/mesa/-/blob/master/src/gallium/winsys/kmsro/drm/kmsro_drm_winsys.c#L69

08:22 <DPA> https://gitlab.freedesktop.org/DPA/mesa/-/blob/master/src/gallium/winsys/etnaviv/drm/etnaviv_drm_winsys.c#L107

08:22 <DPA> The gpu_fd is for the same device in both cases, so this here:

08:22 <DPA> Will find the already existing pipe_screen for the correct gpu, but for the wrong kms_fd, if both devices are used with gbm.

08:22 <DPA> Creating a scanout buffer for the second kms device using gbm will then be valid for the first instead of the second kms device.

08:29 <DPA> Note how there is one struct renderonly instance per pipe_screen, and that etnaviv uses that when allocating the buffer:

08:29 <DPA> https://gitlab.freedesktop.org/DPA/mesa/-/blob/master/src/gallium/drivers/etnaviv/etnaviv_resource.c#L259-290

09:31 <austriancoder> DPA: okay.. I see the problem - need to think about it

10:08 <austriancoder> DPA: if you would use ro->kms_fd for the hash table it could work with the result to have one pipe_screen for each kms_fd

10:11 <austriancoder> lunch time

17:44 <cengiz_io> hello folks! I'm running 5.4 on an imx6dl and whenever I do drmModeGetResources on /dev/dri/card1 resource values come as default values. any help is greatly appreciated

17:45 <cengiz_io> hello marex

20:52 <marex> cengiz_io: what is /dev/dri/card1 , etnaviv or imx-drm ?