[Mesa-dev] create src/wsi

[Emil Velikov]

On 23 October 2017 at 16:03, Jason Ekstrand <jason at jlekstrand.net> wrote:
> On Mon, Oct 23, 2017 at 6:27 AM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
>>
>> On 21.10.2017 03:00, Dylan Baker wrote:
>>>
>>> This very short series creates a new src/wsi folder, and moves
>>> wayland-drm into
>>> it. Basically wsi stuff is scattered about, and is needed by multiple
>>> components
>>> within mesa, wayland-drm, for example, is used by EGL, GBM, and vulkan
>>> wayland-wsi.
>>>
>>> I think there's more that could be moved into wsi, we could move EGL,
>>> GBM, and
>>> GLX, and vulkan/wsi, for example.
>>
>>
>> The general thrust sounds good to me.
>>
>> Is there a clean model for what should go into src/wsi and what shouldn't?
>> Where's the boundary?
>>
>> For an example of the type of headaches, does DRI driver code (stuff that
>> ends up in xxx_dri.so, for example) count as part of src/wsi? If so, then
>> what about gallium/state_trackers/dri? What about mesa/drivers/dri/common?
>
>
> Maybe?  I guess it depends on what it does and how much sense it makes to
> share it higher than the gallium level.
>
>>
>> I don't have a full picture of all this code so it's hard for me to say,
>> but I really hope your changes will lead to a clearer picture overall :)
>
>
> Dylan and I talked about it quite a bit off-line so I have a few opinions.
> :)  In particular, here's what I envison:
>
> src/wsi/gbm
> src/wsi/egl
> src/wsi/wayland-drm
> src/wsi/dri3 (currently src/loader)
> src/wsi/glx
> src/wsi/vulkan (currently src/vulkan/wsi)
> src/wsi/hgl
>
Idea is mostly ok, but there's a bit of a snafu:

Things are not as clean cut/split as per above. Here are some of the
current inter-dependencies.

src/loader - loader.c WSI agnostic DRI loader code.
src/loader - loader_dri3.c X11 DRI3 code.

gbm - depends on loader.c, wayland-drm (I've sent patches to remove this), egl
egl  - depends on loader.c loader_dri3.c wayland-drm, gbm (pokes one
of the AMD devs to attempt this)
vulkan - has completely different wayland-drm/X11 dri3 code.

One could be able to flatten and use uniform interface across the
board. I would be weary as above code gets limited testing with
piglit/CTS/dEQP.

-Emil