gbm backend doesn't display anything

[fjhenigman]

Unlike all the other backends, gbm is off-screen only. I've got drm/kms display working on this branch, though it's WIP:
https://github.com/fjhenigman/waffle/tree/gbmdisplay
At the moment it's controlled by environment variable because it was convenient and I was undecided on how to do it right. I thought of a few ways:

1. different platforms, e.g. WAFFLE_PLATFORM_GBM and WAFFLE_PLATFORM_GBM_ONSCREEN
2. new context flags, e.g. WAFFLE_CONTEXT_OFFSCREEN - might be relevant to other platforms
3. show on screen if waffle_window_show() is called, otherwise do not
4. add argument(s) to waffle_display_connect() or waffle_window_create() or waffle_window_show()
5. new function(s)
   1-3 have the advantage of not changing the waffle api, though 3 is only an on/off option, it wouldn't allow specifying copy vs. flip for example. As for option 1 we might not want to clutter the platform namespace with a lot of things like WAFFLE_PLATFORM_GBM_OFFSCREEN, WAFFLE_PLATFORM_GBM_FLIP, WAFFLE_PLATFORM_GBM_COPY...
   Option 2 is avoids that, and is nicely open-ended, but display details maybe don't belong with context?

[fjhenigman]

I see the value in keeping device-specific code out of waffle and I think there's a nice way forward.
We're working on a new gbm implementation called "minigbm" for chrome os, though I think anyone could use it (https://code.google.com/p/chromium/issues/detail?id=413947) and a corresponding waffle backend (https://code.google.com/p/chromium/issues/detail?id=431585).
This should let us keep all device specific display code in minigbm, and still add display capability to waffle.
For chrome os we might be fine with some defaults, but the api seems lacking in display control. Passing a list of attributes to waffle_display_connect and/or waffle_window_create (as is done with waffle_config_choose) could have a lot of uses (option 4/5 in my list above).
Interested in any feedback about:

• extending waffle api for display options
• waffle backend for minigbm

[linyaa-kiwi]

I want to see Waffle gain a minigbm backend. Lately, my general opinion about graphics features throughout the Linux stack has been "If Chrome OS needs it, then let's do it". Within reason, of course ;)

@fjhenigman Apologies that I haven't had a chance to deeply look at your gbmdisplay branch yet. A few days after you first contacted me about it, I had to take unexpected medical leave from work. I returned at end of October, and am still tying up the loose ends that I left hanging that month.

Unlike all the other backends, gbm is off-screen only. I've got drm/kms display working on this branch, though it's WIP:
https://github.com/fjhenigman/waffle/tree/gbmdisplay
At the moment it's controlled by environment variable because it was convenient and I was undecided on how to do it right. I thought of a few ways:

1. different platforms, e.g. WAFFLE_PLATFORM_GBM and WAFFLE_PLATFORM_GBM_ONSCREEN

I dislike (1). Let's try to coalesce onscreen and offscreen GBM into the same platform, the existing WAFFLE_PLATFORM_GBM.

2. new context flags, e.g. WAFFLE_CONTEXT_OFFSCREEN - might be relevant to other platforms
3. show on screen if waffle_window_show() is called, otherwise do not
4. add argument(s) to waffle_display_connect() or waffle_window_create() or waffle_window_show()

Some combination of 2, 3, and 4 feels right to me. I'm open to adding an extensible attribute list parameter to each waffle_display_connect() and waffle_window_create(), and possibly waffle_window_show(). I regret that I didn't do that originally.

If we do add additional parameters to those functions, I prefer to avoid ABI breakage by actually introducing new function names, and preserving the old function signatures as-is. Perhaps name the variants like waffle_display_connect2() or waffle_display_connect_attrs() or waffle_display_connect_attribs().

1-3 have the advantage of not changing the waffle api, though 3 is only an on/off option, it wouldn't allow specifying copy vs. flip for example. As for option 1 we might not want to clutter the platform namespace with a lot of things like WAFFLE_PLATFORM_GBM_OFFSCREEN, WAFFLE_PLATFORM_GBM_FLIP, WAFFLE_PLATFORM_GBM_COPY...
Option 2 is avoids that, and is nicely open-ended, but display details maybe don't belong with context?

I'm unsure which object (display, context, window?) to associate the new attributes to. Definitely not the waffle_config. And I don't feel qualified to make that decision alone. I need to lean on your expertise here.

Let's continue this conversation, and I'll take a closer look at minigbm and your gbmdisplay branch no later than Wed 19 Nov (and hopefully sooner).

[fjhenigman]

@chadversary No worries about not looking. I mainly just wanted to start this discussion. And now I'm more interested in a minigbm waffle platform and implementing display for that. If you think there will still be a use for gbm display after we have minigbm, I can try to share display code between them.
Thanks for your input on API question. I'll reply after giving it more thought.

[laanwj]

I think it's a pity that this never went through.

I'm working on an open source embedded GPU driver etnaviv and for the current target device I need screen rendering without any window system. I also have to be able to switch backends without recompiling (to compare the DRM driver against the proprietary one).

Right now I'm hacking my custom EGL shim into every application that does GL output, but it's quite limited, extending it would pretty much mean duplicating Waffle (badly). So I may instead pick this up at some point.

[fjhenigman]

There is a working WAFFLE_PLATFORM_SURFACELESS back end in my waffle fork that uses gbm and does display on screen. Let me know if you're interested and I'll figure out which branch you should try. One of these years it should get merged into the main waffle repo.

[laanwj]

I'm certainly interested!

[fjhenigman]

If you're desperate you can try this:
fjhenigman@945aec7
The platform is actually called WAFFLE_PLATFORM_NULL in there. It works (it's been in use for chrome os tests for some time) but it is now 1.5 years behind mainstream waffle. I have a later branch where I worked on polishing this stuff for eventual un-forking, but if I recall it is WIP and I wouldn't recommend it.
It look like Chad is hard at work bringing this functionality into mainstream waffle (see mailing list) where it will be called WAFFLE_PLATFORM_SURFACELESS.

[evelikov]

@chadversary I believe you had some ideas [1] how to get KMS support. Can you please elaborate a bit so that others can give it a stab ?

[1] https://lists.freedesktop.org/archives/waffle/2016-October/001563.html