Re: Wayland talk at FOSDEM

[Pekka Paalanen]

On Wed, 10 Jan 2018 14:41:46 +0100
Philipp Kerling  wrote:

> Hey Pekka,
> 
> thanks for your input - further comments below. The talk has been
> accepted, but shortened to 25 min due to the amount of talks that had
> been submitted overall. This means that I will have significantly less
> time than I thought and most of the advanced stuff will have to go I'm
> afraid, but I'll still try to give a comprehensive overview within the
> timeframe I'm given.
> 
> 2017-12-08 (金) の 10:39 +0200 に Pekka Paalanen さんは書きました:
> > On Thu, 07 Dec 2017 23:56:49 +0200
> > Philipp Kerling  wrote:
> >   
> > > Hi Pekka,
> > > 
> > > 2017-12-07 (木) の 09:56 +0200 に Pekka Paalanen さんは書きました:  
> > > > On Tue, 05 Dec 2017 16:46:41 +0200
> > > > Philipp Kerling  wrote:
> > > > 
> > > > > Hey everyone,
> > > > > 
> > > > > I've been thinking about submitting a Wayland-themed talk to
> > > > > the
> > > > > FOSDEM
> > > > > graphics devroom [1] and wanted to check with the community if
> > > > > anyone
> > > > > else has considered this or another Wayland topic and whether
> > > > > you
> > > > > think
> > > > > it would be a good idea™.
> > > > > 
> > > > > What I would want to talk about is a beginner's introduction to
> > > > > Wayland
> > > > > from the client perspective. I think that resources on this
> > > > > (and on
> > > > > Wayland in general to be honest) are quite scarce and that I
> > > > > could
> > > > > pass
> > > > > on some of the knowledge I have gained by implementing native
> > > > > Wayland
> > > > > support in Kodi this way.
> > > > 
> > > > Hi,
> > > > 
> > > > that sounds like a good idea.


> > > > > * Difference between core and extension protocols

Maybe there is actually not so much a difference to emphasize but more
of what programs tend to require.

> > > > 
> > > > This is a bit hazy to me as well, depending on at what level you
> > > > are
> > > > looking to use Wayland. Only wl_display, wl_registry and
> > > > wl_callback
> > > > interfaces are not extensions, strictly speaking. What extensions
> > > > are
> > > > mandatory depends on the target environment. Technically, e.g.
> > > > wl_compositor is an extension and not mandatory, but it's hard to
> > > > find
> > > > a use case without it.
> > > 
> > > I'd have argued that the wayland.xml shipped with wayland is the
> > > "core"
> > > protocol and wayland-protocols + all other stuff are "extensions."
> > > Is
> > > that a reasonable assumption or should I be more careful about the
> > > wording here? In any case, I guess it makes sense to mention that
> > > Wayland is not only built for traditional desktop environments,
> > > even if
> > > that is what I'll be focusing on in the talk.  
> > 
> > The split is not so clear. The most obvious example of the contrary
> > is
> > wl_shell extension which is in wayland.xml, but is not considered
> > "core". E.g. IVI environment using Wayland does not use it.  
> I think I've raised this point in #wayland before, but part of the
> problem seems to be that wayland.xml does not explicitly spell out (in
> most cases) what is considered "core" at the moment and what not. You
> can sort of infer it from the description, but it's not very clear imo.
> As you said though, protocols depend heavily on the environment Wayland
> is used in. What do you in general think about making a recommendation
> such as "All compositors MUST implement wl_compositor, wl_shm, etc.
> Desktop compositors SHOULD additionally implement this and that."? That
> would at least give client apps some information on what they can
> expect to be there.

Rather than giving "must" and "should" lists, maybe it'd be better to
list what most common toolkits expect: what do you need to get a GTK+3
app up, for example.

> > wl_shell is a "shell extension", which is a category of Wayland
> > extensions. With Wayland core protocol and wl_compositor, you cannot
> > actually show a window. A shell extension is necessary to tell the
> > compositor what it should do with a wl_surface, i.e. assign the
> > wl_surface a role. Wayland.xml does have some interfaces which can be
> > considered core and assign surface roles, but they are not enough to
> > have a working application. An example of such role is the pointer
> > cursor.
> > 
> > The other global interfaces (advertised through wl_registry) in
> > wayland.xml are quite "core" I think, but it's not unthinkable to
> > imagine to replace them in the future, should the need arise.
> > 
> > That is actually a design feature of Wayland: (almost) everything is
> > an
> > extension. As a corollary, everything can be deprecated and replaced
> > with something else if really necessary, forming a new "core". The
> > old
> > stuff can eventually be dropped completely, except for the interfaces
> > that exist without having to find them in wl_registry.
> > 
> > For instance, wl_output could be replaced with something better, but

Re: Wayland talk at FOSDEM

[Pekka Paalanen]

On Thu, 07 Dec 2017 23:56:49 +0200
Philipp Kerling  wrote:

> Hi Pekka,
> 
> 2017-12-07 (木) の 09:56 +0200 に Pekka Paalanen さんは書きました:
> > On Tue, 05 Dec 2017 16:46:41 +0200
> > Philipp Kerling  wrote:
> >   
> > > Hey everyone,
> > > 
> > > I've been thinking about submitting a Wayland-themed talk to the
> > > FOSDEM
> > > graphics devroom [1] and wanted to check with the community if
> > > anyone
> > > else has considered this or another Wayland topic and whether you
> > > think
> > > it would be a good idea™.
> > > 
> > > What I would want to talk about is a beginner's introduction to
> > > Wayland
> > > from the client perspective. I think that resources on this (and on
> > > Wayland in general to be honest) are quite scarce and that I could
> > > pass
> > > on some of the knowledge I have gained by implementing native
> > > Wayland
> > > support in Kodi this way.  
> > 
> > Hi,
> > 
> > that sounds like a good idea.  
> Thanks!
> 
> >   
> > > This would include stuff such as:
> > >  * Wayland architecture
> > > * Comparison with X
> > > * Security architecture
> > > * Limitations: What is not possible with Wayland (currently)  
> > 
> > Please underline that many things are wanted and the only reason they
> > are not there yet is because they have not been worked on enough to
> > produce a Waylandish solution and reach a concensus, not because they
> > are somehow "banned". :-)  
> Good point since you hear from time to time that Wayland "forbids"
> this-and-that and therefore is evil ... I'll definitely keep it in
> mind. Even so, I guess it is a quite safe bet to e.g. say that
> accessing the buffer contents of all other applications without any
> user authentication will not be a feature of mainstream Wayland
> compositors anytime soon.

Hi Philipp

Yes. There are some more or less banned things, but I would tend to
think that they are a minority in numbers. "Without user permission" is
the main problem for most of the popular features that are not yet
standardised - the features are good, necessary and supportable, but
the main issue is how to expose them without compromising security and
without annoying users or asking users questions they cannot reliably
answer.

I believe it is actually quite likely that the solution to the
authentication problem is mostly outside of the scope of Wayland
protocol, but we would still need a working example in some environment
to be able to comfortably promote "privileged interfaces".

> > In some cases, the Waylandish solution to produce an end-user feature
> > may be very different from what has traditionally been done. In some
> > other cases, a solution might be better or already exist outside of
> > Wayland.  
> Yes, the problem lies mostly in the expectation that things will work
> just like they did with X.
> 
> >   
> > > * Difference between core and extension protocols  
> > 
> > This is a bit hazy to me as well, depending on at what level you are
> > looking to use Wayland. Only wl_display, wl_registry and wl_callback
> > interfaces are not extensions, strictly speaking. What extensions are
> > mandatory depends on the target environment. Technically, e.g.
> > wl_compositor is an extension and not mandatory, but it's hard to
> > find
> > a use case without it.  
> I'd have argued that the wayland.xml shipped with wayland is the "core"
> protocol and wayland-protocols + all other stuff are "extensions." Is
> that a reasonable assumption or should I be more careful about the
> wording here? In any case, I guess it makes sense to mention that
> Wayland is not only built for traditional desktop environments, even if
> that is what I'll be focusing on in the talk.

The split is not so clear. The most obvious example of the contrary is
wl_shell extension which is in wayland.xml, but is not considered
"core". E.g. IVI environment using Wayland does not use it.

wl_shell is a "shell extension", which is a category of Wayland
extensions. With Wayland core protocol and wl_compositor, you cannot
actually show a window. A shell extension is necessary to tell the
compositor what it should do with a wl_surface, i.e. assign the
wl_surface a role. Wayland.xml does have some interfaces which can be
considered core and assign surface roles, but they are not enough to
have a working application. An example of such role is the pointer
cursor.

The other global interfaces (advertised through wl_registry) in
wayland.xml are quite "core" I think, but it's not unthinkable to
imagine to replace them in the future, should the need arise.

That is actually a design feature of Wayland: (almost) everything is an
extension. As a corollary, everything can be deprecated and replaced
with something else if really necessary, forming a new "core". The old
stuff can eventually be dropped completely, except for the interfaces
that exist without having to find them in wl_registry.

For instance, wl_output could be replaced with 

Re: Wayland talk at FOSDEM

[Silvan Jegen]

On Thu, Dec 7, 2017 at 10:32 PM, Philipp Kerling  wrote:
> Hi,
>
> 2017-12-06 (水) の 08:56 +0100 に Silvan Jegen さんは書きました:
>> I see that you left out the text-input/input-method protocols in your
>> topics. Is it because those are unstable or because you don't
>> consider
>> them to be important enough?
> I just hadn't seen them in practice yet personally, to be honest.
> Having taken a closer look, I think it would be best to focus on
> protocols that have or are expected to have good cross-compositor
> support and are useful for general-purpose desktop applications. Is

Yeah, that makes sense.


> text-input implemented in a mainstream compositor besides weston?

IIRC, Gnome doesn't use it but uses dbus for communication with the
IME and KDE implemented their own new version of the text-input
protocol. I don't know about Sway though. Apparently the current
version of the text-input/input-method protocols have some
shortcomings and that's why they are not being used.

The new KDE version of the text-input protocol was posted on this
mailing list early last year but their revisions have not made it into
a new official unstable protocol yet. I am just wondering if there is
a chicken and egg problem here with noone using the protocol because
it doesn't suit their needs and then people not caring about it since
noone is using it...


Cheers,

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

Re: Wayland talk at FOSDEM

[Philipp Kerling]

Hi Pekka,

2017-12-07 (木) の 09:56 +0200 に Pekka Paalanen さんは書きました:
> On Tue, 05 Dec 2017 16:46:41 +0200
> Philipp Kerling  wrote:
> 
> > Hey everyone,
> > 
> > I've been thinking about submitting a Wayland-themed talk to the
> > FOSDEM
> > graphics devroom [1] and wanted to check with the community if
> > anyone
> > else has considered this or another Wayland topic and whether you
> > think
> > it would be a good idea™.
> > 
> > What I would want to talk about is a beginner's introduction to
> > Wayland
> > from the client perspective. I think that resources on this (and on
> > Wayland in general to be honest) are quite scarce and that I could
> > pass
> > on some of the knowledge I have gained by implementing native
> > Wayland
> > support in Kodi this way.
> 
> Hi,
> 
> that sounds like a good idea.
Thanks!

> 
> > This would include stuff such as:
> >  * Wayland architecture
> > * Comparison with X
> > * Security architecture
> > * Limitations: What is not possible with Wayland (currently)
> 
> Please underline that many things are wanted and the only reason they
> are not there yet is because they have not been worked on enough to
> produce a Waylandish solution and reach a concensus, not because they
> are somehow "banned". :-)
Good point since you hear from time to time that Wayland "forbids"
this-and-that and therefore is evil ... I'll definitely keep it in
mind. Even so, I guess it is a quite safe bet to e.g. say that
accessing the buffer contents of all other applications without any
user authentication will not be a feature of mainstream Wayland
compositors anytime soon.

> In some cases, the Waylandish solution to produce an end-user feature
> may be very different from what has traditionally been done. In some
> other cases, a solution might be better or already exist outside of
> Wayland.
Yes, the problem lies mostly in the expectation that things will work
just like they did with X.

> 
> > * Difference between core and extension protocols
> 
> This is a bit hazy to me as well, depending on at what level you are
> looking to use Wayland. Only wl_display, wl_registry and wl_callback
> interfaces are not extensions, strictly speaking. What extensions are
> mandatory depends on the target environment. Technically, e.g.
> wl_compositor is an extension and not mandatory, but it's hard to
> find
> a use case without it.
I'd have argued that the wayland.xml shipped with wayland is the "core"
protocol and wayland-protocols + all other stuff are "extensions." Is
that a reasonable assumption or should I be more careful about the
wording here? In any case, I guess it makes sense to mention that
Wayland is not only built for traditional desktop environments, even if
that is what I'll be focusing on in the talk.

> So it kind of depends on your definition of "Wayland". Purely IPC? A
> graphical output protocol? A windowing protocol with input? A desktop
> window system protocol?
> 
> Maybe giving a definition for "Wayland" would be a good way to start?
Is there an officially accepted one? :-)
My personal stance would be: Windowing protocol definition + ecosystem
(C libraries, scanner, extension protocols that among other things
cover the traditional desktop use case)

> > * Global registry
> > * Relevant documentation and resources
> >  * Why you should not be writing a Wayland client yourself (aka use
> >toolkits if possible)
> 
> +1
> 
> >  * Relevant compositors to test on and how to use nested mode
> >  * Basic client programming
> > * Protocols needed to get a surface on screen (wl_compositor,
> >   wl_surface, wl_shm, wl_shm_pool, wl_shell, wl_shell_surface)
> 
> Mind that wl_shell is finally officially deprecated with the
> stabilization of xdg-shell.
I'm not sure how to handle that yet. Technically, it would make sense
to directly introduce xdg-shell and skip the wl_shell details. But
realistically speaking it will still take some time until there is
sufficient compositor support and you can get by with an application
that does not support anything but the xdg_wm_base global.
One alternative could be to introduce xdg-shell unstable v6 instead of
wl_shell and tell people to switch to xdg-shell stable at some point?
I'm not sure the latest KDE stable release supports xdg-shell unstable
v6 though. Last time I checked KDE only had v5 in stable.

> > * Seats and input
> >* Keyboard: wl_keyboard and libxkbcommon
> >* Mouse: wl_pointer and libwayland-cursor for cursor
> > handling
> > * xdg_wm_base
> > * Window decorations
> > * EGL
> > 
> > Possible extensions/replacement topics:
> >  * Bindings (just mention: C++, D, Java, Rust)
> >  * Vulkan (I think EGL is more relevant at the moment)
> >  * Some more extension protocols such as pointer-constraints and
> >relative-pointer (relevant e.g. for games)
> >  * Subcompositing
> >  * ...
> > 
> > I would not include:
> >  * Details of libwayland API (e.g. proxy 

Re: Wayland talk at FOSDEM

[Philipp Kerling]

Hi,

2017-12-06 (水) の 08:56 +0100 に Silvan Jegen さんは書きました:
> Hi
> 
> On Tue, Dec 5, 2017 at 3:46 PM, Philipp Kerling 
> wrote:
> > I've been thinking about submitting a Wayland-themed talk to the
> > FOSDEM
> > graphics devroom [1] and wanted to check with the community if
> > anyone
> > else has considered this or another Wayland topic and whether you
> > think
> > it would be a good idea™.
> > 
> > What I would want to talk about is a beginner's introduction to
> > Wayland
> > from the client perspective. I think that resources on this (and on
> > Wayland in general to be honest) are quite scarce and that I could
> > pass
> > on some of the knowledge I have gained by implementing native
> > Wayland
> > support in Kodi this way.
> > 
> > This would include stuff such as:
> >  * Wayland architecture
> > * Comparison with X
> > * Security architecture
> > * Limitations: What is not possible with Wayland (currently)
> > * Difference between core and extension protocols
> > * Global registry
> > * Relevant documentation and resources
> >  * Why you should not be writing a Wayland client yourself (aka use
> >toolkits if possible)
> >  * Relevant compositors to test on and how to use nested mode
> >  * Basic client programming
> > * Protocols needed to get a surface on screen (wl_compositor,
> >   wl_surface, wl_shm, wl_shm_pool, wl_shell, wl_shell_surface)
> > * Seats and input
> >* Keyboard: wl_keyboard and libxkbcommon
> >* Mouse: wl_pointer and libwayland-cursor for cursor
> > handling
> > * xdg_wm_base
> > * Window decorations
> > * EGL
> 
> I would be very interested in an overview like that and think it's a
> very good idea™ indeed!
Thanks! I've submitted the abstract, let's see if I get a slot.

> I see that you left out the text-input/input-method protocols in your
> topics. Is it because those are unstable or because you don't
> consider
> them to be important enough?
I just hadn't seen them in practice yet personally, to be honest.
Having taken a closer look, I think it would be best to focus on
protocols that have or are expected to have good cross-compositor
support and are useful for general-purpose desktop applications. Is
text-input implemented in a mainstream compositor besides weston?

Regards,
Philipp

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

Re: Wayland talk at FOSDEM

[Philipp Kerling]

Hello Eugen,

2017-12-05 (火) の 22:08 +0100 に Eugen Friedrich さんは書きました:
> Hello Philipp,
> 
> I also thinking give a talk about the usage of weston in ivi systems,
> this should give an overview what is the main difference to the
> desktop environment and why the ivi-shell is used. Also I would like
> to give short overview about the recent activities in ivi-shell and
> usage of waltham.
Nice, I'll be looking forward to that. I always wanted to know more
about how Wayland is actually being used for IVI.

> 2017-12-05 15:46 GMT+01:00 Philipp Kerling :
> > 
> > Hey everyone,
> > 
> > I've been thinking about submitting a Wayland-themed talk to the
> > FOSDEM
> > graphics devroom [1] and wanted to check with the community if
> > anyone
> > else has considered this or another Wayland topic and whether you
> > think
> > it would be a good idea™.
> > 
> > What I would want to talk about is a beginner's introduction to
> > Wayland
> > from the client perspective. I think that resources on this (and on
> > Wayland in general to be honest) are quite scarce and that I could
> > pass
> > on some of the knowledge I have gained by implementing native
> > Wayland
> > support in Kodi this way.
> > 
> > This would include stuff such as:
> >  * Wayland architecture
> > * Comparison with X
> > * Security architecture
> > * Limitations: What is not possible with Wayland (currently)
> > * Difference between core and extension protocols
> > * Global registry
> > * Relevant documentation and resources
> >  * Why you should not be writing a Wayland client yourself (aka use
> >toolkits if possible)
> >  * Relevant compositors to test on and how to use nested mode
> >  * Basic client programming
> > * Protocols needed to get a surface on screen (wl_compositor,
> >   wl_surface, wl_shm, wl_shm_pool, wl_shell, wl_shell_surface)
> > * Seats and input
> >* Keyboard: wl_keyboard and libxkbcommon
> >* Mouse: wl_pointer and libwayland-cursor for cursor
> > handling
> > * xdg_wm_base
> > * Window decorations
> > * EGL
> > 
> > Possible extensions/replacement topics:
> >  * Bindings (just mention: C++, D, Java, Rust)
> >  * Vulkan (I think EGL is more relevant at the moment)
> >  * Some more extension protocols such as pointer-constraints and
> >relative-pointer (relevant e.g. for games)
> >  * Subcompositing
> >  * ...
> 
> just as idea: there are a few patch series which are pending for a
> very long time,
> one of the famous one is the atomic mode setting patch series from
> Daniel :-)
> maybe it would be interesting to give a short overview of the "cool"
> pending feature
> on the list which people can expect in next or over next release.
I thought that I'd just introduce the common/important compositors
(weston, mutter, KWin, sway maybe?) briefly. But I'll have to say a few
words about weston in particular anyway since it is the reference
compositor, so it could very well fit there.

Regards,
Philipp

> > 
> > I would not include:
> >  * Details of libwayland API (e.g. proxy wrappers)
> >  * Every extension protocol or even core protocol object just for
> >completeness
> >  * Historical baggage such as xdg_shell v5
> >  * EGL/Mesa internals
> > 
> > I'd love to hear any comments/suggestions you might have and
> > generally
> > what kind of topics people would be interested in.
> > 
> > [1] https://lists.freedesktop.org/archives/wayland-devel/2017-Novem
> > ber/035880.html
> > 
> > Regards,
> > Philipp
> > ___
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Wayland talk at FOSDEM

[Pekka Paalanen]

On Tue, 05 Dec 2017 16:46:41 +0200
Philipp Kerling  wrote:

> Hey everyone,
> 
> I've been thinking about submitting a Wayland-themed talk to the FOSDEM
> graphics devroom [1] and wanted to check with the community if anyone
> else has considered this or another Wayland topic and whether you think
> it would be a good idea™.
> 
> What I would want to talk about is a beginner's introduction to Wayland
> from the client perspective. I think that resources on this (and on
> Wayland in general to be honest) are quite scarce and that I could pass
> on some of the knowledge I have gained by implementing native Wayland
> support in Kodi this way.

Hi,

that sounds like a good idea.

> This would include stuff such as:
>  * Wayland architecture
> * Comparison with X
> * Security architecture
> * Limitations: What is not possible with Wayland (currently)

Please underline that many things are wanted and the only reason they
are not there yet is because they have not been worked on enough to
produce a Waylandish solution and reach a concensus, not because they
are somehow "banned". :-)

In some cases, the Waylandish solution to produce an end-user feature
may be very different from what has traditionally been done. In some
other cases, a solution might be better or already exist outside of
Wayland.

> * Difference between core and extension protocols

This is a bit hazy to me as well, depending on at what level you are
looking to use Wayland. Only wl_display, wl_registry and wl_callback
interfaces are not extensions, strictly speaking. What extensions are
mandatory depends on the target environment. Technically, e.g.
wl_compositor is an extension and not mandatory, but it's hard to find
a use case without it.

So it kind of depends on your definition of "Wayland". Purely IPC? A
graphical output protocol? A windowing protocol with input? A desktop
window system protocol?

Maybe giving a definition for "Wayland" would be a good way to start?

> * Global registry
> * Relevant documentation and resources
>  * Why you should not be writing a Wayland client yourself (aka use
>toolkits if possible)

+1

>  * Relevant compositors to test on and how to use nested mode
>  * Basic client programming
> * Protocols needed to get a surface on screen (wl_compositor,
>   wl_surface, wl_shm, wl_shm_pool, wl_shell, wl_shell_surface)

Mind that wl_shell is finally officially deprecated with the
stabilization of xdg-shell.

> * Seats and input
>* Keyboard: wl_keyboard and libxkbcommon
>* Mouse: wl_pointer and libwayland-cursor for cursor handling
> * xdg_wm_base
> * Window decorations
> * EGL
> 
> Possible extensions/replacement topics:
>  * Bindings (just mention: C++, D, Java, Rust)
>  * Vulkan (I think EGL is more relevant at the moment)
>  * Some more extension protocols such as pointer-constraints and
>relative-pointer (relevant e.g. for games)
>  * Subcompositing
>  * ...
> 
> I would not include:
>  * Details of libwayland API (e.g. proxy wrappers)

I suppose one detail might be worth mentioning: client projects are
expected to run wayland-scanner (or equivalent) as part of their
builds. The only exception are the interfaces in wayland.xml, but
it may be a surprise to realize that wayland.xml is the exception, not
the rule.

>  * Every extension protocol or even core protocol object just for
>completeness
>  * Historical baggage such as xdg_shell v5
>  * EGL/Mesa internals
> 
> I'd love to hear any comments/suggestions you might have and generally
> what kind of topics people would be interested in.
> 
> [1] 
> https://lists.freedesktop.org/archives/wayland-devel/2017-November/035880.html


Thanks,
pq


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

Re: Wayland talk at FOSDEM

[Silvan Jegen]

Hi

On Tue, Dec 5, 2017 at 3:46 PM, Philipp Kerling  wrote:
> I've been thinking about submitting a Wayland-themed talk to the FOSDEM
> graphics devroom [1] and wanted to check with the community if anyone
> else has considered this or another Wayland topic and whether you think
> it would be a good idea™.
>
> What I would want to talk about is a beginner's introduction to Wayland
> from the client perspective. I think that resources on this (and on
> Wayland in general to be honest) are quite scarce and that I could pass
> on some of the knowledge I have gained by implementing native Wayland
> support in Kodi this way.
>
> This would include stuff such as:
>  * Wayland architecture
> * Comparison with X
> * Security architecture
> * Limitations: What is not possible with Wayland (currently)
> * Difference between core and extension protocols
> * Global registry
> * Relevant documentation and resources
>  * Why you should not be writing a Wayland client yourself (aka use
>toolkits if possible)
>  * Relevant compositors to test on and how to use nested mode
>  * Basic client programming
> * Protocols needed to get a surface on screen (wl_compositor,
>   wl_surface, wl_shm, wl_shm_pool, wl_shell, wl_shell_surface)
> * Seats and input
>* Keyboard: wl_keyboard and libxkbcommon
>* Mouse: wl_pointer and libwayland-cursor for cursor handling
> * xdg_wm_base
> * Window decorations
> * EGL

I would be very interested in an overview like that and think it's a
very good idea™ indeed!

I see that you left out the text-input/input-method protocols in your
topics. Is it because those are unstable or because you don't consider
them to be important enough?


Cheers,

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

Re: Wayland talk at FOSDEM

[Eugen Friedrich]

Hello Philipp,

I also thinking give a talk about the usage of weston in ivi systems,
this should give an overview what is the main difference to the
desktop environment and why the ivi-shell is used. Also I would like
to give short overview about the recent activities in ivi-shell and
usage of waltham.

2017-12-05 15:46 GMT+01:00 Philipp Kerling :
>
> Hey everyone,
>
> I've been thinking about submitting a Wayland-themed talk to the FOSDEM
> graphics devroom [1] and wanted to check with the community if anyone
> else has considered this or another Wayland topic and whether you think
> it would be a good idea™.
>
> What I would want to talk about is a beginner's introduction to Wayland
> from the client perspective. I think that resources on this (and on
> Wayland in general to be honest) are quite scarce and that I could pass
> on some of the knowledge I have gained by implementing native Wayland
> support in Kodi this way.
>
> This would include stuff such as:
>  * Wayland architecture
> * Comparison with X
> * Security architecture
> * Limitations: What is not possible with Wayland (currently)
> * Difference between core and extension protocols
> * Global registry
> * Relevant documentation and resources
>  * Why you should not be writing a Wayland client yourself (aka use
>toolkits if possible)
>  * Relevant compositors to test on and how to use nested mode
>  * Basic client programming
> * Protocols needed to get a surface on screen (wl_compositor,
>   wl_surface, wl_shm, wl_shm_pool, wl_shell, wl_shell_surface)
> * Seats and input
>* Keyboard: wl_keyboard and libxkbcommon
>* Mouse: wl_pointer and libwayland-cursor for cursor handling
> * xdg_wm_base
> * Window decorations
> * EGL
>
> Possible extensions/replacement topics:
>  * Bindings (just mention: C++, D, Java, Rust)
>  * Vulkan (I think EGL is more relevant at the moment)
>  * Some more extension protocols such as pointer-constraints and
>relative-pointer (relevant e.g. for games)
>  * Subcompositing
>  * ...
just as idea: there are a few patch series which are pending for a
very long time,
one of the famous one is the atomic mode setting patch series from Daniel :-)
maybe it would be interesting to give a short overview of the "cool"
pending feature
on the list which people can expect in next or over next release.

>
> I would not include:
>  * Details of libwayland API (e.g. proxy wrappers)
>  * Every extension protocol or even core protocol object just for
>completeness
>  * Historical baggage such as xdg_shell v5
>  * EGL/Mesa internals
>
> I'd love to hear any comments/suggestions you might have and generally
> what kind of topics people would be interested in.
>
> [1] 
> https://lists.freedesktop.org/archives/wayland-devel/2017-November/035880.html
>
> Regards,
> Philipp
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Wayland talk at FOSDEM

[Philipp Kerling]

Hey everyone,

I've been thinking about submitting a Wayland-themed talk to the FOSDEM
graphics devroom [1] and wanted to check with the community if anyone
else has considered this or another Wayland topic and whether you think
it would be a good idea™.

What I would want to talk about is a beginner's introduction to Wayland
from the client perspective. I think that resources on this (and on
Wayland in general to be honest) are quite scarce and that I could pass
on some of the knowledge I have gained by implementing native Wayland
support in Kodi this way.

This would include stuff such as:
 * Wayland architecture
* Comparison with X
* Security architecture
* Limitations: What is not possible with Wayland (currently)
* Difference between core and extension protocols
* Global registry
* Relevant documentation and resources
 * Why you should not be writing a Wayland client yourself (aka use
   toolkits if possible)
 * Relevant compositors to test on and how to use nested mode
 * Basic client programming
* Protocols needed to get a surface on screen (wl_compositor,
  wl_surface, wl_shm, wl_shm_pool, wl_shell, wl_shell_surface)
* Seats and input
   * Keyboard: wl_keyboard and libxkbcommon
   * Mouse: wl_pointer and libwayland-cursor for cursor handling
* xdg_wm_base
* Window decorations
* EGL

Possible extensions/replacement topics:
 * Bindings (just mention: C++, D, Java, Rust)
 * Vulkan (I think EGL is more relevant at the moment)
 * Some more extension protocols such as pointer-constraints and
   relative-pointer (relevant e.g. for games)
 * Subcompositing
 * ...

I would not include:
 * Details of libwayland API (e.g. proxy wrappers)
 * Every extension protocol or even core protocol object just for
   completeness
 * Historical baggage such as xdg_shell v5
 * EGL/Mesa internals

I'd love to hear any comments/suggestions you might have and generally
what kind of topics people would be interested in.

[1] 
https://lists.freedesktop.org/archives/wayland-devel/2017-November/035880.html

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