My wayland port of xfwm4 currently consists of two binaries, a compositor and a
helper client. The compositor sends events to the helper client using a private
protocol. The helper client controls the compositor. The helper client
basically contains all the code of the original xfwm4. The tabwin
On 23/12/2022 00:14, Jessica Zhang wrote:
Loosen the requirements for atomic and legacy commit so that, in cases
where solid fill planes is enabled (and FB_ID is NULL), the commit can
still go through.
In addition, add framebuffer NULL checks in other areas to account for
FB being NULL when soli
On 23/12/2022 00:14, Jessica Zhang wrote:
Initialize and use the color_fill properties for planes in DPU driver. In
addition, relax framebuffer requirements within atomic commit path and
add checks for NULL framebuffers. Finally, drop DPU_PLANE_COLOR_FILL_FLAG
as it's unused.
Changes since V2:
-
Hello there,
> The compositor-and-helper-client approach works fine for the tabwin, but it
> may have limitations when attempting to port server-side decorations. I
> suppose copying the X11 approach could result in a lot of pointless
> back-and-forth between the helper client and server. How c
