Yes those branches are not related at all. Unless we expect each client to create a fullscreen transparent/empty surface on every output.
Do we really want to support client side decorations?
If so we could have a look at xdg-shells way of doing it. When a window drag should be started (because the client clicked on the client side title bar) the client sends a request to move the window according to a given input device. The compositor then either denies or takes over the processing of the input events. I could not verify that, but I assume that the compositor is in charge of ending the window drag.
If we expect the client to emit relative surface motion (in surface coordinates - in the surface plane) we need to make sure that unity8 clients receive relative motion. The disadvantage of this would be two or maybe one frame slower than the above.
Yes those branches are not related at all. Unless we expect each client to create a fullscreen transparent/empty surface on every output.
Do we really want to support client side decorations?
If so we could have a look at xdg-shells way of doing it. When a window drag should be started (because the client clicked on the client side title bar) the client sends a request to move the window according to a given input device. The compositor then either denies or takes over the processing of the input events. I could not verify that, but I assume that the compositor is in charge of ending the window drag.
If we expect the client to emit relative surface motion (in surface coordinates - in the surface plane) we need to make sure that unity8 clients receive relative motion. The disadvantage of this would be two or maybe one frame slower than the above.