On Tue, 05 Dec 2017 16:46:41 +0200 Philipp Kerling <pkerl...@casix.org> 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
