[Patch v3][weston] gl-renderer.c: Use gr->egl_config to create pbuffer surface

2018-08-16 Thread Madhurkiran Harikrishnan
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, 
_config) < 0) {
-   weston_log("failed to choose EGL config for PbufferSurface\n");
+
+   if(!eglGetConfigAttrib(gr->egl_display, gr->egl_config, 
EGL_SURFACE_TYPE, _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

2018-08-16 Thread Simon Ser
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 
> > > 

Re: [PATCH wayland-protocols] unstable: add xdg-primary-selection protocol

2018-08-16 Thread Carlos Garnacho
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   \
>> > +   
>> > 

Re: [PATCH wayland-protocols] unstable: add xdg-primary-selection protocol

2018-08-16 Thread Jonas Ådahl
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

2018-08-16 Thread Carlos Garnacho
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
> +

Re: [PATCH] cursor: use memfd_create or shm_open for anonymous in-memory files

2018-08-16 Thread Jan Engelhardt

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

2018-08-16 Thread Simon Ser
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

2018-08-16 Thread Emil Velikov
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