Re: How to maintain relative position of two surfaces?

I am not familiar with subsurfaces as I am new to weston. I will look at it and see how it works. Thanks, Hongze On Wed, Sep 24, 2014 at 8:45 PM, Jasper St. Pierre wrote: > This sounds like you want to use subsurfaces, then. > > Any reason you can't just draw the child surface on top of the fat

Re: How to maintain relative position of two surfaces?

This sounds like you want to use subsurfaces, then. Any reason you can't just draw the child surface on top of the father surface, though? On Wed, Sep 24, 2014 at 6:16 PM, Hongze Zhao wrote: > Hi Jasper, > > Thanks for reply. > > Here is my use case. > > Suppose we have a client called "father"

Re: How to maintain relative position of two surfaces?

Hi Jasper, Thanks for reply. Here is my use case. Suppose we have a client called "father", who has a larger surface called "father surface" and a client called "child", whose smaller surface is "child surface". The child surface should be displayed in a given relative position above father surf

Re: How to maintain relative position of two surfaces?

The only way to position surfaces relatively one to another is by using a subsurface. But I imagine this isn't exactly what you want. Can you explain a bit more about your use case? What happens if I put one surface on a different workspace from the others? Should the two be stacked independently

How to maintain relative position of two surfaces?

Hi All, I am doing some experiments on weston compositor. I am wondering if someone could give me some hints about how to maintain relative position of two surfaces. Suppose I have two wayland clients. After I grab and move the surface of one client, I would like to maintain the relative position

Re: [PATCH weston 1/3] Introduce pointer lock interface

On 09/24/2014 09:04 AM, Matthieu Gautier wrote: If for any reason the user move the mouse and the pointer position doesn't change (cause of pointer lock or pointer is already on a screen corner), a motion event is still generated but with surface_x/surface_y being the same as the previous ones.

Re: [PATCH weston 1/3] Introduce pointer lock interface

On 09/23/2014 10:34 PM, Peter Hutterer wrote: I figured the fixed type would be used, and wrap around. At 100 units/per inch the 24.8 fixed type would wrap to where the sign changed after the mouse was moved in the same direction for 1.3 miles. I think clients can ignore this possibility, or if

Re: [PATCH weston 1/3] Introduce pointer lock interface

You cannot add new events to a request or an argument. You can add a new event, but that would be double the traffic for every move. Additionally, the only time relative events are actually useful is when you can know that you will receive them beyond the bounds of your entire surface (e.g. FPS gam

Re: [PATCH weston 1/3] Introduce pointer lock interface

Le 24/09/2014 16:41, Jason Ekstrand a écrit : On Wed, Sep 24, 2014 at 1:46 AM, Matthieu Gautier > wrote: Hi Jason, Well, I'll try to be more concise. In fact, there are two unrelated parts in my proposition : # First part : getting relative events

Unable to get events from my touchscreen in Weston using libinput

Hello, I am using weston-1.6.0 with wayland-1.6.0 libinput-0.6.0 compiled for ARM with yocto When I start weston I can see that the touch is detected in the logs : """[13:28:20.166] input device 'ADS7846 Touchscreen', /dev/input/event0 is a touch device """ Here is the complete log : http://pas

Re: [PATCH weston 1/3] Introduce pointer lock interface

On Wed, Sep 24, 2014 at 1:46 AM, Matthieu Gautier wrote: > Hi Jason, > > Well, I'll try to be more concise. > > In fact, there are two unrelated parts in my proposition : > > # First part : getting relative events > > Passing through a wl_pointer that may not exists to get relative events > seem

Re: [PATCH libinput 3/4] touchpad: hook up left-handed configuration

Hi, On 09/23/2014 08:09 AM, Peter Hutterer wrote: > Tapping and clickfinger is unaffected, physical and software buttons are > swapped. The main area of a clickpad remains as left button though. > > Signed-off-by: Peter Hutterer > --- > src/evdev-mt-touchpad-buttons.c | 17 - >

[PATCH wayland 2/4] tests: add timeout test

sanity test if timeouts work. Signed-off-by: Marek Chalupa --- tests/sanity-test.c | 25 + 1 file changed, 25 insertions(+) diff --git a/tests/sanity-test.c b/tests/sanity-test.c index 46f4f85..5a03e7c 100644 --- a/tests/sanity-test.c +++ b/tests/sanity-test.c @@ -29,6 +

[PATCH wayland 1/4] tests: add timeout

Add test_set_timeout() function that allows the test to set timeout for its completition. Any other call to the function re-sets the timeout to the new value. The timeouts can be turned off (usefull when debugging) by setting evironment variable NO_TIMEOUTS. Signed-off-by: Marek Chalupa --- test

[PATCH wayland 3/4] tests: use test_set_timeout in display-test

replace call to alarm() with test_set_timeout() Signed-off-by: Marek Chalupa --- tests/display-test.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tests/display-test.c b/tests/display-test.c index a1e45b1..8435d60 100644 --- a/tests/display-test.c +++ b/tests/displ

[PATCH wayland 4/4] queue-test: put back timeout

In 93e654061b9 we removed call to alarm() that served as timeout in this test. Now when we have test_set_timeout() func, return the timeout back. Signed-off-by: Marek Chalupa --- tests/queue-test.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tests/queue-test.c b/tests/queue-test.c inde

[PATCH wayland] tests: use our own XDG_RUNTIME_DIR for tests

Use $XDG_RUNTIME_DIR/wayland-tests for tests. This way we won't be messing XDG_RUNTIME_DIR and it also fixes a bug, when socket-test failed when another compositor was running. Signed-off-by: Marek Chalupa --- tests/test-runner.c | 52 1 file

Re: [PATCH V2] wayland.xml: add "enum", "bitfield" and "is_bitfield" attributes

Le 22/09/2014 23:47, Jason Ekstrand a écrit : I would certainly like to do this, but wl_output.transform is always passed as a signed integer and I'm not sure if this is a bitfield or not. I assumed it is, because you can reconstruct

Re: [PATCH weston 1/3] Introduce pointer lock interface

Hi Jason, Well, I'll try to be more concise. In fact, there are two unrelated parts in my proposition : # First part : getting relative events Passing through a wl_pointer that may not exists to get relative events seems a bit odd to me. My main idea is to have a new object (I've call wl_re