Re: [RFC wayland-protocols v4] Add Primary Selection Protocol Version 1

[Jonas Ådahl]

On Sat, Feb 20, 2016 at 01:31:59AM +0100, Carlos Garnacho wrote:
> From: Lyude 
> 
> This primary selection is similar in spirit to the eponimous
> in X11, allowing a quick "select text + middle click" shortcut
> to copying and pasting.
> 
> It's otherwise very similar to it wayland counterpart, and
> explicitly made consistent with it.
> 
> Signed-off-by: Lyude 
> Signed-off-by: Carlos Garnacho 
> ---
> After having talked with Lyude, I'll be trying to move this ahead.
> 
> Changes since v3:
> - Added a rather verbose protocol description, including a
>   high-level overview of the workings.
> - Made event emission 1:1 with wayland core protocol selections,
>   wp_primary_selection_offer.offer events are now expected to be
>   emitted between wp_primary_data_device.data_offer and 
>   wp_primary_data_device.selection
> - Improved wording here and there.
> - Added serial argument to wp_primary_data_offer.receive that can be
>   used to match against recent events.
> 
> 
>  Makefile.am|   1 +
>  unstable/primary-selection/README  |   4 +
>  .../primary-selection-unstable-v1.xml  | 229 
> +
>  3 files changed, 234 insertions(+)
>  create mode 100644 unstable/primary-selection/README
>  create mode 100644 
> unstable/primary-selection/primary-selection-unstable-v1.xml
> 
> diff --git a/Makefile.am b/Makefile.am
> index 57d0023..eefa20f 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -7,6 +7,7 @@ unstable_protocols =  
> \
>   unstable/xdg-shell/xdg-shell-unstable-v5.xml
> \
>   unstable/relative-pointer/relative-pointer-unstable-v1.xml  
> \
>   unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
> \
> + unstable/primary-selection/primary-selection-unstable-v1.xml
> \
>   $(NULL)
>  
>  stable_protocols =   
> \
> diff --git a/unstable/primary-selection/README 
> b/unstable/primary-selection/README
> new file mode 100644
> index 000..6d8c0c6
> --- /dev/null
> +++ b/unstable/primary-selection/README
> @@ -0,0 +1,4 @@
> +Primary selection protocol
> +
> +Maintainers:
> +Lyude 
> diff --git a/unstable/primary-selection/primary-selection-unstable-v1.xml 
> b/unstable/primary-selection/primary-selection-unstable-v1.xml
> new file mode 100644
> index 000..a3618d5
> --- /dev/null
> +++ b/unstable/primary-selection/primary-selection-unstable-v1.xml
> @@ -0,0 +1,229 @@
> +
> +
> +  
> +Copyright © 2015 Red Hat
> +
> +Permission is hereby granted, free of charge, to any person obtaining a
> +copy of this software and associated documentation files (the 
> "Software"),
> +to deal in the Software without restriction, including without limitation
> +the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +and/or sell copies of the Software, and to permit persons to whom the
> +Software is furnished to do so, subject to the following conditions:
> +
> +The above copyright notice and this permission notice (including the next
> +paragraph) shall be included in all copies or substantial portions of the
> +Software.
> +
> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> OR
> +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> OTHER
> +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> +DEALINGS IN THE SOFTWARE.
> +  
> +
> +  
> +This protocol provides the ability to have a primary selection device to
> +match that of the X server. This primary selection is a shortcut to the
> +common clipboard selection, where text just needs to be selected in order
> +to allow copying it elsewhere. The de facto way to perform this action
> +is the middle mouse button, although it is not limited to this one.
> +
> +Clients wishing to honor primary selection should create a primary
> +selection source and set it as the selection through
> +wp_primary_selection_device.set_selection whenever the text selection
> +changes. In order to minimize calls in pointer-driven text selection,
> +it should happen only once after the operation finished. Similarly,
> +a NULL source should be set when text is unselected.
> +
> +wp_primary_selection_offer objects are first announced through the
> +wp_primary_selection_device.data_offer event. Immediately after this 
> event,
> +the primary data offer will emit wp_primary_selection_offer.offer events
> +to let know of the 

Re: [RFC wayland-protocols v4] Add Primary Selection Protocol Version 1

[Michal Suchanek]

On 23 February 2016 at 20:03, Bill Spitzak  wrote:
>
>
> On Tue, Feb 23, 2016 at 1:32 AM, Michal Suchanek  wrote:
>>
>> On 22 February 2016 at 19:23, Carlos Garnacho  wrote:
>>
>> > Right, that's why I suggest having those reunited in a single logical
>> > focus. Anything else is plagued of corner cases.
>>
>> That's totally not going to work. When  you have multiple touch panels
>> you can  touch multiple places. Are you proposing that on whichever
>> panel you happen to touch first locks the other panel from working or
>> on whichever panel you touch last steals the touch on the earlier
>> panel?
>>
>> I do not think either is expected behaviour.
>
>
> What? Absolutely this is the expected behavior. All the touch events go to
> the same client as the first touch event. For a more obvioius example,
> keystrokes and modifier states need to be sent to the client that you are
> pressing a mouse button on, even if the "keyboard focus" is some other
> client. There is only one focus for every single thing in the seat, the
> thing you are calling the "keyboard focus" is just a helper for what that
> focus is when no mouse buttons are held down.
>
> If you want them to go to different clients, put the touch panels on
> different seats.
>
> I fully agree that having "number of focus" != "number of seats" is going to
> be plagued with corner cases.
>
>> > Citation needed :). Windows can be certainly arranged so that it's not
>> > possible to move the pointer between app A and B without going through
>> > a third application. The problem with doing this on pointer focus is
>>
>> That can happen only with relative axis. With absolute axis you can
>> point anywhere anytime without going through anywhere else. Let's say
>> that for the sake of rodent users it is better to consider entry and
>> motion events insignificant.
>
>
> Who cares that it can't happen for absolute axis. It does happen for
> relative and those exist, even if you personally don't own a mouse.
>
>> > What is unreasonable about serial checking?
>>
>> How is the serial related to the paste? How is the application
>> supposed to pick serial so it can receive the paste? You can pick the
>> event which triggers the paste in the application logic. Will that
>> mean that when compositor fails to check events from a device (or the
>> application uses a device exclusively and possibly directly drives the
>> hardware) binding to some buttons will work and binding to other
>> buttons will fail?
>
>
> It's really easy: the client sends the event it thinks triggered the paste.
> The compositor checks to make sure it is an event that really existed and
> that it counts as some active user interaction (ie it is a mouse or keyboard
> click). If the client sends a fake event or a focus-in event or anything
> else the compositor does not like, it will not get access to the clipboard
> data.
>
> The entire point of this is so that it would be possible to put sensitive
> data into the selection, because client cannot look at it without the user
> doing something obvious, such as clicking. Moving the mouse around should
> not cause clients to be able to look at the selection.
>
>> > Let's take the most extreme case, primary selection can be broadcasted
>> > and clients can be free to read data right away. You've just allowed
>> > compositors to replicate all the flaws of X11 primary selection.
>>
>> And you have allowed all the legacy X11 clients to perform flawlessly.
>
>
> Except that the user has to be careful to not select passwords or banking
> numbers or anything else sensitive.
>
>> So it's fine to suggest reasonable default policy for compositor
>> implementors but it's also fine to allow for different policies.
>>
>> I would not mandate broadcasting the selection changes
>> indiscriminately. However, if people are concerned about applications
>> that listen for the broadcasts in X11 land it should be possible to
>> set up special policy for them so they can receive the broadcasts in
>> Wayland as well. Similarly when an application is supposed to run
>> sandboxed and there is enough concern about information leak through
>> clipboard it should be possible to set up a policy for it to never
>> receive selection offers.
>
>
> It sounds like you are basically saying "paste does not work unless the
> client is specially privileged".

You are saying that also. You say that the client must have keyboard
focus to receive pastes.

What I add is that different policies might be viable and useful and
the protocol should not preclude the compositor from using different
policies.

>
> The reason for the serial is so that the compositor can decide whether to
> honor a request for the clipboard. You can still have specially privileged
> clients that can get it for any event, this is for "normal" clients so that
> paste works.

And since there is already policy in place that gives client(s) the
privilege to receive 

Re: [PATCH weston 7/7] protocol: migrate to stable presentation-time.xml

[Bryce Harrington]

On Tue, Feb 23, 2016 at 02:19:32PM +0200, Pekka Paalanen wrote:
> > > diff --git a/configure.ac b/configure.ac
> > > index 276584f..92eaa3c 100644
> > > --- a/configure.ac
> > > +++ b/configure.ac
> > > @@ -181,6 +181,7 @@ fi
> > >  PKG_CHECK_MODULES(LIBINPUT_BACKEND, [libinput >= 0.8.0])
> > >  PKG_CHECK_MODULES(COMPOSITOR, [$COMPOSITOR_MODULES])
> > >  
> > > +# XXX: wayland-protocols needs a version bump for 
> > > stable/presentation-time.
> > >  PKG_CHECK_MODULES(WAYLAND_PROTOCOLS, [wayland-protocols >= 1.0],
> > > [ac_wayland_protocols_pkgdatadir=`$PKG_CONFIG 
> > > --variable=pkgdatadir wayland-protocols`])
> > >  AC_SUBST(WAYLAND_PROTOCOLS_DATADIR, $ac_wayland_protocols_pkgdatadir)  
> > 
> > For what it's worth, the ideal place to put notes for the release
> > manager is at the very top of the file, near where the version number
> > is.  That's the only place in the file that we can be 100% certain will
> > be looked at during review time.
> 
> That's a good idea, I can move it there. Seems to be easy to find the
> place where to edit.
> 
> > If you want to formalize this a bit, and we're not doing the .90 on
> > wayland-protocols (which I still think is a fair idea), we could
> > have these notes placed somewhere specifically, and either document in
> > releasing.txt to check for notes, or even cause 'make dist' refuse to
> > operate if these notes exist.
> 
> Making 'make dist' or distcheck to fail is an excellent idea. It could
> grep configure.ac for 'RELEASE_BLOCKER' for instance, and then one
> would just put that string in the comment anywhere.
>
> There just one problem: people want to be able to run distcheck, and
> dist is a dependency on distcheck, I believe. So we'd need an option to
> avoid the check until release time, but... it's getting awkward.

I'm sure there's a definable hook or way to script it to only occur with
actual releases, but yeah unless this becomes a common thing it's
probably not worth the bother.  The note at the top of configure.ac is
adequate for now.

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

Re: [PATCH wayland-protocols 1/4] stable: add presentation-time draft

[Bryce Harrington]

On Tue, Feb 23, 2016 at 12:27:23PM +0200, Pekka Paalanen wrote:
> On Mon, 22 Feb 2016 15:39:18 -0800
> Bryce Harrington  wrote:
> 
> > On Mon, Feb 22, 2016 at 03:34:40PM +0200, Pekka Paalanen wrote:
> > > From: Pekka Paalanen 
> > > 
> > > This XML file has been copied verbatim from Weston 1.10.0 release,
> > > protocol/presentation_timing.xml. The last behavioral change to that
> > > file was in December 2014, so the behaviour is considered stable.
> > > 
> > > Interfaces still need to be renamed according wayland-protocols policy.
> > > That will be done in a follow-up patch to clearly show the changes.
> > > 
> > > Signed-off-by: Pekka Paalanen   
> > 
> > Reviewed-by: Bryce Harrington 
> > 
> > Presumably the API is fine, below comments focus on grammatical
> > suggestions.  Nothing terribly critical, but there are a few clunky
> > passages which might be worth revisiting now that this is becoming
> > official.
> 
> Hi,
> 
> cool.
> 
> > > ---
> > >  stable/presentation-time/README|   5 +
> > >  stable/presentation-time/presentation-time.xml | 274 
> > > +
> > >  2 files changed, 279 insertions(+)
> > >  create mode 100644 stable/presentation-time/README
> > >  create mode 100644 stable/presentation-time/presentation-time.xml
> > > 
> > > diff --git a/stable/presentation-time/README 
> > > b/stable/presentation-time/README
> > > new file mode 100644
> > > index 000..c7781ea
> > > --- /dev/null
> > > +++ b/stable/presentation-time/README
> > > @@ -0,0 +1,5 @@
> > > +Presentation time protocol
> > > +
> > > +Maintainers:
> > > +Pekka Paalanen 
> > > +
> > > diff --git a/stable/presentation-time/presentation-time.xml 
> > > b/stable/presentation-time/presentation-time.xml
> > > new file mode 100644
> > > index 000..10a5f14
> > > --- /dev/null
> > > +++ b/stable/presentation-time/presentation-time.xml
> > > @@ -0,0 +1,274 @@
> > > +
> > > +
> > > +
> > > +
> > > +  
> > > +Copyright © 2013-2014 Collabora, Ltd.  
> > 
> > Probably extend the copyright date to now, unless there's a specific
> > reason not to?
> 
> 2014 is the last time any significant (copyrightable) changes were
> made, so I don't see a reason to bump it. Unless we make non-trivial
> changes now, of course.

I would think the protocol becoming officially stable would be a
suitably non-trivial change.  But whatever, it's your copyright.  ;-)

> > > +Permission is hereby granted, free of charge, to any person 
> > > obtaining a
> > > +copy of this software and associated documentation files (the 
> > > "Software"),
> > > +to deal in the Software without restriction, including without 
> > > limitation
> > > +the rights to use, copy, modify, merge, publish, distribute, 
> > > sublicense,
> > > +and/or sell copies of the Software, and to permit persons to whom the
> > > +Software is furnished to do so, subject to the following conditions:
> > > +
> > > +The above copyright notice and this permission notice (including the 
> > > next
> > > +paragraph) shall be included in all copies or substantial portions 
> > > of the
> > > +Software.
> > > +
> > > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
> > > EXPRESS OR
> > > +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
> > > MERCHANTABILITY,
> > > +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT 
> > > SHALL
> > > +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> > > OTHER
> > > +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 
> > > ARISING
> > > +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> > > +DEALINGS IN THE SOFTWARE.
> > > +  
> > > +
> > > +  
> > > +
> > > +
> > > +
> > > +
> > > +  The main feature of this interface is accurate presentation
> > > +  timing feedback to ensure smooth video playback while maintaining
> > > +  audio/video synchronization. Some features use the concept of a
> > > +  presentation clock, which is defined in presentation.clock_id
> > > +  event.  
> > 
> > "defined in the"
> 
> Yup.
> 
> > > +  Request 'feedback' can be regarded as an additional wl_surface
> > > +  method. It is part of the double-buffered surface state update
> > > +  mechanism, where other requests first set up the state and then
> > > +  wl_surface.commit atomically applies the state into use. In
> > > +  other words, wl_surface.commit submits a content update.  
> > 
> > Could this paragraph be restated to be more clear?
> 
> Perhaps, but I have hard time finding the words. The key points are
> that feedback is double-buffered, part of a commit as all
> double-buffered state is, and it defines the term "content update" used
> later.

I would suggest a rephrasing myself but I'm not sure 

Re: [PATCH weston] tests: cleanup test runner script.

[Pekka Paalanen]

On Tue, 16 Feb 2016 21:55:06 -0800
Bryce Harrington  wrote:

> On Mon, Dec 21, 2015 at 01:38:51PM -0800, Jon A. Cruz wrote:
> > Cleaned up test runner script to unify sections launching weston.
> > This makes the sections more legible and differences easier to spot.
> > 
> > Signed-off-by: Jon A. Cruz   
> 
> Reviewed-by: Bryce Harrington 

Pushed:
   35552aa..c25f72d  master -> master


Thanks,
pq

> > ---
> >  tests/weston-tests-env | 20 ++--
> >  1 file changed, 10 insertions(+), 10 deletions(-)
> > 
> > diff --git a/tests/weston-tests-env b/tests/weston-tests-env
> > index 0b9ff1e..ab2d6c0 100755
> > --- a/tests/weston-tests-env
> > +++ b/tests/weston-tests-env
> > @@ -55,11 +55,11 @@ case $TEST_FILE in
> > WESTON_BUILD_DIR=$abs_builddir \
> > WESTON_TEST_REFERENCE_PATH=$abs_top_srcdir/tests/reference \
> > $WESTON --backend=$MODDIR/$BACKEND \
> > +   ${CONFIG} \
> > --shell=$SHELL_PLUGIN \
> > --socket=test-${TEST_NAME} \
> > --modules=$MODDIR/${TEST_FILE/.la/.so},$XWAYLAND_PLUGIN 
> > \
> > --log="$SERVERLOG" \
> > -   ${CONFIG} \  
> > &> "$OUTLOG"  
> > ;;
> > ivi-*.weston)
> > @@ -67,26 +67,26 @@ case $TEST_FILE in
> >  
> > WESTON_BUILD_DIR=$abs_builddir \
> > WESTON_TEST_REFERENCE_PATH=$abs_top_srcdir/tests/reference \
> > -   WESTON_TEST_CLIENT_PATH=$abs_builddir/$TEST_FILE $WESTON \
> > -   --socket=test-${TEST_NAME} \
> > -   --backend=$MODDIR/$BACKEND \
> > +   WESTON_TEST_CLIENT_PATH=$abs_builddir/$TEST_FILE \
> > +   $WESTON --backend=$MODDIR/$BACKEND \
> > --config=$abs_builddir/tests/weston-ivi.ini \
> > --shell=$SHELL_PLUGIN \
> > -   --log="$SERVERLOG" \
> > +   --socket=test-${TEST_NAME} \
> > --modules=$TEST_PLUGIN \
> > +   --log="$SERVERLOG" \
> > $($abs_builddir/$TESTNAME --params) \  
> > &> "$OUTLOG"  
> > ;;
> > *)
> > WESTON_BUILD_DIR=$abs_builddir \
> > WESTON_TEST_REFERENCE_PATH=$abs_top_srcdir/tests/reference \
> > -   WESTON_TEST_CLIENT_PATH=$abs_builddir/$TEST_FILE $WESTON \
> > -   --socket=test-${TEST_NAME} \
> > -   --backend=$MODDIR/$BACKEND \
> > +   WESTON_TEST_CLIENT_PATH=$abs_builddir/$TEST_FILE \
> > +   $WESTON --backend=$MODDIR/$BACKEND \
> > +   ${CONFIG} \
> > --shell=$SHELL_PLUGIN \
> > -   --log="$SERVERLOG" \
> > +   --socket=test-${TEST_NAME} \
> > --modules=$TEST_PLUGIN,$XWAYLAND_PLUGIN \
> > -   ${CONFIG} \
> > +   --log="$SERVERLOG" \
> > $($abs_builddir/$TEST_FILE --params) \  
> > &> "$OUTLOG"  
> >  esac
> > -- 
> > 2.5.0
> > 
> > ___
> > 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
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel



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

Re: [PATCH weston v3] drm: port the drm backend to the new init api

[Pekka Paalanen]

On Tue, 24 Nov 2015 16:31:42 +0200
Giulio Camuffo  wrote:

> 2015-11-20 11:38 GMT+02:00 Quentin Glidic :
> > For now, I will just comment on the part I am not too happy with.
> >
> > On 31/10/2015 12:08, Giulio Camuffo wrote:  
> >>
> >> [snip]

> >> +static void
> >> +drm_configure_output(struct weston_compositor *c, const char *name,
> >> +struct weston_drm_backend_output_config *config)
> >> +{
> >> +   struct weston_config *wc = weston_compositor_get_user_data(c);
> >> +   struct weston_config_section *section;
> >> +   char *s;
> >> +   int scale;
> >> +
> >> +   section = weston_config_get_section(wc, "output", "name", name);
> >> +   weston_config_section_get_string(section, "mode", ,
> >> "preferred");
> >> +   if (strcmp(s, "off") == 0)
> >> +   config->type = WESTON_DRM_BACKEND_OUTPUT_TYPE_OFF;
> >> +   else if (strcmp(s, "preferred") == 0)
> >> +   config->type = WESTON_DRM_BACKEND_OUTPUT_TYPE_PREFERRED;
> >> +   else if (strcmp(s, "current") == 0)
> >> +   config->type = WESTON_DRM_BACKEND_OUTPUT_TYPE_CURRENT;
> >> +   else if (sscanf(s, "%dx%d", >base.width,
> >> +   >base.height) == 2)
> >> +   config->type = WESTON_DRM_BACKEND_OUTPUT_TYPE_MODE;
> >> +   else if (parse_modeline(s, >modeline) == 0)
> >> +   config->type = WESTON_DRM_BACKEND_OUTPUT_TYPE_MODELINE;
> >> +   else {
> >> +   weston_log("Invalid mode \"%s\" for output %s\n",
> >> +  s, name);
> >> +   config->type = WESTON_DRM_BACKEND_OUTPUT_TYPE_PREFERRED;
> >> +   }
> >> +   free(s);  
> >
> >
> > I would like this part shared between the backend and the compositor.
> > As I said, the parsing of modeline should be in the backend, but also what I
> > would call “light modeline”, i.e. "width x height". That put the “technical”
> > part into the “technical code”.
> > Then you have a separate setting for on/off(/current).
> >
> > The configure_output function would return a boolean, which indicates
> > whether or not to activate that output. The modeline would be passed as a
> > string (config->moduline) and could be NULL.
> > Returning FALSE obviously means that all the configuration will be ignored
> > (and thus, you can return early, keeping everything to NULL) and the meaning
> > of TRUE depends on the modeline:
> > - if it is a well-formed modeline (or “light modeline”), use it;
> > - if it is malformed, fallback to NULL;
> > - if it is NULL, use the preferred setting.
> >
> > If “current” is really a needed setting (I do not know the use case it was
> > added for), we can just use a 3-values enum as the return value:
> > - OFF = 0
> > - PREFERRED = 1
> > - CURRENT = -1
> > which will change the meaning of a NULL modeline.  
> 
> I'm not sure what current is for but i would not remove it.

Hi,

FWIW, these are the same as explained in weston.ini man page. Preferred
means the preferred mode in EDID or similar, while current means the
currently active video mode when the compositor is starting, to allow
avoiding a mode switch in case preferred != current. E.g. when you
force the mode on kernel command line.


Thanks,
pq


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

Re: [PATCH weston 5/7] Makefile: move presentation_timing source out of toytoolkit

[Pekka Paalanen]

On Mon, 22 Feb 2016 15:44:17 -0800
Bryce Harrington  wrote:

> On Mon, Feb 22, 2016 at 03:34:44PM +0200, Pekka Paalanen wrote:
> > From: Pekka Paalanen 
> > 
> > Toytoolkit sources don't actually use the presentation_timing client
> > protocol bindings for anything. Apparently they were there only because
> > that's how they end up in BUILT_SOURCES.
> > 
> > Move them from toytoolkit sources to BUILT_SOURCES where also other such
> > things are.
> > 
> > Signed-off-by: Pekka Paalanen   
> 
> Reviewed-by: Bryce Harrington 

Pushed:
   3f2062c..35552aa  master -> master

Thanks,
pq

> > ---
> >  Makefile.am | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/Makefile.am b/Makefile.am
> > index 623621d..e365396 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -565,8 +565,6 @@ nodist_libtoytoolkit_la_SOURCES =   
> > \
> > protocol/text-cursor-position-client-protocol.h \
> > protocol/scaler-protocol.c  \
> > protocol/scaler-client-protocol.h   \
> > -   protocol/presentation_timing-protocol.c \
> > -   protocol/presentation_timing-client-protocol.h  \
> > protocol/xdg-shell-unstable-v5-protocol.c   \
> > protocol/xdg-shell-unstable-v5-client-protocol.h\
> > protocol/ivi-application-protocol.c \
> > @@ -772,6 +770,8 @@ BUILT_SOURCES +=
> > \
> > protocol/weston-desktop-shell-protocol.c\
> > protocol/scaler-client-protocol.h   \
> > protocol/scaler-protocol.c  \
> > +   protocol/presentation_timing-protocol.c \
> > +   protocol/presentation_timing-client-protocol.h  \
> > protocol/fullscreen-shell-unstable-v1-protocol.c\
> > protocol/fullscreen-shell-unstable-v1-client-protocol.h \
> > protocol/xdg-shell-unstable-v5-protocol.c   \
> > -- 
> > 2.4.10


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

Re: [PATCH weston 6/7] Makefile: handle also stable wayland-protocols

[Pekka Paalanen]

On Mon, 22 Feb 2016 16:02:23 -0800
Bryce Harrington  wrote:

> On Mon, Feb 22, 2016 at 03:34:45PM +0200, Pekka Paalanen wrote:
> > From: Pekka Paalanen 
> > 
> > Fix the protostability function to handle stable protocol files
> > correctly. Stable protocol XML file names do not have 'stable' in their
> > name, nor do we want to write that in the prerequisite lists in the
> > Makefile.
> > 
> > Function 'protoname' does not need fixing, because for stable protocol
> > prerequisites, the sed pattern will not match, and it passes stem
> > through as is, which is correct.
> > 
> > Signed-off-by: Pekka Paalanen 
> > ---
> >  Makefile.am | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/Makefile.am b/Makefile.am
> > index e365396..505d40a 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -1423,7 +1423,7 @@ doc: $(DOXYGEN_INDICES)
> >  .SECONDEXPANSION:
> >  
> >  define protostability
> > -$(shell echo $1 | sed 's/.*\(\\|\\).*/\1/')
> > +$(if $(findstring unstable,$1),unstable,stable)
> >  endef  
> 
> So, we were looking for "unstable" or "stable" as distinct words in the
> filename, to determine whether to look under /unstable/ or /stable/.
> But by policy stable protocols don't have the word "stable" in them, so
> simplify the check to just look for 'unstable' anywhere in the protocol
> filename and consider anything else to be a stable protocol.
> 
> Could we test for '-unstable-' just to avoid any false positives if we
> have some weird protocol (nouns table? pun stab levity?) that happens to
> match?  OTOH I suppose if someone comes up with a protocol that matches
> that, maybe they deserve what they get.  ;-)
> 
> Reviewed-by: Bryce Harrington 

Pushed:
   3f2062c..35552aa  master -> master


Thanks,
pq


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

Re: [PATCH weston 7/7] protocol: migrate to stable presentation-time.xml

[Pekka Paalanen]

On Mon, 22 Feb 2016 16:12:49 -0800
Bryce Harrington  wrote:

> On Mon, Feb 22, 2016 at 03:34:46PM +0200, Pekka Paalanen wrote:
> > From: Pekka Paalanen 
> > 
> > Remove the unstable presentation_timing.xml file, and use
> > presentation-time.xml from wayland-protocols instead to generate all the
> > Presentation extension bindings.
> > 
> > The following renames are done according to the XML changes:
> > - generated header includes
> > - enum constants and macros prefixed with WP_
> > - interface symbol names prefixed with wp_
> > - protocol API calls prefixed with wp_
> > 
> > Clients use wp_presentation_interface.name rather than hardcoding the
> > global interface name: presentation-shm, weston-info, presentation-test.
> > 
> > Signed-off-by: Pekka Paalanen   
> 
> Reviewed-by: Bryce Harrington 
> 
> A bit of discussion down below relating to the note in configure.ac.
> 
> Also, patches 5 and 6 in this series don't seem to depend on anything
> else in this patchset, so I'd propose we just go ahead and land those
> two directly.

Hi,

I can do that, sure.

> > ---
> > 
> > Note: When landing this patch, check the wayland-protocols version that
> > released presentation-time, and fix the version dependency in
> > configure.ac.
> > ---
> >  Makefile.am  |  21 ++-
> >  clients/presentation-shm.c   |  65 +-
> >  clients/weston-info.c|  19 +--
> >  configure.ac |   1 +
> >  protocol/presentation_timing.xml | 274 
> > ---
> >  src/compositor-drm.c |  22 ++--
> >  src/compositor-fbdev.c   |   4 +-
> >  src/compositor-headless.c|   4 +-
> >  src/compositor-rdp.c |   2 +-
> >  src/compositor-rpi.c |   8 +-
> >  src/compositor-wayland.c |   2 +-
> >  src/compositor-x11.c |   4 +-
> >  src/compositor.c |  32 ++---
> >  src/compositor.h |   2 +-
> >  tests/presentation-test.c|  34 ++---
> >  15 files changed, 111 insertions(+), 383 deletions(-)
> >  delete mode 100644 protocol/presentation_timing.xml

> > diff --git a/configure.ac b/configure.ac
> > index 276584f..92eaa3c 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -181,6 +181,7 @@ fi
> >  PKG_CHECK_MODULES(LIBINPUT_BACKEND, [libinput >= 0.8.0])
> >  PKG_CHECK_MODULES(COMPOSITOR, [$COMPOSITOR_MODULES])
> >  
> > +# XXX: wayland-protocols needs a version bump for stable/presentation-time.
> >  PKG_CHECK_MODULES(WAYLAND_PROTOCOLS, [wayland-protocols >= 1.0],
> >   [ac_wayland_protocols_pkgdatadir=`$PKG_CONFIG 
> > --variable=pkgdatadir wayland-protocols`])
> >  AC_SUBST(WAYLAND_PROTOCOLS_DATADIR, $ac_wayland_protocols_pkgdatadir)  
> 
> For what it's worth, the ideal place to put notes for the release
> manager is at the very top of the file, near where the version number
> is.  That's the only place in the file that we can be 100% certain will
> be looked at during review time.

That's a good idea, I can move it there. Seems to be easy to find the
place where to edit.

> If you want to formalize this a bit, and we're not doing the .90 on
> wayland-protocols (which I still think is a fair idea), we could
> have these notes placed somewhere specifically, and either document in
> releasing.txt to check for notes, or even cause 'make dist' refuse to
> operate if these notes exist.

Making 'make dist' or distcheck to fail is an excellent idea. It could
grep configure.ac for 'RELEASE_BLOCKER' for instance, and then one
would just put that string in the comment anywhere.

There just one problem: people want to be able to run distcheck, and
dist is a dependency on distcheck, I believe. So we'd need an option to
avoid the check until release time, but... it's getting awkward.

I'll just move the comment up for now.


Thanks,
pq


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

Re: [PATCH weston 6/7] Makefile: handle also stable wayland-protocols

[Pekka Paalanen]

On Mon, 22 Feb 2016 16:02:23 -0800
Bryce Harrington  wrote:

> On Mon, Feb 22, 2016 at 03:34:45PM +0200, Pekka Paalanen wrote:
> > From: Pekka Paalanen 
> > 
> > Fix the protostability function to handle stable protocol files
> > correctly. Stable protocol XML file names do not have 'stable' in their
> > name, nor do we want to write that in the prerequisite lists in the
> > Makefile.
> > 
> > Function 'protoname' does not need fixing, because for stable protocol
> > prerequisites, the sed pattern will not match, and it passes stem
> > through as is, which is correct.
> > 
> > Signed-off-by: Pekka Paalanen 
> > ---
> >  Makefile.am | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/Makefile.am b/Makefile.am
> > index e365396..505d40a 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -1423,7 +1423,7 @@ doc: $(DOXYGEN_INDICES)
> >  .SECONDEXPANSION:
> >  
> >  define protostability
> > -$(shell echo $1 | sed 's/.*\(\\|\\).*/\1/')
> > +$(if $(findstring unstable,$1),unstable,stable)
> >  endef  
> 
> So, we were looking for "unstable" or "stable" as distinct words in the
> filename, to determine whether to look under /unstable/ or /stable/.
> But by policy stable protocols don't have the word "stable" in them, so
> simplify the check to just look for 'unstable' anywhere in the protocol
> filename and consider anything else to be a stable protocol.
> 
> Could we test for '-unstable-' just to avoid any false positives if we
> have some weird protocol (nouns table? pun stab levity?) that happens to
> match?  OTOH I suppose if someone comes up with a protocol that matches
> that, maybe they deserve what they get.  ;-)
> 
> Reviewed-by: Bryce Harrington 

Hi,

yeah, I'll punt fixing further issues to the next victim, it seems to
be the habit on this one. ;-)

Wayland-protocols defines a policy for deprecating extensions too, and
if Weston ever wanted to use a deprecated extension, someone would need
to fix this again.


Thanks,
pq


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

Re: [PATCH wayland-protocols 4/4] Makefile: install and dist stable protocols

[Pekka Paalanen]

On Mon, 22 Feb 2016 15:41:46 -0800
Bryce Harrington  wrote:

> On Mon, Feb 22, 2016 at 03:34:43PM +0200, Pekka Paalanen wrote:
> > From: Pekka Paalanen 
> > 
> > Signed-off-by: Pekka Paalanen   
> 
> Personally I'd squash 2,3,4 since they're all short "hook things up"
> changes that go together, but no biggie.

That is a possibility, sure. In my mind, patch 2 is the changes to the
spec and nothing else and very important to review. Patch 3 is hooking
it up in the build since patch 1 didn't do that when adding the file
(because the spec was not finished). Patch 4 could be landed completely
separately, if wanted, so it's separate.

> Reviewed-by: Bryce Harrington 

Thanks for the reviews for wayland-protocols. I'll probably do the
suggested changes as follow-ups.

Thanks,
pq

> 
> > ---
> >  Makefile.am | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/Makefile.am b/Makefile.am
> > index 21b1a00..e0bd079 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -15,10 +15,12 @@ stable_protocols =  
> > \
> >  
> >  nobase_dist_pkgdata_DATA = 
> > \
> > $(unstable_protocols)   
> > \
> > +   $(stable_protocols) 
> > \
> > $(NULL)
> >  
> >  dist_noinst_DATA = 
> > \
> > $(sort $(foreach p,$(unstable_protocols),$(dir $p)README))  
> > \
> > +   $(sort $(foreach p,$(stable_protocols),$(dir $p)README))
> > \
> > $(NULL)
> >  
> >  noarch_pkgconfig_DATA = wayland-protocols.pc
> > -- 
> > 2.4.10


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

Re: [PATCH wayland-protocols 1/4] stable: add presentation-time draft

[Pekka Paalanen]

On Mon, 22 Feb 2016 15:39:18 -0800
Bryce Harrington  wrote:

> On Mon, Feb 22, 2016 at 03:34:40PM +0200, Pekka Paalanen wrote:
> > From: Pekka Paalanen 
> > 
> > This XML file has been copied verbatim from Weston 1.10.0 release,
> > protocol/presentation_timing.xml. The last behavioral change to that
> > file was in December 2014, so the behaviour is considered stable.
> > 
> > Interfaces still need to be renamed according wayland-protocols policy.
> > That will be done in a follow-up patch to clearly show the changes.
> > 
> > Signed-off-by: Pekka Paalanen   
> 
> Reviewed-by: Bryce Harrington 
> 
> Presumably the API is fine, below comments focus on grammatical
> suggestions.  Nothing terribly critical, but there are a few clunky
> passages which might be worth revisiting now that this is becoming
> official.

Hi,

cool.

> > ---
> >  stable/presentation-time/README|   5 +
> >  stable/presentation-time/presentation-time.xml | 274 
> > +
> >  2 files changed, 279 insertions(+)
> >  create mode 100644 stable/presentation-time/README
> >  create mode 100644 stable/presentation-time/presentation-time.xml
> > 
> > diff --git a/stable/presentation-time/README 
> > b/stable/presentation-time/README
> > new file mode 100644
> > index 000..c7781ea
> > --- /dev/null
> > +++ b/stable/presentation-time/README
> > @@ -0,0 +1,5 @@
> > +Presentation time protocol
> > +
> > +Maintainers:
> > +Pekka Paalanen 
> > +
> > diff --git a/stable/presentation-time/presentation-time.xml 
> > b/stable/presentation-time/presentation-time.xml
> > new file mode 100644
> > index 000..10a5f14
> > --- /dev/null
> > +++ b/stable/presentation-time/presentation-time.xml
> > @@ -0,0 +1,274 @@
> > +
> > +
> > +
> > +
> > +  
> > +Copyright © 2013-2014 Collabora, Ltd.  
> 
> Probably extend the copyright date to now, unless there's a specific
> reason not to?

2014 is the last time any significant (copyrightable) changes were
made, so I don't see a reason to bump it. Unless we make non-trivial
changes now, of course.

> > +Permission is hereby granted, free of charge, to any person obtaining a
> > +copy of this software and associated documentation files (the 
> > "Software"),
> > +to deal in the Software without restriction, including without 
> > limitation
> > +the rights to use, copy, modify, merge, publish, distribute, 
> > sublicense,
> > +and/or sell copies of the Software, and to permit persons to whom the
> > +Software is furnished to do so, subject to the following conditions:
> > +
> > +The above copyright notice and this permission notice (including the 
> > next
> > +paragraph) shall be included in all copies or substantial portions of 
> > the
> > +Software.
> > +
> > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
> > EXPRESS OR
> > +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
> > MERCHANTABILITY,
> > +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT 
> > SHALL
> > +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> > OTHER
> > +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> > +DEALINGS IN THE SOFTWARE.
> > +  
> > +
> > +  
> > +
> > +
> > +
> > +
> > +  The main feature of this interface is accurate presentation
> > +  timing feedback to ensure smooth video playback while maintaining
> > +  audio/video synchronization. Some features use the concept of a
> > +  presentation clock, which is defined in presentation.clock_id
> > +  event.  
> 
> "defined in the"

Yup.

> > +  Request 'feedback' can be regarded as an additional wl_surface
> > +  method. It is part of the double-buffered surface state update
> > +  mechanism, where other requests first set up the state and then
> > +  wl_surface.commit atomically applies the state into use. In
> > +  other words, wl_surface.commit submits a content update.  
> 
> Could this paragraph be restated to be more clear?

Perhaps, but I have hard time finding the words. The key points are
that feedback is double-buffered, part of a commit as all
double-buffered state is, and it defines the term "content update" used
later.

> > +
> > +
> > +  When the final realized presentation time is available, e.g.
> > +  after a framebuffer flip completes, the requested
> > +  presentation_feedback.presented events are sent. The final
> > +  presentation time can differ from the compositor's predicted
> > +  display update time and the update's target time, especially
> > +  when the compositor misses its target vertical blanking period.
> > +
> > +
> > +
> > +  
> > +These fatal protocol 

Re: [PATCH wayland-protocols 1/4] stable: add presentation-time draft

[Pekka Paalanen]

On Mon, 22 Feb 2016 11:45:44 -0800
Bill Spitzak  wrote:

> On Mon, Feb 22, 2016 at 5:34 AM, Pekka Paalanen  wrote:
> 
> >
> > +Argument 'refresh' gives the compositor's prediction of how
> > +many nanoseconds after tv_sec, tv_nsec the very next output
> > +refresh may occur. This is to further aid clients in
> > +predicting future refreshes, i.e., estimating the timestamps
> > +targeting the next few vblanks. If such prediction cannot
> > +usefully be done, the argument is zero.
> > +
> > +The 64-bit value combined from seq_hi and seq_lo is the value
> > +of the output's vertical retrace counter when the content
> > +update was first scanned out to the display. This value must
> > +be compatible with the definition of MSC in
> > +GLX_OML_sync_control specification. Note, that if the display
> > +path has a non-zero latency, the time instant specified by
> > +this counter may differ from the timestamp's.
> > +
> > +If the output does not have a constant refresh rate, explicit
> > +video mode switches excluded, then the refresh argument must
> > +be zero.
> > +
> > +If the output does not have a concept of vertical retrace or a
> > +refresh cycle, or the output device is self-refreshing without
> > +a way to query the refresh count, then the arguments seq_hi
> > +and seq_lo must be zero.
> >  
> 
> I think the two middle paragraphs above need to be swapped. Number 1 and 3
> are talking about the refresh nanoseconds, number 2 and 4 are talking about
> the sequence counter.

Hi,

sure, makes sense.


Thanks,
pq


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

Re: [RFC wayland-protocols v4] Add Primary Selection Protocol Version 1

[Michal Suchanek]

On 22 February 2016 at 19:23, Carlos Garnacho  wrote:
> Hi Michal,
>
> On Mon, Feb 22, 2016 at 4:53 PM, Michal Suchanek  wrote:
>> On 22 February 2016 at 15:57, Carlos Garnacho  wrote:
>>> Hi Michal,
>>>
>>> On Mon, Feb 22, 2016 at 2:25 PM, Michal Suchanek  wrote:
 Hello,

 On 20 February 2016 at 01:31, Carlos Garnacho  wrote:

> +
> +  
> +This protocol provides the ability to have a primary selection 
> device to
> +match that of the X server. This primary selection is a shortcut to 
> the
> +common clipboard selection, where text just needs to be selected in 
> order
> +to allow copying it elsewhere. The de facto way to perform this 
> action
> +is the middle mouse button, although it is not limited to this one.
> +
> +Clients wishing to honor primary selection should create a primary
> +selection source and set it as the selection through
> +wp_primary_selection_device.set_selection whenever the text selection
> +changes. In order to minimize calls in pointer-driven text selection,
> +it should happen only once after the operation finished. Similarly,
> +a NULL source should be set when text is unselected.
> +
> +wp_primary_selection_offer objects are first announced through the
> +wp_primary_selection_device.data_offer event. Immediately after this 
> event,
> +the primary data offer will emit wp_primary_selection_offer.offer 
> events
> +to let know of the mime types being offered.
> +
> +When the primary selection changes, the client with the keyboard 
> focus
> +will receive wp_primary_selection_device.selection events. Only the 
> client

 Why keyboard focus?

 Since paste is done mainly using mouse this has nothing to do with
 keyboard focus.
>>>
>>> Doing this so allows us to behave just the same than we do with the
>>> core protocol selection, slightly divergent protocols make sharing
>>> code harder.
>>>
>>> Conceptually, it also makes some sense to me. I argue that a logical
>>> "key" focus is needed in compositors, even on lack of wl_keyboard
>>> capabilities. Things that IMO make sense to tie together in this
>>> focus, per-seat are:
>>> - wl_keyboard focus
>>> - wp_text_input focus
>>> - focus por (possibly several) pads/buttonsets
>>> - clipboard selection
>>> - primary selection
>>>
>>> Of course these are only guidelines, and compositors may attempt to
>>> implement split foci for these. But still, selection should be tied to
>>> some definite focus, the other option is broadcasting, and I'd very
>>> much prefer not to do that.
>>>
>>> I may try to change the wording just to suggest it's loosely attached
>>> to keyboard focus though.
>>
>> If you put an Insert sticker on your pad button and bind pasting to
>> that pad button and the pad focus is not tied to keyboard focus you
>> have potentially a problem there.
>
> Right, that's why I suggest having those reunited in a single logical
> focus. Anything else is plagued of corner cases.

That's totally not going to work. When  you have multiple touch panels
you can  touch multiple places. Are you proposing that on whichever
panel you happen to touch first locks the other panel from working or
on whichever panel you touch last steals the touch on the earlier
panel?

I do not think either is expected behaviour.

>
>>
>>>

> +with the keyboard focus will receive such events with a non-NULL
> +wp_primary_selection_offer. Across keyboard focus changes, previously
> +focused clients will receive wp_primary_selection_device.events with 
> a
> +NULL wp_primary_selection_offer.
> +
> +In order to request the primary selection data, the client must pass
> +a recent serial pertaining to the press event that is triggering the
> +operation, if the compositor deems the serial valid and recent, the

 Why press event when it has an offer event to base the request on?

 There is no need to involve other unrelated events.
>>>
>>> IIRC The first protocol drafts attempted to limit the circumstances in
>>> which a client could read the primary selection. This is a change of
>>> approach.
>>>

 IMHO the fact that the application receives ANY input event suffices.
 eg. a pointer entry event.
>>>
>>> Do you mean wl_pointer.enter should be enough to have the application
>>> read the primary selection? seems open to data leaks to me.
>>>
>>> This serial event is meant to check for user interaction rather than
>>> "any input event", so just focusing a client is not enough to have it
>>> retrieve the primary selection.
>>
>> And why is clicking enough and focusing not?
>>
>> Accidentally clicking an application can happen as much as
>> accidentally 

Re: desktop-shell: How to enable really alpha blending of weston background?

[Pekka Paalanen]

On Tue, 23 Feb 2016 10:11:39 +0900
YoungJun Jo  wrote:

> Hello,
> 
> Thanks for your reply.
> 
> What i want is alpha blending for my chips.
> As i mentioned, My chips have four independent H/W overlays.
> 
> For example,
> H/W Overlay 1 => Weston, Applications, etc..
> H/W Overlay 2 => Video play.
> H/W Overlay 3 = > Empty.
> H/W Overlay 4 = > Empty.
> 
> I also know that weston don't know H/W Overlays above mentioned.

Hi,

ok. The current state of Weston is slightly sad, as the support for
hardware overlays is disabled by default, because enabling it causes
performance problems. All that will be fixed once the patch series to
support atomic/nuclear KMS in the DRM backend by Daniel Stone will
land. I think Daniel is polishing it for submission whenever he has
time for it.

I would expect the situation to improve for Weston 1.11, but that's no
promise.

Btw. if you are using an fbdev backed, you have already lost: it will
never support hardware overlays. Use the DRM-backend instead. It is
possible to activate overlay support already with the debug key binding
Mod+Shift+space, v.

> Scenario:
> 1. If i click play button on my video application, it will be call alpha
> blending API.
> 2. When weston receives alpha blending api, weston background will be
> transparent.
> 3. And i could see video playing from H/W Layer 2.(Still H/W Layer1 shows
> GUI of video control buttons)
> 
> So i want really alpha blending of weston background.

I suppose you could do it like that, assuming that:
- you will only ever support your one special video player
- your video player is not cooperating with the display server, but it
  is bypassing the display server instead and holding the display
  server as a hostage (otherwise the display server, e.g. weston, can
  mess up your video view)
- your video player is likely specific to your hardware and cannot work
  elsewhere
- you will have to use a modified Weston, as upstream will never accept
  what you would need for this
- you will need to create a protocol extension for the "alpha blending
  API" or whatever to tell weston to get out of the way
- you won't have any application window mapped while playing e.g.
  fullscreen video
- you will waste power by always having to have a fullscreen completely
  transparent overlay on top the video overlay, rather than having the
  video on the top-most overlay

and probably many more limitations that make the approach very painful
to use in anything but a simple single-purpose device with a throw-away
software stack.

Essentially, you are using a display server (weston) to get a window
system, and then your aim is to remove the window system and bypass the
display server, telling weston to not mess with your video player.

Btw. I forgot a few things earlier. Not only you need to have the
backend tell the renderer use an alpha-capable framebuffer format, you
also need to hack clients/desktop-shell.c to not force the background
to be opaque. I'm not sure, but there might also be further things to
adjust in a backend to make sure the alpha bits actually get into the
hardware.


The proper solution using Wayland and Weston as they are intended would
involve the following:
- ensure your display hardware has proper DRM drivers supporting atomic
  KMS
- wait for the atomic support to land in Weston, which...
- puts Weston in control of all hardware planes, so that...
- Weston will automatically use all hardware planes for everything it
  can
- use any general purpose video player you want which supports
  linux_dmabuf Wayland protocol extension...
- and that will get the video on the hw overlay automatically when it
  is possible, and through hardware accelerated composition when the
  overlay cannot be used.

When the video player uses EGL or linux_dmabuf to push the video frames
to Weston, then Weston has the possibility to show them on a hardware
overlay.

As Weston will be in charge of everything on the display, the
fullscreen video playback won't suffer from the same waste of power as
your approach.

The proper solution is likely to result in a near-optimal use of
hardware resources in all cases automatically, both where overlays can
and cannot be used. The proper solution is also generic in that it is
not tied to a particular hardware platform.

In summary, do what you must, but I would strongly recommend the proper
solution if at all possible for you.


Thanks,
pq

> 2016-02-22 21:36 GMT+09:00 YoungJun Jo :
> 
> > Environment
> > OS : Linux kernel 3.10
> > Version : Weston 1.8.0
> > H/W spec : embedded soc based on ARM
> >
> > Hello, All
> >
> > I have a question about weston background.
> > I want enable alpha blending to background, so i have typed
> > 'background-color=0x00ff' on weston.ini.
> > But that's not really alpha blending. Because alpha value of pixel is a
> > 'ff'.
> > My chips have four H/W layers, top of the layer is UI layer and second
> > layer is video layer.
> >
> >