modesetting: implement everything using libgbm as well as dumb_bo

[stefan11111]

Only a proof of concept for now.

libgbm from mesa is a generic buffer management library for gpu buffers.
In the modesetting driver, we also roll our own dumb_bo implementation, so that we don't depend on libgbm.
libgbm supports allocating dumb buffers, as well as "smarter" buffers.

With this, everything that was only implemented with dumb_bo, is now also implemented with libgbm.

The next steps after this are to decouple libgbm from glamor, to allow using it even when we don't have accelerated modesetting.

After that, I think we should remove the dumb_bo implementation, and use libgbm for everything.

While writing this, I also noticed some questionable code, which I wrote some comment about.

Closes: #734

[stefan11111]

@notbabaisyou ping

[cepelinas9000]

I know It is offtopic, shouldn't be here to be something smarter? Because all nvida card which i have, only supports xBGR2101010

[stefan11111]

I'm not sure what we can do better here.
Do we have any way of querying the format?

[notbabaisyou]

Wouldn't it make more sense to assign the actual value, distros with older libgbm that don't support the feature would ignore the value anyway.

[stefan11111]

We'd be passing flags to libgbm that it doesn't support, and hope that it does the right thing and ignores them.

[stefan11111]

gbm-only path now works with/without glamor, with/without shadowfb (on my system, at least)

[github-actions]

Merge Conflict found

[github-actions]

Merge Conflict found

[stefan11111]

@metux @callmetango @cepelinas9000 @notbabaisyou @ONykyf
Thoughts on the idea to implement everything with libgbm and use that as the primary path?

[github-actions]

Merge Conflict found

[cepelinas9000]

@metux @callmetango @cepelinas9000 @notbabaisyou @ONykyf Thoughts on the idea to implement everything with libgbm and use that as the primary path?

I support it - going though mesa libgbm it tries to use optimal path for gpu memory and etc.

It just i have nit as going though code (i know we not using for cursors yet and i'm not familar with mesa code) but it looks like it don't want play nice with cursors:

1. If we create gbm buffer with GBM_BO_USE_CURSOR in src/gbm/backends/dri/gbm_dri.c
2. deeper in code there are magic 64x64 constant for cursor in src/gallium/frontends/dri/dri2.c

@stefan11111 wont it be problem?

[stefan11111]

@metux @callmetango @cepelinas9000 @notbabaisyou @ONykyf Thoughts on the idea to implement everything with libgbm and use that as the primary path?

I support it - going though mesa libgbm it tries to use optimal path for gpu memory and etc.

It just i have nit as going though code (i know we not using for cursors yet and i'm not familar with mesa code) but it looks like it don't want play nice with cursors:

1. If we create gbm buffer with `GBM_BO_USE_CURSOR` in [src/gbm/backends/dri/gbm_dri.c](https://gitlab.com/freedesktop-sdk/mirrors/freedesktop/mesa/mesa/-/blob/main/src/gbm/backends/dri/gbm_dri.c?ref_type=heads#L803)

2. deeper in code there are magic 64x64 constant for cursor in [src/gallium/frontends/dri/dri2.c](https://gitlab.com/freedesktop-sdk/mirrors/freedesktop/mesa/mesa/-/blob/main/src/gallium/frontends/dri/dri2.c#L989)

@stefan11111 wont it be problem?

It shouldn't be a problem, since that check isn't there on the dumb path.
I wonder if the check on the modifiers path is intended, or just forgotten from when libgbm forced cursor buffers to be 64x64?