[no subject]

[shashank singh]

Hello everyone, My name is Shashank. I want to apply for EVoC(endless
vacation of code) and was looking for a potential mentor. As for the
experience with open source, I've recently completed my GSoC project and I
am looking forward to applying for EVoC :)

[no subject]

[Selastin George]

How to run a qtwayland compositor without the support of any platform by
using DRM.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: (No Subject)

[Simon Ser]

On Monday, May 27, 2019 10:27 AM, adlo  wrote:
> > On 25 May 2019, at 14:44, Simon Ser cont...@emersion.fr wrote:
>
> > Hi,
> >
> > > On Saturday, May 25, 2019 4:23 PM, Alexandre Mazari sca...@gmail.com 
> > > wrote:
> > > Greetings wayland-devel,
> > > I am currently looking at ways to abstract Xisms in Plasma
> > > global-menu daemon and applet and provide a Wayland implementation.
> > > X11/xcb is currently used there to set and obtain to/from the
> > > active window some metadata (atoms) relative to the DBus address of
> > > the application menu provider.
> > > A wayland implementation [0] should first be able to track the active
> > > window.
> > > AFAIK, none of the current protocols provides such mechanism.
> > > I wonder whether that is by design to avoid some info leakage or
> > > would an activeSurface/activeWindow method/signal couple make sense
> > > in xdg-shell or xdg_surface?
> >
> > Yes, this is by design. Regular clients don't have any way to list
> > other clients' toplevels or to manage them, unlike on X11.
> > I don't think it would make sense to add such a request/event to
> > xdg-shell, because this is out-of-scope for xdg-shell.
> >
> > > Moreover, the shell compositor often has the best knowledge of the
> > > link between surface/window and their owner application. Specific
> > > clients (like the global-menu) might be interested in this data,
> > > avoiding convoluted ways to do the matching. a get_app_id request in
> > > xdg shell could prove useful there.
> > > What do you think?
> >
> > Some projects like GNOME make the compositor responsible for drawing
> > desktop UI elements like a global menu. This has the upside of being
> > easy to implement, but has also some downsides: for instance the
> > compositor is responsible for drawing complex UI elements, which slows
> > down composition and makes it more likely to crash.
> > If you cannot or don't want to do it this way, other compositors
> > (e.g. Weston, KDE as far as I've understood, and many wlroots
> > compositors) typically use a dedicated protocol for privileged clients.
> > In the case of KWin, the existing KDE-specific Wayland protocols are
> > here:
> > https://github.com/KDE/kwayland/tree/master/src/client/protocols
> > It's worth noting that as of now, only Weston restricts access to
> > privileged protocols to a limited set of clients. In other compositors,
> > these protocols are exposed to all clients (and this has security
> > implications).
> > Regarding this specific use-case, wlroots has standardized a protocol
> > for listing and managing toplevels:
> > https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-foreign-toplevel-management-unstable-v1.xml
>
> Are there any examples of server-side implementations of 
> plasma-window-management.xml on libweston? Alternatively, are there any plain 
> C implementations of the same without all the KDE/Qt stuff?
>
> What would a basic boilerplate implementation of plasma-window-management 
> look like on libweston?

No, plasma-window-management is a private KDE protocol. If you want a
protocol that has been designed to be cross-compositor, I'd suggest
looking into wlr-foreign-toplevel-management (a plain C implementation
exists in wlroots, it should be pretty self-contained).
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: (No Subject)

[adlo]

> On 25 May 2019, at 14:44, Simon Ser  wrote:
> 
> Hi,
> 
>> On Saturday, May 25, 2019 4:23 PM, Alexandre Mazari  wrote:
>> Greetings wayland-devel,
>> 
>> I am currently looking at ways to abstract Xisms in Plasma
>> global-menu daemon and applet and provide a Wayland implementation.
>> 
>> X11/xcb is currently used there to set and obtain to/from the
>> *active* window some metadata (atoms) relative to the DBus address of
>> the application menu provider.
>> 
>> A wayland implementation [0] should first be able to track the active
>> window.
>> AFAIK, none of the current protocols provides such mechanism.
>> I wonder whether that is by design to avoid some info leakage or
>> would an activeSurface/activeWindow method/signal couple make sense
>> in xdg-shell or xdg_surface?
> 
> Yes, this is by design. Regular clients don't have any way to list
> other clients' toplevels or to manage them, unlike on X11.
> 
> I don't think it would make sense to add such a request/event to
> xdg-shell, because this is out-of-scope for xdg-shell.
> 
>> Moreover, the shell compositor often has the best knowledge of the
>> link between surface/window and their owner application. Specific
>> clients (like the global-menu) might be interested in this data,
>> avoiding convoluted ways to do the matching. a get_app_id request in
>> xdg shell could prove useful there.
>> 
>> What do you think?
> 
> Some projects like GNOME make the compositor responsible for drawing
> desktop UI elements like a global menu. This has the upside of being
> easy to implement, but has also some downsides: for instance the
> compositor is responsible for drawing complex UI elements, which slows
> down composition and makes it more likely to crash.
> 
> If you cannot or don't want to do it this way, other compositors
> (e.g. Weston, KDE as far as I've understood, and many wlroots
> compositors) typically use a dedicated protocol for privileged clients.
> In the case of KWin, the existing KDE-specific Wayland protocols are
> here:
> https://github.com/KDE/kwayland/tree/master/src/client/protocols
> 
> It's worth noting that as of now, only Weston restricts access to
> privileged protocols to a limited set of clients. In other compositors,
> these protocols are exposed to all clients (and this has security
> implications).
> 
> Regarding this specific use-case, wlroots has standardized a protocol
> for listing and managing toplevels:
> https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-foreign-toplevel-management-unstable-v1.xml
> 

Are there any examples of server-side implementations of 
plasma-window-management.xml on libweston? Alternatively, are there any plain C 
implementations of the same without all the KDE/Qt stuff?

What would a basic boilerplate implementation of plasma-window-management look 
like on libweston?

Regards

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

Re: (No Subject)

[Simon Ser]

Hi,

On Saturday, May 25, 2019 4:23 PM, Alexandre Mazari  wrote:
> Greetings wayland-devel,
>
> I am currently looking at ways to abstract Xisms in Plasma
> global-menu daemon and applet and provide a Wayland implementation.
>
> X11/xcb is currently used there to set and obtain to/from the
> *active* window some metadata (atoms) relative to the DBus address of
> the application menu provider.
>
> A wayland implementation [0] should first be able to track the active
> window.
> AFAIK, none of the current protocols provides such mechanism.
> I wonder whether that is by design to avoid some info leakage or
> would an activeSurface/activeWindow method/signal couple make sense
> in xdg-shell or xdg_surface?

Yes, this is by design. Regular clients don't have any way to list
other clients' toplevels or to manage them, unlike on X11.

I don't think it would make sense to add such a request/event to
xdg-shell, because this is out-of-scope for xdg-shell.

> Moreover, the shell compositor often has the best knowledge of the
> link between surface/window and their owner application. Specific
> clients (like the global-menu) might be interested in this data,
> avoiding convoluted ways to do the matching. a get_app_id request in
> xdg shell could prove useful there.
>
> What do you think?

Some projects like GNOME make the compositor responsible for drawing
desktop UI elements like a global menu. This has the upside of being
easy to implement, but has also some downsides: for instance the
compositor is responsible for drawing complex UI elements, which slows
down composition and makes it more likely to crash.

If you cannot or don't want to do it this way, other compositors
(e.g. Weston, KDE as far as I've understood, and many wlroots
compositors) typically use a dedicated protocol for privileged clients.
In the case of KWin, the existing KDE-specific Wayland protocols are
here:
https://github.com/KDE/kwayland/tree/master/src/client/protocols

It's worth noting that as of now, only Weston restricts access to
privileged protocols to a limited set of clients. In other compositors,
these protocols are exposed to all clients (and this has security
implications).

Regarding this specific use-case, wlroots has standardized a protocol
for listing and managing toplevels:
https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-foreign-toplevel-management-unstable-v1.xml

Hope this helps,

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

[no subject]

[Alexandre Mazari]

Greetings wayland-devel,

I am currently looking at ways to abstract Xisms in Plasma global-menu
daemon and applet and provide a Wayland implementation.

X11/xcb is currently used there to set and obtain to/from the *active*
window some metadata (atoms) relative to the DBus address of the
application menu provider.

A wayland implementation [0] should first be able to track the active
window.
AFAIK, none of the current protocols provides such mechanism.
I wonder whether that is by design to avoid some info leakage or
would an activeSurface/activeWindow method/signal couple make sense in
xdg-shell or xdg_surface?

Moreover, the shell compositor often has the best knowledge of the link
between surface/window and their owner application. Specific clients (like
the global-menu) might be interested in this data, avoiding convoluted ways
to do the matching. a get_app_id request in xdg shell could prove useful
there.

What do you think?

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

[no subject]

[scott . anderson]

Hi,

I've come to realise that it's become a bit of a fool's errand to try
and put all of the information related to content security into a single
protocol and have the interface be general yet sane, so I've instead
redesigned this to be general core which can be extended by other protocols.

This takes heavy inspiration from wl_surface "roles" and copies a lot of
the language of that. So each security interface will now have an
"implementation" which currently could be HDCP, the "I don't care" one,
or whatever one that someone decides to extend this with in the future.

The HDCP protocol is basically copied from [1], but I don't really know
a lot of the details of HDCP and it would currently rely on kernel
interfaces not upstream. This protocol is only really here to show what
it could look like.

I also have a basic proof-of-concept implementation of the first
protocol here [2].

Scott

[1] 
https://gitlab.freedesktop.org/wayland/weston/blob/5700409c4da6512cfdc6ffc0e644853273b455f3/protocol/content-protection.xml
[2] https://gitlab.freedesktop.org/ascent/weston/tree/secure-output

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

[no subject]

[cmailings]

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

[no subject]

[Jiayi Zhao]

This latest patch (v4) adds documentation for the new natural_scoll
option in weston.ini via the weston.ini.man man page.

Signed-off-by: Jiayi Zhao 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[no subject]

[Sung-jae Park]

ㅣ

⁣--- 
What You Think Is What You Get. 
Software will make your dream come true. 
Welcome, http://nicesj.com 
--- ​___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[no subject]

[nerdopolis]

I had to resend, because in the first patch I sent I accidentally removed an 
empty line
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 9/9] doc: Removed \ref when it refers to the subject the text is attached to

[Bill Spitzak]

This does not make a difference to doxygen output but may help other
document generators not make redundant links.
---
 src/wayland-client.c |2 +-
 src/wayland-client.h |   10 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/wayland-client.c b/src/wayland-client.c
index 16df207..9172f7c 100644
--- a/src/wayland-client.c
+++ b/src/wayland-client.c
@@ -1537,7 +1537,7 @@ wl_display_dispatch(struct wl_display *display)
  * to dispatch.
  *
  * To proper integrate the wayland display fd into a main loop, the
- * client should always call \ref wl_display_dispatch_pending() and then
+ * client should always call wl_display_dispatch_pending() and then
  * \ref wl_display_flush() prior to going back to sleep. At that point,
  * the fd typically doesn't have data so attempting I/O could block, but
  * events queued up on the main queue should be dispatched.
diff --git a/src/wayland-client.h b/src/wayland-client.h
index 0801a81..dd42d7b 100644
--- a/src/wayland-client.h
+++ b/src/wayland-client.h
@@ -41,7 +41,7 @@ extern C {
  * turn call the handler set with \ref wl_proxy_add_listener().
  *
  * \note With the exception of function \ref wl_proxy_set_queue(), functions
- * accessing a \ref wl_proxy are not normally used by client code. Clients
+ * accessing a wl_proxy are not normally used by client code. Clients
  * should normally use the higher level interface generated by the scanner to
  * interact with compositor objects.
  *
@@ -53,15 +53,15 @@ struct wl_proxy;
  * \brief Represents a connection to the compositor and acts as a proxy to
  * the wl_display singleton object.
  *
- * A \ref wl_display object represents a client connection to a Wayland
+ * A wl_display object represents a client connection to a Wayland
  * compositor. It is created with either \ref wl_display_connect() or
  * \ref wl_display_connect_to_fd(). A connection is terminated using
  * \ref wl_display_disconnect().
  *
- * A \ref wl_display is also used as the \ref wl_proxy for the \ref wl_display
+ * A wl_display is also used as the \ref wl_proxy for the wl_display
  * singleton object on the compositor side.
  *
- * A \ref wl_display object handles all the data sent from and to the
+ * A wl_display object handles all the data sent from and to the
  * compositor. When a \ref wl_proxy marshals a request, it will write its wire
  * representation to the display's write buffer. The data is sent to the
  * compositor when the client calls \ref wl_display_flush().
@@ -71,7 +71,7 @@ struct wl_proxy;
  * added to a queue. On the dispatch step, the handler for the incoming
  * event set by the client on the corresponding \ref wl_proxy is called.
  *
- * A \ref wl_display has at least one event queue, called the emmain
+ * A wl_display has at least one event queue, called the emmain
  * queue/em. Clients can create additional event queues with \ref
  * wl_display_create_queue() and assign \ref wl_proxy's to it. Events
  * occurring in a particular proxy are always queued in its assigned queue.
-- 
1.7.9.5

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

[no subject]

[spitzak]

Second version of the patch. This one removes cairo-gl instructions and
has some typos fixed. Box added to the pre tag in the css file.

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

[no subject]

[Quentin Glidic]

This patch series introduce the notification_daemon interface.
It is intended to be the standard Weston interface that all non-DE (and
probably Weston-based) compositors will have to support.

The current supported layouts are limited to the “bubbles list”, which
is the most common one. Other layout will be supported in the future.

The implementation is done as a separate module, making the feature
available to all Weston-based compositors directly.

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

[no subject]

[Rob Bradford]

This patch should be squashed with Move matrix.[ch] to shared

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

Subject: [PATCH] Fall back to accept() on systems where accept4() is not implemented.

[Samuel Rødal]

 From 1ee0fe1e9c30890a2c2e8b997295f74754e63a2b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Samuel=20R=C3=B8dal?= samuel.ro...@nokia.com
Date: Mon, 30 May 2011 17:23:40 +0200
Subject: [PATCH] Fall back to accept() on systems where accept4() is not implemented.

---
 wayland/wayland-server.c |8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/wayland/wayland-server.c b/wayland/wayland-server.c
index d30df5b..886ec69 100644
--- a/wayland/wayland-server.c
+++ b/wayland/wayland-server.c
@@ -703,8 +703,14 @@ socket_data(int fd, uint32_t mask, void *data)
 	length = sizeof name;
 	client_fd =
 		accept4(fd, (struct sockaddr *) name, length, SOCK_CLOEXEC);
+	if (client_fd  0  errno == ENOSYS) {
+		client_fd = accept(fd, (struct sockaddr *) name, length);
+		if (client_fd = 0  fcntl(client_fd, F_SETFD, FD_CLOEXEC) == -1)
+			fprintf(stderr, failed to set FD_CLOEXEC flag on client fd, errno: %d\n, errno);
+	}
+
 	if (client_fd  0)
-		fprintf(stderr, failed to accept\n);
+		fprintf(stderr, failed to accept, errno: %d\n, errno);
 
 	wl_client_create(display, client_fd);
 
-- 
1.7.1

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

[no subject]

[maltee]

First of all, especially after reading through the mailing list for a bit,
I think Wayland is an amazing project and I want to thank everyone
contributing to it! Keep up the great work!

I used to be against Client Side Decorations, but after reading through
the mailing list, I'm starting to think this might actually be the way to
go. But one (imho important) question remains unanswered: How are we going
to maintain uniformity amongst decorations? My concern is rather the feel,
than the look. Application windows look different anyway, but with X, all
titlebars (with very few exceptions, such as chromium) look and behave
roughly the same. Button orders of applications being different would have
a huge impact on usability, even button sizes and exact positions is
something to worry about. On a GTK+ based Desktop you probably want GTK+
based window decorations. Qt applications will probably integrate the look
and feel, so this won't be a problem. But what about applications that
don't use a specific toolkit, such as games or X for wayland? I see no
way, those would actually start using one of the major toolkits instead
(which would be a very bad idea). Should everyone start implementing their
own decorations, resulting in a decoration chaos? We definitely need some
standard.
Mac OS X and Windows don't have this problem because they each have a
default toolkit most of the other available toolkits try to wrap/emulate.
On Linux we have to deal with the advantages and disadvantages of variety
with no standard. Inconsistency of decorations is nothing we should take
for inevitable.

Unfortunatly, I don't understand much of the subject, I might be talking
rubbish, so please bear with me: My general idea is to define some sort of
plugin API for decorations. Toolkits/Applications can provide their own
decoration plugin which is used unless overridden and would integrate well
with the application window. There might be a very simple default
decoration provided by wayland. Applications can allow to replace their
own decoration with something else (or test the desktops default for
functionality and decide whether they want to use their own or not).
Decorations can interact with Applications on ABI basis rather than
protocol basis.
+ Decorations would integrate well with application windows for the
majority of applications on the desktop
+ All decorations will have the same lookfeel (with few exceptions)
+ Applications that do not use a specific toolkit would not have to
implement their own decorations
+ Applications that want to do something fancy, like tabs (chromium) in
the decoration can do so by extending the toolkit's decoration plugin so
they will have something that looks similar to many other applications and
they don't need to reinvent the wheel.
+ People who want something special can write their own decorations, just
like people write their own window managers now.

Maybe Client Side Decorations are the way to go, but not before the
consistency issue is solved!

Regards,
Malte E.


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

[no subject]

[Jonas -]

Will wayland support Hybritgpu ? gpu on board or apu and for games pcie?
  ___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel