[Patch v3][weston] gl-renderer.c: Use gr->egl_config to create pbuffer surface
The original implementation always chose first egl config for pbuffer surface type, however the returned configs are implementation specific and egl config may not always match between ctx and surface. Hence, use gr->egl_config which already has the matching config but ensure that windows and pbuffer bit are set for the surface type. Signed-off-by: Madhurkiran Harikrishnan --- libweston/gl-renderer.c | 30 ++ 1 file changed, 14 insertions(+), 16 deletions(-) diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c index da29b07..726ca68 100644 --- a/libweston/gl-renderer.c +++ b/libweston/gl-renderer.c @@ -3033,7 +3033,7 @@ gl_renderer_setup_egl_extensions(struct weston_compositor *ec) } static const EGLint gl_renderer_opaque_attribs[] = { - EGL_SURFACE_TYPE, EGL_WINDOW_BIT, + EGL_SURFACE_TYPE, EGL_WINDOW_BIT | EGL_PBUFFER_BIT, EGL_RED_SIZE, 1, EGL_GREEN_SIZE, 1, EGL_BLUE_SIZE, 1, @@ -3043,7 +3043,7 @@ static const EGLint gl_renderer_opaque_attribs[] = { }; static const EGLint gl_renderer_alpha_attribs[] = { - EGL_SURFACE_TYPE, EGL_WINDOW_BIT, + EGL_SURFACE_TYPE, EGL_WINDOW_BIT | EGL_PBUFFER_BIT, EGL_RED_SIZE, 1, EGL_GREEN_SIZE, 1, EGL_BLUE_SIZE, 1, @@ -3146,17 +3146,7 @@ output_handle_destroy(struct wl_listener *listener, void *data) static int gl_renderer_create_pbuffer_surface(struct gl_renderer *gr) { - EGLConfig pbuffer_config; - - static const EGLint pbuffer_config_attribs[] = { - EGL_SURFACE_TYPE, EGL_PBUFFER_BIT, - EGL_RED_SIZE, 1, - EGL_GREEN_SIZE, 1, - EGL_BLUE_SIZE, 1, - EGL_ALPHA_SIZE, 0, - EGL_RENDERABLE_TYPE, EGL_OPENGL_ES2_BIT, - EGL_NONE - }; + EGLint surface_type; static const EGLint pbuffer_attribs[] = { EGL_WIDTH, 10, @@ -3164,13 +3154,21 @@ gl_renderer_create_pbuffer_surface(struct gl_renderer *gr) { EGL_NONE }; - if (egl_choose_config(gr, pbuffer_config_attribs, NULL, 0, &pbuffer_config) < 0) { - weston_log("failed to choose EGL config for PbufferSurface\n"); + + if(!eglGetConfigAttrib(gr->egl_display, gr->egl_config, EGL_SURFACE_TYPE, &surface_type)) { + weston_log("failed to get surface type for PbufferSurface\n"); + } + + if (!((surface_type & EGL_WINDOW_BIT) && (surface_type & EGL_PBUFFER_BIT)) && + !gr->has_configless_context) { + weston_log("attempted to use a different EGL config for an " + "output but EGL_KHR_no_config_context or " + "EGL_MESA_configless_context is not supported\n"); return -1; } gr->dummy_surface = eglCreatePbufferSurface(gr->egl_display, - pbuffer_config, + gr->egl_config, pbuffer_attribs); if (gr->dummy_surface == EGL_NO_SURFACE) { -- 2.7.4 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols] unstable: add xdg-primary-selection protocol
Hi, Thanks for the clarification. On August 16, 2018 3:46 PM, Jonas Ådahl wrote: > On Thu, Aug 16, 2018 at 04:25:06PM +0200, Carlos Garnacho wrote: > > > Hi!, > > Thanks Simon for moving this forward. FTR this looks good to me. Had > > some chat with Jonas on IRC about the suitability of xdg vs wp > > prefixes, but I personally think your choice is fine. Either way, this > > is > > To elaborate what the discussion was about: > > "xdg" shouldn't be seen as a "desktop" (device that sits on a desk) > thing, but a place to put protocols that aims to "bridge" different > environments, be they things running in devices placed on desks or in > hands. In my mind "xdg" meant "desktop-style compositors", be it targeted at desktop machines as well as laptops. I was thinking "xdg" was separate from e.g. IVI and mobile phones. But it seems I'm wrong here -- can you elaborate on this "bridge" idea? Do you mean a bridge between different compositors? Or a bridge between desktops/laptops/smartphones/tablets? > For example, if someone plugs in a mouse to a smartphone or tablet, if > that person has the middle-click-paste function on the actual desktop > computer, I'd assume the same user would expect it also on the > not-a-desktop-computer device. I'm not sure smartphone/tablets compositors would want to implement things like drag-and-drop and primary selection. If they do, this is only to accommodate for situations in which the user makes their device more desktop-y (e.g. by plugging a mouse), in which case implementing an "xdg" protocol makes sense. > Personally I don't think clipboard really fall into this category of > desktop environment interoperability, and "primary selection" is not > really different from the regular clipboard and drag-n-drop > functionality here I think. The difference is that while you have clipboard on a smartphone/tablet, you don't have drag-and-drop nor primary selection. Yeah, primary selection is similar to drag-and-drop. > On the other hand, if we see clipboard as something that bridges > environments (e.g. if gtk wants to have interoperable clipboard, it > needs to use a bridging protocol), and with that in mind, primary > selection do fall into this category (so does regular clipboard, but > can't rename that so meh). I personally think at least drag-and-drop doesn't belong in the core Wayland protocol. But yeah, it's not like we can change this. > So, my personal opinion is that putting this inside a "xdg_" prefix is > not entirely suitable, given that this is clipboard type plumbing that > just happens to historically come from the traditional desktop Linux > usage. So in the end, do you want to use the "wp_" prefix, or maybe another prefix? IMHO the "wp_" prefix is too broad for this protocol. I'm not feeling strongly about this in any case. > Thoughts? If we ignore form factors (desktop vs hand held), where does > it fall, you think? > > Jonas > > > Acked-by: Carlos Garnacho carl...@gnome.org > > On Sun, Jul 8, 2018 at 9:14 PM, Simon Ser cont...@emersion.fr wrote: > > > > > This primary selection is similar in spirit to the eponimous > > > in X11, allowing a quick "select text + middle click" shortcut > > > to copying and pasting. > > > It's otherwise very similar to its Yayland counterpart, and > > > explicitly made consistent with it. > > > > > > Signed-off-by: Simon Ser cont...@emersion.fr > > > > > > - > > > > > > This is a continuation of 1. This protocol was pretty close to being > > > accepted. > > > I've chosen to put the xdg prefix because this primary selection is > > > mostly relevant > > > to desktop compositors. > > > I've added myself as maintainer, Carlos and Lyude let me know if you want > > > to replace > > > me or be added to the list too. > > > Makefile.am | 3 +- > > > unstable/xdg-primary-selection/README | 4 + > > > .../xdg-primary-selection-unstable-v1.xml | 225 ++ > > > 3 files changed, 231 insertions(+), 1 deletion(-) > > > create mode 100644 unstable/xdg-primary-selection/README > > > create mode 100644 > > > unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml > > > diff --git a/Makefile.am b/Makefile.am > > > index 2b59d34..66a65af 100644 > > > --- a/Makefile.am > > > +++ b/Makefile.am > > > @@ -19,7 +19,8 @@ unstable_protocols = \ > > > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml > > > \ > > > unstable/xdg-output/xdg-output-unstable-v1.xml \ > > > unstable/input-timestamps/input-timestamps-unstable-v1.xml \ > > > > > > - unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \\ > > > > > > > > > > > > - unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > > > - > > > unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml\\ > > > $(NULL) > > > > > > > > > > > > stable_protocols = \ > > > diff --git a/unstable/xdg-primary-selection/README > > > b/unstable/xdg-primary-selection
Re: [PATCH wayland-protocols] unstable: add xdg-primary-selection protocol
On Thu, Aug 16, 2018 at 4:46 PM, Jonas Ådahl wrote: > On Thu, Aug 16, 2018 at 04:25:06PM +0200, Carlos Garnacho wrote: >> Hi!, >> >> Thanks Simon for moving this forward. FTR this looks good to me. Had >> some chat with Jonas on IRC about the suitability of xdg vs wp >> prefixes, but I personally think your choice is fine. Either way, this >> is > > To elaborate what the discussion was about: > > "xdg" shouldn't be seen as a "desktop" (device that sits on a desk) > thing, but a place to put protocols that aims to "bridge" different > environments, be they things running in devices placed on desks or in > hands. Making merits for my "captain obvious" award, I'll point out the 'd' in xdg stands for "desktop" :). If we aim 'xdg' to be a form factor-agnostic set of standards, I would say that even window management is a bit of a stretch... Certainly not something you usually see in tablets or mobile. But times surely change, so I don't say we must attain to the original meaning, AFAIR the 'x' was already switched to 'cross' at some point. > > For example, if someone plugs in a mouse to a smartphone or tablet, if > that person has the middle-click-paste function on the actual desktop > computer, I'd assume the same user would expect it also on the > not-a-desktop-computer device. > > Personally I don't think clipboard really fall into this category of > desktop environment interoperability, and "primary selection" is not > really different from the regular clipboard and drag-n-drop > functionality here I think. > > On the other hand, if we see clipboard as something that bridges > environments (e.g. if gtk wants to have interoperable clipboard, it > needs to use a bridging protocol), and with that in mind, primary > selection *do* fall into this category (so does regular clipboard, but > can't rename that so meh). That is my line of thought, although I kind of agree this is being a "historical artifact". This is about having heterogeneous clients have a lingua franca. I ultimately think the prefix is least relevant for that goal, the wayland-protocols blessing should be enough :) > > So, my personal opinion is that putting this inside a "xdg_" prefix is > not entirely suitable, given that this is clipboard type plumbing that > just happens to historically come from the traditional desktop Linux > usage. > > Thoughts? If we ignore form factors (desktop vs hand held), where does > it fall, you think? I guess we are less likely to regret it in 10 years time if it's wp, but just because it's such a big bucket :). But I see some pain going that way with the xdg rubberstamp... the amount of form factors is not going to decrease, anything can potentially get a bad idea in retrospective if we aim for the lowest common denominator. Or maybe should we acknowledge form-factor variety in xdg, so eg. a VR headset protocol could be "xdg" just as we have xdg-shell for desktop-style window management? Cheers, Carlos > > > Jonas > > >> >> Acked-by: Carlos Garnacho >> >> On Sun, Jul 8, 2018 at 9:14 PM, Simon Ser wrote: >> > This primary selection is similar in spirit to the eponimous >> > in X11, allowing a quick "select text + middle click" shortcut >> > to copying and pasting. >> > >> > It's otherwise very similar to its Yayland counterpart, and >> > explicitly made consistent with it. >> > >> > Signed-off-by: Simon Ser >> > --- >> > This is a continuation of [1]. This protocol was pretty close to being >> > accepted. >> > >> > I've chosen to put the xdg prefix because this primary selection is mostly >> > relevant >> > to desktop compositors. >> > >> > I've added myself as maintainer, Carlos and Lyude let me know if you want >> > to replace >> > me or be added to the list too. >> > >> > [1]: >> > https://lists.freedesktop.org/archives/wayland-devel/2016-February/027101.html >> > >> > Makefile.am | 3 +- >> > unstable/xdg-primary-selection/README | 4 + >> > .../xdg-primary-selection-unstable-v1.xml | 225 ++ >> > 3 files changed, 231 insertions(+), 1 deletion(-) >> > create mode 100644 unstable/xdg-primary-selection/README >> > create mode 100644 >> > unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml >> > >> > diff --git a/Makefile.am b/Makefile.am >> > index 2b59d34..66a65af 100644 >> > --- a/Makefile.am >> > +++ b/Makefile.am >> > @@ -19,7 +19,8 @@ unstable_protocols = >> > \ >> > >> > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml >> > \ >> > unstable/xdg-output/xdg-output-unstable-v1.xml >> > \ >> > unstable/input-timestamps/input-timestamps-unstable-v1.xml \ >> > - unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ >> > + unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ >> > + >> > unstable/xdg-primary-selection/xdg-primary-selection-un
Re: [PATCH wayland-protocols] unstable: add xdg-primary-selection protocol
On Thu, Aug 16, 2018 at 04:25:06PM +0200, Carlos Garnacho wrote: > Hi!, > > Thanks Simon for moving this forward. FTR this looks good to me. Had > some chat with Jonas on IRC about the suitability of xdg vs wp > prefixes, but I personally think your choice is fine. Either way, this > is To elaborate what the discussion was about: "xdg" shouldn't be seen as a "desktop" (device that sits on a desk) thing, but a place to put protocols that aims to "bridge" different environments, be they things running in devices placed on desks or in hands. For example, if someone plugs in a mouse to a smartphone or tablet, if that person has the middle-click-paste function on the actual desktop computer, I'd assume the same user would expect it also on the not-a-desktop-computer device. Personally I don't think clipboard really fall into this category of desktop environment interoperability, and "primary selection" is not really different from the regular clipboard and drag-n-drop functionality here I think. On the other hand, if we see clipboard as something that bridges environments (e.g. if gtk wants to have interoperable clipboard, it needs to use a bridging protocol), and with that in mind, primary selection *do* fall into this category (so does regular clipboard, but can't rename that so meh). So, my personal opinion is that putting this inside a "xdg_" prefix is not entirely suitable, given that this is clipboard type plumbing that just happens to historically come from the traditional desktop Linux usage. Thoughts? If we ignore form factors (desktop vs hand held), where does it fall, you think? Jonas > > Acked-by: Carlos Garnacho > > On Sun, Jul 8, 2018 at 9:14 PM, Simon Ser wrote: > > This primary selection is similar in spirit to the eponimous > > in X11, allowing a quick "select text + middle click" shortcut > > to copying and pasting. > > > > It's otherwise very similar to its Yayland counterpart, and > > explicitly made consistent with it. > > > > Signed-off-by: Simon Ser > > --- > > This is a continuation of [1]. This protocol was pretty close to being > > accepted. > > > > I've chosen to put the xdg prefix because this primary selection is mostly > > relevant > > to desktop compositors. > > > > I've added myself as maintainer, Carlos and Lyude let me know if you want > > to replace > > me or be added to the list too. > > > > [1]: > > https://lists.freedesktop.org/archives/wayland-devel/2016-February/027101.html > > > > Makefile.am | 3 +- > > unstable/xdg-primary-selection/README | 4 + > > .../xdg-primary-selection-unstable-v1.xml | 225 ++ > > 3 files changed, 231 insertions(+), 1 deletion(-) > > create mode 100644 unstable/xdg-primary-selection/README > > create mode 100644 > > unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml > > > > diff --git a/Makefile.am b/Makefile.am > > index 2b59d34..66a65af 100644 > > --- a/Makefile.am > > +++ b/Makefile.am > > @@ -19,7 +19,8 @@ unstable_protocols = > > \ > > > > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml > > \ > > unstable/xdg-output/xdg-output-unstable-v1.xml > > \ > > unstable/input-timestamps/input-timestamps-unstable-v1.xml \ > > - unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > > + unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > > + > > unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml\ > > $(NULL) > > > > stable_protocols = > > \ > > diff --git a/unstable/xdg-primary-selection/README > > b/unstable/xdg-primary-selection/README > > new file mode 100644 > > index 000..ae0a402 > > --- /dev/null > > +++ b/unstable/xdg-primary-selection/README > > @@ -0,0 +1,4 @@ > > +Primary selection protocol > > + > > +Maintainers: > > +Simon Ser > > diff --git > > a/unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml > > b/unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml > > new file mode 100644 > > index 000..eb97425 > > --- /dev/null > > +++ b/unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml > > @@ -0,0 +1,225 @@ > > + > > + > > + > > +Copyright © 2015, 2016 Red Hat > > + > > +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
Re: [PATCH wayland-protocols] unstable: add xdg-primary-selection protocol
Hi!, Thanks Simon for moving this forward. FTR this looks good to me. Had some chat with Jonas on IRC about the suitability of xdg vs wp prefixes, but I personally think your choice is fine. Either way, this is Acked-by: Carlos Garnacho On Sun, Jul 8, 2018 at 9:14 PM, Simon Ser wrote: > This primary selection is similar in spirit to the eponimous > in X11, allowing a quick "select text + middle click" shortcut > to copying and pasting. > > It's otherwise very similar to its Yayland counterpart, and > explicitly made consistent with it. > > Signed-off-by: Simon Ser > --- > This is a continuation of [1]. This protocol was pretty close to being > accepted. > > I've chosen to put the xdg prefix because this primary selection is mostly > relevant > to desktop compositors. > > I've added myself as maintainer, Carlos and Lyude let me know if you want to > replace > me or be added to the list too. > > [1]: > https://lists.freedesktop.org/archives/wayland-devel/2016-February/027101.html > > Makefile.am | 3 +- > unstable/xdg-primary-selection/README | 4 + > .../xdg-primary-selection-unstable-v1.xml | 225 ++ > 3 files changed, 231 insertions(+), 1 deletion(-) > create mode 100644 unstable/xdg-primary-selection/README > create mode 100644 > unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > index 2b59d34..66a65af 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -19,7 +19,8 @@ unstable_protocols = > \ > > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml > \ > unstable/xdg-output/xdg-output-unstable-v1.xml > \ > unstable/input-timestamps/input-timestamps-unstable-v1.xml \ > - unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > + unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > + unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml > \ > $(NULL) > > stable_protocols = > \ > diff --git a/unstable/xdg-primary-selection/README > b/unstable/xdg-primary-selection/README > new file mode 100644 > index 000..ae0a402 > --- /dev/null > +++ b/unstable/xdg-primary-selection/README > @@ -0,0 +1,4 @@ > +Primary selection protocol > + > +Maintainers: > +Simon Ser > diff --git > a/unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml > b/unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml > new file mode 100644 > index 000..eb97425 > --- /dev/null > +++ b/unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml > @@ -0,0 +1,225 @@ > + > + > + > +Copyright © 2015, 2016 Red Hat > + > +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. > + > + > + > +This protocol provides the ability to have a primary selection device to > +match that of the X server. This primary selection is a shortcut to the > +common clipboard selection, where text just needs to be selected in order > +to allow copying it elsewhere. The de facto way to perform this action > +is the middle mouse button, although it is not limited to this one. > + > +Clients wishing to honor primary selection should create a primary > +selection source and set it as the selection through > +xdg_primary_selection_device.set_selection whenever the text selection > +changes. In order to minimize calls in pointer-driven text selection, > +it should happen only once after the operation finished. Similarly, > +a NULL source should be set when text is unselected. > + > +xdg_primary_selection_offer objects are first announced through the > +xdg_primary_selecti
Re: [PATCH] cursor: use memfd_create or shm_open for anonymous in-memory files
On Thursday 2018-08-16 12:41, Emil Velikov wrote: >On 15 August 2018 at 15:14, Simon Ser wrote: >> On Linux, try using memfd_create and file sealing. Fallback to >> shm_open on old kernels. >> >> On FreeBSD, use shm_open with SHM_ANON. >> >> Otherwise, use shm_open with a random name, making sure the name >> isn't already taken. >> >Thinking out loud: > >I wonder if the next POSIX standard will finally standardise >random/anonymous shm files. Be that shm_open+SHM_ANON [...] According to the shm_open.3 from Linux man-pages-4.16 project, shm_open is already marked standardized: CONFORMING TO POSIX.1-2001, POSIX.1-2008. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] cursor: use memfd_create or shm_open for anonymous in-memory files
On August 16, 2018 11:57 AM, Jan Engelhardt wrote: > On Thursday 2018-08-16 12:41, Emil Velikov wrote: > > > On 15 August 2018 at 15:14, Simon Ser cont...@emersion.fr wrote: > > > > > On Linux, try using memfd_create and file sealing. Fallback to > > > shm_open on old kernels. > > > On FreeBSD, use shm_open with SHM_ANON. > > > Otherwise, use shm_open with a random name, making sure the name > > > isn't already taken. > > > > Thinking out loud: > > I wonder if the next POSIX standard will finally standardise > > random/anonymous shm files. Be that shm_open+SHM_ANON [...] > > According to the shm_open.3 from Linux man-pages-4.16 project, > shm_open is already marked standardized: > > CONFORMING TO > POSIX.1-2001, POSIX.1-2008. Yes, but this doesn't include SHM_ANON unfortunately. So we still need to generate a random name and make sure it hasn't been taken already. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] cursor: use memfd_create or shm_open for anonymous in-memory files
On 15 August 2018 at 15:14, Simon Ser wrote: > On Linux, try using memfd_create and file sealing. Fallback to > shm_open on old kernels. > > On FreeBSD, use shm_open with SHM_ANON. > > Otherwise, use shm_open with a random name, making sure the name > isn't already taken. > Thinking out loud: I wonder if the next POSIX standard will finally standardise random/anonymous shm files. Be that shm_open+SHM_ANON (FreeBSD), shm_mk*temp (OpenBSD) or any other solution. -Emil ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 2/2] input: Update to-be-restored focus when unfocused
On 8/16/18 5:24 AM, Peter Hutterer wrote: On Fri, Aug 10, 2018 at 12:55:42PM -0500, Derek Foreman wrote: On 2018-08-02 03:32 AM, Quentin Glidic wrote: On 8/2/18 10:29 AM, Quentin Glidic wrote: From: Quentin Glidic If we start a special (grabbing) client when Weston is unfocused, it would lose focus when coming back to Weston. A first attempt to fix this was 85d55540cb64bf97a08b40f79dc66843f8295d3b but it messed with VT switching. This fix just updates the saved focus, so when Weston gets focused back, it will focus the correct client. Signed-off-by: Quentin Glidic --- Sorry for the delay, I hoped I could make a Gitlab MR but sadly it didn’t happen yet. :-) I think this patch won’t conflict with VT switching, and it does fix the issue I had initially. I'm a bit confused as to where we're at with this. How did the reverted patch "mess with" or "conflict with" VT switching? it ended up always setting the keyboard focus to NULL on VT switch (due to how libinput devices are handled), so on vt switch back you had no focus. Is it intended that these two patches be applied, and then Jamey's patch (marked as "superseded" in patchwork) be applied on top to resolve the loss of focus on VT switch away/back? AIUI, these two need supersede Jamey's patchl but I'm not 100% sure on that, sorry. Cheers, Peter Thought this might be important to land before the release, but it's not terribly clear what it actually fixes. I'd assumed it was the VT switch thing, but that remains unresolved. Help? :) Sorry for the confusion. This (second) patch is a cleaner fix of the issue that was “fixed” by the reverted commit. Then on top of it, you’ll have to apply Jamey’s patch, which is an independent issue+fix (which the old fix conflicted with). I’m not sure why it was marked superseeded, maybe Patchwork detecting my patch as a reply? -- Quentin “Sardem FF7” Glidic ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel