Re: [PATCH v2 wayland] protocol: specify behavior of get_pointer when capabilities change

2015-12-04 Thread Bill Spitzak 
This seems more complex than is needed.

My impression is that there are a non-zero set of version<5 compositors
that implement the new behaviour. Therefore a client that relies on the
incorrect behavior is broken even if it requests a version < 5, as it will
fail with some compositors. I think you should completely remove any text
about "it may act this way" as it is just confusing.

I also think that any such text will encourage *some* compositor to work
the old way, irregardless of what version number is claims. This will then
lead to some clients relying on the old behaviour. If these clients are at
all popular it will pretty much force all compositors to implement the old
behavior, making all this text irrelevant.

On Thu, Dec 3, 2015 at 5:01 PM, Jonas Ådahl  wrote:

> On Fri, Dec 04, 2015 at 10:34:34AM +1000, Peter Hutterer wrote:
> > Also applies to touch/keyboard
> >
> > Signed-off-by: Peter Hutterer 
> > ---
> > Changes to v1:
> > - make it clear that from the next version onwards sending events to an
> >   earlier wl_pointer object is a no-no.
> >
> >  protocol/wayland.xml | 36 +---
> >  1 file changed, 33 insertions(+), 3 deletions(-)
> >
> > diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> > index 7ca5049..471c1fe 100644
> > --- a/protocol/wayland.xml
> > +++ b/protocol/wayland.xml
> > @@ -1396,6 +1396,30 @@
> >   This is emitted whenever a seat gains or loses the pointer,
> >   keyboard or touch capabilities.  The argument is a capability
> >   enum containing the complete set of capabilities this seat has.
> > +
> > + When the pointer capability is added, a client may create a
> > + wl_pointer object using the wl_seat.get_pointer request. This
> object
> > + will receive pointer events until the capability is removed in the
> > + future.
> > +
> > + When the pointer capability is removed, a client should destroy the
> > + wl_pointer objects associated with the seat where the capability
> was
> > + removed, using the wl_pointer.release request. No further pointer
> > + events will be received on these objects.
> > +
> > + If a seat regains the pointer capability and a client has a pointer
> > + object obtained previously, that object may start sending pointer
> > + events. This behavior was implemented in some compositors
> supporting
> > + version 5 or less of the wl_seat interface and is considered a
>
> 5 -> 4
>
> > + misinterpretation of the intended behavior.
>
> tricycleshed: This newline will be ignored when displayed as HTML, so I
> don't think it that good to rely on such formatting.
>
> > + This behavior must not be relied upon by the client. A compositor
> > + implementing version 6 or later of the wl_seat or wl_pointer
>
> 6 -> 5
>
> > + interface must not send events to a wl_pointer object created
> > + before the most recent event notifying the client of an added
> > + pointer capability.
>
>
> This to me reads like we are now aiming to break those clients, as if
> they happen to connect to a newer compositor supporting version >= 5
> of wl_seat will not continue supporting the old behaviour. Was that the
> conclusion drawn?
>
> If so is the case, the text sounds correct to me, but I think it could be
> made to sound more obvious that the behaviour is not supported any more.
>
> In some compositors only supporting version 4 or less of the
> wl_seat, if a seat regains the pointer capability and a client
> has a pointer object obtained previously, that object may start
> sending pointer events. This behaviour is considered a
> misinterpretation and must not be relied upon by the client. A
> compositor implementing version 5 or later of the wl_seat or
> wl_pointer interface must not send events to a wl_pointer object
> created before the most recent event notifying the client of an
> added pointer capability.
>
> That way its more up front that its old unsupported behaviour.
>
>
> Jonas
>
> > +
> > + The above behavior also applies to wl_keyboard and wl_touch with
> the
> > + keyboard and touch capabilities, respectively.
> >
> >
> >  
> > @@ -1406,7 +1430,9 @@
> >   for this seat.
> >
> >   This request only takes effect if the seat has the pointer
> > - capability.
> > + capability, or has had the pointer capability in the past.
> > + It is a protocol violation to issue this request on a seat that has
> > + never had the pointer capability.
> >
> >
> >  
> > @@ -1417,7 +1443,9 @@
> >   for this seat.
> >
> >   This request only takes effect if the seat has the keyboard
> > - capability.
> > + capability, or has had the keyboard capability in the past.
> > + It is a protocol violation to issue this request on a seat that has
> > + never had the

Re: [PATCH v2 wayland] protocol: add support for cross-interface enum attributes

2015-12-04 Thread Bill Spitzak 
On Wed, Dec 2, 2015 at 7:19 AM, Nils Chr. Brause 
wrote:

> On Wed, Dec 2, 2015 at 11:48 AM, Auke Booij  wrote:
> > I'd be happy to rebase against that, but since that hasn't been merged
> > yet, I thought I'd take the current tree as a a basis.
> >
> > If you think having the interface:: prefix everywhere makes sense, I
> > can change that if you want.
>
> I think that would be very nice for consistency. :)
>

It was an accident in how I wrote it, but it seems at least one person (and
possibly two as there was another comment but I'm not sure who from) like
it that way.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] [RFC] desktop-shell: change the alpha of black view in fullscreen mode

2015-12-04 Thread Pekka Paalanen 
On Thu, 3 Dec 2015 14:18:54 -0800
Bryce Harrington  wrote:

> On Thu, Dec 03, 2015 at 10:33:27PM +0900, Hyungwon Hwang wrote:
> > This patch changes the alpha value of black view in fullscreen mode,
> > when the applications opacity changes.
> > 
> > Signed-off-by: Hyungwon Hwang 
> > ---
> > This patch is incomplete, and just a proof of concept. But I want to
> > make this patch as the starting point of discussion related the opacity
> > in fullscreen mode [1]. I tested it with weston-fullscreen.  
> 
> Thanks for sending this as an RFC, as a follow up to the earlier
> discussion with pq.  I notice some of the points he had raised in that
> discussion (e.g. avoiding alpha for letterbox edges, etc.) aren't
> being addressed.  In technical terms this patch doesn't look bad but you
> might include a discussion of how the remaining problems would be
> handled?

FWIW, I do think that changing the opacity of the black surface like
this is a totally wrong approach to any problem.

Either the opaque black borders exist or they do not. They are realized
by either a single black surface behind the window like currently, or
several black surfaces around the window. When the black borders must
not be drawn, the black surface(s) must be destroyed (and re-created
on-demand).

If there are obvious bugs with the on-demand realization of the black
surface, like I understood from the comments that there might be,
fixing those would not be controversial.

The real question here is, what use case is there for a fullscreen
window to be semi-transparent?

Should the definition of fullscreen include the assumption of not being
able to see through the window?

The answer to that question must affect shell protocol specification,
or you will get varying implementations between compositors. So, the
proper starting point for that discussion is to look at the shell
protocol specifications.

Also, xdg_shell specification is very different to that of wl_shell
right now. Xdg_shell requires that the window size matches the output
size, which pushes the issue of black borders to the client. So in the
current state of protocol development, questions here apply pretty much
only to wl_shell.

What Weston currently implements wrt. to the black surface may not be
correct for all possible use cases, but I claim that the intention is
correct for the cases where the window size does not match the output
size, as specified in wl_shell spec.

Mind, I will outright refuse all use cases where you use opacity and
input region manipulations to just "switch windows" from client side.


Thanks,
pq

> > 1. Changing the opacity in normal mode.
> > 2. Changing the opacity in fullscreen mode.
> > 3. Changing the opacity in fullscreen mode, but the content is smaller
> > then output.
> > 4. After 1 & 2, switch to another application.
> > 5. After 3, switch to another application.
> > 
> > In case of 1 ~ 4, it works fine. But in case of 5, the opacity does
> > not be kept, and it must be fixed. I think that it is also related another
> > issue I stated in PS below.
> > 
> > I want to discuss about what stance Weston will be on with this issue
> > : When opacity changes in fullscreen mode, which surface's opacity should
> > be affected.
> > 
> > PS. As I made this patch, I found that the opacity resets when the user 
> > switch
> > to another application irrespective of fullscreen. It also seemed a little
> > odd to me.
> > 
> > Best regards,
> > Hyungwon Hwang
> > 
> > [1]
> > http://lists.freedesktop.org/archives/wayland-devel/2015-December/025859.html


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

Re: [PATCH v3 wayland-protocols] configure.ac: Fix compatibility for older pkg-config versions

2015-12-04 Thread Pekka Paalanen 
On Thu,  3 Dec 2015 17:40:47 -0800
Bryce Harrington  wrote:

> noarch_pkgconfigdir is not available on oldish pkg-config's.  Among
> other things this affects Wayland's nightly auto-build Ubuntu 14.04
> PPAs.
> 
> Signed-off-by: Bryce Harrington 
> Cc: Pekka Paalanen 
> Cc: Quentin Glidic 
> Cc: Peter Hutterer 
> ---
> Changes from v2
>- Place config.m4 into an m4 subdir
>- Auto load m4's via AC_CONFIG_MACRO_DIR
> 
> Changes from v1
>- Document why the work around is needed and what obsoletes it.
>- Drop pkgconfigdir, which isn't strictly needed
> 
>  configure.ac |  2 ++
>  m4/compat.m4 | 12 
>  2 files changed, 14 insertions(+)
>  create mode 100644 m4/compat.m4
> 
> diff --git a/configure.ac b/configure.ac
> index 93688d0..c51b7fc 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -11,6 +11,8 @@ AC_INIT([wayland-protocols],
>  [wayland-protocols],
>  [http://wayland.freedesktop.org/])
>  
> +AC_CONFIG_MACRO_DIR([m4])
> +
>  AC_SUBST([WAYLAND_PROTOCOLS_VERSION], [wayland_protocols_version])
>  
>  AM_INIT_AUTOMAKE([1.11 foreign no-dist-gzip dist-xz])
> diff --git a/m4/compat.m4 b/m4/compat.m4
> new file mode 100644
> index 000..290ef03
> --- /dev/null
> +++ b/m4/compat.m4
> @@ -0,0 +1,12 @@
> +dnl noarch_pkgconfigdir only available in pkg-config 0.27 and newer
> +dnl http://lists.freedesktop.org/archives/pkg-config/2012-July/000875.html
> +dnl Ubuntu 14.04 provides only pkg-config 0.26 so lacks this function.
> +dnl
> +dnl The Wayland project maintains automated builds for Ubuntu 14.04 in
> +dnl a Launchpad PPA.  14.04 is a Long Term Support distro release, which
> +dnl will reach EOL April 2019, however the Wayland PPA may stop targeting
> +dnl it some time after the next LTS release (April 2016).
> +m4_ifndef([PKG_NOARCH_INSTALLDIR], [AC_DEFUN([PKG_NOARCH_INSTALLDIR], [
> +noarch_pkgconfigdir='${datadir}'/pkgconfig
> +AC_SUBST([noarch_pkgconfigdir])
> +])])

Hi Bryce,

this looks good to me, but I would like to see R-b from Quentin.


Thanks,
pq


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

Re: [PATCH v3 wayland-protocols] configure.ac: Fix compatibility for older pkg-config versions

2015-12-04 Thread Jonas Ådahl 
On Fri, Dec 04, 2015 at 10:45:06AM +0100, Quentin Glidic wrote:
> On 04/12/2015 02:40, Bryce Harrington wrote:
> >noarch_pkgconfigdir is not available on oldish pkg-config's.  Among
> >other things this affects Wayland's nightly auto-build Ubuntu 14.04
> >PPAs.
> >
> >Signed-off-by: Bryce Harrington 
> >Cc: Pekka Paalanen 
> >Cc: Quentin Glidic 
> >Cc: Peter Hutterer 
> >---
> >Changes from v2
> >- Place config.m4 into an m4 subdir
> >- Auto load m4's via AC_CONFIG_MACRO_DIR
> >
> >Changes from v1
> >- Document why the work around is needed and what obsoletes it.
> >- Drop pkgconfigdir, which isn't strictly needed
> >
> >  configure.ac |  2 ++
> >  m4/compat.m4 | 12 
> >  2 files changed, 14 insertions(+)
> >  create mode 100644 m4/compat.m4
> >
> >diff --git a/configure.ac b/configure.ac
> >index 93688d0..c51b7fc 100644
> >--- a/configure.ac
> >+++ b/configure.ac
> >@@ -11,6 +11,8 @@ AC_INIT([wayland-protocols],
> >  [wayland-protocols],
> >  [http://wayland.freedesktop.org/])
> >
> >+AC_CONFIG_MACRO_DIR([m4])
> >+
> >  AC_SUBST([WAYLAND_PROTOCOLS_VERSION], [wayland_protocols_version])
> >
> >  AM_INIT_AUTOMAKE([1.11 foreign no-dist-gzip dist-xz])
> >diff --git a/m4/compat.m4 b/m4/compat.m4
> >new file mode 100644
> >index 000..290ef03
> >--- /dev/null
> >+++ b/m4/compat.m4
> >@@ -0,0 +1,12 @@
> >+dnl noarch_pkgconfigdir only available in pkg-config 0.27 and newer
> >+dnl http://lists.freedesktop.org/archives/pkg-config/2012-July/000875.html
> >+dnl Ubuntu 14.04 provides only pkg-config 0.26 so lacks this function.
> >+dnl
> >+dnl The Wayland project maintains automated builds for Ubuntu 14.04 in
> >+dnl a Launchpad PPA.  14.04 is a Long Term Support distro release, which
> >+dnl will reach EOL April 2019, however the Wayland PPA may stop targeting
> >+dnl it some time after the next LTS release (April 2016).
> >+m4_ifndef([PKG_NOARCH_INSTALLDIR], [AC_DEFUN([PKG_NOARCH_INSTALLDIR], [
> >+noarch_pkgconfigdir='${datadir}'/pkgconfig
> >+AC_SUBST([noarch_pkgconfigdir])
> >+])])
> >
> 
> Perfect.
> 
> Reviewed-by: Quentin Glidic 

Thanks,

Pushed with yours and Peters RBs:
   3543bb7..da33164  master -> master


Jonas

> 
> -- 
> 
> Quentin “Sardem FF7” Glidic
> ___
> 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

[PATCH v2] rephrasing the index.html to be more acurate

2015-12-04 Thread Benoit Gschwind 
Include fixes from Silvan Jegen

---
 index.html | 41 ++---
 1 file changed, 26 insertions(+), 15 deletions(-)

diff --git a/index.html b/index.html
index a9ebcaa..db04a91 100644
--- a/index.html
+++ b/index.html
@@ -12,21 +12,32 @@
 
 Wayland
 
-Wayland is intended as a simpler replacement for X, easier to develop
-and maintain.  GNOME and KDE are expected to be ported to it.
-
-Wayland is a protocol for a compositor to talk to its clients as
-well as a C library implementation of that protocol.  The compositor
-can be a standalone display server running on Linux kernel modesetting
-and evdev input devices, an X application, or a wayland client itself.
-The clients can be traditional applications, X servers (rootless or
-fullscreen) or other display servers.
-
-Part of the Wayland project is also the Weston reference
-implementation of a Wayland compositor.  Weston can run as an X client
-or under Linux KMS and ships with a few demo clients.  The Weston
-compositor is a minimal and fast compositor and is suitable for many
-embedded and mobile use cases.  
+Wayland project is intended to replace X11 protocol. The aim is to 
+provide a protocol that is easier to use, that improve weakness of 
+the legacy X11 protocol and that is faster.  GNOME and KDE are 
+expected to implement those protocol in there own server.  The 
+Wayland project is focused on 3 components : Wayland, LibWayland 
+and Weston.
+
+Wayland is a protocol for sharing screens and inputs devices 
+between concurents clients.  The Wayland protocol define the way a 
+server talk to a its clients and how each client can talks to the 
+server.  The server is reponsible to setup screens, inputs devices 
+and make the final images that the user see on screens.  The server 
+is usualy called compositor.
+
+LibWayland is a reference library that implement the Wayland 
+protocol, this library is intend to help developers to implements 
+compositors and clients.  This library is splited on 2 distinct 
+parts, the server side library and the client side library.
+
+Weston is a reference compositor that use LibWayland to talk 
+with its clients, he can run under Linux KMS as standalone 
+compositor or can run as X client.  In the latter case, Weston 
+create a virtual screens that is drawn in X window and create 
+virtual inputs devices taken from the X server similarly to Xnest 
+ot Xephyr. Weston also include few proof-of-concept clients like
+flower or the wayland terminal.
 
 Information:
 
-- 
2.4.10

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

Input device to weston after start

2015-12-04 Thread Keskinarkaus, Teemu 
Hi,

I have a HW with touchscreen that is connected to serial port. I'm using 
inputattach to attach the touch to Linux input system. After that I start 
Weston and touch works just fine.

Problem now is that the inputattach takes some time to find/install the touch 
device and if I start Weston before that the touch won't work. This causes 
delay at startup that now is wanted to be eliminated. I think the delay in 
adding the touch device comes from kernel side so I'm not willing to touch to 
that if possible to avoid.

Question now is that is it possible to add input devices to Weston _after_ it's 
been started? If so, then how to do it? Simply adding the device the kernel 
input system doesn't automatically make it visible in Weston. Ie. if in my case 
the inputattach is started after Weston is started, the touch won't start 
working.

Teemu Keskinarkaus
Software system engineer





Actuant Corporation Email Notice

This message is intended only for the use of the Addressee and may contain 
information that is PRIVILEGED and/or CONFIDENTIAL.
This email is intended only for the personal and confidential use of the 
recipient(s) named above. If the reader of this email is not an intended 
recipient, you have received this email in error and any review, dissemination, 
distribution or copying is strictly prohibited.
If you have received this email in error, please notify the sender immediately 
by return mail and permanently delete the copy you received.

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

Re: Input device to weston after start

2015-12-04 Thread Pekka Paalanen 
On Fri, 4 Dec 2015 08:04:55 +
"Keskinarkaus, Teemu"  wrote:

> Hi,
> 
> I have a HW with touchscreen that is connected to serial port. I'm
> using inputattach to attach the touch to Linux input system. After
> that I start Weston and touch works just fine.
> 
> Problem now is that the inputattach takes some time to find/install
> the touch device and if I start Weston before that the touch won't
> work. This causes delay at startup that now is wanted to be
> eliminated. I think the delay in adding the touch device comes from
> kernel side so I'm not willing to touch to that if possible to avoid.
> 
> Question now is that is it possible to add input devices to Weston
> _after_ it's been started? If so, then how to do it? Simply adding
> the device the kernel input system doesn't automatically make it
> visible in Weston. Ie. if in my case the inputattach is started after
> Weston is started, the touch won't start working.

AFAIK Weston is listening on udev events and should be opening input
devices as they appear. Perhaps you could compare what happens when
hotplugging a normal keyboard or mouse vs. starting inputattach?

I suppose one would check if there are any udev events from that, does
Weston see them and if so, does something in Weston reject the device,
or is Weston never notified about it.


Thanks,
pq


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

[PATCH] xdg-shell: add state range reservation for EFL

2015-12-04 Thread Mike Blumenkrantz 
Reviewed-by: Jasper St. Pierre 
---
 unstable/xdg-shell/xdg-shell-unstable-v5.xml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v5.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v5.xml
index 127992b..542491f 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v5.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v5.xml
@@ -338,6 +338,7 @@
 
 0x - 0x0FFF: xdg-shell core values, documented below.
 0x1000 - 0x1FFF: GNOME
+0x2000 - 0x2FFF: EFL
   
   

-- 
2.4.3

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

Re: [PATCH] [RFC] desktop-shell: change the alpha of black view in fullscreen mode

2015-12-04 Thread hyungwon.hwang7 

Hello Pekka,

On 2015년 12월 04일 17:14, Pekka Paalanen wrote:

On Thu, 3 Dec 2015 14:18:54 -0800
Bryce Harrington  wrote:


On Thu, Dec 03, 2015 at 10:33:27PM +0900, Hyungwon Hwang wrote:

This patch changes the alpha value of black view in fullscreen mode,
when the applications opacity changes.

Signed-off-by: Hyungwon Hwang 
---
This patch is incomplete, and just a proof of concept. But I want to
make this patch as the starting point of discussion related the opacity
in fullscreen mode [1]. I tested it with weston-fullscreen.


Thanks for sending this as an RFC, as a follow up to the earlier
discussion with pq.  I notice some of the points he had raised in that
discussion (e.g. avoiding alpha for letterbox edges, etc.) aren't
being addressed.  In technical terms this patch doesn't look bad but you
might include a discussion of how the remaining problems would be
handled?


FWIW, I do think that changing the opacity of the black surface like
this is a totally wrong approach to any problem.

Either the opaque black borders exist or they do not. They are realized
by either a single black surface behind the window like currently, or
several black surfaces around the window. When the black borders must
not be drawn, the black surface(s) must be destroyed (and re-created
on-demand).

If there are obvious bugs with the on-demand realization of the black
surface, like I understood from the comments that there might be,
fixing those would not be controversial.

The real question here is, what use case is there for a fullscreen
window to be semi-transparent?

Should the definition of fullscreen include the assumption of not being
able to see through the window?

The answer to that question must affect shell protocol specification,
or you will get varying implementations between compositors. So, the
proper starting point for that discussion is to look at the shell
protocol specifications.


I found the spec in 
http://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_shell. Again, 
I am new to wayland. We are seeing the same document, right?The spec 
does not break anything in wl_shell_surface::fullscreen_method. The 
protocol describe what should be happen when the surface output and the 
output size differ. With this change, it doesn't affect that behavior. 
It just makes the users to be able to adjust the opacity of the black 
view behind the surface of fullscreen application. For now, when the 
user intentionally adjust the opacity of application in fullscreen mode, 
only the application surface is affected. So the black view appears as 
the surface becomes transparent. But with this change, the behind 
surfaces will appears because the black view's alpha is synced with the 
application's alpha. In the discussion, we talked about 3 use cases,

1. Fullscreen media player
2. Fullscreen game
3. Fullscreen terminal

For 1 & 2, I think that the user probably would not want to make the app 
transparent in most cases. In these cases, the behavior related with 
black border is same as it is. But even he wants intentionally, the 
application itself and the black border around the application would be 
transparent as he wants.


For 3, some people including me like transparent fullscreen terminal. 
But for now, it is not available because of opaque black view behind.


If it does not break something in spec, I think that this change will 
give the users more options to use Weston for their purpose.




Also, xdg_shell specification is very different to that of wl_shell
right now. Xdg_shell requires that the window size matches the output
size, which pushes the issue of black borders to the client. So in the
current state of protocol development, questions here apply pretty much
only to wl_shell.

What Weston currently implements wrt. to the black surface may not be
correct for all possible use cases, but I claim that the intention is
correct for the cases where the window size does not match the output
size, as specified in wl_shell spec.

Mind, I will outright refuse all use cases where you use opacity and
input region manipulations to just "switch windows" from client side.



I think that there are some misunderstanding about "switching windows". 
I am not a English native. So I wrote the sentences unclearly. If it 
was, I am sorry about that. Anyway, I meant to say that is there any 
reason to reset the opacity of an application which the user 
intentionally adjusted, when the user just switch to another application 
and return back? I thougt that it was weston bug, isn't it?


Thanks for your comment, Pekka.

Best regards,
Hyungwon Hwang



Thanks,
pq


1. Changing the opacity in normal mode.
2. Changing the opacity in fullscreen mode.
3. Changing the opacity in fullscreen mode, but the content is smaller
then output.
4. After 1 & 2, switch to another application.
5. After 3, switch to another application.

In case of 1 ~ 4, it works fine. But in case of 5,

Re: [PATCH] [RFC] desktop-shell: change the alpha of black view in fullscreen mode

2015-12-04 Thread hyungwon.hwang7 

Hello Bryce,

On 2015년 12월 04일 07:18, Bryce Harrington wrote:

On Thu, Dec 03, 2015 at 10:33:27PM +0900, Hyungwon Hwang wrote:

This patch changes the alpha value of black view in fullscreen mode,
when the applications opacity changes.

Signed-off-by: Hyungwon Hwang 
---
This patch is incomplete, and just a proof of concept. But I want to
make this patch as the starting point of discussion related the opacity
in fullscreen mode [1]. I tested it with weston-fullscreen.


Thanks for sending this as an RFC, as a follow up to the earlier
discussion with pq.  I notice some of the points he had raised in that
discussion (e.g. avoiding alpha for letterbox edges, etc.) aren't
being addressed.  In technical terms this patch doesn't look bad but you
might include a discussion of how the remaining problems would be
handled?



OK. Next time I send RFC, I will clear my opinion. Thanks for your comment.


Also, don't forget to use your samsung address when sending patches
(assuming this is for work).


It's my hobby at home.

Best regards,
Hyungwon Hwnag




1. Changing the opacity in normal mode.
2. Changing the opacity in fullscreen mode.
3. Changing the opacity in fullscreen mode, but the content is smaller
then output.
4. After 1 & 2, switch to another application.
5. After 3, switch to another application.

In case of 1 ~ 4, it works fine. But in case of 5, the opacity does
not be kept, and it must be fixed. I think that it is also related another
issue I stated in PS below.

I want to discuss about what stance Weston will be on with this issue
: When opacity changes in fullscreen mode, which surface's opacity should
be affected.

PS. As I made this patch, I found that the opacity resets when the user switch
to another application irrespective of fullscreen. It also seemed a little
odd to me.

Best regards,
Hyungwon Hwang

[1]
http://lists.freedesktop.org/archives/wayland-devel/2015-December/025859.html

  desktop-shell/shell.c | 36 +++-
  1 file changed, 23 insertions(+), 13 deletions(-)

diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 780902d..418c66f 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -2767,7 +2767,7 @@ black_surface_configure(struct weston_surface *es, 
int32_t sx, int32_t sy);
  static struct weston_view *
  create_black_surface(struct weston_compositor *ec,
 struct weston_surface *fs_surface,
-float x, float y, int w, int h)
+float x, float y, int w, int h, float alpha)
  {
struct weston_surface *surface = NULL;
struct weston_view *view;
@@ -2783,11 +2783,12 @@ create_black_surface(struct weston_compositor *ec,
weston_surface_destroy(surface);
return NULL;
}
+   view->alpha = alpha;

surface->configure = black_surface_configure;
surface->configure_private = fs_surface;
weston_surface_set_label_func(surface, black_surface_get_label);
-   weston_surface_set_color(surface, 0.0, 0.0, 0.0, 1);
+   weston_surface_set_color(surface, 0.0, 0.0, 0.0, alpha);
pixman_region32_fini(>opaque);
pixman_region32_init_rect(>opaque, 0, 0, w, h);
pixman_region32_fini(>input);
@@ -2812,7 +2813,8 @@ shell_ensure_fullscreen_black_view(struct shell_surface 
*shsurf)
 shsurf->surface,
 output->x, output->y,
 output->width,
-output->height);
+output->height,
+shsurf->view->alpha);

weston_view_geometry_dirty(shsurf->fullscreen.black_view);
weston_layer_entry_remove(>fullscreen.black_view->layer_link);
@@ -4717,10 +4719,24 @@ resize_binding(struct weston_pointer *pointer, uint32_t 
time,
  }

  static void
+do_adjust_alpha(struct weston_view *view, wl_fixed_t value) {
+   float step = 0.005;
+
+   view->alpha -= wl_fixed_to_double(value) * step;
+
+   if (view->alpha > 1.0)
+   view->alpha = 1.0;
+   if (view->alpha < step)
+   view->alpha = step;
+
+   weston_view_geometry_dirty(view);
+   weston_surface_damage(view->surface);
+}
+
+static void
  surface_opacity_binding(struct weston_pointer *pointer, uint32_t time,
uint32_t axis, wl_fixed_t value, void *data)
  {
-   float step = 0.005;
struct shell_surface *shsurf;
struct weston_surface *focus = pointer->focus->surface;
struct weston_surface *surface;
@@ -4734,15 +4750,9 @@ surface_opacity_binding(struct weston_pointer *pointer, 
uint32_t time,
if (!shsurf)
return;

-   shsurf->view->alpha -= wl_fixed_to_double(value) * step;
-
-   if (shsurf->view->alpha > 1.0)
-   shsurf->view->alpha =

Re: [PATCH v2 wayland] protocol: add support for cross-interface enum attributes

2015-12-04 Thread Bryce Harrington 
On Sun, Nov 29, 2015 at 01:54:46PM +, Auke Booij wrote:
> The enum attribute, for which scanner support was introduced in
> 1771299, can be used to link message arguments to s. However,
> some arguments refer to s in a different .
> 
> This adds scanner support for referring to an  in a different
>  using dot notation. It also sets the attributes in this
> style in the wayland XML protocol (wl_shm_pool::create_buffer::format
> to wl_shm::format, and wl_surface::set_buffer_transform::transform to
> wl_output::transform), and updates the documentation XSL so that this
> new style is supported.
> 
> Changes since v1:
>  - several implementation bugs fixed
> 
> Signed-off-by: Auke Booij 
> ---
>  doc/publican/protocol-to-docbook.xsl | 17 +--
>  protocol/wayland.xml |  4 +--
>  src/scanner.c| 59 
> +++-
>  3 files changed, 61 insertions(+), 19 deletions(-)
> 
> diff --git a/doc/publican/protocol-to-docbook.xsl 
> b/doc/publican/protocol-to-docbook.xsl
> index fad207a..1fa066d 100644
> --- a/doc/publican/protocol-to-docbook.xsl
> +++ b/doc/publican/protocol-to-docbook.xsl
> @@ -103,9 +103,20 @@
>  
>  
>
> -
> -  
> -
> +
> +  
> +
> +  
> +  ::
> +  
> +
> +  
> +  
> +
> +  
> +
> +  
> +
>
>
>
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index f9e6d76..0873553 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -229,7 +229,7 @@
>
>
>
> -  
> +  
>  
>  
>  
> @@ -1292,7 +1292,7 @@
>   wl_output.transform enum the invalid_transform protocol error
>   is raised.
>
> -  
> +  
>  
>  
>  
> diff --git a/src/scanner.c b/src/scanner.c
> index 406519f..e69bd2a 100644
> --- a/src/scanner.c
> +++ b/src/scanner.c
> @@ -785,32 +785,62 @@ start_element(void *data, const char *element_name, 
> const char **atts)
>   }
>  }
>  
> +static struct enumeration *
> +find_enumeration(struct protocol *protocol, struct interface *interface, 
> char *enum_attribute)
> +{
> + struct interface *i;
> + struct enumeration *e, *f = NULL;
> + char *enum_name;
> + int idx = 0, j;
> +
> +for (j = 0; j + 1 < (int)strlen(enum_attribute); j++) {

whitespace error here; use tab for the indent.

Also instead of casting the strlen to an int, maybe make idx and i
unsigned ints?

> + if (enum_attribute[j] == '.') {
> + idx = j;
> + }
> + }
> +
> + if (idx > 0) {
> + enum_name = enum_attribute + idx + 1;
> +
> + wl_list_for_each(i, >interface_list, link)
> + if (strncmp(i->name, enum_attribute, idx) == 0)
> + wl_list_for_each(e, >enumeration_list, link)
> + if(strcmp(e->name, enum_name) == 0)
> + f = e;
> + } else if (interface) {
> + enum_name = enum_attribute;
> +
> + wl_list_for_each(e, >enumeration_list, link)
> + if(strcmp(e->name, enum_name) == 0)
> + f = e;
> + }
> +
> + return f;

Presumably there's only going to be a single enumeration of a given
name; why not return that as soon as its found rather than continuing
the iteration until the end and returning the last one found?

> +}
> +
>  static void
> -verify_arguments(struct parse_context *ctx, struct wl_list *messages, struct 
> wl_list *enumerations)
> +verify_arguments(struct parse_context *ctx, struct interface *interface, 
> struct wl_list *messages, struct wl_list *enumerations)
>  {
>   struct message *m;
>   wl_list_for_each(m, messages, link) {
>   struct arg *a;
>   wl_list_for_each(a, >arg_list, link) {
> - struct enumeration *e, *f;
> + struct enumeration *e;
>  
>   if (!a->enumeration_name)
>   continue;
>  
> - f = NULL;
> - wl_list_for_each(e, enumerations, link) {
> - if(strcmp(e->name, a->enumeration_name) == 0)
> - f = e;
> - }
>  
> - if (f == NULL)
> + e = find_enumeration(ctx->protocol, interface, 
> a->enumeration_name);
> +
> + if (e == NULL)
>   fail(>loc,
>"could not find enumeration %s",
>a->enumeration_name);
>  
>   switch (a->type) {
>