[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]

[Anna Paige Sanders]

Hello

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

[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

[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

[no subject]

[Scott Moreau]

These patches are rebased on top of current master.
___
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 look&feel (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

[no subject]

[Jonas -]

Hi,

 I have a question about the design of wayland

 will it be possible to run the server wayland on an apu and if  the resource 
are not enough to turn a pci gpu on if you need more resources? 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[no subject]

[princezhou]

hello:
   every one!

2011-04-06 



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

[no subject]

[hyro5239]

Hi, all.

This is tista.
Just now I joined and may I talk about "Using Wayland on GMA500/Poulsbo" ?

I'm a Sony VAIO P (VPCP11AKJ) user, unfortunately GMA500/Poulsbo employed. 
also a Member of GMA500 team in Ubuntu PPA: https://launchpad.net/~tista 
Then I'm testing Natty (Ubuntu 11.04) alpha-1 and Intel's EMGD ver.1.5 driver 
and I often had reported results to the topic of ubuntu forum:
http://ubuntuforums.org/showthread.php?t=1229345

Hopefully Xorg-edgers team had opened PPA of Wayland testing use:
https://launchpad.net/~xorg-edgers/+archive/wayland
(I think those packages  were not so much new compared with your git branch, but
easy to test for me.)
I'm also testing them on VAIO P. yeah very experimental...

Please let me know the possibility about "Using Wayland on GMA500/Poulsbo".
And if you have any ideas, tell me and I want to try anything !!

- Today's some details of mine. -
dmesg --> http://paste.ubuntu.com/548827/
lshw --> http://paste.ubuntu.com/548828/
xorg.conf --> http://paste.ubuntu.com/548830/
Xorg.0.log --> http://paste.ubuntu.com/548835/
.xsession-errors --> http://paste.ubuntu.com/548831/ (Sorry for mixing with
Japanese...)
grub.cfg --> http://paste.ubuntu.com/548832/ (my default Natty is lines 205-212)
glxinfo --> http://paste.ubuntu.com/548834/
wayland errors --> http://paste.ubuntu.com/548833/
--

Best Regards.

tista


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