Re: xdg shell status and gaps

[Bill Spitzak]

On 09/25/2014 03:04 PM, Jasper St. Pierre wrote:


You mean like the existing set_parent request that has been there since
xdg-shell has landed?

http://cgit.freedesktop.org/wayland/weston/tree/protocol/xdg-shell.xml#n140


Yes except it needs a guarantee about what happens when you change 
parents. Currently I think it will have to do nothing until the new 
parent or the child is raised or mapped or unmapped. The goal is that 
the client can switch between two arbitrary stackings of arbitrary sets 
of surfaces with no "blinking": every pixel on the screen transitions 
exactly once.


For instance setting the parent cannot immediately raise the child 
because the client may add yet another child above that one. That would 
cause two transitions: first from whatever overlaid the first child to 
that child, then from it to the new child.


I have not been able to prove it to myself, but it is possible that 
immediate raises will be allowable as long as the client follows some 
rules about the order it sets the parents (in the above example it sets 
the highest child's parent first). Lowering of windows is definitely 
out, though.


It is also a requirement that the client can defer window raising until 
after it has been able to create and set all the child windows wanted. I 
think preventing window raises entirely is also useful for drag & drop 
sources and just to make overlapping windows useful, so I also want 
clients to be able to refuse to raise.


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: weston-launch failed to start up in system initialize phase.

[Pekka Paalanen]

On Wed, 24 Sep 2014 06:05:17 +
Yang Andy  wrote:

> Hi everyone
> 
> I have a question about weston-launch start up in system initialize phase.
> 
> When i start up target device,weston-launch which is launch from 
> systemd/service is crashed  in system initialize phase.
> 
> But i can run weston-launch correctly when i launch weston-launch from 
> console terminal.
> 
> As below coredump show,it seems that eglGetDisplay has something wrong.
> 
> Could anyone give me some advice?
> 
> Best regards.
> 
> [coredump]
> Core was generated by `/usr/bin/weston -i0'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x76d67cf0 in gcoHAL_QueryChipCount (Hal=Hal@entry=0x0, 
> Count=Count@entry=0x1dea98c) at gc_hal_user_query.c:1002
> 1002gc_hal_user_query.c: No such file or directory.
> (gdb) where
> #0  0x76d67cf0 in gcoHAL_QueryChipCount (Hal=Hal@entry=0x0, 
> Count=Count@entry=0x1dea98c) at gc_hal_user_query.c:1002
> #1  0x76e47a90 in veglGetThreadData () at gc_egl.c:239
> #2  0x76e3e640 in eglGetDisplay (display_id=0x1dea3f0) at gc_egl_init.c:521
> #3 
>  0x76954b5e in gl_renderer_create (ec=0x1de8fd8, display= out>, attribs=0x76957414 , 
> visual_id=0x0) at src/gl-renderer.c:1936
> #4  0x769d9b00 in 
> fbdev_compositor_create (param=0x7ef936dc, config=0x1de6a08, 
> argv=, argc=, 
> display=0x1de64b0)
> at src/compositor-fbdev.c:945
> #5  
> backend_init (display=0x1de64b0, argc=, 
> argv=, config=0x1de6a08) at 
> src/compositor-fbdev.c:998
> #6  0xe6ee in main (argc=1, argv=0x7ef93b24) at src/compositor.c:4240

Hi,

it looks like you are using a properietary graphics stack. We at weston
upstream cannot help you with that, because I assume the source code is
not public.

A wild guess: could it be that your system loads some graphics
(kernel?) drivers in parallel, and when weston is first attempted, the
driver has not loaded yet?


Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: xdg shell status and gaps

[Jasper St. Pierre]

Well, it can't be a state enum, because that's from compositor to client.
We certainly could make it a small extension as part of gtk_shell, though.

On Fri, Sep 26, 2014 at 12:02 AM, Jason Ekstrand 
wrote:

>
> On Sep 25, 2014 3:04 PM, "Jasper St. Pierre" 
> wrote:
> >
> >
> >
> > On Thu, Sep 25, 2014 at 3:58 PM, Bill Spitzak  wrote:
> >>
> >> On 09/25/2014 01:57 PM, Jasper St. Pierre wrote:
> >>
> >>>
> https://github.com/magcius/weston/commit/c1e5a846f4f57400bca1262111f9793e451c5b49
> >>
> >>
> >> That patch has nothing to do with what is needed.
> >>
> >> You don't need a "modal window type". This is trivial for a client to
> do by just pretending that whatever keystrokes it gets go to the "modal"
> window even if the compositor sends them to a different window.
> >>
> >> What is needed is a non-flickering and atomic method of creating that
> modal window atop the main one and keeping it there. That requires a
> parent, not a "modal" flag. (well actually it does not require a parent if
> instead there was a way to atomically map and rearrange a set of surfaces,
> but I think the parent will be much easier and matches what programmers are
> familiar with).
> >
> >
> > You mean like the existing set_parent request that has been there since
> xdg-shell has landed?
> >
> >
> http://cgit.freedesktop.org/wayland/weston/tree/protocol/xdg-shell.xml#n140
>
> If parenting isn't sufficient, it would be easy enough to add a mutter
> extension for modal windows in the form of another state enum.  If it turns
> out to be a well-defined thing other compositors want, we can think about
> moving it to core. In any case, it should be trivial from a protocol point
> of view.
>
> >
> > --
> >   Jasper
> >
> > ___
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> >
>



-- 
  Jasper
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: xdg shell status and gaps

[Jason Ekstrand]

On Sep 25, 2014 3:04 PM, "Jasper St. Pierre"  wrote:
>
>
>
> On Thu, Sep 25, 2014 at 3:58 PM, Bill Spitzak  wrote:
>>
>> On 09/25/2014 01:57 PM, Jasper St. Pierre wrote:
>>
>>>
https://github.com/magcius/weston/commit/c1e5a846f4f57400bca1262111f9793e451c5b49
>>
>>
>> That patch has nothing to do with what is needed.
>>
>> You don't need a "modal window type". This is trivial for a client to do
by just pretending that whatever keystrokes it gets go to the "modal"
window even if the compositor sends them to a different window.
>>
>> What is needed is a non-flickering and atomic method of creating that
modal window atop the main one and keeping it there. That requires a
parent, not a "modal" flag. (well actually it does not require a parent if
instead there was a way to atomically map and rearrange a set of surfaces,
but I think the parent will be much easier and matches what programmers are
familiar with).
>
>
> You mean like the existing set_parent request that has been there since
xdg-shell has landed?
>
>
http://cgit.freedesktop.org/wayland/weston/tree/protocol/xdg-shell.xml#n140

If parenting isn't sufficient, it would be easy enough to add a mutter
extension for modal windows in the form of another state enum.  If it turns
out to be a well-defined thing other compositors want, we can think about
moving it to core. In any case, it should be trivial from a protocol point
of view.

>
> --
>   Jasper
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: xdg shell status and gaps

[Jasper St. Pierre]

On Thu, Sep 25, 2014 at 3:58 PM, Bill Spitzak  wrote:

> On 09/25/2014 01:57 PM, Jasper St. Pierre wrote:
>
>  https://github.com/magcius/weston/commit/c1e5a846f4f57400bca1262111f979
>> 3e451c5b49
>>
>
> That patch has nothing to do with what is needed.
>
> You don't need a "modal window type". This is trivial for a client to do
> by just pretending that whatever keystrokes it gets go to the "modal"
> window even if the compositor sends them to a different window.
>
> What is needed is a non-flickering and atomic method of creating that
> modal window atop the main one and keeping it there. That requires a
> parent, not a "modal" flag. (well actually it does not require a parent if
> instead there was a way to atomically map and rearrange a set of surfaces,
> but I think the parent will be much easier and matches what programmers are
> familiar with).
>

You mean like the existing set_parent request that has been there since
xdg-shell has landed?

http://cgit.freedesktop.org/wayland/weston/tree/protocol/xdg-shell.xml#n140

-- 
  Jasper
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: xdg shell status and gaps

[Bill Spitzak]

On 09/25/2014 01:57 PM, Jasper St. Pierre wrote:


https://github.com/magcius/weston/commit/c1e5a846f4f57400bca1262111f9793e451c5b49


That patch has nothing to do with what is needed.

You don't need a "modal window type". This is trivial for a client to do 
by just pretending that whatever keystrokes it gets go to the "modal" 
window even if the compositor sends them to a different window.


What is needed is a non-flickering and atomic method of creating that 
modal window atop the main one and keeping it there. That requires a 
parent, not a "modal" flag. (well actually it does not require a parent 
if instead there was a way to atomically map and rearrange a set of 
surfaces, but I think the parent will be much easier and matches what 
programmers are familiar with).


I suppose it may be useful for the compositor to know what window is 
actually responding to keystrokes, so it can highlight it. However this 
should be done by the client sending a request to move the keyboard 
focus (ignored if the client does not already have focus). Relying on 
flags and window types to get this correct is really difficult and makes 
it impossible to introduce new window behaviors (for instance surfaces 
that are not modal all the time).

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: xdg shell status and gaps

[Matthias Clasen]

On Thu, Sep 25, 2014 at 4:18 PM, Bill Spitzak  wrote:


> I agree it would be better to just hide the window. Pointer lock (being
> discussed elsewhere) should not be lost when this happens. It sounds like
> the loss of grabs is why you lower rather than hide in X. Also if your
> client wants to identify the clicked window it will need some privileges.

The inspector is in-process, so there is no need for privileges.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: xdg shell status and gaps

[Jasper St. Pierre]

On Thu, Sep 25, 2014 at 2:18 PM, Bill Spitzak  wrote:

> On 09/25/2014 07:32 AM, Jasper St. Pierre wrote:
>
>  1) Marking dialogs as modal (needed so we can implement the 'attached
>> modal' visuals of gnome-shell
>>
>
> I notice this one was ignored. There seems to be some set of people
> working on wayland that hate overlapping windows and want to guarantee they
> are useless.
>

Considering this was one feature I prototyped a patch for, you have no idea
what you're talking about:

https://github.com/magcius/weston/commit/c1e5a846f4f57400bca1262111f9793e451c5b49

 2) Lowering windows (used e.g. by GtkInspector to get out of the way
>> when picking a window
>>
>> I'm not comfortable adding this. You can hide briefly the inspector by
>> giving it a 1x1 blank surface and emptying the input region. Perhaps we
>> should make this equivalent to what the "NULL surface" semantics are.
>>
>
> I agree it would be better to just hide the window. Pointer lock (being
> discussed elsewhere) should not be lost when this happens. It sounds like
> the loss of grabs is why you lower rather than hide in X. Also if your
> client wants to identify the clicked window it will need some privileges.
>

Pointer lock should totally be lost. I'm not sure why we take a server grab
in the inspector, instead of just a toolkit grab.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

>


-- 
  Jasper
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: xdg shell status and gaps

[Bill Spitzak]

On 09/25/2014 07:32 AM, Jasper St. Pierre wrote:


1) Marking dialogs as modal (needed so we can implement the 'attached
modal' visuals of gnome-shell


I notice this one was ignored. There seems to be some set of people 
working on wayland that hate overlapping windows and want to guarantee 
they are useless.


Anyway, I have only posted about this about a billion times but will try 
again, though it seems a hopeless task:


1. All windows have a "parent" window. If not null the compositor keeps 
the child atop the parent and syncs up map/unmap. This may seem really 
simple, but wait:


2. Clients can change the parent of any window at any time. This has no 
visible effect until one of the windows is raised or mapped or unmapped. 
This is to allow more complex hierarchy than a tree without making the 
api fiendishly complex (gimp's overlapping dialogs will work perfectly).


3. Raise NEVER happens unless the client requests it. This is so the 
client can change the parenting and create/destroy child windows before 
the raise. This is VITAL for Wayland's "every frame is perfect" 
guarantee and cannot be waved away like some people here seem to think. 
It is also necessary so that drag & drop from a lower window works as 
Windows users expect. And yes, boo hoo, it means a client can ignore 
click-to-raise. That's a FEATURE.


4. To support what you are probably calling "modal", the client can take 
keystrokes it gets for any window and pretend they went to the modal 
dialog. Do not require the user to click or move the pointer to the 
modal dialog, that is incredibly stupid! So that panels can highlight 
the window that is actually responding it may be useful for the client 
to send a request moving the keyboard focus to it.



2) Lowering windows (used e.g. by GtkInspector to get out of the way
when picking a window

I'm not comfortable adding this. You can hide briefly the inspector by
giving it a 1x1 blank surface and emptying the input region. Perhaps we
should make this equivalent to what the "NULL surface" semantics are.


I agree it would be better to just hide the window. Pointer lock (being 
discussed elsewhere) should not be lost when this happens. It sounds 
like the loss of grabs is why you lower rather than hide in X. Also if 
your client wants to identify the clicked window it will need some 
privileges.



3) Raising or activating windows (needed e.g when activating a
pre-existing window of a single-window application)


This has been discussed though for some reason they are calling it 
"attention requested". I would instead call it "raise" and make it the 
same as the above raise request that is needed to make overlapping 
windows work. The request includes the event that triggered it, and the 
compositor is aware of what windows are mapped and how they overlap and 
where the mouse and keyboard focus is, so it can easily figure out 
whether to do an actual raise or flash an icon or whatever.



5) Finding out if there is desktop chrome that should be avoided (ie.
'workarea') ? (Useful e.g. for window size heuristics)

This will be handled by the probe extension, but I'm not really sure why
you need this. You can't manually place your window with global
coordinates. "Avoiding" anything doesn't make too much sense to me.


I think he wants to know the maximum size a window can be, even though 
he can't place it. Not clear if just requesting the window initially 
maximized is enough. Need more info on exactly what he is trying to do. 
One possibility is he only wants to maximize in one direction.



6) Snap-back animation if a drag ends unsuccessfully

This should be handled by the compositor, not by the app. It can keep
this surface alive and do the animation itself.


What? I'm pretty certain the client has to do this. Only the client 
knows where the position to snap-back to is. And...



7) Root window drop

When is this useful?


As he pointed out he is really interested in why a drop failed. He wants 
to do something other than snap-back, which is another reason the client 
has to do snap-back animation, since it may not want it.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Bill Spitzak]

On 09/25/2014 06:41 AM, Matthieu Gautier wrote:


How do you handle transformed surfaces ?

If a surface is scale by 0.5 for example. Absolute cursor seems to move
twice its speed from client pov.

Do we want game to turn player position quickly in this situation ? (And
with rotation transformation ?)


Not sure I understand. I certainly assumed the absolute and relative 
coordinates are in the same space, and find it hard to imagine any 
useful alternative.



Switching to relative events does not help at all, it makes clients more
complicated. This is because there is a race condition,

This is why I was thinking of a way to send relative events
(untransformed events is better name) always (as far as the client want it)

If there is no relation between pointer lock and untransformed event,
there is no race condition.


That would work. However I think this can still be combined with my 
idea. When pointer lock is turned on, you continue getting relative and 
absolute events just like before. The only difference is you will not 
get a leave event. It also means absolute events can stop at the screen 
edge if relative ones are available.



Client "open untransform event object" and deal with untranformed events
without care of absolute move events from the pointer.


That's probably what they would like, but I think it would be better to 
just add the relative info to the normal move events. The client needs 
an easy way to match up the relative and absolute events. You can't just 
switch them because the absolute events have useful information that a 
relative-event client may want (i.e. where the cursor is).



So please don't have a "confine" mode.


I disagree here.

Compositor has to know what is the confine zone.
If we rely on the client to replace the cursor position we may face off
some kind of flickering cursor position:


No, I solved that because the cursor stops being moved by the compositor 
when pointer lock is on. All the motion is due to the client setting the 
cursor position so there is no disagreement and thus no flickering.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: xdg shell status and gaps

[Matthias Clasen]

On Thu, Sep 25, 2014 at 10:32 AM, Jasper St. Pierre
 wrote:


>> Anyway, here's the list:
>>
>> 1) Marking dialogs as modal (needed so we can implement the 'attached
>> modal' visuals of gnome-shell

What about this one ?

>> 2) Lowering windows (used e.g. by GtkInspector to get out of the way
>> when picking a window
>
> I'm not comfortable adding this. You can hide briefly the inspector by
> giving it a 1x1 blank surface and emptying the input region. Perhaps we
> should make this equivalent to what the "NULL surface" semantics are.

Might work - I chose lowering here instead of hiding since hiding
breaks the grabs we use under X.

>>
>> 4) Learning about output characteristics - is this display the
>> 'primary' / builtin / projector ? (needed e.g. when deciding which
>> output to show a presentation on)

>> 5) Finding out if there is desktop chrome that should be avoided (ie.
>> 'workarea') ? (Useful e.g. for window size heuristics)
>
>
> This will be handled by the probe extension, but I'm not really sure why you
> need this. You can't manually place your window with global coordinates.
> "Avoiding" anything doesn't make too much sense to me.

As I said, we currently use the workarea in
gtk_window_guess_default_size() when figuring out which size to give
the window initially. Thats somewhat useful, even if we have no
control of the placement.

>>
>> 7) Root window drop
>
>
> When is this useful?

One place where it is used is when dragging tabs out of a window to
create a new window. gnome-terminal, gedit, nautilus, all do this. But
looking closer, the way it is implemented is not actually as a root
window drop, specifically, but just any failed drop - if you don't
drop on a notebook in the same app that is hooked up to accept the
tab, we just treat any failed drop as a change to create a new window.
So, what we need is a signal that a drop failed. Not sure we get that,
currently ?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: How to maintain relative position of two surfaces?

[Hongze Zhao]

Actually for this stage I only want to write a desktop application. But I
may want to extend it to embedded systems. I will read the document of ivi
first.

Thanks,
Hongze

On Thu, Sep 25, 2014 at 10:33 AM, Jasper St. Pierre 
wrote:

> Note that ivi-shell is designed for embedded systems, and won't be
> implemented by traditional desktop systems. It depends on the type of
> application you're writing. If you want to write a traditional desktop
> application, ivi-shell isn't for you.
>
> On Thu, Sep 25, 2014 at 1:32 AM, Ucan, Emre (ADITG/SW1) <
> eu...@de.adit-jv.com> wrote:
>
>>  Hi,
>>
>>
>>
>> you can do it with weston-ivi-shell. IVI-Shell introduces layer concept
>> to weston.
>>
>>
>>
>> A layer is a group of surfaces which can be moved or resized together.
>>
>>
>>
>> But IVI-Shell is just an interface and you have to implement your own
>> APIs to use it.
>>
>>
>>
>> Wayland-IVI-Extension is a set of readily implemented APIs which are
>> using weston-ivi-shell.
>>
>>
>>
>> Some example APIs:
>>
>>
>>
>> *ilm_layerSetPosition *
>>
>> *“*Sets the horizontal and vertical position of the layer. Relative
>> position of layer’s surfaces would be maintained.”
>>
>>
>>
>> *ilm_layerSetDestinationRectangle *
>>
>> *“*Set the destination area on the display for a layer. The layer will
>> be scaled and positioned to this rectangle
>>
>> for rendering.”
>>
>>
>>
>> *ilm_layerSetVisibility*
>>
>> “Sets the visibility  for all surfaces of a layer”
>>
>>
>>
>> *ilm_layerSetVisibility*
>>
>> “Sets the opacity for all surfaces of a layer”
>>
>>
>>
>> You can get more information from the website:
>> http://projects.genivi.org/wayland-ivi-extension/home
>>
>>
>>
>> If you are interested I can help you to install & use it.
>>
>>
>>
>> Best regards
>>
>> *Emre Ucan*
>> Software Group I (ADITG/SW1)
>>
>> Tel. +49 5121 49 6937
>>
>> *From:* wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org]
>> *On Behalf Of *Hongze Zhao
>> *Sent:* Donnerstag, 25. September 2014 03:49
>> *To:* Jasper St. Pierre
>> *Cc:* wayland mailing list
>> *Subject:* 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 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", 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 surface and maintain their relative position. When I
>> move father surface, the child surface will be moved together. But the
>> child surface cannot be moved. Thus the child surface will looks like a
>> part of father surface. I just need it works in the simplest scenario. I
>> assume the two surfaces is in the same workspace, both surfaces cannot be
>> resized, maximized or fullscreened. The two clients and compositor should
>> work together to achieve this goal.
>>
>>
>>
>> I know this is a weird use case. I am just wondering if there is some
>> natural or easy way to implement this functionality. Or I have to do a lot
>> of modifications.
>>
>>
>>
>> Thanks,
>>
>> Hongze
>>
>>
>>
>>
>>
>> On Wed, Sep 24, 2014 at 7:54 PM, Jasper St. Pierre 
>> wrote:
>>
>> 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 (e.g. your window A, my terminal, your window B)? What
>> happens when I resize the surfaces? Or maximize or fullscreen them?
>>
>>
>>
>> On Wed, Sep 24, 2014 at 5:49 PM, Hongze Zhao 
>> wrote:
>>
>>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 positions of the the
>> surfaces from two clients. Thus I have to automatically update the position
>> of the other surface.
>>
>>
>>
>> I feel that surface position is stored in an instance of weston_view,
>> which is mainly maintained by desktop-shell. So I am not sure if there is
>> some easy way to achieve my goal by modifying desktop-shell.
>>
>>
>>
>> Thanks,
>>
>> Hongze
>>
>>
>>
>> ___
>> wayland-devel mailing list
>> wayl

Re: How to maintain relative position of two surfaces?

[Jasper St. Pierre]

Note that ivi-shell is designed for embedded systems, and won't be
implemented by traditional desktop systems. It depends on the type of
application you're writing. If you want to write a traditional desktop
application, ivi-shell isn't for you.

On Thu, Sep 25, 2014 at 1:32 AM, Ucan, Emre (ADITG/SW1) <
eu...@de.adit-jv.com> wrote:

>  Hi,
>
>
>
> you can do it with weston-ivi-shell. IVI-Shell introduces layer concept to
> weston.
>
>
>
> A layer is a group of surfaces which can be moved or resized together.
>
>
>
> But IVI-Shell is just an interface and you have to implement your own APIs
> to use it.
>
>
>
> Wayland-IVI-Extension is a set of readily implemented APIs which are using
> weston-ivi-shell.
>
>
>
> Some example APIs:
>
>
>
> *ilm_layerSetPosition *
>
> *“*Sets the horizontal and vertical position of the layer. Relative
> position of layer’s surfaces would be maintained.”
>
>
>
> *ilm_layerSetDestinationRectangle *
>
> *“*Set the destination area on the display for a layer. The layer will be
> scaled and positioned to this rectangle
>
> for rendering.”
>
>
>
> *ilm_layerSetVisibility*
>
> “Sets the visibility  for all surfaces of a layer”
>
>
>
> *ilm_layerSetVisibility*
>
> “Sets the opacity for all surfaces of a layer”
>
>
>
> You can get more information from the website:
> http://projects.genivi.org/wayland-ivi-extension/home
>
>
>
> If you are interested I can help you to install & use it.
>
>
>
> Best regards
>
> *Emre Ucan*
> Software Group I (ADITG/SW1)
>
> Tel. +49 5121 49 6937
>
> *From:* wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org]
> *On Behalf Of *Hongze Zhao
> *Sent:* Donnerstag, 25. September 2014 03:49
> *To:* Jasper St. Pierre
> *Cc:* wayland mailing list
> *Subject:* 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 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", 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 surface and maintain their relative position. When I
> move father surface, the child surface will be moved together. But the
> child surface cannot be moved. Thus the child surface will looks like a
> part of father surface. I just need it works in the simplest scenario. I
> assume the two surfaces is in the same workspace, both surfaces cannot be
> resized, maximized or fullscreened. The two clients and compositor should
> work together to achieve this goal.
>
>
>
> I know this is a weird use case. I am just wondering if there is some
> natural or easy way to implement this functionality. Or I have to do a lot
> of modifications.
>
>
>
> Thanks,
>
> Hongze
>
>
>
>
>
> On Wed, Sep 24, 2014 at 7:54 PM, Jasper St. Pierre 
> wrote:
>
> 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 (e.g. your window A, my terminal, your window B)? What
> happens when I resize the surfaces? Or maximize or fullscreen them?
>
>
>
> On Wed, Sep 24, 2014 at 5:49 PM, Hongze Zhao  wrote:
>
>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 positions of the the
> surfaces from two clients. Thus I have to automatically update the position
> of the other surface.
>
>
>
> I feel that surface position is stored in an instance of weston_view,
> which is mainly maintained by desktop-shell. So I am not sure if there is
> some easy way to achieve my goal by modifying desktop-shell.
>
>
>
> Thanks,
>
> Hongze
>
>
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
>
>
> --
>   Jasper
>
>
>
>
>
> --
>
> Hongze Zhao
>
> Department of Computer Science
>
> Duke University
>
> Email: zhaohon...@gmail.com
>
>
>
>   --
>   Jasper
>
>
>
>
>
> --
>
> Hongze Zhao
>
> Department of Computer Science
>
> Duke University
>
> Email: zhaohon...@gmail.com
>
> ___
> wayland-dev

Re: xdg shell status and gaps

[Jasper St. Pierre]

On Thu, Sep 25, 2014 at 5:20 AM, Matthias Clasen 
wrote:

> Hi,
>
> so yesterday we released what we described as a day-to-day usable
> GNOME/Wayland. Congratulations to everybody involved in defining
> xdg-shell on getting us this far.
>
> But... (I wouldn't write if there wasn't a but) we are not yet calling
> it a '100% complete port' because there are still a number of things
> that don't work, compared to X.
>
> It is quite possible that some of these should be done differently
> under Wayland, or not at all. It is also possible that there are
> already plans for supporting these things that I don't know about. In
> that case, please set me straight.
>
> Anyway, here's the list:
>
> 1) Marking dialogs as modal (needed so we can implement the 'attached
> modal' visuals of gnome-shell
>
> 2) Lowering windows (used e.g. by GtkInspector to get out of the way
> when picking a window
>

I'm not comfortable adding this. You can hide briefly the inspector by
giving it a 1x1 blank surface and emptying the input region. Perhaps we
should make this equivalent to what the "NULL surface" semantics are.


> 3) Raising or activating windows (needed e.g when activating a
> pre-existing window of a single-window application)
>

This is one of the final things that will be added to xdg_surface, as the
first revision.


> 4) Learning about output characteristics - is this display the
> 'primary' / builtin / projector ? (needed e.g. when deciding which
> output to show a presentation on)
>

This should be part of wl_output. I think this makes sense as a new event
on that.


> 5) Finding out if there is desktop chrome that should be avoided (ie.
> 'workarea') ? (Useful e.g. for window size heuristics)
>

This will be handled by the probe extension, but I'm not really sure why
you need this. You can't manually place your window with global
coordinates. "Avoiding" anything doesn't make too much sense to me.


> Outside of xdg-shell, we found that there's currently no protocol
> support for handling some traditional aspects of DND:
>

6) Snap-back animation if a drag ends unsuccessfully
>

This should be handled by the compositor, not by the app. It can keep this
surface alive and do the animation itself.


> 7) Root window drop
>

When is this useful?

Thanks for the list! It's always helpful to have feedback on xdg-shell.

Matthias
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



-- 
  Jasper
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Matthieu Gautier]

Le 24/09/2014 21:44, Bill Spitzak a écrit :

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.


This is exactly (except for the pointer-lock) what I would suggest. Some
X servers (IRIX I think) did exactly this when the mouse hit the edge of
the screen, and it was very useful for making huge menus scroll as the
user dragged the mouse. Later X servers did not do this and it made some
nice menu interaction impossible (we had to resort to the
warp-the-cursor hack you mention games doing).

These old systems did use low-resolution mice, so it knew a motion event
corresponded to one pixel. This may be a problem with modern systems as
the events are delivered for very tiny movements. An alternative idea is
to deliver motion events as though the xy position kept moving outside
the screen, but if the user moves the mouse back toward the screen such
that the cursor should move away from the edge, the xy position jumps
back inside the screen.

Pointer lock:

I'm not sure what "wl_pointer" is, but there have been a lot of strange
statements that seem to indicate people think it is impossible for the
motion events to have something other than where the user sees the
cursor. There are in fact two objects of interest:

1. A cursor. This is an image (usually an arrow) that is composited into
the display. There is one cursor per seat. This can be placed anywhere
on the screen. Usually the compositor does this, but when pointer-lock
is on the client does it.

2. An xy position. This is a per-seat xy position. Motion events and
enter/leave are delivered by this. The compositor updates it based on
input devices attached to the seat. It might also move it when pointer
lock is canceled.

These are DIFFERENT!!! It should be obvious that if the client can move
the cursor there is a race condition if the motion events depend on that
position. Therefore they must be independent.


My separation was more between relative events and their integration to 
get absolute position.


But yes, there are two different parts and they should not been combine.



The client should be allowed to move the cursor anywhere while pointer
lock is on (the compositor may clamp it to be on-screen). It has ZERO
effect on motion events it gets.

PS: The client cannot make a "fake cursor", as several have suggested,
because when pointer lock is released the xy position and cursor had
better be in the same location the user thought it was. Therefore the
compositor has to know where the cursor is.

Relative events:

You should not have relative events.

As long as moving the mouse actually produces different numbers (ie it
does not stop at any edges) then it is trivial for the client to extract
relative events, by subtracting the previous position.



How do you handle transformed surfaces ?

If a surface is scale by 0.5 for example. Absolute cursor seems to move 
twice its speed from client pov.


Do we want game to turn player position quickly in this situation ? (And 
with rotation transformation ?)




Switching to relative events does not help at all, it makes clients more
complicated. This is because there is a race condition, the compositor
may have delivered some normal motion events before responding to the
pointer lock. The client has to deal with these so it must already have
code to deal with absolute events and therefore relative events do not
save anything.


This is why I was thinking of a way to send relative events 
(untransformed events is better name) always (as far as the client want it)


If there is no relation between pointer lock and untransformed event, 
there is no race condition.


Client "open untransform event object" and deal with untranformed events 
without care of absolute move events from the pointer.




If the input device is relative (ie a mouse), pointer lock should allow
the xy position to move anywhere, not limited to the screen. This is the
only change needed to get the benefits of "relative events".

Confine:

"confine to surface" is useless. This is because the client will always
want to confine to a widget, which the compositor is unaware of.

All that is needed is for the client to be able to move the cursor while
pointer lock is on. It can then implement any confinement rules it
wants, such as mapping to a spherical projection.

So please don't have a "confine" mode.


I disagree here.

Compositor has to know what is the confine zone.
If we rely on the client to replace the cursor position we may face off 
some kind of flickering cursor position:


- Compositor will displayed the cursor at its new position.
- It send the cursor position to the client
- Client change the position of cursor cause of personal rule about 
confine zone.
- If the user continue to move m

xdg shell status and gaps

[Matthias Clasen]

Hi,

so yesterday we released what we described as a day-to-day usable
GNOME/Wayland. Congratulations to everybody involved in defining
xdg-shell on getting us this far.

But... (I wouldn't write if there wasn't a but) we are not yet calling
it a '100% complete port' because there are still a number of things
that don't work, compared to X.

It is quite possible that some of these should be done differently
under Wayland, or not at all. It is also possible that there are
already plans for supporting these things that I don't know about. In
that case, please set me straight.

Anyway, here's the list:

1) Marking dialogs as modal (needed so we can implement the 'attached
modal' visuals of gnome-shell

2) Lowering windows (used e.g. by GtkInspector to get out of the way
when picking a window

3) Raising or activating windows (needed e.g when activating a
pre-existing window of a single-window application)

4) Learning about output characteristics - is this display the
'primary' / builtin / projector ? (needed e.g. when deciding which
output to show a presentation on)

5) Finding out if there is desktop chrome that should be avoided (ie.
'workarea') ? (Useful e.g. for window size heuristics)

Outside of xdg-shell, we found that there's currently no protocol
support for handling some traditional aspects of DND:

6) Snap-back animation if a drag ends unsuccessfully

7) Root window drop


Matthias
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

RE: How to maintain relative position of two surfaces?

[Ucan, Emre (ADITG/SW1)]

Hi,

you can do it with weston-ivi-shell. IVI-Shell introduces layer concept to 
weston.

A layer is a group of surfaces which can be moved or resized together.

But IVI-Shell is just an interface and you have to implement your own APIs to 
use it.

Wayland-IVI-Extension is a set of readily implemented APIs which are using 
weston-ivi-shell.

Some example APIs:

ilm_layerSetPosition
“Sets the horizontal and vertical position of the layer. Relative position of 
layer’s surfaces would be maintained.”

ilm_layerSetDestinationRectangle
“Set the destination area on the display for a layer. The layer will be scaled 
and positioned to this rectangle
for rendering.”

ilm_layerSetVisibility
“Sets the visibility  for all surfaces of a layer”

ilm_layerSetVisibility
“Sets the opacity for all surfaces of a layer”

You can get more information from the website: 
http://projects.genivi.org/wayland-ivi-extension/home

If you are interested I can help you to install & use it.

Best regards

Emre Ucan
Software Group I (ADITG/SW1)

Tel. +49 5121 49 6937
From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On 
Behalf Of Hongze Zhao
Sent: Donnerstag, 25. September 2014 03:49
To: Jasper St. Pierre
Cc: wayland mailing list
Subject: 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 
mailto:jstpie...@mecheye.net>> wrote:
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 
mailto:zhaohon...@gmail.com>> wrote:
Hi Jasper,

Thanks for reply.

Here is my use case.
 [cid:image001.png@01CFD8A0.CF723890]
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 surface and maintain their relative position. When I move father 
surface, the child surface will be moved together. But the child surface cannot 
be moved. Thus the child surface will looks like a part of father surface. I 
just need it works in the simplest scenario. I assume the two surfaces is in 
the same workspace, both surfaces cannot be resized, maximized or fullscreened. 
The two clients and compositor should work together to achieve this goal.

I know this is a weird use case. I am just wondering if there is some natural 
or easy way to implement this functionality. Or I have to do a lot of 
modifications.

Thanks,
Hongze


On Wed, Sep 24, 2014 at 7:54 PM, Jasper St. Pierre 
mailto:jstpie...@mecheye.net>> wrote:
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 (e.g. your window A, my terminal, your window B)? What happens 
when I resize the surfaces? Or maximize or fullscreen them?

On Wed, Sep 24, 2014 at 5:49 PM, Hongze Zhao 
mailto:zhaohon...@gmail.com>> wrote:
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 positions of the the surfaces 
from two clients. Thus I have to automatically update the position of the other 
surface.

I feel that surface position is stored in an instance of weston_view, which is 
mainly maintained by desktop-shell. So I am not sure if there is some easy way 
to achieve my goal by modifying desktop-shell.

Thanks,
Hongze

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel



--
  Jasper



--
Hongze Zhao
Department of Computer Science
Duke University
Email: zhaohon...@gmail.com


--
  Jasper



--
Hongze Zhao
Department of Computer Science
Duke University
Email: zhaohon...@gmail.com
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel