<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"> 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>