Re: black surface in desktop shell fullscreen mode

[Pekka Paalanen]

On Thu, 1 Oct 2015 12:27:21 -0700
Bill Spitzak  wrote:

> On Thu, Oct 1, 2015 at 12:50 AM, Pekka Paalanen  wrote:
> 

> > The black blanket surface behind the window OTOH allows for direct
> > scanout. If black bars are not visible and the client buffer is
> > completely opaque, it is possible to scan it out without composition by
> > rendering.
> >
> 
> There should be some way to detect if the buffer is opaque, in which case
> these optimizations could be done.

There is, the hint is given by the client:
wl_surface.set_opaque_region. This one we already do in Weston.


Thanks,
pq


pgp6naXPNg65g.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 1/6] xdg-shell: define the present/present_from_event() requests

[Jonas Ådahl]

On Thu, Apr 09, 2015 at 06:22:53PM +0200, Manuel Bachmann wrote:
> xdg_surface_present() and xdg_surface_present_from_event()
> are new requests supposed to be called on an existing
> xdg_surface. They tell the compositor that the surface
> has new content which may be of interest to the user.
> The compositor may then choose to notify the user.
> 
> xdg_surface_present_from_event() takes a serial coming
> from an input (wl_keyboard, wl_pointer, wl_touch) event as
> an argument. If the serial is valid and sufficiently recent,
> we can suppose the new content has been issued at the user's
> request ; the compositor may then choose to raise the
> surface directly. Otherwise, it just behaves like present().
> 
> Signed-off-by: Manuel Bachmann 
> ---
>  desktop-shell/shell.c  | 15 +++
>  protocol/xdg-shell.xml | 20 
>  2 files changed, 35 insertions(+)
> 
> diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
> index f7c928e..d1d3f3c 100644
> --- a/desktop-shell/shell.c
> +++ b/desktop-shell/shell.c
> @@ -3923,6 +3923,19 @@ xdg_surface_set_minimized(struct wl_client *client,
>   set_minimized(shsurf->surface);
>  }
>  
> +static void
> +xdg_surface_present(struct wl_client *client,
> + struct wl_resource *resource)
> +{
> +}
> +
> +static void
> +xdg_surface_present_from_event(struct wl_client *client,
> +struct wl_resource *resource,
> +uint32_t serial)
> +{
> +}
> +
>  static const struct xdg_surface_interface xdg_surface_implementation = {
>   xdg_surface_destroy,
>   xdg_surface_set_parent,
> @@ -3938,6 +3951,8 @@ static const struct xdg_surface_interface 
> xdg_surface_implementation = {
>   xdg_surface_set_fullscreen,
>   xdg_surface_unset_fullscreen,
>   xdg_surface_set_minimized,
> + xdg_surface_present,
> + xdg_surface_present_from_event,
>  };
>  
>  static void
> diff --git a/protocol/xdg-shell.xml b/protocol/xdg-shell.xml
> index 68cf469..10f82c5 100644
> --- a/protocol/xdg-shell.xml
> +++ b/protocol/xdg-shell.xml
> @@ -396,6 +396,26 @@
>
>  
>  
> +
> +  
> + The surface has new content and would like the compositor
> + to notify the user.
> +  
> +
> +
> +
> +  
> + The surface has new content and would like the compositor
> + to notify the user.
> +
> + If a valid and sufficiently recent serial coming from an
> + input (keyboard, pointer, touch) event is passed as an
> + argument, the compositor may want to raise the surface.
> + Otherwise, the request just behaves like the "present" one.
> +  
> +  
> +
> +

This changes the protocol without bumping any versions. I'm also a bit
skeptical to, at this point, doing non-essential changes to xdg_shell.
Changing the experimental version is a huge pain because a version
mismatch causes any mismatching client trying to use it to be
terminated, without any way to discover whether it is compatible or not.
Could we maybe add this as an extension to xdg_shell or something like
that?


Jonas

>  
>
>  The close event is sent by the compositor when the user
> -- 
> 1.8.3.1
> 
> ___
> 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: [PATCH wayland v2] scanner: Close input resource when done to prevent leak

[Jonas Ådahl]

On Thu, Oct 01, 2015 at 06:13:29PM -0700, Bryce Harrington wrote:
> Addresses this error reported by Denis Denisov:
> 
>   [src/scanner.c:1415]: (error) Resource leak: input
> 
> Signed-off-by: Bryce Harrington 
> 
> v2: Also close input for other exit points in main.
> Signed-off-by: Bryce Harrington 

I guess we should also free_protocol() on some of the EXIT_FAILUREs, but
thats not really related to this patch. So..

Reviewed-by: Jonas Ådahl 


Jonas

> ---
>  src/scanner.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/src/scanner.c b/src/scanner.c
> index 9b41ae4..5504fce 100644
> --- a/src/scanner.c
> +++ b/src/scanner.c
> @@ -1531,6 +1531,7 @@ int main(int argc, char *argv[])
>   if (freopen(argv[2], "w", stdout) == NULL) {
>   fprintf(stderr, "Could not open output file: %s\n",
>   strerror(errno));
> + fclose(input);
>   exit(EXIT_FAILURE);
>   }
>   }
> @@ -1550,6 +1551,7 @@ int main(int argc, char *argv[])
>   XML_SetUserData(ctx.parser, &ctx);
>   if (ctx.parser == NULL) {
>   fprintf(stderr, "failed to create parser\n");
> + fclose(input);
>   exit(EXIT_FAILURE);
>   }
>  
> @@ -1561,6 +1563,7 @@ int main(int argc, char *argv[])
>   len = fread(buf, 1, XML_BUFFER_SIZE, input);
>   if (len < 0) {
>   fprintf(stderr, "fread: %m\n");
> + fclose(input);
>   exit(EXIT_FAILURE);
>   }
>   if (XML_ParseBuffer(ctx.parser, len, len == 0) == 0) {
> @@ -1569,6 +1572,7 @@ int main(int argc, char *argv[])
>   XML_GetCurrentLineNumber(ctx.parser),
>   XML_GetCurrentColumnNumber(ctx.parser),
>   XML_ErrorString(XML_GetErrorCode(ctx.parser)));
> + fclose(input);
>   exit(EXIT_FAILURE);
>   }
>   } while (len > 0);
> @@ -1588,6 +1592,7 @@ int main(int argc, char *argv[])
>   }
>  
>   free_protocol(&protocol);
> + fclose(input);
>  
>   return 0;
>  }
> -- 
> 1.9.1
> 
> ___
> 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: [RFC 1/2] Introduce wl_probe_visible protocol

[Jonas Ådahl]

On Thu, Oct 01, 2015 at 01:04:34PM +0200, Carlos Garnacho wrote:
> Hey Jonas!,
> 
> On Thu, Oct 1, 2015 at 8:51 AM, Jonas Ådahl  wrote:
> > wl_probe_visible (for now _wl_probe_visible) is a reintroduction of
> > the "wl_probe" method of making it possible to position a surface so
> > that it is completely visible, when positioning it relative to some
> > other already mapped surface. It works by checking what parts of a
> > rectangle relative to an existing surface would be visible, allowing
> > the client to reposition its surface accordingly.
> >
> > The protocol and implementation is based on patches by Rob Bradford
> > from 2013[0][1].
> >
> > [1] 
> > http://lists.freedesktop.org/archives/wayland-devel/2013-April/008665.html
> > [2] 
> > http://lists.freedesktop.org/archives/wayland-devel/2013-April/008666.html
> >
> > Signed-off-by: Jonas Ådahl 
> > ---
> >
> > Hi,
> >
> > Some time ago I took the old "wl_probe" patches and updated them to
> > work today. The approach is mostly the same, but with some renaming and
> > moving around (it's for example not part of wl_shell anymore). It was
> > brought up on the mailing list recently, so I thought it could be a good
> > idea to make it easier to test on todays weston, so here it is.
> >
> > The are a few problems with this approach, such as:
> >
> > 1) It requires an extra roundtrip to create a popup/tooltip (not that
> > big of a deal though, I'd say).
> > 2) When the parent surface has non-trivial transformations (non-90
> > degree rotation etc), a resulting rectangle is ambigous. This could be
> > made implementation specific or with some required semantics (such as
> > prefer rectangles where more corners are untouched, prefer larger
> > rectangle etc).
> 
> I'm tempted to say this is compositor-specific territory, this depends
> a lot on how do compositors represent/map surfaces, and what do they
> allow to do with them at all. IMHO, mentioning that the coordinate
> axes of both surfaces are expected to be aligned is a generic enough
> common ground.
> 
> > 3) It may be abused to get an (incorrect) absolute surface position.
> > 4) It is racy - for a moving surface, the visibility will change as it
> > moves.
> 
> I would like to point out that it could be a common case. In GTK+ this
> would also be interesting for GtkPopover positioning, those are
> implemented as subsurfaces. It would be great to keep them onscreen
> (they are able to snap to either of four sides) but at the same time
> the toplevel window is draggable, so the positioning isn't static.
> Moreover, each next position tried must be probed too, because it
> might have the same space problem.
> 
> >
> > A different approach of solving the same issue is to shift the
> > responsibility for positioning popups from the client to the
> > compositor. This requires a more complex protocol allowing the client
> > describing the expected semantics, as well as a roundtrip then the
> > client needs to know how the compositor positioned a given rectangle.
> > For the position readback case, this approach has the same racyness as
> > the approach in this patch, and adding a new kind of positioning logic
> > would need changing the protocol. This approach is what Mir is taking.
> >
> > Personally, I'm not completely convinced a "wl_probe" way of improving
> > the menu positioning is the better option here, and would like to hear
> > what other think about this.
> 
> Perhaps changing this to a "subscription" model, where you pass
> surface+rectangle on the constructor and you receive events as parent
> surfaces move? I think it'd get rid of the roundtrip/raciness problem,
> seems a better fit for those "often repositioned" cases, and would be
> down to a single event for static cases (although you keep an object
> around). It would be great to attach this to the lifetime of the
> surface you're about to map though, or at least advise through docs.

I think that if we want to make it possible to change the relative
position of a popup/tooltip/popover in response to the parent surface
moving (like keeping a popover inside the visible area) we really should
use the second approach. If we need to support letting the client draw
its surface differently depending on where its placed, we should
probably do something similar to a combination of
xdg_surface.configure_ack and a synchronized subsurface. Sending updates
for every movement will be very noicy, and it doesn't seem like
something we want to expose.


Jonas

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

[PATCH wayland v2] scanner: Close input resource when done to prevent leak

[Bryce Harrington]

Addresses this error reported by Denis Denisov:

  [src/scanner.c:1415]: (error) Resource leak: input

Signed-off-by: Bryce Harrington 

v2: Also close input for other exit points in main.
Signed-off-by: Bryce Harrington 
---
 src/scanner.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/scanner.c b/src/scanner.c
index 9b41ae4..5504fce 100644
--- a/src/scanner.c
+++ b/src/scanner.c
@@ -1531,6 +1531,7 @@ int main(int argc, char *argv[])
if (freopen(argv[2], "w", stdout) == NULL) {
fprintf(stderr, "Could not open output file: %s\n",
strerror(errno));
+   fclose(input);
exit(EXIT_FAILURE);
}
}
@@ -1550,6 +1551,7 @@ int main(int argc, char *argv[])
XML_SetUserData(ctx.parser, &ctx);
if (ctx.parser == NULL) {
fprintf(stderr, "failed to create parser\n");
+   fclose(input);
exit(EXIT_FAILURE);
}
 
@@ -1561,6 +1563,7 @@ int main(int argc, char *argv[])
len = fread(buf, 1, XML_BUFFER_SIZE, input);
if (len < 0) {
fprintf(stderr, "fread: %m\n");
+   fclose(input);
exit(EXIT_FAILURE);
}
if (XML_ParseBuffer(ctx.parser, len, len == 0) == 0) {
@@ -1569,6 +1572,7 @@ int main(int argc, char *argv[])
XML_GetCurrentLineNumber(ctx.parser),
XML_GetCurrentColumnNumber(ctx.parser),
XML_ErrorString(XML_GetErrorCode(ctx.parser)));
+   fclose(input);
exit(EXIT_FAILURE);
}
} while (len > 0);
@@ -1588,6 +1592,7 @@ int main(int argc, char *argv[])
}
 
free_protocol(&protocol);
+   fclose(input);
 
return 0;
 }
-- 
1.9.1

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

Re: [PATCH wayland v4] protocol: Add DnD actions

[Carlos Garnacho]

On Thu, Oct 1, 2015 at 9:47 PM, Bill Spitzak  wrote:
> I really do not like the idea that the compositor is responsible for
> matching up modifiers with actions.
>
> Still trying to figure out why the destination cannot pick one of the
> actions, rather than the compositor doing this. If the modifiers are needed
> then either the destination gets the modifiers, or the source gets them and
> uses them to alter the list of offered actions.

Because DnD could be carried out by a pointer+keyboard, accessibility
technologies, or a gravity gun for that matter. It introduces the
unnecessary concept of keyboard modifiers to something that's agnostic
of the input device, when actions must be already present and carried
around.

>
> My best guess is that you are having trouble emulating XDND. I think that is
> a poor excuse for a non-optimal api however, and I really doubt it cannot be
> worked around.

I'm not going down this rathole again. It is not emulating, but being
able to interoperate with, plus not requiring gratuitous major changes
on toolkits and clients. I'm not going to implement something I know
broken for cases I immediately have to fix next, you're free to flesh
out your criticism on an alternative patch if you want.

>
> My overall opinion is that the destination needs a lot more control over
> this to get a proper modern ui. The destination may want to show a preview
> of what the drop will look like, which means the destination MUST be able to
> control the cursor image. I don't care if this somehow violates any
> principles of grab. It can revert to the cursor image from the source when
> the destination refuses the drag.

What kind of preview to you want to show *on the cursor*? if it's
"preview" what you want, it should surely happen on the dest surface
itself.

>
> The destination must also be able to pop up a menu of actions that the user
> chooses from. Therefore it must be able to get the list from the source and
> respond with a chosen one. The reason the destination must do this is
> because the drop target may be ambiguous, and the destination needs to be
> able to ask the user which to do. The user does not see any difference
> between this and deciding whether move/copy needs to be done, so any api
> that does not allow the user to select both simultaneously with a single
> push is broken.

Although I'd like to see mimetype/action in a single request too,
nothing prevents such menus either with these patches, set "ask" as
first action, and issue a late .action() request when it's been
picked. I'm most certain because I've seen it working on current apps
with patched gtk+.

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

Re: Enums, bitfields and wl_arrays

[Bill Spitzak]

On Thu, Oct 1, 2015 at 12:00 PM, Nils Chr. Brause 
wrote:

>
> There are some enum attributes missing, namely:
> - wl_shm_pool::create_buffer::format (it's wl_shm::format)
> - wl_shell_surface::set_fullscreen::method (it's
> wl_shell_surface::fullscreen_method)
> - wl_surface::set_buffer_transform::transform (it's wl_output::transform)
>
> I would prefer, if the enum attributes would also name the interface,
> where the enum can be found, e.g.:
> 
> If two enums in different interfaces happen to have the same name (if
> that's possible?), this would lead to ambiguities otherwise. Also a
> scanner wouldn't have to look up the interface name that way.
>

Oh rats, it does look like you are right, and the current patch just
skipped all the cross-object enums. There will have to be changes to the
xml translators to handle these.

I'm not sure how hard it is to make xml translators change behaviour
depending on whether there is a period in the string. If so then the
current protocol file patches could continue to work, by making "no period"
mean "in the current object". But it might be easier to just add the object
name to all enum attributes, like you propose. That could also leave open
the possibility that "no period" means some future "global" namespace for
the enum.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 1/2] Clarify the enum argument type

[Bill Spitzak]

On Thu, Oct 1, 2015 at 12:09 PM, Nils Chr. Brause 
wrote:

> On Thu, Oct 1, 2015 at 9:00 PM, Bill Spitzak  wrote:
> >
> >
> > On Thu, Oct 1, 2015 at 8:09 AM, Nils Chr. Brause <
> nilschrbra...@gmail.com>
> > wrote:
> >>
> >> Hi,
> >>
> >> I would recommend to also include the name of the interface, where the
> >> enum is defined, in the enum attribute, e.g:
> >> 
> >
> >
> > I believe popular opinion was that a "local" enum, belonging to the same
> > object as the message or event, should not require this prefix. One big
> > reason is so that the object can be renamed without having to edit it's
> > contents.
> >
> > And currently only such "local" enums are being used in the protocols, so
> > there is no need for parsers to support any such prefix yet, and no need
> to
> > figure out it's rules. Whether the ability to get enums from other
> objects,
> > or from some global space, does not have to be decided yet.
>
> There are "non-local" enums, e.g.
> wl_surface::set_buffer_transform::transform uses the enum
> wl_output::transform, or am I missing something important here?
>

It looks like you are right. Not sure what was done, I have not looked at
it for a long time now. However whatever is in the patch seems to work and
I would use that.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] server: Make serial number 0 mean invalid

[Bill Spitzak]

On Thu, Oct 1, 2015 at 12:59 PM, Jasper St. Pierre 
wrote:

> For the present case, present_with_event will support focus-stealing
> prevention if the serial is garbage or not up to date, whereas present
> should always steal focus.
>
> The garbage serial and don't-have-a-serial cases are different, so I
> believe we should have two different methods in that case for
> different behavior.
>

That is an ok reason, although I really did not expect it. I certainly
figured that focus-stealing would be true ALWAYS, and therefore the garbage
version and no-event version were identical.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] server: Make serial number 0 mean invalid

[Jasper St. Pierre]

For the present case, present_with_event will support focus-stealing
prevention if the serial is garbage or not up to date, whereas present
should always steal focus.

The garbage serial and don't-have-a-serial cases are different, so I
believe we should have two different methods in that case for
different behavior.

On Thu, Oct 1, 2015 at 12:52 PM, Bill Spitzak  wrote:
> The no-serial value really really really needs to be zero. Otherwise you get
> all kinds of annoyances with many language wrappers which map zero to false
> and all other values to true. I think most will have to resort to xor'ing
> the value with the no-serial value, meaning the numerical values are all
> different.
>
>
>
> On Wed, Sep 30, 2015 at 1:23 PM, Jasper St. Pierre 
> wrote:
>>
>>
>> In cases where we have two behaviors for serial-aware and
>> non-serial-aware operations, I would rather have two different client
>> requests.
>
>
> Absolutely wrong. One of the main reasons for the no-serial value is so that
> it is encouraged that unrecognized serial numbers act exactly like the
> no-serial case. If sending garbage to the serial-taking message has some
> useful result that is not achieved by the no-serial version, then clients
> are going to do this. Having a no-serial value avoids this design mistake.
>
>
>



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

Re: [PATCH wayland] protocol: Improve data source notification around DnD progress

[Carlos Garnacho]

On Thu, Oct 1, 2015 at 8:48 PM, Bill Spitzak  wrote:
>
>
> On Wed, Sep 30, 2015 at 1:45 PM, Carlos Garnacho  wrote:
>>
>>
>> - wl_data_source.drop_performed: Happens when the operation has been
>>   physically finished (eg. the button is released), it could be the right
>>   place to reset the pointer cursor back and undo any other state
>> resulting
>>   from the initial button press.
>
>
> This should not be necessary. When the grab is lost, whatever client is
> under the pointer should get an enter event and should then set the cursor
> to whatever it wants. The dnd source should certainly not set the cursor in
> this case because it may set it to the wrong one, resulting in a blink of
> this wrong cursor (ie it will quickly change between the drag cursor, the
> cursor the source thought it should be, and the actual cursor for that
> screen location).

Remember, toolkits preserve some state. The drag source is in control
of the pointer cursor as long as the DnD operation holds, so it should
reset its internal current cursor to the regular one for the next time
the pointer enters the surface. And that's the bare minimals to be
done there, in X11-land toolkits usually implemented DnD and its
cursor changes through a grab, at least in the case of GTK+ this is
carried on, and brings in a lot more side effects than just an
extraneous cursor, so really can't wait until the next
wl_pointer.enter.

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

Re: [PATCH wayland] server: Make serial number 0 mean invalid

[Bill Spitzak]

The no-serial value really really really needs to be zero. Otherwise you
get all kinds of annoyances with many language wrappers which map zero to
false and all other values to true. I think most will have to resort to
xor'ing the value with the no-serial value, meaning the numerical values
are all different.



On Wed, Sep 30, 2015 at 1:23 PM, Jasper St. Pierre 
wrote:

>
> In cases where we have two behaviors for serial-aware and
> non-serial-aware operations, I would rather have two different client
> requests.


Absolutely wrong. One of the main reasons for the no-serial value is so
that it is encouraged that unrecognized serial numbers act exactly like the
no-serial case. If sending garbage to the serial-taking message has some
useful result that is not achieved by the no-serial version, then clients
are going to do this. Having a no-serial value avoids this design mistake.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland v4] protocol: Add DnD actions

[Bill Spitzak]

I really do not like the idea that the compositor is responsible for
matching up modifiers with actions.

Still trying to figure out why the destination cannot pick one of the
actions, rather than the compositor doing this. If the modifiers are needed
then either the destination gets the modifiers, or the source gets them and
uses them to alter the list of offered actions.

My best guess is that you are having trouble emulating XDND. I think that
is a poor excuse for a non-optimal api however, and I really doubt it
cannot be worked around.

My overall opinion is that the destination needs a lot more control over
this to get a proper modern ui. The destination may want to show a preview
of what the drop will look like, which means the destination MUST be able
to control the cursor image. I don't care if this somehow violates any
principles of grab. It can revert to the cursor image from the source when
the destination refuses the drag.

The destination must also be able to pop up a menu of actions that the user
chooses from. Therefore it must be able to get the list from the source and
respond with a chosen one. The reason the destination must do this is
because the drop target may be ambiguous, and the destination needs to be
able to ask the user which to do. The user does not see any difference
between this and deciding whether move/copy needs to be done, so any api
that does not allow the user to select both simultaneously with a single
push is broken.

On Wed, Sep 30, 2015 at 4:02 PM, Michael Catanzaro 
wrote:

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

Re: [PATCH wayland] protocol: Improve data source notification around DnD progress

[Carlos Garnacho]

Hey Michael,

On Thu, Oct 1, 2015 at 6:46 PM, Michael Catanzaro  wrote:
> One problem with this model is that a broken or malicious client could
> force the drag source to be leaked by [sending accept and] never
> destroying its data offer... but only once per user-initiated drag, so
> we can probably ignore that issue

I think there is no way around that, we're in the end coordinating two
clients to send data around, AFAICS there will be always state in one
that should live as long as the other needs the data, no matter how we
lay it. The consolation is that it happens after .drop_performed, so
the source-side client will be in an state where it can start other
dnd operations, and maybe drop the previous data source.

FWIW, (I'm sure it's not flash news) XDND has a similar flaw if the
drag destination fails to send XdndFinished.

>
> On Thu, 2015-10-01 at 12:00 +0200, Carlos Garnacho wrote:
>> This is in order to be able to emit .cancelled if there is no
>> agreement between source and destination about the data to be
>> transferred. Otherwise every drop on any client with a wl_data_device
>> would seem successful.
>
> Ah, so the goal is to allow the drag source to know if the drop
> succeeded. The only solution I can think of that avoids the problem I
> mention is to delay the canceled event until the data offer is
> destroyed. Then there is no race, and the drag source must simply wait
> until drag_finished or a later drag_cancelled if it wants to indicate
> to the user if the drag succeeded or not (the drop success indication
> would be delayed until the data transfer is completed). I don't see any
> problems with such a scheme, but if you can find one, then I think we'd
> have to go with your solution and just say that my problem is a client
> bug.

Hmm, that would mean that .drop_performed would need to happen on both
.cancelled and .drag_finished cases, because at the moment of dropping
you don't know whether some or no mimetype/action will be accepted in
the end. I also wonder if postponing the success/failure indications
until the transfer is complete is a good idea, those can take an
arbitrary time (even if usually short enough).

To add up to the mess, there's one situation I can think where
feedback is different from the real outcome at wl_data_offer destroy
time, popping up a menu on drop with a "cancel" option (or dismissed
through other means), you certainly wouldn't want the UI feedback to
wait until you pick an option or close the menu.

But this is a very valid concern, if you preemptively accept() with a
random mimetype, the user quickly finishes the drag before transfers
are done, and it isn't accepted in the end, you'd get the wrong
feedback, and the wrong outcome in move operations, where the source
may think it's ok to delete the data. The other option is not
accept()ing until the first transfer is done like you do right now,
and train the user to wait long enough on huge dnd transfers, so early
drops turn out cancelled. There'd usually be at least cursor feedback
from the drag source when accept() finally happens. Both options are
somewhat disconcerting, I admit...

>
>> I know .accept has had no functional role in the DnD state machine
>> till now (besides UI feedback on the source-side, setting the
>> appropriate cursor/dnd surfaces mostly), it made sense to me to reuse
>> this though because compositor-side UI feedback and overall DnD
>> outcome would be in sync for virtually every usecase I can imagine. I
>> would expect .accept() to be called regularly on DnD motion over a
>> surface, the pointer moves across inner widgets that accept different
>> mimetypes or none.
>
> Chrome does call it regularly on DnD motion, but only beginning after
> it has received all the data.
>
>> Actually, IMO there should be checks somewhere about the mimetype
>> being one of the offered ones, in order to behave properly on wrong
>> requests, although that means keeping the mimetype list in memory
>> instead of just forwarding it.
>
> If you mean that the mime type sent in accept or receive requests
> should always be one of the offered mime types, then having the
> compositor check for that is a fine idea that can't possibly hurt
> anything.

Yeah, that's what I meant.

>
>> However, I can imagine other usecases where we don't know any
>> concrete
>> mimetype beforehand, eg. a "paste as html/plain text" popup menu on
>> .drop_performed, there'd be no other way in these cases than
>> preemptively picking one, as you say in your other mail.
>
> Deciding later which type of data to actually use doesn't require any
> interaction with the source process if the data has already been
> received (as is the case for Chrome), and if the data has not already
> been received, the receive request must specify an offered mime type.
> In fact, Chrome's DnD backend doesn't ever know anything about which
> mime type will actually be used (and in accept messages, it just sends
> back whatever the first offered 

Re: black surface in desktop shell fullscreen mode

[Bill Spitzak]

On Thu, Oct 1, 2015 at 12:50 AM, Pekka Paalanen  wrote:

>
> A fullscreen window with show-through parts is kind of an odd concept,
> IMHO. For maximized I might understand.
>

It seems partially-transparent fullscreen terminals are really popular.

Pad repeat? That requires application awareness to actually set the
> edge pixels. This may be very hard e.g. for video players that just
> push the decoded video frame out to screen, and expect the compositor
> to add black bars as necessary. You are often dealing with
> hardware-acceleration capable buffers, which causes all kinds of
> complications.
>

Yes you are probably right that this is difficult and expensive.

For the video player it would have to use a subsurface and make a surface
with the background color that is 1 pixel larger on all sides, and then the
compositor would have to detect this setup and still produce whatever the
fast method of displaying the window is. That seems pretty painful.

If a client really wants to use the transparency, and does not want opaque
black bars, it can be the client's responsibility to produce a buffer that
can fill the screen.

The black blanket surface behind the window OTOH allows for direct
> scanout. If black bars are not visible and the client buffer is
> completely opaque, it is possible to scan it out without composition by
> rendering.
>

There should be some way to detect if the buffer is opaque, in which case
these optimizations could be done.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC 1/2] Introduce wl_probe_visible protocol

[Bill Spitzak]

I don't see anything wrong with the compositor selecting the position for
popups, and really don't see any way this "probe" idea can do better. This
will avoid round trips, and also allow the compositor to move the popups if
other obscuring objects appear after they are created. There are a few
requirements however:

1. The client sends a desired position, and the result will be as close to
this as the compositor can do.

2. The compositor must send an event telling the client when the popup
moves and where to. This is not a global window position, it is relative to
the parent surface.

3. The client must have a way to move the cursor so that it remains pointed
at a desired widget. I think it would be acceptable to require the client
to request a position such that if unchanged the cursor will be pointed
correctly, and perhaps a flag indicating if the pointer warping is wanted.
This sounds a lot like pointer-lock mode, too.

4. This needs to be applied to subsurfaces as well as popups. One of the
many many reasons I think these two things need to be unified.

Some other random ideas:

1. Client may want to indicate an "important" rectangle/region, and that
area outside of that can be clipped.

2. For rotations I think the compositor should be allowed to clip off some
sharp corners, rather than strictly showing every pixel in the popup.


On Thu, Oct 1, 2015 at 4:04 AM, Carlos Garnacho  wrote:

>
> > A different approach of solving the same issue is to shift the
> > responsibility for positioning popups from the client to the
> > compositor. This requires a more complex protocol allowing the client
> > describing the expected semantics, as well as a roundtrip then the
> > client needs to know how the compositor positioned a given rectangle.
> > For the position readback case, this approach has the same racyness as
> > the approach in this patch, and adding a new kind of positioning logic
> > would need changing the protocol. This approach is what Mir is taking.
> >
> > Personally, I'm not completely convinced a "wl_probe" way of improving
> > the menu positioning is the better option here, and would like to hear
> > what other think about this.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 1/2] Clarify the enum argument type

[Nils Chr. Brause]

On Thu, Oct 1, 2015 at 9:00 PM, Bill Spitzak  wrote:
>
>
> On Thu, Oct 1, 2015 at 8:09 AM, Nils Chr. Brause 
> wrote:
>>
>> Hi,
>>
>> I would recommend to also include the name of the interface, where the
>> enum is defined, in the enum attribute, e.g:
>> 
>
>
> I believe popular opinion was that a "local" enum, belonging to the same
> object as the message or event, should not require this prefix. One big
> reason is so that the object can be renamed without having to edit it's
> contents.
>
> And currently only such "local" enums are being used in the protocols, so
> there is no need for parsers to support any such prefix yet, and no need to
> figure out it's rules. Whether the ability to get enums from other objects,
> or from some global space, does not have to be decided yet.

There are "non-local" enums, e.g.
wl_surface::set_buffer_transform::transform uses the enum
wl_output::transform, or am I missing something important here?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Enums, bitfields and wl_arrays

[Nils Chr. Brause]

Hi,

On Thu, Oct 1, 2015 at 7:49 PM, Bryce Harrington  wrote:
> The topic of adding better enum/bitfield support to the protocol has
> come up a few[0] times[1] in the past, and again more recently[2].  We
> also have several proposed patches in patchwork, but I'm not sure they
> reflect consensus and none have Reviewed-by's on them yet [3,4,5,6,7].

I think this topic was first brought up in September 2014, so it is
more than a year now.

> From what I gather of the discussions, no one is really against this
> feature conceptually, and impementationally the discussions appear to
> have moved further afield.  It feels like we're real close to having
> something that could be landed, but it's not 100% clear to me what
> exactly to land.  Since it's a protocol types change I would prefer to
> make sure it has a strong consensus before landing it.
>
> I know that several people have proposed patches on this - Bill, Nils
> and Auke at least.  Since there's a definite need for this, and since
> agreement appears to be not far off, I would like to get this landed
> this release.  And ideally I'd like to get this landed early in the
> release so we give plenty of time for testing.

That would be great.

> Since Auke's patchset proposalis the most recent, let's take that one as
> the candidate for landing.  Gentlemen, I'd like to ask you to review
> these three patches [5,6,7] and either give your Reviewed-by's or flag
> specific improvements needed.  If you have a more conceptual
> disagreement, and don't think the patchset is landable as implemented,
> please raise that issue asap too.

There are some enum attributes missing, namely:
- wl_shm_pool::create_buffer::format (it's wl_shm::format)
- wl_shell_surface::set_fullscreen::method (it's
wl_shell_surface::fullscreen_method)
- wl_surface::set_buffer_transform::transform (it's wl_output::transform)

I would prefer, if the enum attributes would also name the interface,
where the enum can be found, e.g.:

If two enums in different interfaces happen to have the same name (if
that's possible?), this would lead to ambiguities otherwise. Also a
scanner wouldn't have to look up the interface name that way.

The scanner code looks good to me and seems to work.

The documentation looks good to me, too.

>
> Bryce
>
> 0: http://lists.freedesktop.org/archives/wayland-devel/2015-April/021438.html
> 1: http://lists.freedesktop.org/archives/wayland-devel/2015-June/023008.html
> 2: 
> http://lists.freedesktop.org/archives/wayland-devel/2015-September/024249.html
>
> 3: http://patchwork.freedesktop.org/patch/47726/
> 4: http://patchwork.freedesktop.org/patch/47727/
> 5: http://patchwork.freedesktop.org/patch/53018/
> 6: http://patchwork.freedesktop.org/patch/53019/
> 7: http://patchwork.freedesktop.org/patch/53020/
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 1/2] Clarify the enum argument type

[Bill Spitzak]

On Thu, Oct 1, 2015 at 8:09 AM, Nils Chr. Brause 
wrote:

> Hi,
>
> I would recommend to also include the name of the interface, where the
> enum is defined, in the enum attribute, e.g:
> 
>

I believe popular opinion was that a "local" enum, belonging to the same
object as the message or event, should not require this prefix. One big
reason is so that the object can be renamed without having to edit it's
contents.

And currently only such "local" enums are being used in the protocols, so
there is no need for parsers to support any such prefix yet, and no need to
figure out it's rules. Whether the ability to get enums from other objects,
or from some global space, does not have to be decided yet.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] protocol: Improve data source notification around DnD progress

[Bill Spitzak]

On Wed, Sep 30, 2015 at 1:45 PM, Carlos Garnacho  wrote:

>
> - wl_data_source.drop_performed: Happens when the operation has been
>   physically finished (eg. the button is released), it could be the right
>   place to reset the pointer cursor back and undo any other state resulting
>   from the initial button press.
>

This should not be necessary. When the grab is lost, whatever client is
under the pointer should get an enter event and should then set the cursor
to whatever it wants. The dnd source should certainly not set the cursor in
this case because it may set it to the wrong one, resulting in a blink of
this wrong cursor (ie it will quickly change between the drag cursor, the
cursor the source thought it should be, and the actual cursor for that
screen location).
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Enums, bitfields and wl_arrays

[Bill Spitzak]

I'm not sure why one of the large patches seems to be attributed to me, it
is actually Auke's.

My only contribution was a small patch (number 4) to use the enum/bitfield
information in the generated docs. My patch is slightly different that
Auke's proposal and he liked it better, I was just holding on to it until
the enum patches were applied.

I think the necessary enums were added to the xdg_shell and some other
protocol files but I don't see those patches listed.


On Thu, Oct 1, 2015 at 10:59 AM, Jasper St. Pierre 
wrote:

> We have a few constraints. First off, not all enums are closed. Some
> are intentionally open, like xdg_shell.state. So we definitely need a
> distinction between a closed enum and an open enum. I'm not familiar
> enough with Rust to be able to apply something to that.
>
> Second, I think we need to make a big effort to map out how the XML
> converts to a wire format. For the most part, it's obvious, except for
> the n -> sun hack we apply when we don't have an interface name. We
> should probably specify that somewhere.
>
> There's also a compatibility issue that has been brought up, but I
> never understood that one. Somebody else would be able to talk about
> that better.
>
> On Thu, Oct 1, 2015 at 10:49 AM, Bryce Harrington 
> wrote:
> > The topic of adding better enum/bitfield support to the protocol has
> > come up a few[0] times[1] in the past, and again more recently[2].  We
> > also have several proposed patches in patchwork, but I'm not sure they
> > reflect consensus and none have Reviewed-by's on them yet [3,4,5,6,7].
> >
> > From what I gather of the discussions, no one is really against this
> > feature conceptually, and impementationally the discussions appear to
> > have moved further afield.  It feels like we're real close to having
> > something that could be landed, but it's not 100% clear to me what
> > exactly to land.  Since it's a protocol types change I would prefer to
> > make sure it has a strong consensus before landing it.
> >
> > I know that several people have proposed patches on this - Bill, Nils
> > and Auke at least.  Since there's a definite need for this, and since
> > agreement appears to be not far off, I would like to get this landed
> > this release.  And ideally I'd like to get this landed early in the
> > release so we give plenty of time for testing.
> >
> > Since Auke's patchset proposalis the most recent, let's take that one as
> > the candidate for landing.  Gentlemen, I'd like to ask you to review
> > these three patches [5,6,7] and either give your Reviewed-by's or flag
> > specific improvements needed.  If you have a more conceptual
> > disagreement, and don't think the patchset is landable as implemented,
> > please raise that issue asap too.
> >
> > Bryce
> >
> > 0:
> http://lists.freedesktop.org/archives/wayland-devel/2015-April/021438.html
> > 1:
> http://lists.freedesktop.org/archives/wayland-devel/2015-June/023008.html
> > 2:
> http://lists.freedesktop.org/archives/wayland-devel/2015-September/024249.html
> >
> > 3: http://patchwork.freedesktop.org/patch/47726/
> > 4: http://patchwork.freedesktop.org/patch/47727/
> > 5: http://patchwork.freedesktop.org/patch/53018/
> > 6: http://patchwork.freedesktop.org/patch/53019/
> > 7: http://patchwork.freedesktop.org/patch/53020/
> > ___
> > 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: Can I enable mode switching from wayland/weston?

[Jasper St. Pierre]

As I mentioned on your post on Reddit [0], SDL2's video mode hooks are
no-ops, which explains why SDL isn't changing the resolution. You
could change SDL's code to use a different fullscreen mode. I am still
struggling why you need to change the resolution with a modeset.

[0] 
https://www.reddit.com/r/wayland/comments/3mkhlf/weston_outputs_monitor_preferred_resolution/

On Thu, Oct 1, 2015 at 8:12 AM, Robert Folland  wrote:
>
>> On 01 Oct 2015, at 17:08, Giulio Camuffo  wrote:
>>
>> 2015-10-01 18:03 GMT+03:00 Robert Folland :
>>> On 01 Oct 2015, at 16:47, Giulio Camuffo  wrote:

 2015-10-01 16:40 GMT+03:00 Robert Folland :
> Hi,
>
> I need to display video in different resolutions (the resolution of the 
> recording), but with weston/wayland I always end up with the resolution 
> preferred by the monitor (1920x1080 in my current setup).
>
> SDL2 thinks it is producing e.g. 1280x720, but that is not the real 
> output to screen. This is probably due to weston scaling this to 
> 1920x1080 for the monitor, intstead of doing a mode switching, which is 
> what I require for my application.

 Why do you need a mode switch? Unless you're using a CRT the monitor
 will scale the image up internally, and usually weston can do it
 better.
 Anyway, I assume SDL uses wl_shell, not xdg_shell, and
 wl_shell_surface.set_fullscreen accepts several modes, and one of them
 asks the compositor to perform a mode switch. Note that it *asks* to,
 there is no way to force it, and that's by design.

>>>
>>> I’ve set up a box to be an input source to other equipment. So it is 
>>> providing input to another box instead of e.g cameras, playing out 
>>> uncompressed video.
>>> So, it will not be displaying to monitors directly, but to a camera input 
>>> on another box. And that camera input is accepting a range of resolutions.
>>>
>>> When I check the resolution actually asked for from within SDL it says it 
>>> is producing my wanted resolution, but is is not actually apparing on the 
>>> output. So I suspect it is not able to force it to weston.
>>>
>>> The monitor/camera input receiving the signal is providing a list of 
>>> resolutions in its EDID data, and I guess one is preferred as a native 
>>> resolution. But as long as there are more entries in that EDID list, would 
>>> it not be a good idea to allow these to be “forced” through weston?
>>
>> It's not a good idea to let clients force modes, but it seems like you
>> just want weston to always use that resolution, am i right? If so you
>> can tell it to do so by setting the correct resolution in weston.ini.
>> Check "man weston.ini" for details.
>>
>
> Not really, this is a tool where users can change resolutions (actually 
> change video sequences) on the fly. But, it may work to restart weston on 
> every change, I can try that… thanks!
>
> -Robert
>
>
> ___
> 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: Enums, bitfields and wl_arrays

[Jasper St. Pierre]

We have a few constraints. First off, not all enums are closed. Some
are intentionally open, like xdg_shell.state. So we definitely need a
distinction between a closed enum and an open enum. I'm not familiar
enough with Rust to be able to apply something to that.

Second, I think we need to make a big effort to map out how the XML
converts to a wire format. For the most part, it's obvious, except for
the n -> sun hack we apply when we don't have an interface name. We
should probably specify that somewhere.

There's also a compatibility issue that has been brought up, but I
never understood that one. Somebody else would be able to talk about
that better.

On Thu, Oct 1, 2015 at 10:49 AM, Bryce Harrington  wrote:
> The topic of adding better enum/bitfield support to the protocol has
> come up a few[0] times[1] in the past, and again more recently[2].  We
> also have several proposed patches in patchwork, but I'm not sure they
> reflect consensus and none have Reviewed-by's on them yet [3,4,5,6,7].
>
> From what I gather of the discussions, no one is really against this
> feature conceptually, and impementationally the discussions appear to
> have moved further afield.  It feels like we're real close to having
> something that could be landed, but it's not 100% clear to me what
> exactly to land.  Since it's a protocol types change I would prefer to
> make sure it has a strong consensus before landing it.
>
> I know that several people have proposed patches on this - Bill, Nils
> and Auke at least.  Since there's a definite need for this, and since
> agreement appears to be not far off, I would like to get this landed
> this release.  And ideally I'd like to get this landed early in the
> release so we give plenty of time for testing.
>
> Since Auke's patchset proposalis the most recent, let's take that one as
> the candidate for landing.  Gentlemen, I'd like to ask you to review
> these three patches [5,6,7] and either give your Reviewed-by's or flag
> specific improvements needed.  If you have a more conceptual
> disagreement, and don't think the patchset is landable as implemented,
> please raise that issue asap too.
>
> Bryce
>
> 0: http://lists.freedesktop.org/archives/wayland-devel/2015-April/021438.html
> 1: http://lists.freedesktop.org/archives/wayland-devel/2015-June/023008.html
> 2: 
> http://lists.freedesktop.org/archives/wayland-devel/2015-September/024249.html
>
> 3: http://patchwork.freedesktop.org/patch/47726/
> 4: http://patchwork.freedesktop.org/patch/47727/
> 5: http://patchwork.freedesktop.org/patch/53018/
> 6: http://patchwork.freedesktop.org/patch/53019/
> 7: http://patchwork.freedesktop.org/patch/53020/
> ___
> 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

Enums, bitfields and wl_arrays

[Bryce Harrington]

The topic of adding better enum/bitfield support to the protocol has
come up a few[0] times[1] in the past, and again more recently[2].  We
also have several proposed patches in patchwork, but I'm not sure they
reflect consensus and none have Reviewed-by's on them yet [3,4,5,6,7].

From what I gather of the discussions, no one is really against this
feature conceptually, and impementationally the discussions appear to
have moved further afield.  It feels like we're real close to having
something that could be landed, but it's not 100% clear to me what
exactly to land.  Since it's a protocol types change I would prefer to
make sure it has a strong consensus before landing it.

I know that several people have proposed patches on this - Bill, Nils
and Auke at least.  Since there's a definite need for this, and since
agreement appears to be not far off, I would like to get this landed
this release.  And ideally I'd like to get this landed early in the
release so we give plenty of time for testing.

Since Auke's patchset proposalis the most recent, let's take that one as
the candidate for landing.  Gentlemen, I'd like to ask you to review
these three patches [5,6,7] and either give your Reviewed-by's or flag
specific improvements needed.  If you have a more conceptual
disagreement, and don't think the patchset is landable as implemented,
please raise that issue asap too.

Bryce

0: http://lists.freedesktop.org/archives/wayland-devel/2015-April/021438.html
1: http://lists.freedesktop.org/archives/wayland-devel/2015-June/023008.html
2: 
http://lists.freedesktop.org/archives/wayland-devel/2015-September/024249.html

3: http://patchwork.freedesktop.org/patch/47726/
4: http://patchwork.freedesktop.org/patch/47727/
5: http://patchwork.freedesktop.org/patch/53018/
6: http://patchwork.freedesktop.org/patch/53019/
7: http://patchwork.freedesktop.org/patch/53020/
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 1/4] ivi-shell: Add missing '\n' in weston_log function usage

[Bryce Harrington]

On Thu, Oct 01, 2015 at 10:51:29AM -0400, Chris Michael wrote:
> Signed-off-by: Chris Michael 
> ---
>  ivi-shell/hmi-controller.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Pretty straightforward, I pushed the set:

remote: Updating patchwork state for 
http://patchwork.freedesktop.org/project/wayland/list/
remote: I: patch #60856 updated using rev 
c083af99073a7cff98a27b16cae47ad1347b33c0
remote: I: patch #60855 updated using rev 
5169a57013111ccb344ee861a7db0f1a0f297c11
remote: I: patch #60857 updated using rev 
c262b4a94f5abd2a3fb1f47990ce7485ce26fb15
remote: I: patch #60858 updated using rev 
7e17fec68d8056c13d8ed557c338438deaf5b53d
remote: I: 4 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/wayland/weston
   64635ee..7e17fec  master -> master

Thanks,
Bryce
 
> diff --git a/ivi-shell/hmi-controller.c b/ivi-shell/hmi-controller.c
> index c388164..5cc76d3 100644
> --- a/ivi-shell/hmi-controller.c
> +++ b/ivi-shell/hmi-controller.c
> @@ -1780,7 +1780,7 @@ controller_module_init(struct weston_compositor *ec,
>   struct wl_event_loop *loop = NULL;
>  
>   if (interface_version < sizeof(struct ivi_controller_interface)) {
> - weston_log("ivi-shell: version mismatch of controller 
> interface");
> + weston_log("ivi-shell: version mismatch of controller 
> interface\n");
>   return -1;
>   }
>  
> -- 
> 2.5.3
> 
> ___
> 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: [PATCH wayland] protocol: Improve data source notification around DnD progress

[Michael Catanzaro]

One problem with this model is that a broken or malicious client could
force the drag source to be leaked by [sending accept and] never
destroying its data offer... but only once per user-initiated drag, so
we can probably ignore that issue

On Thu, 2015-10-01 at 12:00 +0200, Carlos Garnacho wrote:
> This is in order to be able to emit .cancelled if there is no
> agreement between source and destination about the data to be
> transferred. Otherwise every drop on any client with a wl_data_device
> would seem successful.

Ah, so the goal is to allow the drag source to know if the drop
succeeded. The only solution I can think of that avoids the problem I
mention is to delay the canceled event until the data offer is
destroyed. Then there is no race, and the drag source must simply wait
until drag_finished or a later drag_cancelled if it wants to indicate
to the user if the drag succeeded or not (the drop success indication
would be delayed until the data transfer is completed). I don't see any
problems with such a scheme, but if you can find one, then I think we'd
have to go with your solution and just say that my problem is a client
bug.

> I know .accept has had no functional role in the DnD state machine
> till now (besides UI feedback on the source-side, setting the
> appropriate cursor/dnd surfaces mostly), it made sense to me to reuse
> this though because compositor-side UI feedback and overall DnD
> outcome would be in sync for virtually every usecase I can imagine. I
> would expect .accept() to be called regularly on DnD motion over a
> surface, the pointer moves across inner widgets that accept different
> mimetypes or none.

Chrome does call it regularly on DnD motion, but only beginning after
it has received all the data.

> Actually, IMO there should be checks somewhere about the mimetype
> being one of the offered ones, in order to behave properly on wrong
> requests, although that means keeping the mimetype list in memory
> instead of just forwarding it.

If you mean that the mime type sent in accept or receive requests
should always be one of the offered mime types, then having the
compositor check for that is a fine idea that can't possibly hurt
anything.

> However, I can imagine other usecases where we don't know any
> concrete
> mimetype beforehand, eg. a "paste as html/plain text" popup menu on
> .drop_performed, there'd be no other way in these cases than
> preemptively picking one, as you say in your other mail.

Deciding later which type of data to actually use doesn't require any
interaction with the source process if the data has already been
received (as is the case for Chrome), and if the data has not already
been received, the receive request must specify an offered mime type.
In fact, Chrome's DnD backend doesn't ever know anything about which
mime type will actually be used (and in accept messages, it just sends
back whatever the first offered mime type was, fdo#91950).

Now, verifying that receive requests use a previously-accepted mime
type would be problematic for Chrome, since we receive and then accept
instead of vice-versa, but I don't think that's what you're proposing?

>  So perhaps it
> makes sense to split into a request with a boolean after all?
> Nonetheless, for the case of GTK+, both would be called from the same
> place (and .accept is already invariably called with the first
> mimetype from the list, hmm...)

Can you clarify your idea? I am a bit lost now. :)

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

Re: Can I enable mode switching from wayland/weston?

[Robert Folland]

> On 01 Oct 2015, at 17:08, Giulio Camuffo  wrote:
> 
> 2015-10-01 18:03 GMT+03:00 Robert Folland :
>> On 01 Oct 2015, at 16:47, Giulio Camuffo  wrote:
>>> 
>>> 2015-10-01 16:40 GMT+03:00 Robert Folland :
 Hi,
 
 I need to display video in different resolutions (the resolution of the 
 recording), but with weston/wayland I always end up with the resolution 
 preferred by the monitor (1920x1080 in my current setup).
 
 SDL2 thinks it is producing e.g. 1280x720, but that is not the real output 
 to screen. This is probably due to weston scaling this to 1920x1080 for 
 the monitor, intstead of doing a mode switching, which is what I require 
 for my application.
>>> 
>>> Why do you need a mode switch? Unless you're using a CRT the monitor
>>> will scale the image up internally, and usually weston can do it
>>> better.
>>> Anyway, I assume SDL uses wl_shell, not xdg_shell, and
>>> wl_shell_surface.set_fullscreen accepts several modes, and one of them
>>> asks the compositor to perform a mode switch. Note that it *asks* to,
>>> there is no way to force it, and that's by design.
>>> 
>> 
>> I’ve set up a box to be an input source to other equipment. So it is 
>> providing input to another box instead of e.g cameras, playing out 
>> uncompressed video.
>> So, it will not be displaying to monitors directly, but to a camera input on 
>> another box. And that camera input is accepting a range of resolutions.
>> 
>> When I check the resolution actually asked for from within SDL it says it is 
>> producing my wanted resolution, but is is not actually apparing on the 
>> output. So I suspect it is not able to force it to weston.
>> 
>> The monitor/camera input receiving the signal is providing a list of 
>> resolutions in its EDID data, and I guess one is preferred as a native 
>> resolution. But as long as there are more entries in that EDID list, would 
>> it not be a good idea to allow these to be “forced” through weston?
> 
> It's not a good idea to let clients force modes, but it seems like you
> just want weston to always use that resolution, am i right? If so you
> can tell it to do so by setting the correct resolution in weston.ini.
> Check "man weston.ini" for details.
> 

Not really, this is a tool where users can change resolutions (actually change 
video sequences) on the fly. But, it may work to restart weston on every 
change, I can try that… thanks!

-Robert



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 1/2] Clarify the enum argument type

[Nils Chr. Brause]

Hi,

I would recommend to also include the name of the interface, where the enum
is defined, in the enum attribute, e.g:


Also, I think you forgot some enum attributes, e.g. wl_shm_pool::
create_buffer::format is the wl_shm::format enum, but I can't find it in
your patch (I can't seem to find the e-mail with your second patch, though).
You might want to compare with my XML file:
https://github.com/NilsBrause/waylandpp/blob/master/scanner/wayland.xml

Apart from that, I like it for obvious reasons. :)

Cheers,
Nils


On 23 Apr 2015 04:41, "Bill Spitzak"  wrote:
>
> This improvement to the protocol allows you to refer to the kind of enum
you are expecting.
> It also introduces a distinction between enums that are bitfields, ie
> that can be OR'ed together.
> ---
>  protocol/wayland.dtd |2 ++
>  protocol/wayland.xml |   32 
>  2 files changed, 18 insertions(+), 16 deletions(-)
>
> diff --git a/protocol/wayland.dtd b/protocol/wayland.dtd
> index b8b1573..3b67ca8 100644
> --- a/protocol/wayland.dtd
> +++ b/protocol/wayland.dtd
> @@ -14,6 +14,7 @@
>  
>
>
> +  
>  
>
>
> @@ -25,5 +26,6 @@
>
>
>
> +  
>  
>
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index f52677f..2b9efa1 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -367,7 +367,7 @@
> can be used for buffers. Known formats include
> argb and xrgb.
>
> -  
> +  
>  
>
>
> @@ -774,7 +774,7 @@
>
>
>
> -  
> +  
>  
>
>  
> @@ -785,7 +785,7 @@
>
>  
>
> -
> +
>
> These flags specify details of the expected behaviour
> of transient surfaces. Used in the set_transient request.
> @@ -807,7 +807,7 @@
>
>
>
> -  
> +  
>  
>
>  
> @@ -891,7 +891,7 @@
>
>
>
> -  
> +  
>  
>
>  
> @@ -972,7 +972,7 @@
> in surface local coordinates.
>
>
> -  
> +  
>
>
>  
> @@ -1337,7 +1337,7 @@
>maintains a keyboard focus and a pointer focus.
>  
>
> -
> +
>
>  This is a bitmask of capabilities this seat has; if a member is
>  set, then it is present on the seat.
> @@ -1353,7 +1353,7 @@
> keyboard or touch capabilities.  The argument is a capability
> enum containing the complete set of capabilities this seat has.
>
> -  
> +  
>  
>
>  
> @@ -1521,7 +1521,7 @@
>
>
>
> -  
> +  
>  
>
>  
> @@ -1553,7 +1553,7 @@
>
>
>
> -  
> +  
>
>  
>
> @@ -1593,7 +1593,7 @@
> This event provides a file descriptor to the client which can be
> memory-mapped to provide a keyboard mapping description.
>
> -  
> +  
>
>
>  
> @@ -1638,7 +1638,7 @@
>
>
>
> -  
> +  
>  
>
>  
> @@ -1819,17 +1819,17 @@
>summary="width in millimeters of the output"/>
>summary="height in millimeters of the output"/>
> -   +  summary="subpixel orientation of the output"/>
>summary="textual description of the manufacturer"/>
>summary="textual description of the model"/>
> -   +  summary="transform that maps framebuffer to output"/>
>  
>
> -
> +
>
> These flags describe properties of an output mode.
> They are used in the flags bitfield of the mode event.
> @@ -1856,7 +1856,7 @@
>  the output may be scaled, as described in wl_output.scale,
>  or transformed , as described in wl_output.transform.
>
> -  
> +  
>
>
>
> --
> 1.7.9.5
>
> ___
> 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: Can I enable mode switching from wayland/weston?

[Giulio Camuffo]

2015-10-01 18:03 GMT+03:00 Robert Folland :
> On 01 Oct 2015, at 16:47, Giulio Camuffo  wrote:
>>
>> 2015-10-01 16:40 GMT+03:00 Robert Folland :
>>> Hi,
>>>
>>> I need to display video in different resolutions (the resolution of the 
>>> recording), but with weston/wayland I always end up with the resolution 
>>> preferred by the monitor (1920x1080 in my current setup).
>>>
>>> SDL2 thinks it is producing e.g. 1280x720, but that is not the real output 
>>> to screen. This is probably due to weston scaling this to 1920x1080 for the 
>>> monitor, intstead of doing a mode switching, which is what I require for my 
>>> application.
>>
>> Why do you need a mode switch? Unless you're using a CRT the monitor
>> will scale the image up internally, and usually weston can do it
>> better.
>> Anyway, I assume SDL uses wl_shell, not xdg_shell, and
>> wl_shell_surface.set_fullscreen accepts several modes, and one of them
>> asks the compositor to perform a mode switch. Note that it *asks* to,
>> there is no way to force it, and that's by design.
>>
>
> I’ve set up a box to be an input source to other equipment. So it is 
> providing input to another box instead of e.g cameras, playing out 
> uncompressed video.
> So, it will not be displaying to monitors directly, but to a camera input on 
> another box. And that camera input is accepting a range of resolutions.
>
> When I check the resolution actually asked for from within SDL it says it is 
> producing my wanted resolution, but is is not actually apparing on the 
> output. So I suspect it is not able to force it to weston.
>
> The monitor/camera input receiving the signal is providing a list of 
> resolutions in its EDID data, and I guess one is preferred as a native 
> resolution. But as long as there are more entries in that EDID list, would it 
> not be a good idea to allow these to be “forced” through weston?

It's not a good idea to let clients force modes, but it seems like you
just want weston to always use that resolution, am i right? If so you
can tell it to do so by setting the correct resolution in weston.ini.
Check "man weston.ini" for details.


--
Giulio

>
> -Robert
>
>
>
> ___
> 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: Can I enable mode switching from wayland/weston?

[Robert Folland]

On 01 Oct 2015, at 16:47, Giulio Camuffo  wrote:
> 
> 2015-10-01 16:40 GMT+03:00 Robert Folland :
>> Hi,
>> 
>> I need to display video in different resolutions (the resolution of the 
>> recording), but with weston/wayland I always end up with the resolution 
>> preferred by the monitor (1920x1080 in my current setup).
>> 
>> SDL2 thinks it is producing e.g. 1280x720, but that is not the real output 
>> to screen. This is probably due to weston scaling this to 1920x1080 for the 
>> monitor, intstead of doing a mode switching, which is what I require for my 
>> application.
> 
> Why do you need a mode switch? Unless you're using a CRT the monitor
> will scale the image up internally, and usually weston can do it
> better.
> Anyway, I assume SDL uses wl_shell, not xdg_shell, and
> wl_shell_surface.set_fullscreen accepts several modes, and one of them
> asks the compositor to perform a mode switch. Note that it *asks* to,
> there is no way to force it, and that's by design.
> 

I’ve set up a box to be an input source to other equipment. So it is providing 
input to another box instead of e.g cameras, playing out uncompressed video.
So, it will not be displaying to monitors directly, but to a camera input on 
another box. And that camera input is accepting a range of resolutions.

When I check the resolution actually asked for from within SDL it says it is 
producing my wanted resolution, but is is not actually apparing on the output. 
So I suspect it is not able to force it to weston.

The monitor/camera input receiving the signal is providing a list of 
resolutions in its EDID data, and I guess one is preferred as a native 
resolution. But as long as there are more entries in that EDID list, would it 
not be a good idea to allow these to be “forced” through weston?

-Robert




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 4/4] compositor-rdp: Add missing '\n' in weston_log usage

[Chris Michael]

Signed-off-by: Chris Michael 
---
 src/compositor-rdp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
index c221eb9..7272f41 100644
--- a/src/compositor-rdp.c
+++ b/src/compositor-rdp.c
@@ -1241,7 +1241,7 @@ rdp_backend_create(struct weston_compositor *compositor,
/* get the socket from RDP_FD var */
fd_str = getenv("RDP_FD");
if (!fd_str) {
-   weston_log("RDP_FD env variable not set");
+   weston_log("RDP_FD env variable not set\n");
goto err_output;
}
 
-- 
2.5.3

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

[PATCH 3/4] cms-colord: Add missing '\n' in weston_log usage

[Chris Michael]

Signed-off-by: Chris Michael 
---
 src/cms-colord.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/cms-colord.c b/src/cms-colord.c
index 1e61feb..c88eb11 100644
--- a/src/cms-colord.c
+++ b/src/cms-colord.c
@@ -145,7 +145,7 @@ update_device_with_profile_in_idle(struct cms_output *ocms)
gchar tmp = '\0';
rc = write(cms->writefd, &tmp, 1);
if (rc == 0)
-   weston_log("colord: failed to write to pending fd");
+   weston_log("colord: failed to write to pending fd\n");
}
 }
 
@@ -375,7 +375,7 @@ colord_dispatch_all_pending(int fd, uint32_t mask, void 
*data)
/* done */
rc = read(cms->readfd, &tmp, 1);
if (rc == 0)
-   weston_log("colord: failed to read from pending fd");
+   weston_log("colord: failed to read from pending fd\n");
return 1;
 }
 
-- 
2.5.3

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

[PATCH 2/4] screen-share: Add missing '\n' in weston_log usage

[Chris Michael]

Signed-off-by: Chris Michael 
---
 src/screen-share.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/screen-share.c b/src/screen-share.c
index e5f91ea..d961c89 100644
--- a/src/screen-share.c
+++ b/src/screen-share.c
@@ -438,13 +438,13 @@ shared_output_get_shm_buffer(struct shared_output *so)
 
fd = os_create_anonymous_file(height * stride);
if (fd < 0) {
-   weston_log("os_create_anonymous_file: %m");
+   weston_log("os_create_anonymous_file: %m\n");
return NULL;
}
 
data = mmap(NULL, height * stride, PROT_READ | PROT_WRITE, MAP_SHARED, 
fd, 0);
if (data == MAP_FAILED) {
-   weston_log("mmap: %m");
+   weston_log("mmap: %m\n");
goto out_close;
}
 
@@ -914,7 +914,7 @@ shared_output_create(struct weston_output *output, int 
parent_fd)
so->parent.surface =
wl_compositor_create_surface(so->parent.compositor);
if (!so->parent.surface) {
-   weston_log("Screen share failed: %m");
+   weston_log("Screen share failed: %m\n");
goto err_display;
}
 
@@ -924,7 +924,7 @@ shared_output_create(struct weston_output *output, int 
parent_fd)
  so->parent.output,
  
output->current_mode->refresh);
if (!so->parent.mode_feedback) {
-   weston_log("Screen share failed: %m");
+   weston_log("Screen share failed: %m\n");
goto err_display;
}

_wl_fullscreen_shell_mode_feedback_add_listener(so->parent.mode_feedback,
@@ -938,7 +938,7 @@ shared_output_create(struct weston_output *output, int 
parent_fd)
wl_event_loop_add_fd(loop, epoll_fd, WL_EVENT_READABLE,
 shared_output_handle_event, so);
if (!so->event_source) {
-   weston_log("Screen share failed: %m");
+   weston_log("Screen share failed: %m\n");
goto err_display;
}
 
-- 
2.5.3

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

[PATCH 1/4] ivi-shell: Add missing '\n' in weston_log function usage

[Chris Michael]

Signed-off-by: Chris Michael 
---
 ivi-shell/hmi-controller.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ivi-shell/hmi-controller.c b/ivi-shell/hmi-controller.c
index c388164..5cc76d3 100644
--- a/ivi-shell/hmi-controller.c
+++ b/ivi-shell/hmi-controller.c
@@ -1780,7 +1780,7 @@ controller_module_init(struct weston_compositor *ec,
struct wl_event_loop *loop = NULL;
 
if (interface_version < sizeof(struct ivi_controller_interface)) {
-   weston_log("ivi-shell: version mismatch of controller 
interface");
+   weston_log("ivi-shell: version mismatch of controller 
interface\n");
return -1;
}
 
-- 
2.5.3

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

Re: Can I enable mode switching from wayland/weston?

[Giulio Camuffo]

2015-10-01 16:40 GMT+03:00 Robert Folland :
> Hi,
>
> I need to display video in different resolutions (the resolution of the 
> recording), but with weston/wayland I always end up with the resolution 
> preferred by the monitor (1920x1080 in my current setup).
>
> SDL2 thinks it is producing e.g. 1280x720, but that is not the real output to 
> screen. This is probably due to weston scaling this to 1920x1080 for the 
> monitor, intstead of doing a mode switching, which is what I require for my 
> application.

Why do you need a mode switch? Unless you're using a CRT the monitor
will scale the image up internally, and usually weston can do it
better.
Anyway, I assume SDL uses wl_shell, not xdg_shell, and
wl_shell_surface.set_fullscreen accepts several modes, and one of them
asks the compositor to perform a mode switch. Note that it *asks* to,
there is no way to force it, and that's by design.


--
Giulio

>
> I am using arch linux with SDL2 2.0.3-1 and weston 1.8.0-1. If I use X11 
> instead of wayland/weston I get tmode switching ouput resolutions I require.
>
> Maybe there are some settings to weston I am missing? Googling gave me 
> references to weston fullscreen-shell. Can I get weston to output fullscreen 
> resolutions other than the one preferred by the monitor?
>
> Thanks,
> -Robert
>
>
> ___
> 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

Can I enable mode switching from wayland/weston?

[Robert Folland]

Hi,

I need to display video in different resolutions (the resolution of the 
recording), but with weston/wayland I always end up with the resolution 
preferred by the monitor (1920x1080 in my current setup).

SDL2 thinks it is producing e.g. 1280x720, but that is not the real output to 
screen. This is probably due to weston scaling this to 1920x1080 for the 
monitor, intstead of doing a mode switching, which is what I require for my 
application.

I am using arch linux with SDL2 2.0.3-1 and weston 1.8.0-1. If I use X11 
instead of wayland/weston I get tmode switching ouput resolutions I require.

Maybe there are some settings to weston I am missing? Googling gave me 
references to weston fullscreen-shell. Can I get weston to output fullscreen 
resolutions other than the one preferred by the monitor?

Thanks,
-Robert



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 1/2] Clarify the enum argument type

[Pekka Paalanen]

On Wed, 22 Apr 2015 19:40:44 -0700
Bill Spitzak  wrote:

> This improvement to the protocol allows you to refer to the kind of enum you 
> are expecting.
> It also introduces a distinction between enums that are bitfields, ie
> that can be OR'ed together.
> ---
>  protocol/wayland.dtd |2 ++
>  protocol/wayland.xml |   32 
>  2 files changed, 18 insertions(+), 16 deletions(-)

Hi,

I like the enum="" additions. I believe wayland-scanner should be
ignoring unknown attributes since its inception, so that should not
pose a problem.

All in all this patch series would be a very good improvement to the
docs.

However, I don't think we have a closure on the enum/bitfield attribute
discussion yet: how they can be used, what they guarantee and require, and
what to do when things change. I think we need to see that through
before taking this or the 2/2 patch, because these attributes may
affect other code generators than C. (TBF, I haven't been able to dig
into that discussion again.)

Let's keep these two patches still in the queue until the enum/bitfield
attribute design is decided.


Thanks,
pq


pgpVy0USblDsh.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Multiple views for the same IVI surface

[Pekka Paalanen]

On Thu, 1 Oct 2015 13:27:45 +0200
Frederico Cadete  wrote:

> On Thu, Oct 1, 2015 at 12:23 PM Pekka Paalanen  wrote:
> >
> > On Thu, 01 Oct 2015 17:13:47 +0900
> > Nobuhiko Tanibata  wrote:
> >
> > > Hi,
> > >
> > > Tested-by: Nobuhiko Tanibata 
> > > Reviewed-by: Nobuhiko Tanibata 
> > >
> > > These constructors are reserved for a feature of 'a ivi-surface to
> > > several layers' and 'a ivi-layer to several screens'. This feature is
> > > required for
> > > - for example, car navigation application prepares junction guide on a
> > > surface, which shall be displayed in its own UI and cloned on
> > > instrumental cluster in another screen as well. In this case, a
> > > ivi-surface can be located in both.
> 
> I realize this is a hypothetical feature and certainly not for now, but
> 
> I understand the need for showing the same thing in more than one screen. But
> is it sure that using the same shell surface and allowing it to be in
> more than one
> layer is the correct approach?

Hi Frederico,

Wayland allows this, that's all I can say as not an IVI person.

> The current code has properties such as destination region and
> visiblity that are part
> of the surface. These semantics are exported in ivi-layout-export.h.
> 
> I would be tempted to look into using the same wl_buffer attached to two
> wl_surfaces, but it's too much for me when I start thinking about how
> the releasing
> of the buffer would work.

That's actually a very good question:
https://bugs.freedesktop.org/show_bug.cgi?id=75303

It should work in theory, but there is some work needed to make the
semantics right.

> Maybe other shells have done this, or would be
> interested in it?
> This question would also arise if using one ivi_surface on two ivi_layers.

The difference here is: do you require the app to create a good number
of wl_surfaces with proper ivi-ids, or do you want the IVI-controller
(window manager) to be able to do it without app's explicit cooperation.

That's for the IVI architects to decide. Both ways are possible from
Wayland and Weston point of view.


Thanks,
pq

> > > However, I have to modify weston core to realize it. So, for the time
> > > being, we can remove them at this time to simplify codes.
> >
> > Hi,
> >
> > I'm not sure you need to modify Weston core. You need to create
> > one weston_view for each ivi-screen/ivi-layer/ivi-surface combination.


pgp81w3HBXTbT.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Multiple views for the same IVI surface

[Frederico Cadete]

On Thu, Oct 1, 2015 at 12:23 PM Pekka Paalanen  wrote:
>
> On Thu, 01 Oct 2015 17:13:47 +0900
> Nobuhiko Tanibata  wrote:
>
> > Hi,
> >
> > Tested-by: Nobuhiko Tanibata 
> > Reviewed-by: Nobuhiko Tanibata 
> >
> > These constructors are reserved for a feature of 'a ivi-surface to
> > several layers' and 'a ivi-layer to several screens'. This feature is
> > required for
> > - for example, car navigation application prepares junction guide on a
> > surface, which shall be displayed in its own UI and cloned on
> > instrumental cluster in another screen as well. In this case, a
> > ivi-surface can be located in both.

I realize this is a hypothetical feature and certainly not for now, but

I understand the need for showing the same thing in more than one screen. But
is it sure that using the same shell surface and allowing it to be in
more than one
layer is the correct approach?
The current code has properties such as destination region and
visiblity that are part
of the surface. These semantics are exported in ivi-layout-export.h.

I would be tempted to look into using the same wl_buffer attached to two
wl_surfaces, but it's too much for me when I start thinking about how
the releasing
of the buffer would work. Maybe other shells have done this, or would be
interested in it?
This question would also arise if using one ivi_surface on two ivi_layers.

Regards,
Frederico

> >
> > However, I have to modify weston core to realize it. So, for the time
> > being, we can remove them at this time to simplify codes.
>
> Hi,
>
> I'm not sure you need to modify Weston core. You need to create
> one weston_view for each ivi-screen/ivi-layer/ivi-surface combination.
>
> Emre, these are nice clean-ups. I have a couple of comments for the
> future:
> - mind the line length in the commit message, I re-wrapped all the
>   patches
> - use a space after a keyword like 'if', I think there were a few without
>
> Pushed all 5 patches:
>dcba1a1..64635ee  master -> master
>
>
> Thanks,
> pq
> ___
> 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: [RFC 1/2] Introduce wl_probe_visible protocol

[Carlos Garnacho]

Hey Jonas!,

On Thu, Oct 1, 2015 at 8:51 AM, Jonas Ådahl  wrote:
> wl_probe_visible (for now _wl_probe_visible) is a reintroduction of
> the "wl_probe" method of making it possible to position a surface so
> that it is completely visible, when positioning it relative to some
> other already mapped surface. It works by checking what parts of a
> rectangle relative to an existing surface would be visible, allowing
> the client to reposition its surface accordingly.
>
> The protocol and implementation is based on patches by Rob Bradford
> from 2013[0][1].
>
> [1] http://lists.freedesktop.org/archives/wayland-devel/2013-April/008665.html
> [2] http://lists.freedesktop.org/archives/wayland-devel/2013-April/008666.html
>
> Signed-off-by: Jonas Ådahl 
> ---
>
> Hi,
>
> Some time ago I took the old "wl_probe" patches and updated them to
> work today. The approach is mostly the same, but with some renaming and
> moving around (it's for example not part of wl_shell anymore). It was
> brought up on the mailing list recently, so I thought it could be a good
> idea to make it easier to test on todays weston, so here it is.
>
> The are a few problems with this approach, such as:
>
> 1) It requires an extra roundtrip to create a popup/tooltip (not that
> big of a deal though, I'd say).
> 2) When the parent surface has non-trivial transformations (non-90
> degree rotation etc), a resulting rectangle is ambigous. This could be
> made implementation specific or with some required semantics (such as
> prefer rectangles where more corners are untouched, prefer larger
> rectangle etc).

I'm tempted to say this is compositor-specific territory, this depends
a lot on how do compositors represent/map surfaces, and what do they
allow to do with them at all. IMHO, mentioning that the coordinate
axes of both surfaces are expected to be aligned is a generic enough
common ground.

> 3) It may be abused to get an (incorrect) absolute surface position.
> 4) It is racy - for a moving surface, the visibility will change as it
> moves.

I would like to point out that it could be a common case. In GTK+ this
would also be interesting for GtkPopover positioning, those are
implemented as subsurfaces. It would be great to keep them onscreen
(they are able to snap to either of four sides) but at the same time
the toplevel window is draggable, so the positioning isn't static.
Moreover, each next position tried must be probed too, because it
might have the same space problem.

>
> A different approach of solving the same issue is to shift the
> responsibility for positioning popups from the client to the
> compositor. This requires a more complex protocol allowing the client
> describing the expected semantics, as well as a roundtrip then the
> client needs to know how the compositor positioned a given rectangle.
> For the position readback case, this approach has the same racyness as
> the approach in this patch, and adding a new kind of positioning logic
> would need changing the protocol. This approach is what Mir is taking.
>
> Personally, I'm not completely convinced a "wl_probe" way of improving
> the menu positioning is the better option here, and would like to hear
> what other think about this.

Perhaps changing this to a "subscription" model, where you pass
surface+rectangle on the constructor and you receive events as parent
surfaces move? I think it'd get rid of the roundtrip/raciness problem,
seems a better fit for those "often repositioned" cases, and would be
down to a single event for static cases (although you keep an object
around). It would be great to attach this to the lifetime of the
surface you're about to map though, or at least advise through docs.

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

RE: [Wayland1.5]CPU occupancy rate of Weston is 99%

[박성진]

Dear Yang Andy,
You can trace the status of Weston with the following ways:

- Trace with WAYLAND_DEBUG environment variable
   export WAYLAND_DEBUG=1
   Run Weston
   Watch what's going on...

- Trace with wchan : you can see which system call is called by a process
   ps -aux | grep weston
   cat /proc/{pid of Weston}/wchan (with root privilege)
   The above command will display the system call called by Weston now.

- Trace with strace : you can see which system call is called by a process
continuously
   e.g. strace -p {pid of Weston} -f
   This will print a lot of system calls if it's not stuck in a specific
system call.
   If Weston is doing somethings in a loop, system calls for those things
will be displayed.

- Trace with ltrace : you can see which library call is called by a process
continuously

- Trace with gdb

I hope this will helpful to you.
Thank and regards,
Sung-Jin Park


-Original Message-
From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On
Behalf Of Pekka Paalanen
Sent: Thursday, October 01, 2015 7:31 PM
To: Yang Andy
Cc: wayland-devel@lists.freedesktop.org
Subject: Re: [Wayland1.5]CPU occupancy rate of Weston is 99%

On Thu, 1 Oct 2015 08:54:47 +
Yang Andy  wrote:

> Hi everyone
> When i run QT-Application on wayland/weston,sometimes there is NG 
> issue that CPU occupancy rate of Weston is 99%. The probability of 
> this NG issue is very low,but if the NG issue occur,CPU occupancy rate 
> of Weston retains 99%. Could anyone give me some advice on how to 
> track the NG issue of weston? And what factors could cause this issue? 
> Best regards. Andy

Hi,

you need to find out where Weston is spinning when it happens. Use gdb to
interrupt Weston several times and note the stack trace, or use a profiling
tool with stack traces.

List corruption often results in an endless loop in wl_list_for_each etc.


Thanks,
pq

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

Re: [Wayland1.5]CPU occupancy rate of Weston is 99%

[Pekka Paalanen]

On Thu, 1 Oct 2015 08:54:47 +
Yang Andy  wrote:

> Hi everyone
> When i run QT-Application on wayland/weston,sometimes there is NG
> issue that CPU occupancy rate of Weston is 99%. The probability of
> this NG issue is very low,but if the NG issue occur,CPU occupancy
> rate of Weston retains 99%. Could anyone give me some advice on how
> to track the NG issue of weston? And what factors could cause this
> issue? Best regards. Andy

Hi,

you need to find out where Weston is spinning when it happens. Use gdb
to interrupt Weston several times and note the stack trace, or use a
profiling tool with stack traces.

List corruption often results in an endless loop in wl_list_for_each
etc.


Thanks,
pq


pgp6S3_E9WHg5.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 1/5] ivi-shell: remove struct link_screen

[Pekka Paalanen]

On Thu, 01 Oct 2015 17:13:47 +0900
Nobuhiko Tanibata  wrote:

> Hi,
> 
> Tested-by: Nobuhiko Tanibata 
> Reviewed-by: Nobuhiko Tanibata 
> 
> These constructors are reserved for a feature of 'a ivi-surface to 
> several layers' and 'a ivi-layer to several screens'. This feature is 
> required for
> - for example, car navigation application prepares junction guide on a 
> surface, which shall be displayed in its own UI and cloned on 
> instrumental cluster in another screen as well. In this case, a 
> ivi-surface can be located in both.
> 
> However, I have to modify weston core to realize it. So, for the time 
> being, we can remove them at this time to simplify codes.

Hi,

I'm not sure you need to modify Weston core. You need to create
one weston_view for each ivi-screen/ivi-layer/ivi-surface combination.

Emre, these are nice clean-ups. I have a couple of comments for the
future:
- mind the line length in the commit message, I re-wrapped all the
  patches
- use a space after a keyword like 'if', I think there were a few without

Pushed all 5 patches:
   dcba1a1..64635ee  master -> master


Thanks,
pq


pgpOH45ZQlqp9.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] protocol: Improve data source notification around DnD progress

[Carlos Garnacho]

Hey Michael :),

On Thu, Oct 1, 2015 at 12:43 AM, Michael Catanzaro
 wrote:
> Reviewed-by: Michael Catanzaro 
>
> These are important fixes for the protocol that will allow drags to
> work between GTK+ and Chrome. Thanks for working on this, Carlos!

Thanks for the review!

>
> Nit #1: the existing documentation doesn't use the DnD abbreviation, so
> I would write out "drag-and-drop" in the documentation of the cancelled
> event.
>
> Nit #2: You have a comma splice in the documentation for drag_finished;
> you should change it to a semicolon, or split it into two sentences, or
> add a conjunction.

Right :), fixing these locally. Will send another patch when we've got
an outcome for the question below.

>
> Minor issue: this and the next patch introduce the requirement that
> accept is called on the data offer before the mouse grab is released. I
> now see this has always been required by mutter -- not sure why -- but
> it's new for Weston. (In fact, sending accepts has always been
> optional.) The new restriction seems a bit arbitrary and could be hard
> for some clients. Chrome's cross-platform DnD abstraction all but
> requires drag data to have been received before it can determine
> whether to accept a mime type, so Chrome doesn't send an accept until
> it's done receiving. Previously, that just meant the cursor would not
> be updated in response to motion events during that time, but now it
> means the drop will fail. This is not a huge deal, and the other
> changes in these patches are much more important, but it suggests we
> shouldn't add this restriction unless there's a good reason behind
> it... and I don't know of one, so I'd like to understand that. The
> change isn't necessary for the protocol as-is, and doesn't seem
> necessary for DnD actions, either?

This is in order to be able to emit .cancelled if there is no
agreement between source and destination about the data to be
transferred. Otherwise every drop on any client with a wl_data_device
would seem successful.

I know .accept has had no functional role in the DnD state machine
till now (besides UI feedback on the source-side, setting the
appropriate cursor/dnd surfaces mostly), it made sense to me to reuse
this though because compositor-side UI feedback and overall DnD
outcome would be in sync for virtually every usecase I can imagine. I
would expect .accept() to be called regularly on DnD motion over a
surface, the pointer moves across inner widgets that accept different
mimetypes or none.

Actually, IMO there should be checks somewhere about the mimetype
being one of the offered ones, in order to behave properly on wrong
requests, although that means keeping the mimetype list in memory
instead of just forwarding it.

However, I can imagine other usecases where we don't know any concrete
mimetype beforehand, eg. a "paste as html/plain text" popup menu on
.drop_performed, there'd be no other way in these cases than
preemptively picking one, as you say in your other mail. So perhaps it
makes sense to split into a request with a boolean after all?
Nonetheless, for the case of GTK+, both would be called from the same
place (and .accept is already invariably called with the first
mimetype from the list, hmm...)

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

[Wayland1.5]CPU occupancy rate of Weston is 99%

[Yang Andy]

Hi everyone
When i run QT-Application on wayland/weston,sometimes there is NG issue that 
CPU occupancy rate of Weston is 99%.
The probability of this NG issue is very low,but if the NG issue occur,CPU 
occupancy rate of Weston retains 99%.
Could anyone give me some advice on how to track the NG issue of weston?
And what factors could cause this issue?
Best regards.
Andy  ___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 3/5] ivi-shell: remove is_layer_in_screen API

[Nobuhiko Tanibata]

Hi,

Tested-by: Nobuhiko Tanibata 
Reviewed-by: Nobuhiko Tanibata 

Best Regards,
Nobuhiko Tanibata

2015-08-28 21:59 に Ucan, Emre (ADITG/SW1) さんは書きました:

This internal API is redundant, because a layer is allowed to be only
on one screen.

Signed-off-by: Emre Ucan 
---
 ivi-shell/ivi-layout.c |   19 +--
 1 file changed, 1 insertion(+), 18 deletions(-)

diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index 2a33b3e..47c044a 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/ivi-layout.c
@@ -251,21 +251,6 @@ is_surface_in_layer(struct ivi_layout_surface 
*ivisurf,

return 0;
 }

-static int
-is_layer_in_screen(struct ivi_layout_layer *ivilayer,
-  struct ivi_layout_screen *iviscrn)
-{
-   struct ivi_layout_layer *layer = NULL;
-
-   wl_list_for_each(layer, &iviscrn->pending.layer_list, pending.link) {
-   if (layer->id_layer == ivilayer->id_layer) {
-   return 1;
-   }
-   }
-
-   return 0;
-}
-
 /**
  * Internal API to initialize ivi_screens found from output_list of
weston_compositor.
  * Called by ivi_layout_init_with_compositor.
@@ -2244,15 +2229,13 @@ ivi_layout_screen_add_layer(struct
ivi_layout_screen *iviscrn,
struct ivi_layout *layout = get_instance();
struct ivi_layout_layer *ivilayer = NULL;
struct ivi_layout_layer *next = NULL;
-   int is_layer_in_scrn = 0;

if (iviscrn == NULL || addlayer == NULL) {
weston_log("ivi_layout_screen_add_layer: invalid argument\n");
return IVI_FAILED;
}

-   is_layer_in_scrn = is_layer_in_screen(addlayer, iviscrn);
-   if (is_layer_in_scrn == 1) {
+   if (addlayer->on_screen == iviscrn) {
 		weston_log("ivi_layout_screen_add_layer: addlayer is already 
available\n");

return IVI_SUCCEEDED;
}

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

Re: [PATCH 4/5] ivi-shell: remove is_surface_in_layer API

[Nobuhiko Tanibata]

Hi,

Tested-by: Nobuhiko Tanibata 
Reviewed-by: Nobuhiko Tanibata 

BR,
Nobuhiko Tanibata

2015-08-28 21:59 に Ucan, Emre (ADITG/SW1) さんは書きました:

This internal API is redundant, because a surface is allowed to be
only on one layer.

Signed-off-by: Emre Ucan 
---
 ivi-shell/ivi-layout.c |   23 +--
 1 file changed, 1 insertion(+), 22 deletions(-)

diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index 47c044a..49e789e 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/ivi-layout.c
@@ -233,25 +233,6 @@ ivi_layout_surface_destroy(struct
ivi_layout_surface *ivisurf)
 }

 /**
- * Internal API to check ivi_layer/ivi_surface already added in
ivi_layer/ivi_screen.
- * Called by ivi_layout_layer_add_surface/ivi_layout_screenAddLayer
- */
-static int
-is_surface_in_layer(struct ivi_layout_surface *ivisurf,
-   struct ivi_layout_layer *ivilayer)
-{
-   struct ivi_layout_surface *surf = NULL;
-
-	wl_list_for_each(surf, &ivilayer->pending.surface_list, pending.link) 
{

-   if (surf->id_surface == ivisurf->id_surface) {
-   return 1;
-   }
-   }
-
-   return 0;
-}
-
-/**
  * Internal API to initialize ivi_screens found from output_list of
weston_compositor.
  * Called by ivi_layout_init_with_compositor.
  */
@@ -2386,15 +2367,13 @@ ivi_layout_layer_add_surface(struct
ivi_layout_layer *ivilayer,
struct ivi_layout *layout = get_instance();
struct ivi_layout_surface *ivisurf = NULL;
struct ivi_layout_surface *next = NULL;
-   int is_surf_in_layer = 0;

if (ivilayer == NULL || addsurf == NULL) {
weston_log("ivi_layout_layer_add_surface: invalid argument\n");
return IVI_FAILED;
}

-   is_surf_in_layer = is_surface_in_layer(addsurf, ivilayer);
-   if (is_surf_in_layer == 1) {
+   if (addsurf->on_layer == ivilayer) {
 		weston_log("ivi_layout_layer_add_surface: addsurf is already 
available\n");

return IVI_SUCCEEDED;
}

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

Re: [PATCH 5/5] ivi-shell: introduce get_weston_view

[Nobuhiko Tanibata]

Hi,

Tested-by: Nobuhiko Tanibata 
Reviewed-by: Nobuhiko Tanibata 

Best Regards,
Nobuhiko Tanibata

2015-08-28 21:59 に Ucan, Emre (ADITG/SW1) さんは書きました:
The internal API "get_weston_view" is introduced, which returns the 
weston_view

of the given ivi_layout_surface. The API returns a NULL pointer, if
the ivi_layout_surface
does not have any weston_view.

The weston_view is required in many places of ivi-shell implementation.
Therefore, this API will reduce lines of code. Furthermore, it will 
increase

the maintainability of the ivi-shell implementation.

Old way of getting the weston_view was flawed, because the views list
of the weston_surface
is read without controlling the existence of the weston_surface.
New implementation explicitly throws an error if the weston_surface
does not exist.

Signed-off-by: Emre Ucan 
---
 ivi-shell/ivi-layout.c |   75 
+---

 1 file changed, 33 insertions(+), 42 deletions(-)

diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index 49e789e..702878f 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/ivi-layout.c
@@ -150,6 +150,22 @@ get_layer(struct wl_list *layer_list, uint32_t 
id_layer)

return NULL;
 }

+static struct weston_view *
+get_weston_view(struct ivi_layout_surface *ivisurf)
+{
+   struct weston_view *view = NULL;
+
+   assert(ivisurf->surface != NULL);
+
+   /* One view per surface */
+   if(wl_list_empty(&ivisurf->surface->views))
+   view = NULL;
+   else
+		view = wl_container_of(ivisurf->surface->views.next, view, 
surface_link);

+
+   return view;
+}
+
 static void
 remove_configured_listener(struct ivi_layout_surface *ivisurf)
 {
@@ -302,18 +318,15 @@ static void
 update_opacity(struct ivi_layout_layer *ivilayer,
   struct ivi_layout_surface *ivisurf)
 {
+   struct weston_view *tmpview = NULL;
double layer_alpha = wl_fixed_to_double(ivilayer->prop.opacity);
double surf_alpha  = wl_fixed_to_double(ivisurf->prop.opacity);

if ((ivilayer->event_mask & IVI_NOTIFICATION_OPACITY) ||
(ivisurf->event_mask  & IVI_NOTIFICATION_OPACITY)) {
-   struct weston_view *tmpview = NULL;
-   wl_list_for_each(tmpview, &ivisurf->surface->views, 
surface_link) {
-   if (tmpview == NULL) {
-   continue;
-   }
-   tmpview->alpha = layer_alpha * surf_alpha;
-   }
+   tmpview = get_weston_view(ivisurf);
+   assert(tmpview != NULL);
+   tmpview->alpha = layer_alpha * surf_alpha;
}
 }

@@ -590,11 +603,8 @@ update_prop(struct ivi_layout_layer *ivilayer,

update_opacity(ivilayer, ivisurf);

-   wl_list_for_each(tmpview, &ivisurf->surface->views, surface_link) {
-   if (tmpview != NULL) {
-   break;
-   }
-   }
+   tmpview = get_weston_view(ivisurf);
+   assert(tmpview != NULL);

 	if (ivisurf->prop.source_width == 0 || ivisurf->prop.source_height == 
0) {

weston_log("ivi-shell: source rectangle is not yet set by
ivi_layout_surface_set_source_rectangle\n");
@@ -613,24 +623,18 @@ update_prop(struct ivi_layout_layer *ivilayer,
calc_surface_to_global_matrix_and_mask_to_weston_surface(
ivilayer, ivisurf, &ivisurf->transform.matrix, &r);

-   if (tmpview != NULL) {
-   weston_view_set_mask(tmpview, r.x, r.y, r.width, 
r.height);
-   wl_list_insert(&tmpview->geometry.transformation_list,
-  &ivisurf->transform.link);
+   weston_view_set_mask(tmpview, r.x, r.y, r.width, r.height);
+   wl_list_insert(&tmpview->geometry.transformation_list,
+  &ivisurf->transform.link);

-   weston_view_set_transform_parent(tmpview, NULL);
-   }
+   weston_view_set_transform_parent(tmpview, NULL);
}

ivisurf->update_count++;

-   if (tmpview != NULL) {
-   weston_view_geometry_dirty(tmpview);
-   }
+   weston_view_geometry_dirty(tmpview);

-   if (ivisurf->surface != NULL) {
-   weston_surface_damage(ivisurf->surface);
-   }
+   weston_surface_damage(ivisurf->surface);
 }

 static void
@@ -799,6 +803,7 @@ commit_screen_list(struct ivi_layout *layout)
struct ivi_layout_layer   *ivilayer = NULL;
struct ivi_layout_layer   *next = NULL;
struct ivi_layout_surface *ivisurf  = NULL;
+   struct weston_view *tmpview = NULL;

wl_list_for_each(iviscrn, &layout->screen_list, link) {
if (iviscrn->order.dirty) {
@@ -831,17 +836,11 @@ commit_screen_list(struct ivi_layout *layout)
continue;

 			wl_list_for_each(ivisurf, &ivilayer->order.surface_list, 
order

Re: [PATCH 2/5] ivi-shell: remove struct link_layer

[Nobuhiko Tanibata]

Hi,

Tested-by: Nobuhiko Tanibata 
Reviewed-by: Nobuhiko Tanibata 

BR,
Nobuhiko Tanibata

2015-08-28 21:58 に Ucan, Emre (ADITG/SW1) さんは書きました:

link_layer's sole purpose is to link a surface to multiple layers, if
the surface should be shown in multiple layers.
This can be only achieved, if the surface has multiple weston_views
with different transformation matrices.

Current implementation assumes in many places that a ivi_surface has
only one weston_view.
Therefore, a surface can be only shown on one layer.

Although this (a surface on multiple layers) is a nice to have feature
for ivi-shell, it is not very crucial.
In any case, it is not an easy task to implement this feature, because
it has lot of corner cases.

I removed with this patch the link_layer data structure, because it
does not have any purpose in current implementation.

Signed-off-by: Emre Ucan 
---
 ivi-shell/ivi-layout-private.h |3 +-
 ivi-shell/ivi-layout.c |   92 
+++-

 2 files changed, 7 insertions(+), 88 deletions(-)

diff --git a/ivi-shell/ivi-layout-private.h 
b/ivi-shell/ivi-layout-private.h

index a9dbdde..3244390 100644
--- a/ivi-shell/ivi-layout-private.h
+++ b/ivi-shell/ivi-layout-private.h
@@ -32,11 +32,11 @@
 struct ivi_layout_surface {
struct wl_list link;
struct wl_signal property_changed;
-   struct wl_list layer_list;
int32_t update_count;
uint32_t id_surface;

struct ivi_layout *layout;
+   struct ivi_layout_layer *on_layer;
struct weston_surface *surface;

struct weston_transform transform;
@@ -65,7 +65,6 @@ struct ivi_layout_surface {
 struct ivi_layout_layer {
struct wl_list link;
struct wl_signal property_changed;
-   struct wl_list link_to_surface;
uint32_t id_layer;

struct ivi_layout *layout;
diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index 087f94c..2a33b3e 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/ivi-layout.c
@@ -69,12 +69,6 @@

 #define max(a, b) ((a) > (b) ? (a) : (b))

-struct link_layer {
-   struct ivi_layout_layer *ivilayer;
-   struct wl_list link;
-   struct wl_list link_to_layer;
-};
-
 struct listener_layout_notification {
void *userdata;
struct wl_listener listener;
@@ -126,72 +120,6 @@ get_instance(void)
 }

 /**
- * Internal API to add/remove a link to ivi_surface from ivi_layer.
- */
-static void
-add_link_to_surface(struct ivi_layout_layer *ivilayer,
-   struct link_layer *link_layer)
-{
-   struct link_layer *link = NULL;
-
-   wl_list_for_each(link, &ivilayer->link_to_surface, link_to_layer) {
-   if (link == link_layer)
-   return;
-   }
-
-	wl_list_insert(&ivilayer->link_to_surface, 
&link_layer->link_to_layer);

-}
-
-static void
-remove_link_to_surface(struct ivi_layout_layer *ivilayer)
-{
-   struct link_layer *link = NULL;
-   struct link_layer *next = NULL;
-
-	wl_list_for_each_safe(link, next, &ivilayer->link_to_surface, 
link_to_layer) {

-   wl_list_remove(&link->link_to_layer);
-   wl_list_remove(&link->link);
-   free(link);
-   }
-
-   wl_list_init(&ivilayer->link_to_surface);
-}
-
-/**
- * Internal API to add/remove a ivi_surface from ivi_layer.
- */
-static void
-add_ordersurface_to_layer(struct ivi_layout_surface *ivisurf,
- struct ivi_layout_layer *ivilayer)
-{
-   struct link_layer *link_layer = NULL;
-
-   link_layer = malloc(sizeof *link_layer);
-   if (link_layer == NULL) {
-   weston_log("fails to allocate memory\n");
-   return;
-   }
-
-   link_layer->ivilayer = ivilayer;
-   wl_list_insert(&ivisurf->layer_list, &link_layer->link);
-   add_link_to_surface(ivilayer, link_layer);
-}
-
-static void
-remove_ordersurface_from_layer(struct ivi_layout_surface *ivisurf)
-{
-   struct link_layer *link_layer = NULL;
-   struct link_layer *next = NULL;
-
-   wl_list_for_each_safe(link_layer, next, &ivisurf->layer_list, link) {
-   wl_list_remove(&link_layer->link);
-   wl_list_remove(&link_layer->link_to_layer);
-   free(link_layer);
-   }
-   wl_list_init(&ivisurf->layer_list);
-}
-
-/**
  * Internal API to add/remove a ivi_layer to/from ivi_screen.
  */
 static struct ivi_layout_surface *
@@ -294,7 +222,6 @@ ivi_layout_surface_destroy(struct
ivi_layout_surface *ivisurf)
wl_list_remove(&ivisurf->pending.link);
wl_list_remove(&ivisurf->order.link);
wl_list_remove(&ivisurf->link);
-   remove_ordersurface_from_layer(ivisurf);

wl_signal_emit(&layout->surface_notification.removed, ivisurf);

@@ -878,7 +805,7 @@ commit_layer_list(struct ivi_layout *layout)

wl_list_for_each_safe(ivisurf, next, 
&ivilayer->order.surface_list,
 order.link) {
-  

Re: [PATCH 1/5] ivi-shell: remove struct link_screen

[Nobuhiko Tanibata]

Hi,

Tested-by: Nobuhiko Tanibata 
Reviewed-by: Nobuhiko Tanibata 

These constructors are reserved for a feature of 'a ivi-surface to 
several layers' and 'a ivi-layer to several screens'. This feature is 
required for
- for example, car navigation application prepares junction guide on a 
surface, which shall be displayed in its own UI and cloned on 
instrumental cluster in another screen as well. In this case, a 
ivi-surface can be located in both.


However, I have to modify weston core to realize it. So, for the time 
being, we can remove them at this time to simplify codes.


BR,
Nobuhiko Tanibata

2015-08-28 21:58 に Ucan, Emre (ADITG/SW1) さんは書きました:

link_screen's sole purpose is to link a layer to multiple screens, if
the layer should be shown in multiple screens.
This can be only achieved, if surfaces of the layer have multiple
weston_views dedicated to the different screens.

Current implementation assumes in many places that a ivi_surface has
only one weston_view.
Therefore, a layer can be only shown on one screen.

Although this (a layer on multiple screens) is a nice to have feature
for ivi-shell, it is not very crucial.
In any case, it is not an easy task to implement this feature, because
it has lot of corner cases.

I removed with this patch the link_screen data structure, because it
does not have any purpose in current implementation.

Signed-off-by: Emre Ucan 
---
 ivi-shell/ivi-layout-private.h |2 +-
 ivi-shell/ivi-layout.c |   67 
+++-

 2 files changed, 6 insertions(+), 63 deletions(-)

diff --git a/ivi-shell/ivi-layout-private.h 
b/ivi-shell/ivi-layout-private.h

index 074d598..a9dbdde 100644
--- a/ivi-shell/ivi-layout-private.h
+++ b/ivi-shell/ivi-layout-private.h
@@ -65,11 +65,11 @@ struct ivi_layout_surface {
 struct ivi_layout_layer {
struct wl_list link;
struct wl_signal property_changed;
-   struct wl_list screen_list;
struct wl_list link_to_surface;
uint32_t id_layer;

struct ivi_layout *layout;
+   struct ivi_layout_screen *on_screen;

struct ivi_layout_layer_properties prop;
uint32_t event_mask;
diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index 24bd8dd..087f94c 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/ivi-layout.c
@@ -75,12 +75,6 @@ struct link_layer {
struct wl_list link_to_layer;
 };

-struct link_screen {
-   struct ivi_layout_screen *iviscrn;
-   struct wl_list link;
-   struct wl_list link_to_screen;
-};
-
 struct listener_layout_notification {
void *userdata;
struct wl_listener listener;
@@ -90,7 +84,6 @@ struct ivi_layout;

 struct ivi_layout_screen {
struct wl_list link;
-   struct wl_list link_to_layer;
uint32_t id_screen;

struct ivi_layout *layout;
@@ -165,16 +158,6 @@ remove_link_to_surface(struct ivi_layout_layer 
*ivilayer)

 }

 /**
- * Internal API to add a link to ivi_layer from ivi_screen.
- */
-static void
-add_link_to_layer(struct ivi_layout_screen *iviscrn,
- struct link_screen *link_screen)
-{
-	wl_list_insert(&iviscrn->link_to_layer, 
&link_screen->link_to_screen);

-}
-
-/**
  * Internal API to add/remove a ivi_surface from ivi_layer.
  */
 static void
@@ -211,40 +194,6 @@ remove_ordersurface_from_layer(struct
ivi_layout_surface *ivisurf)
 /**
  * Internal API to add/remove a ivi_layer to/from ivi_screen.
  */
-static void
-add_orderlayer_to_screen(struct ivi_layout_layer *ivilayer,
-struct ivi_layout_screen *iviscrn)
-{
-   struct link_screen *link_scrn = NULL;
-
-   link_scrn = malloc(sizeof *link_scrn);
-   if (link_scrn == NULL) {
-   weston_log("fails to allocate memory\n");
-   return;
-   }
-
-   link_scrn->iviscrn = iviscrn;
-   wl_list_insert(&ivilayer->screen_list, &link_scrn->link);
-   add_link_to_layer(iviscrn, link_scrn);
-}
-
-static void
-remove_orderlayer_from_screen(struct ivi_layout_layer *ivilayer)
-{
-   struct link_screen *link_scrn = NULL;
-   struct link_screen *next = NULL;
-
-	wl_list_for_each_safe(link_scrn, next, &ivilayer->screen_list, link) 
{

-   wl_list_remove(&link_scrn->link);
-   wl_list_remove(&link_scrn->link_to_screen);
-   free(link_scrn);
-   }
-   wl_list_init(&ivilayer->screen_list);
-}
-
-/**
- * Internal API to add/remove a ivi_layer to/from ivi_screen.
- */
 static struct ivi_layout_surface *
 get_surface(struct wl_list *surf_list, uint32_t id_surface)
 {
@@ -422,8 +371,6 @@ create_screen(struct weston_compositor *ec)
wl_list_init(&iviscrn->order.layer_list);
wl_list_init(&iviscrn->order.link);

-   wl_list_init(&iviscrn->link_to_layer);
-
wl_list_insert(&layout->screen_list, &iviscrn->link);
}
 }
@@ -964,7 +911,7 @@ commit_screen_list(struct ivi_layout *layout)
if (iviscrn->order.di

Re: black surface in desktop shell fullscreen mode

[Pekka Paalanen]

On Wed, 30 Sep 2015 09:50:09 -0700
Bill Spitzak  wrote:

> If you are actually destroying the fullscreen surface, then this sounds
> like a bug.

Yes. It all depends on what "hide" means in Wayland protocol terms with
the applications in question.

> The inability to make a fullscreen surface partially-transparent is on
> purpose, though it might be considered a design error.

Yes, it is on purpose, for the use cases that actually want black bars
when the window is smaller than the output size.

A fullscreen window with show-through parts is kind of an odd concept,
IMHO. For maximized I might understand.

All use cases that come to my mind for show-through fullscreen windows
are hacks around how Wayland works, trying to do things one just should
not attempt to do. They are not meant to work.

> I believe Weston is
> trying to pad out the buffer (which may be the wrong shape or size) to fill
> the screen. It could do this by adding black rectangles around it, so
> transparency still works, but instead it is putting a black fullscreen
> rectangle behind it.

Indeed.

> Possibly better would be to replicate the edge pixels
> of the buffer to fill the screen, which would give the client an easy way
> to control the color and transparency of the fill area. Also any rule for
> how this is done needs to apply to normal windows for any cases where the
> client does not produce a buffer that is the size/shape the compositor
> wants, this occurs in tiled window managers.

Pad repeat? That requires application awareness to actually set the
edge pixels. This may be very hard e.g. for video players that just
push the decoded video frame out to screen, and expect the compositor
to add black bars as necessary. You are often dealing with
hardware-acceleration capable buffers, which causes all kinds of
complications.

So, pad repeat would need to be a client opt-in feature. This means new
protocol. Seems like a huge detour to just allow "show through for a
fullscreen window". It would be much simpler to add a flag that would
achieve the show-through. Is this actually a good idea, I don't know. I
have a feeling that some people are trying to work around Wayland
rather than using it the way it is meant to.

Another essential problem with pad repeat is that it forces the
compositor to composite, removing the possibility of direct scanout,
which for fullscreen apps is generally a very important optimization.

The black blanket surface behind the window OTOH allows for direct
scanout. If black bars are not visible and the client buffer is
completely opaque, it is possible to scan it out without composition by
rendering. Even if black bars are visible, the client buffer could be
scanned out on an overlay plane, or if the hardware supports it, it
could be scanned out directly as the primary plane of the crtc and
letting the scanout hardware fill in the black bars. In all cases, the
black surface below would never change, so new video frames would not
cause new rendering in the compositor when direct scanout is possible.


Thanks,
pq

> On Wed, Sep 30, 2015 at 1:35 AM, zou lan  wrote:
> 
> > Hi all
> >
> > As I known, when a window is fullscreen, desktop shell will create a black
> > surface after it. If the window is transparent later, it shows a black
> > screen. But the app developers maybe except it to be hide.
> >
> > Just take QWindow function hide for example, app1 start app2, then app2
> > call hide, it excepts to show app1, but it shows the black surface of app2.
> >
> >
> >
> >- Does the desktop shell doesn't support set fullscreen surface to be
> >transparent?
> >- Thank you.
> >
> > Best Regards
> > Nancy
> >
> > ___
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> >
> >



pgpL06bJ45KOz.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] wayland: add a release request on wl_seat

[Jonas Ådahl]

On Wed, Sep 30, 2015 at 10:17:49PM +0200, David FORT wrote:
> This is required if we want to correctly remove a wl_seat compositor-side. A
> wl_seat is announced as a global object, then it is bound by the client. When
> the compositor wants to remove the seat, it shall announce the global removal 
> of
> the object. The client can then call the release request on the wl_seat (which
> means I won't use that object anymore). When all clients have released the
> wl_seat, it can be destroyed by the compositor.

Missing Signed-off-by.

The last part of the commit message is not really true. A compositor can
destroy its "seat" long before any client has acknowledged it's gone (and
deal with this fact in the interface implementation), so this is really
just about being able to destroy the wl_resource and nothing else. There
is no need to wait for all clients to do anything really (Sorry I
missed the commit message part in the last patch).

> ---
>  protocol/wayland.xml | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index 42c9309..6764565 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -1329,7 +1329,7 @@
>  
> 
>  
> -  
> +  
>  
>A seat is a group of keyboards, pointer and touch devices. This
>object is published as a global during start up, or when such a
> @@ -1400,6 +1400,15 @@
>
>  
>  
> +
> +
> +
> +  
> +  This request is called by the client to inform that it will not use 
> the seat
> +  object.

nit: "The" seat object sounds like there is only one seat object. But
this request is about that the client will stop using *this* seat object.
Less important but IMHO, it would also sound better if it was more clear
that it will not use this seat *anymore*.

With the commit message fixed and the nit above fixed, this is
Reviewed-by: Jonas Ådahl 


Jonas

> +  
> +
> +
>
>  
>
> -- 
> 1.9.1
> 
> ___
> 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