<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="#0563C1" vlink="#954F72"> <div class="WordSection1"> Clear some definition for easy understanding.<o:p></o:p> Supposed B is beside A. B maybe leftof, rightof, above, or below A.<o:p></o:p> If leftof, output(B) is the horizontal parent of A.<o:p></o:p> If above, output(B) is the vertical parent of A.<o:p></o:p> If rightof, output(B) is the horizontal child of A.<o:p></o:p> If below, output(B) is the vertical child of A.<o:p></o:p> <o:p> </o:p> With definition, you will be easy to set up a binary tree. But you may think some node may have two parent. The answer is no, you can have a try to move and will find it is right. Just let you know my mistakes I ever made. When you move output to be leftof or above of another, the output will take the place of another instead of really above or left of the position of another. J After that, you will be know why one node has one parent at most.<o:p></o:p> <o:p> </o:p> Of course, the original layout will be one horizontal line for extended mode.<o:p></o:p> <o:p> </o:p> If clone mode is supported, that is fine. Keep clone link for that in output structure. The algorithm will be updated with minimal. But it will be easy and based on clone mode design.<o:p></o:p> <o:p> </o:p> Thanks<o:p></o:p> <o:p> </o:p> Regards<o:p></o:p> <o:p> </o:p> Quanxian Wang<o:p></o:p> <o:p> </o:p> <a name="_MailEndCompose"><o:p> </o:p></a> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in"> From: Wang, Quanxian Sent: Wednesday, April 16, 2014 11:26 AM To: wayland-devel@lists.freedesktop.org Cc: Wang, Quanxian; Pekka Paalanen (ppaalanen@gmail.com); Jason Ekstrand (jason@jlekstrand.net); Bryce W. Harrington (b.harrington@samsung.com); Fu, Michael; Hardening (rdp.effort@gmail.com); Kang, Jeong Seok Subject: [Weston] More discussion about weston output relative motion algorithm<o:p></o:p> </div> </div> <o:p> </o:p> Hi, All<o:p></o:p> <o:p> </o:p> Relative motion of output is needed in Weston compositor or others. For example, plugin a monitor, you want move it above or leftof or rightof or below others.<o:p></o:p> <o:p> </o:p> More details about this motion algorithm will be shown in the email. Before that, I mention one point, I don’t refer any code from others including xserver. My idea is based on the current Weston compositor design and statistics. It is original for Weston compositor. At the same time, when I implemented it, I try to make parameters to be general. If possible, make it common instead of only in randr protocol.<o:p></o:p> <o:p> </o:p> Weston movement algorithm<o:p></o:p> <o:p> </o:p> If only support one line layout. For example, all vertical or all horizontal, it is very easy to implement. But if we want support both at the same time, it will be more complex instead of 1+1=2. Currently in Weston compositor, only horizontal is supported. Compositor uses output_list to make it happen.<o:p></o:p> <o:p> </o:p> Here are the summary of motion properties.<o:p></o:p> <o:p> </o:p> <![if !supportLists]>1) <![endif]>It is similar with binary tree. Here are some related features. Every node is one output.<o:p></o:p> <![if !supportLists]>a. <![endif]>Every node have one parent at most, also the parent maybe from vertical, maybe from horizontal(it is different with binary tree). But never has two parents. I will not explain why, you can use 4 outputs to do more movement, and you can find this.<o:p></o:p> <![if !supportLists]>b. <![endif]>Every node have two children at most. One is for vertical, another is for horizontal. <o:p></o:p> <![if !supportLists]>c. <![endif]>The tree will link all outputs, if you find some output is not in link, that means link is lost. So when you plugin or output, you need make the link complete. When scan Weston.ini configure, you need to organize the tree following this algorithm.<o:p></o:p> <![if !supportLists]>d. <![endif]>Only one start point(root) exists whose coordinate is x=0 and y=0). From that, you could find all other outputs and position them from left up most to right down most. <o:p></o:p> <![if !supportLists]>e. <![endif]>Every branch from the main branch will never cross each other.<o:p></o:p> <![if !supportLists]>2) <![endif]>The tree is double linked.<o:p></o:p> <![if !supportLists]>3) <![endif]>The only have-to interrupt is when one node is deleted, which child takes its place? Currently I force its horizontal child will take its place.<o:p></o:p> <o:p> </o:p> By the way, I list some statistics. Maybe you could find some interesting why I post more effort on this algorithm. Layout means the final result of all outputs’ position.<o:p></o:p> <o:p> </o:p> Output_number Possible_Layout_number One_line_possbile_layout_number<o:p></o:p> 1 1 1 <o:p></o:p> 2 2x2=4 (2=2x1) 2<o:p></o:p> 3 5x6=30 (6=3x2x1) 6<o:p></o:p> 4 14x24=336 (24=4x3x2x1) 24<o:p></o:p> <o:p> </o:p> You could find that, if we have 4 outputs, there are 14x24=336 possible layout types. So the algorithm has to be designed as complete instead of only for 2, or 3, or less. It should be designed for more. For example, supposed 500, 1000 outputs. Yes, it is in theory. But the algorithm must be that. I enumerate them based on the movement and get the possible layouts. For example, when you have 4 outputs, even if they are in one line, there are 4x3x2x1=24 layouts.<o:p></o:p> <o:p> </o:p> Algorithm Implementation:<o:p></o:p> To implement this algorithm, more links have to be added for output. I add vlink and hlink into output structure. Currently I implemented it in randr protocol (will be posted in next version of Weston randr protocol)<o:p></o:p> <o:p> </o:p> With that features above, two links(vlink and hlink) should be added into current output structure and the tree should be set up. (This will not affect the usage of original list in output). More patches will be needed.<o:p></o:p> <![if !supportLists]>1) <![endif]>Initialization (auto found outputs and link them together)<o:p></o:p> <![if !supportLists]>2) <![endif]>Dynamic plugin and out.<o:p></o:p> <![if !supportLists]>3) <![endif]>If Weston.ini supports the layout, it should work with the algorithm.<o:p></o:p> <![if !supportLists]>4) <![endif]>Randr protocol<o:p></o:p> <o:p> </o:p> Important:<o:p></o:p> Currently the algorithm is implemented in randr protocol. But I want to move it into common code instead of only randr protocol. I am not sure if it is right and where to put algorithm code. I need agreement and discussion for that. If no permission, I will let it in randr protocol (create another structure for output, plus vlink and hlink).<o:p></o:p> <o:p> </o:p> Thanks<o:p></o:p> <o:p> </o:p> Regards<o:p></o:p> <o:p> </o:p> Quanxian Wang<o:p></o:p> <o:p> </o:p> <o:p> </o:p> </div> </body> </html>