[waffle] [RFC] Add display support to GBM backend

[Chad Versace]

On 11/20/2014 12:04 PM, Emil Velikov wrote:
> Hi all,
> 
> On 19/11/14 19:38, Chad Versace wrote:
>> Frank sent this patch as a proof-of-concept. It's a draft, and not ready
>> for committing. I'm posting to the list just to start discussion.
>>
>> See [https://github.com/waffle-gl/waffle/issues/18]. I think detailed
>> patch discussions like this are easier over email than Github's issue
>> tracker, so let's keep the bulk of the discussion in email.
>>
>> Frank, I haven't examined every detail in this patch. I focused on the
>> high-level design.  I'll probably wait to examine the fine details until
>> you submit a real patch for upstreaming.
>>
>>> From: Frank Henigman <fjhenigman at chromium.org>
>>> Date: Tue, 21 Oct 2014 22:58:45 -0400
>>> Subject: [PATCH] gbm WIP: show gbm buffers on screen
>>>
>>> Four options based on the value of environment variable MODE:
>>> COPY: copy render buffer to scanout buffer and flip to scanout buffer
>>> FLIP: scan out directly from render buffer
>>> ORIG: do what the code originally did, i.e. nothing
>>> unset or empty: don't display, but still lock and release buffer
>>>
>>> TO DO
>>> - make it a compile time option
>>> - make it a proper run time option, via config attributes or something,
>>>   instead of by env var
>>
>> I prefer to make the display-mode a runtime option via attributes to
>> waffle_window. Perhaps we should define a new function:
>>
>>    struct waffle_window*
>>    waffle_window_create_attrs(struct waffle_config *config,
>>                               const intptr_t attrib_list[]);
>>
> That makes perfect sense, and I think we can make use of it in WGL/GLX.
> Just a quick question here:
>  - Should the attrib list be platform specific, generic(for all
> platforms) or both ?
> 
> "Both" might be a nice approach, this way we can have
> - WAFFLE_WINDOW_FULLSCREEN
> - WAFFLE_GBM_WINDOW_DISPLAY_MODE
> - WAFFLE_WGL_WINDOW_HACKS
> - other..

I prefer "both" too. That should simplify the API.

> An interesting/related point here is :
> How do we handle platforms where the display device is not the same as
> the one doing rendering.

That will eventually become an interesting a problem to solve. But I think
it best if we defer solving it until initial support lands for GBM display.
 
> [snip]
>>> +// scanout from buffer
>>> +static bool
>>> +buffer_flip(struct buffer *buffer)
>>> +{
>>> +    struct drm_display *drm = drm_display_init(buffer->dpy);
>>> +    if (!drm || !drm->mode)
>>> +        return false;
>>> +
>>> +    if (gbm_bo_get_width(buffer->bo) < drm->mode->hdisplay ||
>>> +        gbm_bo_get_height(buffer->bo) < drm->mode->vdisplay) {
>>> +        wcore_errorf(WAFFLE_ERROR_UNKNOWN,
>>> +                     "cannot flip buffer smaller than screen");
>>
>>    This error message got me thinking... Maybe waffle_window_create()
>> should
>>    interpret (w,h)=(-1,-1) as a fullscreen window.
>>
> Can we use WAFFLE_WINDOW_FULLSCREEN (or similar) ? Would be nice to
> avoid the assumptions and keep everything explicit and clear.

Yeah, WAFFLE_WINDOW_FULLSCREEN is better than (-1, -1). Using a token also
opens up the future ability to intelligently resize the fullscreen window when the
display resolution changes.
 
> Should we change the name to drm, as currently we relate the platform
> name with the display used :P

Nah, let's keep the name unchanged for now. Changing it gives little benefit
but introduces compatibility/conversion headaches.