exo: produce libwayland-client.so

exo: produce libwayland-client.so

Produce wayland_client as shared library in order to enable thirdparty wayland
applications work on exo.
Rename wayland_client to wayland-client because common wayland client library
name is libwayland-client.so.
After this CL, Ubuntu wayland applications run on exo using chromium
libwayland-client.so.

To demonstrate how it works, add new demo, hello_wayland.

BUILD=ninja -C c/Release wayland_client_demo
TEST=XDG_RUNTIME_DIR=/run/chrome ./wayland_client_demo on ssh on amd64-generic image device
BUG=549781

[dshwang, 2016-03-01 18:31:16]

Description was changed from

==========
exo: produce libwayland-client.so

Produce wayland_client as shared library in order to enable thirdparty wayland
applications work on exo.
Rename wayland_client to wayland-client because common wayland client library
name is libwayland-client.so.
After this CL, Ubuntu wayland applications run on exo using chromium
libwayland-client.so.

To demonstrate how it works, add new demo, hello_wayland.

BUILD=ninja -C c/Release wayland_client_demo
TEST=run wayland_client_demo on amd64-generic image
BUG=549781
==========

to

==========
exo: produce libwayland-client.so

Produce wayland_client as shared library in order to enable thirdparty wayland
applications work on exo.
Rename wayland_client to wayland-client because common wayland client library
name is libwayland-client.so.
After this CL, Ubuntu wayland applications run on exo using chromium
libwayland-client.so.

To demonstrate how it works, add new demo, hello_wayland.

BUILD=ninja -C c/Release wayland_client_demo
TEST=run wayland_client_demo on amd64-generic image
BUG=549781
==========

[dshwang, 2016-03-01 18:31:17]

dongseong.hwang@intel.com changed reviewers:
+ reveman@chromium.org

[dshwang, 2016-03-01 18:31:32]

dongseong.hwang@intel.com changed reviewers:
+ joone.hur@intel.com

[dshwang, 2016-03-01 18:32:23]

reveman, could you review?
After this CL, Ubuntu wayland applications run on exo using chromium
libwayland-client.so.

[reveman, 2016-03-01 19:42:40]

I'd rather not include this demo client code in the chromium repo. Note that we
already have an example client as part of the unit tests. See
server_unittest.cc.

Why do we need this to be a shared library?

[dshwang, 2016-03-01 20:22:36]

On 2016/03/01 19:42:40, reveman wrote:
> I'd rather not include this demo client code in the chromium repo. Note that
we
> already have an example client as part of the unit tests. See
> server_unittest.cc.

server_unittest.cc is command line program and doesn't show any graphics
contents, but this demo shows what user can do clearly
here's video clip of this demo. https://goo.gl/photos/2iDp3LZbScpGtCUP9

> Why do we need this to be a shared library?

let's assume there is weston-terminal package which includes weston-terminal
executable.
weston-terminal can launch if there is libwayland-client.so.
> ldd /usr/bin/weston-terminal
	linux-vdso.so.1 =>  (0x00007ffcba9b8000)
	libwayland-client.so.0 => /usr/lib/x86_64-linux-gnu/libwayland-client.so.0
(0x00007f8149bf6000)
        ...

Now we can launch weston-terminal executable in chromeos device because the
device has libwayland-client.so

[reveman, 2016-03-01 20:31:52]

On 2016/03/01 at 20:22:36, dongseong.hwang wrote:
> On 2016/03/01 19:42:40, reveman wrote:
> > I'd rather not include this demo client code in the chromium repo. Note that
we
> > already have an example client as part of the unit tests. See
> > server_unittest.cc.
> 
> server_unittest.cc is command line program and doesn't show any graphics
contents, but this demo shows what user can do clearly
> here's video clip of this demo. https://goo.gl/photos/2iDp3LZbScpGtCUP9
> 
> > Why do we need this to be a shared library?
> 
> let's assume there is weston-terminal package which includes weston-terminal
executable.
> weston-terminal can launch if there is libwayland-client.so.
> > ldd /usr/bin/weston-terminal
> 	linux-vdso.so.1 =>  (0x00007ffcba9b8000)
> 	libwayland-client.so.0 => /usr/lib/x86_64-linux-gnu/libwayland-client.so.0
(0x00007f8149bf6000)
>         ...
> 
> Now we can launch weston-terminal executable in chromeos device because the
device has libwayland-client.so

We don't want that. If we did, then we'd just include the wayland library as
part of chromeos and not as part of chrome. third_party/wayland is for internal
usage in chromium only.

[dshwang, 2016-03-02 11:51:39]

On 2016/03/01 20:31:52, reveman wrote:
> On 2016/03/01 at 20:22:36, dongseong.hwang wrote:
> > On 2016/03/01 19:42:40, reveman wrote:
> > > I'd rather not include this demo client code in the chromium repo. Note
that
> we
> > > already have an example client as part of the unit tests. See
> > > server_unittest.cc.
> > 
> > server_unittest.cc is command line program and doesn't show any graphics
> contents, but this demo shows what user can do clearly
> > here's video clip of this demo. https://goo.gl/photos/2iDp3LZbScpGtCUP9

In addition, server_unittest tests server functionality. Except for you, nobody
exactly knows if thirdparty wayland client app can launch on chromeos.
wayland_client_demo answers it very clearly. Furthermore, wayland_client_demo
executable works on even Weston compositor, because it's just normal wayland
application.

> > > Why do we need this to be a shared library?
> > 
> > let's assume there is weston-terminal package which includes weston-terminal
> executable.
> > weston-terminal can launch if there is libwayland-client.so.
> > > ldd /usr/bin/weston-terminal
> > 	linux-vdso.so.1 =>  (0x00007ffcba9b8000)
> > 	libwayland-client.so.0 => /usr/lib/x86_64-linux-gnu/libwayland-client.so.0
> (0x00007f8149bf6000)
> >         ...
> > 
> > Now we can launch weston-terminal executable in chromeos device because the
> device has libwayland-client.so
> 
> We don't want that. If we did, then we'd just include the wayland library as
> part of chromeos and not as part of chrome. third_party/wayland is for
internal
> usage in chromium only.

You made chromium become wayland server. Now, chromium has responsibility to
provide wayland client library. 

When ChromeOS officially support wayland client, following one line is added in
chromeos-chrome-9999.ebuild, rather than adding whole wayland client source
code.
dosym libwayland-client.so /usr/lib/libwayland-client.so.0d
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/ma...

[reveman, 2016-03-02 15:09:24]

On 2016/03/02 at 11:51:39, dongseong.hwang wrote:
> On 2016/03/01 20:31:52, reveman wrote:
> > On 2016/03/01 at 20:22:36, dongseong.hwang wrote:
> > > On 2016/03/01 19:42:40, reveman wrote:
> > > > I'd rather not include this demo client code in the chromium repo. Note
that
> > we
> > > > already have an example client as part of the unit tests. See
> > > > server_unittest.cc.
> > > 
> > > server_unittest.cc is command line program and doesn't show any graphics
> > contents, but this demo shows what user can do clearly
> > > here's video clip of this demo. https://goo.gl/photos/2iDp3LZbScpGtCUP9
> 
> In addition, server_unittest tests server functionality. Except for you,
nobody exactly knows if thirdparty wayland client app can launch on chromeos.
> wayland_client_demo answers it very clearly. Furthermore, wayland_client_demo
executable works on even Weston compositor, because it's just normal wayland
application.
> 
> > > > Why do we need this to be a shared library?
> > > 
> > > let's assume there is weston-terminal package which includes
weston-terminal
> > executable.
> > > weston-terminal can launch if there is libwayland-client.so.
> > > > ldd /usr/bin/weston-terminal
> > > 	linux-vdso.so.1 =>  (0x00007ffcba9b8000)
> > > 	libwayland-client.so.0 =>
/usr/lib/x86_64-linux-gnu/libwayland-client.so.0
> > (0x00007f8149bf6000)
> > >         ...
> > > 
> > > Now we can launch weston-terminal executable in chromeos device because
the
> > device has libwayland-client.so
> > 
> > We don't want that. If we did, then we'd just include the wayland library as
> > part of chromeos and not as part of chrome. third_party/wayland is for
internal
> > usage in chromium only.
> 
> You made chromium become wayland server. Now, chromium has responsibility to
provide wayland client library.

I don't think so. You can get the wayland client library through other means.
third_party is for chromium dependencies, not to provide third_party libraries
to other apps.
 
> 
> When ChromeOS officially support wayland client, following one line is added
in chromeos-chrome-9999.ebuild, rather than adding whole wayland client source
code.
> dosym libwayland-client.so /usr/lib/libwayland-client.so.0d
>
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/ma...

There are no plans to officially support wayland clients and even if there were
chromium should not provide the client library.

[dshwang, 2016-03-02 15:55:12]

You don't agree on both demo and shared library, right?
If so, I close it as WontFix

> You can get the wayland client library through other means.

It's true. however, it's not strange for chromium to provide the client library
as chromium is wayland server.
If there is other mean, the other mean should depend on chromium because client
library is meaningless without chromium.

> There are no plans to officially support wayland clients and even if there
were
> chromium should not provide the client library.

Could you share plans and goals? you already added --enable-wayland-server by
default.
https://chromium-review.googlesource.com/#/c/309640/7/libchromeos-ui/chromeos...

Some embedders were exciting to exosphere because it can enable any wayland apps
to launch on chromeos, but it's a bit bad news for them. They still can build
apps with static client library though.

[dshwang, 2016-03-02 16:02:41]

Description was changed from

==========
exo: produce libwayland-client.so

Produce wayland_client as shared library in order to enable thirdparty wayland
applications work on exo.
Rename wayland_client to wayland-client because common wayland client library
name is libwayland-client.so.
After this CL, Ubuntu wayland applications run on exo using chromium
libwayland-client.so.

To demonstrate how it works, add new demo, hello_wayland.

BUILD=ninja -C c/Release wayland_client_demo
TEST=run wayland_client_demo on amd64-generic image
BUG=549781
==========

to

==========
exo: produce libwayland-client.so

Produce wayland_client as shared library in order to enable thirdparty wayland
applications work on exo.
Rename wayland_client to wayland-client because common wayland client library
name is libwayland-client.so.
After this CL, Ubuntu wayland applications run on exo using chromium
libwayland-client.so.

To demonstrate how it works, add new demo, hello_wayland.

BUILD=ninja -C c/Release wayland_client_demo
TEST=XDG_RUNTIME_DIR=/run/chrome ./wayland_client_demo on ssh on amd64-generic
image device
BUG=549781
==========

[reveman, 2016-03-02 16:10:34]

On 2016/03/02 at 15:55:12, dongseong.hwang wrote:
> You don't agree on both demo and shared library, right?
> If so, I close it as WontFix
> 
> > You can get the wayland client library through other means.
> 
> It's true. however, it's not strange for chromium to provide the client
library as chromium is wayland server.
> If there is other mean, the other mean should depend on chromium because
client library is meaningless without chromium.
> 
> > There are no plans to officially support wayland clients and even if there
were
> > chromium should not provide the client library.
> 
> Could you share plans and goals? you already added --enable-wayland-server by
default.
>
https://chromium-review.googlesource.com/#/c/309640/7/libchromeos-ui/chromeos...
> 
> Some embedders were exciting to exosphere because it can enable any wayland
apps to launch on chromeos, but it's a bit bad news for them. They still can
build apps with static client library though.

The wayland server support is still very experimental. The testing done so far
and the way I imagine this potentially being used with ChromeOS is having
clients run in a separate chroot where they have all the libraries they might
need. E.g. using crouton.

[dshwang, 2016-03-02 16:22:47]

On 2016/03/02 16:10:34, reveman wrote:
> On 2016/03/02 at 15:55:12, dongseong.hwang wrote:
> > You don't agree on both demo and shared library, right?
> > If so, I close it as WontFix
> > 
> > > You can get the wayland client library through other means.
> > 
> > It's true. however, it's not strange for chromium to provide the client
> library as chromium is wayland server.
> > If there is other mean, the other mean should depend on chromium because
> client library is meaningless without chromium.
> > 
> > > There are no plans to officially support wayland clients and even if there
> were
> > > chromium should not provide the client library.
> > 
> > Could you share plans and goals? you already added --enable-wayland-server
by
> default.
> >
>
https://chromium-review.googlesource.com/#/c/309640/7/libchromeos-ui/chromeos...
> > 
> > Some embedders were exciting to exosphere because it can enable any wayland
> apps to launch on chromeos, but it's a bit bad news for them. They still can
> build apps with static client library though.
> 
> The wayland server support is still very experimental. The testing done so far
> and the way I imagine this potentially being used with ChromeOS is having
> clients run in a separate chroot where they have all the libraries they might
> need. E.g. using crouton.

Ok, thank you for sharing it. This speculated patch is not needed in this stage.
It might need to be more concrete situation for this CL.
I close it as WontFix.