Re: EVoC - Project ideas & hardware requirements
Hi Stefan, I worked on the Xwayland multi-buffer project in last year's GSoC. Well, there is still some stuff to do and I hope to finish it till the release of the next Xserver. You can check out my last patch-set at: https://lists.x.org/archives/xorg-devel/2017-August/054422.html * I can't say much to portable hardware. * You find the X.Org codebase here: https://cgit.freedesktop.org/xorg and the XServer in particular here: https://cgit.freedesktop.org/xorg/xserver/ If you're interested in Xwayland, this code is here: https://cgit.freedesktop.org/xorg/xserver/hw/xwayland. The best would be to clone atleast the xserver repo and take a look at it on your local file system. If you want to read some introduction to the XServer code base, you can read the articles I wrote while I was working on my GSoC project here: http://www.subdiff.de/archive/tags#xwayland This is primarily about Xwayland, but also at least outlines crucial parts of the overall design of the Xserver. * I'm also can't say much regarding your last item. In general though best is to ask on IRC #wayland or #xorg-devel. There are often devs around who will help you. In particular regarding the pressure-only bluetooth project you can also send Peter Hutterer an email or query him on IRC, who is the maintainer of libinput. Cheers Roman On Mon, Dec 18, 2017 at 7:57 AM, Stefan Dvoretskii < stefan.dvore...@gmail.com> wrote: > Hello dear Wayland developers, > > I am a student thinking about participating in EVoC. I've browsed the > Ideas concerning Wayland on the official site (https://www.x.org/wiki/ > SummerOfCodeIdeas/) and found the Pressure-only Bluetooth styli support > and Multi-Buffer for XWayland ideas especially interesting. However, there > are some questions: > > * Hardware requirements - I doubt I would have the proper portable > hardware. Is it possible to run it virtually or could there be some cheaper > solutions for that (i.e., buying/renting the proper hardware for the > duration of the project)? What could you recommend? > > * The codebase of xOrg is pretty huge, so it's pretty hard to find > relevant code. Where should I look at first considering this > projects/ideas? > > * Are there some resources apart from this and ToDo list where one could > find more things worthy doing an EVoC project about them? > > Thanks for your help in advance, > > Kind regards, > Stefan Dvoretskii. > > ___ > 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
[PATCH xserver] xwayland: Flips on subsurfaces
Do flips for child windows via subsurfaces if the Wayland server
supports them.
Signed-off-by: Roman Gilg
---
hw/xwayland/xwayland-present.c | 57 +-
hw/xwayland/xwayland.c | 6 -
hw/xwayland/xwayland.h | 2 ++
present/present_wnmd.c | 23 -
4 files changed, 52 insertions(+), 36 deletions(-)
diff --git a/hw/xwayland/xwayland-present.c b/hw/xwayland/xwayland-present.c
index d08c39e..f68bf92 100644
--- a/hw/xwayland/xwayland-present.c
+++ b/hw/xwayland/xwayland-present.c
@@ -55,15 +55,22 @@ xwl_present_cleanup(WindowPtr window)
* And therefore need to cleanup.
*/
+/* Clear frame callback */
if (xwl_window->present_frame_callback) {
wl_callback_destroy(xwl_window->present_frame_callback);
xwl_window->present_frame_callback = NULL;
}
+/* Clear surfaces */
+if (xwl_window->present_subsurface) {
+wl_subsurface_destroy(xwl_window->present_subsurface);
+wl_surface_destroy(xwl_window->present_surface);
+xwl_window->present_subsurface = NULL;
+}
+xwl_window->present_surface = NULL;
+
/* Reset base data */
xorg_list_del(&xwl_window->present_link);
-
-xwl_window->present_surface = NULL;
xwl_window->present_window = NULL;
TimerFree(xwl_window->present_frame_timer);
@@ -299,29 +306,31 @@ xwl_present_check_flip(RRCrtcPtr crtc,
return FALSE;
/*
- * We currently only allow flips of windows, that have the same
- * dimensions as their xwl_window parent window. For the case of
- * different sizes subsurfaces are presumably the way forward.
+ * Allow different sizes for the presenting window and its associated
+ * xwl_window only if the Wayland server supports subsurfaces.
*/
-if (!RegionEqual(&xwl_window->window->winSize, &present_window->winSize))
+if (!RegionEqual(&xwl_window->window->winSize, &present_window->winSize) &&
+!xwl_window->xwl_screen->subcompositor)
return FALSE;
return TRUE;
}
-static void
+static Bool
xwl_present_reset_present_window(struct xwl_window *xwl_window, WindowPtr
present_window)
{
/* Do not reset if it is the same present_window. But this also means, that
* we always switch to another child window, if it wants to present.
*/
if (xwl_window->present_window == present_window)
-return;
+return FALSE;
if (xwl_window->present_window)
xwl_present_cleanup(xwl_window->present_window);
xwl_window->present_window = present_window;
xorg_list_add(&xwl_window->present_link, &xwl_present_windows);
+
+return TRUE;
}
static Bool
@@ -334,18 +343,37 @@ xwl_present_flip(WindowPtr present_window,
RegionPtr damage)
{
struct xwl_window *xwl_window =
xwl_window_of_top(present_window);
-BoxPtr present_box, damage_box;
+BoxPtr win_box, present_box, damage_box;
+struct xwl_screen *xwl_screen = xwl_window->xwl_screen;
Boolbuffer_created;
struct wl_buffer*buffer;
struct xwl_present_event*event;
+struct wl_region*input_region;
+win_box = RegionExtents(&xwl_window->window->winSize);
present_box = RegionExtents(&present_window->winSize);
damage_box = RegionExtents(damage);
/* Potentially reset the presenting window */
-xwl_present_reset_present_window(xwl_window, present_window);
-/* We can flip directly to the main surface (full screen window without
clips) */
-xwl_window->present_surface = xwl_window->surface;
+if ( xwl_present_reset_present_window(xwl_window, present_window) ) {
+
+if (RegionEqual(&xwl_window->window->winSize,
&present_window->winSize)) {
+/* We can flip directly to the main surface (full screen window
without clips) */
+xwl_window->present_surface = xwl_window->surface;
+} else {
+xwl_window->present_surface =
wl_compositor_create_surface(xwl_screen->compositor);
+wl_surface_set_user_data(xwl_window->present_surface, xwl_window);
+
+xwl_window->present_subsurface =
+wl_subcompositor_get_subsurface(xwl_screen->subcompositor,
xwl_window->present_surface, xwl_window->surface);
+wl_subsurface_set_sync(xwl_window->present_subsurface);
+
+input_region = wl_compositor_create_region(xwl_screen->compositor);
+wl_surface_set_input_region(xwl_window->present_surface,
input_region);
+wl_region_destroy(input_region);
+}
+
+}
event = malloc(sizeof *event);
if (!event) {
@@ -353,6 +38
[RFC][PATCH xserver] Multi-buffered flips on subsurfaces seg fault in Mesa
The above patch series only allows flips on a child window with the same dimensions as its parent xwl_window. For flips on child windows (for example the video view port of a video player in windowed mode, see here: http://www.subdiff.de/assets/images/2017-07-28-a-new-beginning.jpg) I wanted to use Wayland subsurfaces as in the attached patch. The flipping itself works well on Weston and on KWin. But when shutting down KWin in the end I get always a segmentation fault in Mesa when cleaning up EGL via eglTerminate(EGLDisplay) through libepoxy. I pinpointed the seg fault to be a missing destroyImage function pointer here: https://cgit.freedesktop.org/mesa/mesa/tree/src/egl/drivers/dri2/egl_dri2.c#n2685 But I don't see currently what component is making the problems here or if the problem lies in my code. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC][PATCH xserver] Multi-buffered flips on subsurfaces seg fault in Mesa
Sorry, somewhat part of my message got removed. It should begin with: "This is a RFC on a follow-up patch to my recently posted patch series on the xorg-devel mailing list to enable per window flips of Present Pixmaps to Wayland surfaces: https://lists.freedesktop.org/archives/xorg-devel/2018-January/055674.html The above patch series only allows flips..." and so on. On Mon, Jan 29, 2018 at 5:54 PM, Roman Gilg wrote: > The above patch series only allows flips on a child window with the same > dimensions as its parent xwl_window. For flips on child windows (for > example > the video view port of a video player in windowed mode, see here: > http://www.subdiff.de/assets/images/2017-07-28-a-new-beginning.jpg) I > wanted > to use Wayland subsurfaces as in the attached patch. > > The flipping itself works well on Weston and on KWin. But when shutting > down > KWin in the end I get always a segmentation fault in Mesa when cleaning up > EGL > via eglTerminate(EGLDisplay) through libepoxy. > > I pinpointed the seg fault to be a missing destroyImage function pointer > here: > https://cgit.freedesktop.org/mesa/mesa/tree/src/egl/ > drivers/dri2/egl_dri2.c#n2685 > > But I don't see currently what component is making the problems here or if > the > problem lies in my code. > > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Session suspension and restoration protocol
Hi all, I have worked the past few days on a protocol for client session suspension and restoration and I need to get some feedback if I'm running in the right direction. I did get some input from Sway and GNOME devs at the start on what they would want such a protocol to do in general, and I did try to respect that when working on the protocol. Main features of the protocol as pasted below are: * provides an extensible object creation mechanism to let the compositor announce support for a subset of three increasing levels of suspension and let the client opt-in to some or all of these supported suspension levels * these three levels are: 1. sleep: allows destroying surfaces and their later restoration 2. quit: allows connection closing and restart of the client by the compositor via an implementation-independent D-Bus interface 3. shutdown: client will get restored after a server shutdown in a new Wayland session via the same D-Bus interface. * using D-Bus interface only to secure against sandboxed clients * if the client opts-in to level 2, 3 or both, the compositor might try to also restore the client after a client or compositor crash * the program flow would be always: 1. compositor announces supported suspension levels 2. client opts-in to one or several of the supported suspension levels by creating protocol objects for the respective levels 3. when the compositor wants to suspend the client (for example on low memory or shutdown) it sends an event to the respective suspension object, which the client can acknowledge or it must destroy the object to cancel the suspension. So while client and server agree on a subset of usable suspension levels, in the end only the compositor activates a suspension. The protocol is written from scratch, but it shares some similarities with Mike's proposed xdg-session-management protocol (https://lists.freedesktop.org/archives/wayland-devel/2018-February/037236.html). In advance thank you for your feedback! Copyright © 2018 Roman Gilg Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice (including the next paragraph) shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. A protocol for suspending and restoring clients. Multiple modes allow clients and server to match their common support for different levels of suspension from suspending and restoring only the client's surfaces until full client restoration after a system reboot. Warning! The protocol described in this file is experimental and backward incompatible changes may be made. Backward compatible changes may be added together with the corresponding interface version bump. Backward incompatible changes are done by bumping the version number in the protocol and interface names and resetting the interface version. Once the protocol is to be declared stable, the 'z' prefix and the version number in the protocol and interface names are removed and the interface version number is reset. A compositor implementing this interface announces that it is capable of some form of session suspension. Clients can register themselves in order to get more information about the available suspension levels and decide which ones of these they want to support. Clients register themselves in two steps by first sending the register_session_suspension request and then creating other child interfaces relative to which levels of restoration they and the compositor agree on to support. In the current version the protocol supports suspension of surfaces and their subsequent restoration while keeping the Wayland connection between client and server alive, restoration after the client quits the connection voluntarily or by crashing and restoration at the beginning of a new compositor session after a compositor sh
Re: Session suspension and restoration protocol
On Mon, Jun 18, 2018 at 6:01 PM Simon McVittie wrote: > > This document might be useful for the D-Bus side: > https://dbus.freedesktop.org/doc/dbus-api-design.html Hi Simon, thanks for the link. I have read it. Was a good D-Bus overview/introduction I have looked for already for quite some time. Wondering why I never found it before. Should enable me to misuse terminology less often. Thanks for the numerous corrections you did on that in your reply. I won't reply to all of them here, but will integrate them if there is a final proposal. > Do you intend the D-Bus side of the protocol to be equally useful to > X11 apps, or is this a Wayland-only thing? I have only thought about Wayland apps until now, because for X11 / Xwayland in Plasma we have XSMP support. But I'm not against having the mechanism work for X11 apps as well as a replacment for XSMP since GNOME doesn't use it at the moment and thought it was lacking. So yea, if it would work for X11 apps as well, that's fine with me and I will try to help make it happen. > > > and the method being called by the > > compositor on this interface is simply called 'restore' > > D-Bus method names are conventionally in camel-case, so 'Restore'. > > When we discussed this on #gnome-hackers we were talking about doing > restoration by passing the restored session ID as platform_data to the > Activate method defined by > https://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#dbus > which would mean that for trivial/stateless apps, it would be enough to > ignore it and just start up, which DBusActivatable implementations like > GtkApplication will already do. Is there a reason why you've opted to define > a new method instead? I think it makes sense to have a separate method, because a client can dbus-activate with the protocol any dbus-activatable app. Imagine a rogue client tries to dbus-activate an app, which is not written to use this extension but provides the Activate method. The compositor tries to dbus-activate it and gets no feedback that this was an operation not doing what it supposed to do. If there is no Restore method, I assume D-Bus would tell it so. The compositor can then show this information to the user. In this sense the protocol should be extended with the information that the Restore method should also return an error, if the restoration id is not found. A rogue client would that way also not be able to silently start a different client, that is supports the protocol (for that to make it secure the restore IDs should be generated through a hash function though). ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Session suspension and restoration protocol
What I forgot: the Restore method should probably take some similar argument like Activate's platform_data argument instead of a single integer/string. This way the argument can be extended with additional information, like with the Wayland server socket name, what Markus brought up. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Session suspension and restoration protocol
On Tue, Jun 19, 2018 at 11:19 AM Markus Ongyerth wrote: > > Hey Roman, > > first a general remark: > I don't see any mention of which state is supposed to be restored. The > workspace (virtual desktops), geometry (session-restore), just client-side > window (the embedded usecase)? > Is this left implementation-defined intentionally? If so, I think it would be > nice to have a note about that. Should allow restoration of workspace and geometry by compositor and client-side window by client. > While the sleep version of this has a way for a client ot overwrite and > restore itself, I'm missing that functionality on quit/shutdown. > The current state is always compositor triggered on those. While it might make > sense for e.g. multi-window applications or other fancy things to use a > restoration protocol (at least for window geometry) on their own startup. > It *should* work as is, but I'd like to see it explicitly. The rational was that as soon as the client has agreed to the quit/shutdown state, it should have no business anymore to change this. Because in general it is meant to now quit the client connection and its own process only waiting for the Restore call by the compositor. If there is no process, it can no longer cancel the state. So it's not allowed. A client which will quit itself after some internal process ended should therefore not go into the quit state, otherwise it might get restored at some later point although it has nothing more to do. > On 2018/6月/18 05:05, Roman Gilg wrote: > > * using D-Bus interface only to secure against sandboxed clients > What? Why exactly? When I first read this, I expected that the client is > supposed to use the portal stuff to call out of a sandbox, but reading through > the actual protocol, I think the only usage of D-Bus is to launch the > applications from the compositor? > Since this needs explicit client support either way, IMO this could be > implmented by adding a required cmdline argument (e.g. > --org-freedsktop-restore=UID) instead. > Parsing .desktop files, and launching applications in a helper shouldn't bee > too much of a burdon. > I know that GNOME/KDE employ D-Bus either way, but others want to avoid it as > much as possible. The first draft was written exactly this way: parse the desktop file, execute the Exec line with a special argument. But GNOME people said, that D-Bus Activation should be used. And I think they are right in theory. But if there is a large potion of potential users not willing to support D-Bus Activation one could offer the possibility to execute the Exec line or do D-Bus Activation. Client and compositor just need to make sure that they support whatever method they want to use (and if they don't use at least one of the methods at the same time, don't try to use the protocol). Should be easy to do with another event in the manager interface and another argument to its register_session_suspension call. And personally I would at least recommend in the specs to use D-Bus Activation instead of Exec. > > > > > >> summary="an object for the reference already exists"/> > >> summary="parent object destroyed before child objects"/> > >value="2" might be better to differentiate this from defunct_children :) > > summary="unallowed request sent while session suspended"/> > I'd suggest another entry: > summary="client tried to create a suspesion > object that's not > uspported by the compositor"/> My plan in this case was to just not send the respective event (i.e let the client create the sleep object but not send the sleep event if the compositor does not support sleep). But probably it's nicer to put out an error directly. > > [0] https://specifications.freedesktop.org/desktop-entry-spec > > > >>summary="register a new restore session"/> > >>summary="for restoration must match client_id of previous > > session"/> > What if there is no previous session? Then it should be 0. If we decide to use strings instead, it's an empty string. Needs to get mentioned in the description though. > > Calling this request on an xdg_toplevel for which a > > zxdg_session_surface > > object already exists results in a protocol error. > > > >>summary="session surface object"/> > > > > > What's your rational to have the surface_restore_id server allocated and sent > as event? This should be in a "cl
Re: Session suspension and restoration protocol
As a general remark I want to expand upon, why I did work on this protocol although Mike's xdg-session-management protocol already existed: The xdg-session-management protocol defines only how certain sessions / surfaces can be saved for later restoration and how to restore them. But it does not define conditions on if saving is suitable at the moment and how long the compositor needs to remember the saved restoration info. I believe in particular the last point is crucial, and the client needs to negotiate this with the compositor somehow depending on what it wants to do with the restoration info. My proposal tries to solve this by defining very tight concepts (sleep, quit, shutdown) on what the saved surface info is intended to be used for and allows the compositor to remove surface data, that has not been recovered in the boundaries of these concepts. And having DBus-Activation (or the Exec line of desktop files) defined in the protocol as the way to restore an app after it has quit the Wayland connection has the advantages that all information are in one place and that client developers have it easier, since they can rest assure that if they target this one spec and the compositor supports the suspension level, the workspace will at some point reactivate their app in a predictable manner. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] input-method: Add zwp-input-method-v2
Hi, what's the current state of this patch? I have a KWin patch up for review to implement the text-input v3 protocol, so I would be interested in pushing forward the input_method v2 here. If there are already some test applications speaking both ends of the pipeline I could try it out in KWin. Cheers On Thu, Oct 4, 2018 at 10:01 PM Dorota Czaplejewicz wrote: > > This protocol is based on v1, current text-input-v3, and wl_keyboard version > 6. > > The pieces passing data relevant to the application on the other side of the > compositor are a mirror copy of text-input-v3 events and requests. > > Compared to input-method-v1: > - assumes that once preedit is displayed, no selection can be active, > removing some selection handling > - follow text-input and removes language indicators > - explicitly attaches to seats > - removes "commit" text which would replace the preedit string automatically > in case it wasn't "confirmed" (whatever it means) > - adds double-buffering in the same places as text-input-v3 > - drops input_method_context and places its functionality directly in > input_method > - removes the ability to move the cursor position outside of preedit. It > still allows to delete a larger chunk of text and replace it with a preedit > - doesn't allow for sending of keyboard events to the compositor > - doesn't define any surfaces except for a special compositor-positioned popup > --- > Hi, > > continuing the RFC, I think this protocol is actually workable now, and I'm > sending this with the PATCH qualifier. > > The practical verification came in the form of a partial wlroots > implementation [0]. The formal issues (chiefly stemming from copy-pasting > things at night) have been pointed out to me by Simon, and corrected. > > The major unverified parts are keyboard grabs and popup surfaces, which I > will verify next. > > Changes compared to the RFC: > > - fixed so many confusing typos > - renamed preedit_text request to set_preedit_text > - described what happens when things get destroyed > - defined the role of input_popup sorface and forbade it from being deleted > - copied wl_keyboard to serve as the keyboard grab interface > > I hope you can help me find the remaining issues and turn this interface into > reality! > > Cheers, > Dorota Czaplejewicz > > Makefile.am| 1 + > unstable/input-method/input-method-unstable-v2.xml | 490 > + > 2 files changed, 491 insertions(+) > create mode 100644 unstable/input-method/input-method-unstable-v2.xml > > diff --git a/Makefile.am b/Makefile.am > index 6394e26..f3b9f80 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -7,6 +7,7 @@ unstable_protocols = > \ > unstable/text-input/text-input-unstable-v1.xml > \ > unstable/text-input/text-input-unstable-v3.xml > \ > unstable/input-method/input-method-unstable-v1.xml > \ > + unstable/input-method/input-method-unstable-v2.xml > \ > unstable/xdg-shell/xdg-shell-unstable-v5.xml > \ > unstable/xdg-shell/xdg-shell-unstable-v6.xml > \ > unstable/relative-pointer/relative-pointer-unstable-v1.xml > \ > diff --git a/unstable/input-method/input-method-unstable-v2.xml > b/unstable/input-method/input-method-unstable-v2.xml > new file mode 100644 > index 000..62be9d9 > --- /dev/null > +++ b/unstable/input-method/input-method-unstable-v2.xml > @@ -0,0 +1,490 @@ > + > + > + > + > +Copyright © 2008-2011 Kristian Høgsberg > +Copyright © 2010-2011 Intel Corporation > +Copyright © 2012-2013 Collabora, Ltd. > +Copyright © 2012, 2013 Intel Corporation > +Copyright © 2015, 2016 Jan Arne Petersen > +Copyright © 2017, 2018 Red Hat, Inc. > +Copyright © 2018 Purism SPC > + > +Permission is hereby granted, free of charge, to any person obtaining a > +copy of this software and associated documentation files (the > "Software"), > +to deal in the Software without restriction, including without limitation > +the rights to use, copy, modify, merge, publish, distribute, sublicense, > +and/or sell copies of the Software, and to permit persons to whom the > +Software is furnished to do so, subject to the following conditions: > + > +The above copyright notice and this permission notice (including the next > +paragraph) shall be included in all copies or substantial portions of the > +Software. > + > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS > OR > +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR > OTH
Re: Clipboard manager use case
On Fri, Nov 9, 2018 at 9:42 PM Simon Ser wrote: > > What do we need to do in order to move this forward? I see the proposal has > > been > > up for some months but didn't get much attention. > > > > If it is approved, I can probably make it happen on the KDE side, but it > > would > > be nice have input from other compositors. > > I'd really love to have some KWin guys have a look at it. If that can't > happen, > I'll bump it and it'll go through the normal wlr-protocols review process. > > Do you know if there is anyone from the KDE side interested in reviewing this? I already looked through the protocol a bit. But for a more thorough review I would first need to find some time for it. But maybe a better approach would be directly trying to implement the protocol in KWin and make use of it in KDE Connect. After all besides the data device/source/offer heavy protocol language it doesn't look too complicated. This way we can maybe spot issues we otherwise would overlook. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland-protocols scope and governance
On Tue, Feb 19, 2019 at 5:50 PM Daniel Stone wrote: > > Hi all, > I'd like to open up a discussion on enlarging wayland-protocols to a > wider audience, with a better definition of what it contains. Hi Daniel, thanks for moving forward this discussion. To me your suggestions overall sound very sensible. > Currently, wayland-protocols is a relatively small set of protocols > which were either grandfathered in from Weston, or a semi-opinionated > set of protocols that someone thinks is 'good'. > > The original intent was to provide a set of 'blessed' desktop > protocols which 'everyone' would probably implement in order to > provide a coherent Wayland environment. To some extent - xdg-shell, > dmabuf, xdg-output, viewporter - this succeeded. For some others, it > failed badly - the input protocols no-one likes or has implemented, > necessitating Dorota's rewrite. > > The elephant in the room is extensions like layer-shell and some of > the related extensions to build a desktop environment from a set of > disparate clients using generic APIs. Personally I think the > experience of X11 shows it's only designing for pain, and this is the > general position of wayland-protocols at the moment. But on the other > hand, those protocols aren't going away, they are in use, and having > them developed in a separate siloed community is doing us all a > disservice, since neither hand fully knows what the other is doing. > Even if we don't agree on the fundamentals of the protocol, we could > at least discuss it and try to point out some pitfalls and make some > suggestions for improvement. > > A related issue is that it's hard for both application and compositor > authors to figure out what to do. There is no good 'big picture' on > how these protocols fit together, nor can people figure out which of > the competing proposals they should be using if they want to write an > application running on a given compositor, nor can compositor authors > figure out what apps want them to support. Depending on who happens to > be paying attention to the particular forum the question is asked, > they might get very different answers, depending on the point of view > of who answers. > > My first, hopefully uncontroversial, suggestion: introduce a list of > compositors / compositor frameworks, as well as clients / client > frameworks, and which protocols they use and support. This would help > both application and compositor authors figure out where they should > invest time and effort. I suggest that we keep this lightweight: have > a registry of compositors / compositor frameworks / toolkits / > clients, each with a couple of named people who can speak > authoritatively for that project. > > We could then allow each project to declare its support (or otherwise) > for any extension: will not ever implement, implementation not > planned, no opinion or N/A, implementation planned, implemented but > use not recommended (or limited/stubbed), implemented and recommended. > This list would be machine-parseable (XML, JSON, YAML, whatever is > easiest to fit), with a GitLab CI pipeline used to generate a > https://wayland.freedesktop.org/protocols/ website on every push, > which gave both a per-extension and a per-project support table. And > some more readable docs. I think this would be a really good entry > point and clear up a lot of confusion. > > As a strawman list of projects to begin with (I'm sure there are others): > - compositors and compositor frameworks: Chromium (Exosphere), > Enlightenment, KWin, Mutter, Smithay, Sway, Weston/libweston, wlroots > - toolkits: EFL, GTK, Qt > - media: GStreamer, Kodi, VLC, XBMC > - other clients: Chromium (client), Firefox, Mesa (EGL/Vulkan) For completeness KWin uses the KDE Framework KWayland, that wraps common Wayland structs to be nicely consumed by Qt/Cpp based compositors. Writing a Wayland compositor is also possible with QtWayland, which is more high-level. > My second suggestion is to formalise the 'xdg' namespace. xdg > extensions have been accepted or rejected by rough consensus between > Enlightenment/EFL, GNOME, and KDE. That still seems reasonable enough > to me, assuming that 'xdg' retains the focus of an integrated (as > opposed to build-it-yourself) desktop. The IVI namespace would > similarly be delegated to automotive people, and maybe we could > delegate the layer_ namespace to those developers as well. I would formalize the xdg namespace (also in regards to what Simon said) as protocols for "up to a fully integrated desktop". In this notion a fully integrated desktop is defined as the most comprehensive form of what the protocols there try to accomplish, while it does not exclude other maybe less complex or more specialized compositors and devices, like phone UIs from using a sub-set of xdg-protocols, if they are useful in there specific use cases. The "build-it-yourself" desktops would then fall somewhere in the middle of the complexity-range and could still h
Re: wayland-protocols scope and governance
On Thu, Oct 10, 2019 at 11:12 AM Simon Ser wrote: > > This is v5 of the proposal. > > Changes from v4 to v5: > - "at least one member" changed to "at least one other member" (Jonas, Pekka) > - Replace remaining occurences of "push" with "merge" (Jonas, Pekka) > - Add a clause defining "open-source" as distributed with an OSI-approved > license (Drew) > > Diff: https://sr.ht/tT-H.txt > > Signed-off-by: Drew DeVault > Signed-off-by: Simon Ser > Acked-by: Daniel Stone > Acked-by: Pekka Paalanen > Cc: Jonas Ådahl > > * * * > > wayland-protocols governance > > This document governs the maintenance of wayland-protocols and serves to > outline > the broader process for standardization of protocol extensions in the Wayland > ecosystem. > > 1. Membership > > Membership in wayland-protocols is offered to stakeholders in the Wayland > ecosystem who have an interest in participating in protocol extension > standardization. > Qt compile version: 5.12.1 XCB compile version: 1.13.1 > 1.1. Membership requirements > > a. Membership is extended to projects, rather than individuals. > b. Members represent general-purpose projects with a stake in multiple Wayland >protocols (e.g. compositors, GUI toolkits, etc), rather than > special-purpose >applications with a stake in only one or two. > c. Each project must provide one or two named individuals as points-of-contact >for that project who can be reached to discuss protocol-related matters. > > 1.2. Becoming a member > > a. New members who meet the criteria outlined in 1.1 are established by >invitation from an existing member. Projects hoping to join should reach > out >to an existing member asking for this invitation. > b. New members shall write to the wayland-devel mailing list stating their >intention of joining and their sponsor. > c. The sponsor shall respond acknowledging their sponsorship of the > membership. > d. A 14 day discussion period for comments from wayland-protocols members will >be held. > e. At the conclusion of the discussion period, the new membership is > established >unless their application was NACKed by a 1/2 majority of existing members. > > 1.3. Ceasing membership > > a. A member may step down by writing their intention to do so to the >wayland-devel mailing list. > b. A removal vote may be called for by an existing member by posting to the >wayland-devel mailing list. This begins a 14 day voting & discussion >period. > c. At the conclusion of the voting period, the member is removed if the votes >total 2/3rds of members. > d. Removed members are not eligible to apply for membership again for a period >of 1 year. > e. Following a failed vote, the member who called for the vote cannot >call for a re-vote or propose any other removal for 90 days. > > 2. Protocols > > 2.1. Protocol namespaces > > a. Namespaces are implemented in practice by prefixing each interface name in > a >protocol definition (XML) with the namespace name, and an underscore (e.g. >"xdg_wm_base"). > b. Protocols in a namespace may optionally use the namespace followed by a > dash >in the name (e.g. "xdg-shell"). > c. The "xdg" namespace is established for protocols letting clients >configure its surfaces as "windows", allowing clients to affect how they >are managed. > d. The "wp" namespace is established for protocols generally useful to Wayland >implementations (i.e. "plumbing" protocols). > e. The "ext" namespace is established as a general catch-all for protocols > that >fit into no other namespace. > > 2.2. Protocol inclusion requirements > > a. All protocols found in the "xdg" and "wp" namespaces at the time of writing >are grandfathered into their respective namespace without further > discussion. > b. Protocols in the "xdg" and "wp" namespace are eligible for inclusion only > if >ACKed by at least 3 members. > c. Protocols in the "xdg" and "wp" namespace are ineligible for inclusion if >if NACKed by any member. > d. Protocols in the "xdg" and "wp" namespaces must have at last 3 open-source >implementations (either 1 client + 2 servers, or 2 clients + 1 server) to > be >eligible for inclusion. > e. Protocols in the "ext" namespace are eligible for inclusion only if ACKed > by >at least one other member. > f. Protocols in the "ext" namespace must have at least one open-source client > & >one open-source server implementation to be eligible for inclusion. > g. "Open-source" is defined as distributed with an Open Source Initiative >approved license. > > 2.3. Introducing new protocols > > a. A new protocol may be proposed by submitting a merge request to the >wayland-protocols Gitlab reposit
Re: wayland-protocols scope and governance
On Tue, Nov 12, 2019 at 9:14 PM Daniel Stone wrote: > > Hi, > > On Thu, 10 Oct 2019 at 16:12, Simon Ser wrote: > > This document governs the maintenance of wayland-protocols and serves to > > outline > > the broader process for standardization of protocol extensions in the > > Wayland > > ecosystem. > > OK, we're approaching the nine-month anniversary of this discussion. I > think it would be good to merge it before it would've been born. > > We seem to have a unanimous set of agreed-upon initial members with > defined points of contact (listed below). : EFL, Enlightenment, GTK, > KWin, Mutter, Qt, Weston, wlroots (also as a proxy for the wider > phosh/Sway/way-cooler/etc projects using wlroots). > > I think there's a good case to be made for adding Chromium/Exosphere > to the list, since they are actively involved in protocol development > and a few of their protocols have already found their way upstream. > Other major users include GStreamer, Kodi, and VLC, but it doesn't > seem like they participate too much in protocol development, and it's > not clear to me whether or not they'd want to be involved. I don't > have a strong opinion on whether or not they should be in the > membership group. Similarly, you could add Firefox and perhaps even > Mesa to that list; I remember others suggesting GLFW, SDL, maybe even > imgui, mpv? > > I would suggest that we push the patch with the following initial > member projects and their points of contact defined, and finally > enable MRs: > * EFL/Enlightenment: Mike Blumenkrantz @zmike > * GTK/Mutter: Jonas Ådahl @jadahl > * KWin: Roman Gilg @romangg > * Qt: Johan Helsing @johanhelsing > * Weston: Daniel Stone @daniels, Pekka Paalanen @pq > * wlroots (& its users): Drew DeVault @ddevault, Simon Ser @emersion Yea, let's get this done. Though I still think this initial list of members should be mentioned directly in the document or better a reference to the document with the list of current members be made (which then contains the initial member list). Also please add as second point of contact for KWin David Edmundson @d_ed. Other than that: Acked-by: Roman Gilg on behalf of KWin > If we find interest from other projects, we can use their membership > applications as a first test of our governance procedures. > > Cheers, > Daniel > ___ > 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: Plumbing explicit synchronization through the Linux ecosystem
On Wed, Mar 11, 2020 at 8:21 PM Jason Ekstrand wrote: > > On Wed, Mar 11, 2020 at 12:31 PM Jason Ekstrand wrote: > > > > All, > > > > Sorry for casting such a broad net with this one. I'm sure most people > > who reply will get at least one mailing list rejection. However, this > > is an issue that affects a LOT of components and that's why it's > > thorny to begin with. Please pardon the length of this e-mail as > > well; I promise there's a concrete point/proposal at the end. > > > > > > Explicit synchronization is the future of graphics and media. At > > least, that seems to be the consensus among all the graphics people > > I've talked to. I had a chat with one of the lead Android graphics > > engineers recently who told me that doing explicit sync from the start > > was one of the best engineering decisions Android ever made. It's > > also the direction being taken by more modern APIs such as Vulkan. > > > > > > ## What are implicit and explicit synchronization? > > > > For those that aren't familiar with this space, GPUs, media encoders, > > etc. are massively parallel and synchronization of some form is > > required to ensure that everything happens in the right order and > > avoid data races. Implicit synchronization is when bits of work (3D, > > compute, video encode, etc.) are implicitly based on the absolute > > CPU-time order in which API calls occur. Explicit synchronization is > > when the client (whatever that means in any given context) provides > > the dependency graph explicitly via some sort of synchronization > > primitives. If you're still confused, consider the following > > examples: > > > > With OpenGL and EGL, almost everything is implicit sync. Say you have > > two OpenGL contexts sharing an image where one writes to it and the > > other textures from it. The way the OpenGL spec works, the client has > > to make the API calls to render to the image before (in CPU time) it > > makes the API calls which texture from the image. As long as it does > > this (and maybe inserts a glFlush?), the driver will ensure that the > > rendering completes before the texturing happens and you get correct > > contents. > > > > Implicit synchronization can also happen across processes. Wayland, > > for instance, is currently built on implicit sync where the client > > does their rendering and then does a hand-off (via wl_surface::commit) > > to tell the compositor it's done at which point the compositor can now > > texture from the surface. The hand-off ensures that the client's > > OpenGL API calls happen before the server's OpenGL API calls. > > > > A good example of explicit synchronization is the Vulkan API. There, > > a client (or multiple clients) can simultaneously build command > > buffers in different threads where one of those command buffers > > renders to an image and the other textures from it and then submit > > both of them at the same time with instructions to the driver for > > which order to execute them in. The execution order is described via > > the VkSemaphore primitive. With the new VK_KHR_timeline_semaphore > > extension, you can even submit the work which does the texturing > > BEFORE the work which does the rendering and the driver will sort it > > out. > > > > The #1 problem with implicit synchronization (which explicit solves) > > is that it leads to a lot of over-synchronization both in client space > > and in driver/device space. The client has to synchronize a lot more > > because it has to ensure that the API calls happen in a particular > > order. The driver/device have to synchronize a lot more because they > > never know what is going to end up being a synchronization point as an > > API call on another thread/process may occur at any time. As we move > > to more and more multi-threaded programming this synchronization (on > > the client-side especially) becomes more and more painful. > > > > > > ## Current status in Linux > > > > Implicit synchronization in Linux works via a the kernel's internal > > dma_buf and dma_fence data structures. A dma_fence is a tiny object > > which represents the "done" status for some bit of work. Typically, > > dma_fences are created as a by-product of someone submitting some bit > > of work (say, 3D rendering) to the kernel. The dma_buf object has a > > set of dma_fences on it representing shared (read) and exclusive > > (write) access to the object. When work is submitted which, for > > instance renders to the dma_buf, it's queued waiting on all the fences > > on the dma_buf and and a dma_fence is created representing the end of > > said rendering work and it's installed as the dma_buf's exclusive > > fence. This way, the kernel can manage all its internal queues (3D > > rendering, display, video encode, etc.) and know which things to > > submit in what order. > > > > For the last few years, we've had sync_file in the kernel and it's > > plumbed into some drivers. A sync_file is just a wrapper around a > >
Re: RFC: libei - emulated input in Wayland compositors
On Fri, Jul 31, 2020 at 7:13 AM Peter Hutterer wrote: > > I've been working on a new approach for allowing emulated input devices in > Wayland. Or in short - how can we make xdotool and synergy work? And > eventually replace them. > > The proposal I have is a library for Emulated Input, in short libei. > https://gitlab.freedesktop.org/whot/libei/ We talked about it already yesterday but thanks again for this great project. I decided to directly write some experimental integration code based on your Weston branch for the server library in KWinFT [1] in order to try this out as a solution for my Steam Controller issue [2] that - I assume - motivated the creation of this library to some extent. And yes, it works. :) I can move the cursor with the Steam controller as in "Steam client -> XTEST -> patched Xwayland -> libei -> libeis -> KWinFT" just fine. Am I right in assuming that the button-press event is not yet done in libei or in the patched Xwayland version you linked? When it's available let me know and I'll add the necessary logic for that too. > libei has two parts, the client side (libei) for applications and > a server side (libeis) for the compositor. The two libraries communicate > with each other (how? doesn't matter, it's an implementation detail) to > negotiate input devices. > > The process is roughly: > - the libei client connects and says "I am org.freedesktop.SomeApplication > and I want a pointer and a keyboard device" > - the libeis server says "ok, you can have a pointer device and a keyboard > device" > - the libei client says 'move the pointer by 1/1', etc. and the server does > just that. or not, depending on context. > > There are more details, see the README in the repo and the libei.h and > libeis.h header files that describe the API. > > The sticking point here is: emulated input comes via a separate channel. > The server a) knows it's emulated input, b) knows who it is coming from and > c) has complete control over the input. > > a) is interesting because you can differ between the events internally. The > API right now is very similar to libinput's events so integrating it into a > compositor should be trivial. > > b) is somewhat handwavy if an application runs outside a sandbox - any > information will be unreliable. Flatpak gives you an app-id though and > with that we can (eventually) do things like storing the allow/deny > decisions of the user in the portal implementation. > > c) allows you to e.g. suspend the client when convenient or just ignore > certain sequences altogether. The two made-up examples are: suspend EI > during a password prompt, or allow EI from the software yubikey *only* > during a password prompt. > > Now, the next question is: how do they *start* talking to each other? > libei provides multiple backends for the initial connection negotiation. My > goal is to have this work with flatpak portals so an application running > within the sandbox can be restricted accordingly. Alternatives to this could > be public DBus interfaces, simple fd passing or (as is implemented right > now) a named unix socket. Wiring this somehow through portals would be important for sure. Xwayland as a client could either be accepted by default or if Olivier's Xwayland xdg-portal patches [3] land (with the additional portal for libei) only be accepted after the user confirmed it just like every other sandboxed client. That being said the envisioned permission model is still somewhat difficult for me to grasp. To reiterate: the access of sandboxed clients can be accepted or rejected by the user. But to my understanding that's a function of the xdg-portal itself. You said the compositor can filter requests too. Can it only allow libei connections through xdg-portals and Xwayland? What about other clients, how can they be distinguished from xdg-portals and Xwayland securely? Or is this only possible for flatpaked clients? Or is such a client blocked from trying to do that anyway (in other words is it allowed or not to connect to arbitrary sockets like the libei one)? As it is probably clear now the overall concept of xdg-portals in detail is still not very well understood by me. From conversations I had lately with other windowing system developers I believe I'm not the only one. Since xdg-portals become more and more important for securing our graphical sessions it would be great if someone with more knowledge about it could create some kind of article or documentation about it that looks at it from the perspective of windowing systems . How do apps in/out of Flatpaks that display their pixels through X11, Xwayland or Wayland directly work in respect to the sandboxed environment provided by xdg-portals? What does this mean for a Wayland compositor, what does it need to do or refrain from to be on the safe side? For example some simple but lucid diagrams like the one in libei's README describing the flow around client <-> xdg-portals <-> windowing system would probab
Re: RFC: libei - emulated input in Wayland compositors
On Sat, Aug 1, 2020 at 12:47 AM Jonas Ådahl wrote: > > On Fri, Jul 31, 2020 at 08:49:41PM +0200, Roman Gilg wrote: > > On Fri, Jul 31, 2020 at 7:13 AM Peter Hutterer > > wrote: > > > > > > I've been working on a new approach for allowing emulated input devices in > > > Wayland. Or in short - how can we make xdotool and synergy work? And > > > eventually replace them. > > > > > > The proposal I have is a library for Emulated Input, in short libei. > > > https://gitlab.freedesktop.org/whot/libei/ > > > > We talked about it already yesterday but thanks again for this great > > project. I decided to directly write some experimental integration > > code based on your Weston branch for the server library in KWinFT [1] > > in order to try this out as a solution for my Steam Controller issue > > [2] that - I assume - motivated the creation of this library to some > > extent. > > > > And yes, it works. :) I can move the cursor with the Steam controller > > as in "Steam client -> XTEST -> patched Xwayland -> libei -> libeis -> > > KWinFT" just fine. > > > > Am I right in assuming that the button-press event is not yet done in > > libei or in the patched Xwayland version you linked? When it's > > available let me know and I'll add the necessary logic for that too. > > > > > libei has two parts, the client side (libei) for applications and > > > a server side (libeis) for the compositor. The two libraries communicate > > > with each other (how? doesn't matter, it's an implementation detail) to > > > negotiate input devices. > > > > > > The process is roughly: > > > - the libei client connects and says "I am org.freedesktop.SomeApplication > > > and I want a pointer and a keyboard device" > > > - the libeis server says "ok, you can have a pointer device and a keyboard > > > device" > > > - the libei client says 'move the pointer by 1/1', etc. and the server > > > does > > > just that. or not, depending on context. > > > > > > There are more details, see the README in the repo and the libei.h and > > > libeis.h header files that describe the API. > > > > > > The sticking point here is: emulated input comes via a separate channel. > > > The server a) knows it's emulated input, b) knows who it is coming from > > > and > > > c) has complete control over the input. > > > > > > a) is interesting because you can differ between the events internally. > > > The > > > API right now is very similar to libinput's events so integrating it into > > > a > > > compositor should be trivial. > > > > > > b) is somewhat handwavy if an application runs outside a sandbox - any > > > information will be unreliable. Flatpak gives you an app-id though and > > > with that we can (eventually) do things like storing the allow/deny > > > decisions of the user in the portal implementation. > > > > > > c) allows you to e.g. suspend the client when convenient or just ignore > > > certain sequences altogether. The two made-up examples are: suspend EI > > > during a password prompt, or allow EI from the software yubikey *only* > > > during a password prompt. > > > > > > Now, the next question is: how do they *start* talking to each other? > > > libei provides multiple backends for the initial connection negotiation. > > > My > > > goal is to have this work with flatpak portals so an application running > > > within the sandbox can be restricted accordingly. Alternatives to this > > > could > > > be public DBus interfaces, simple fd passing or (as is implemented right > > > now) a named unix socket. > > > > Wiring this somehow through portals would be important for sure. > > Xwayland as a client could either be accepted by default or if > > Olivier's Xwayland xdg-portal patches [3] land (with the additional > > portal for libei) only be accepted after the user confirmed it just > > like every other sandboxed client. > > > > That being said the envisioned permission model is still somewhat > > difficult for me to grasp. To reiterate: the access of sandboxed > > clients can be accepted or rejected by the user. But to my > > understanding that's a function of the xdg-portal itself. You said the > > compositor can filter requests too. Can it only allow libei > > connections throu
Re: Taiwins 0.2.9 is out
On Sun, Jan 31, 2021 at 4:40 PM Simon Ser wrote: > > Hi, > > On Sunday, January 31st, 2021 at 3:41 PM, Sichem Zhou > wrote: > > > Back in September 2020, I released the 0.2 version of Taiwins, which > > was utilising wlroots for backend handling. I have gone on > > implementing backend logics and Laid out most of the ground work. > > I'm curious, why did you choose to re-write your own compositor from > scratch instead of using wlroots? Not trying to say that it's a bad > idea, just trying to understand the motivation. :) Hi Xichen, I would also be interested in hearing your reasons for that. In any case, an interesting project you got there. What are your future plans for collaboration? Cheers Roman > Simon > ___ > 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
FDBuild Helps You Building Entire Wayland And X11 Graphic Stacks From Source
I recently created the first public release of FDBuild, a tool that I have been using over the last years to build all the things I needed to easily switch between hacking on Mesa, Wayland, XServer, etc. I believe it offers a very convenient workflow for that because you basically only need to remember a single command "fdbuild" and you are able to rebuild many projects or only a single one. You can get the tool easily with pip: https://pypi.org/project/fdbuild/ And you can read more about it in this blog post: https://subdiff.org/blog/2023/fdbuild-01-released
The Compositor Modules are released, the modular C++ library for writing Wayland compositors
I'm happy to announce the first publicly available release of The Compositor Modules, the modular C++ library to easily write a Wayland compositor. The release is available on GitHub. [1] You can read the full announcement with more details about the library exclusively on Phoronix. [2] The goal I once described at XDC 21 [3] has finally been reached by that. There are still of course things to do, but the main library structure is now in place. We can concentrate now on more feature work. Check out the feature table in the main README to see what's already there and what we plan on doing next. If you're interested in using the library or contributing to it, let me know either by email or join our Matrix room. [4] [1] https://github.com/winft/como [2] https://www.phoronix.com/review/the-compositor-modules-como [3] https://youtu.be/lTp7al9FXFs?t=885 [4] https://matrix.to/#/#como:matrix.org
