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 <fjhenig...@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. _______________________________________________ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle