Hi pq, Le 29/02/2016 15:43, Pekka Paalanen a écrit : > Hi Bryce, > > On Fri, 26 Feb 2016 13:37:59 -0800 > Bryce Harrington <[email protected]> wrote: > >> To followup Pekka's recent libweston thread, here's the next actions it >> looks like we should take? >> >> a. Revert 5ffbfffa > > Yes. > >> b. Land https://patchwork.freedesktop.org/patch/67547/, which covers >> the drm-backend. (Is this patch proposal good as is, or would it >> benefit from any additional review?) > > Yes, though struct weston_backend_config still needs a 'size_t > struct_size' added as the first member with the following semantics: > - the caller must set struct_size to sizeof(struct > weston_whatever_backend_config) > - if a backend receives a struct_size smaller or equal to what it uses, > it uses the given portion > - if a backend receives a struct_size greater than what it uses, it > must fail >
ok I will update my patches set accordingly. > What happens with struct weston_drm_backend_output_config is still open > a bit. I think we should just land something that gets us forward for > now, and rethink the whole output hotplugging. > > I feel the current approach of "backend found a new output, it demands > some parameters and will extend the desktop there" is a bit rigid. A > more flexible design would be to maintain a dynamic list of possible > outputs with hotplug notifications, and the compositor can then itself > enable, disable and configure outputs as it wants. So rather than a > backend always unconditionally enabling a connected output, it gives the > decision to the compositor which can also pick the layout etc. The current approach is broken, imo. Your proposal look good. > > This might even allow to better integrate nested and bare compositors: > a windowed nested compositor could just create any new output, while a > bare compositor checks if the output is actually connected and succeeds > or fails output enabling accordingly. > > But I assume this will be a major work, so it must not hold up the > libweston effort on other fronts. > >> c. Defer the two alternative options for now >> https://patchwork.freedesktop.org/patch/73206/ >> >> https://patchwork.freedesktop.org/patch/[73035,73036,73037,73038,73039] > > Yes, and we may want to have a comment in the code pointing to e.g. the > email thread where these were discussed, in case the matter comes up > again. > >> d. Review/update wayland-backend and x11-backend to comply >> https://patchwork.freedesktop.org/patch/74553/ >> https://patchwork.freedesktop.org/patch/74504/ > > Yes. > >> This establishes Giulio's "Well Defined Structs" approach for >> configuring libweston backends. This uses versioned structs for >> communicating parameters with the backends. >> >> If no one raises an objection to this plan, I can tackle (a), (b) and >> (c) myself directly. For (d), offhand it appears they at least need to >> add the structure versioning support, but might be suitable to consider >> landing after that? > > Very good. > > > Thanks, > pq > > > > _______________________________________________ > wayland-devel mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
