Re: [PATCH] compositor: Set EGL_PLATFORM env variable for each backend.
On Tue, May 10, 2011 at 04:42:56PM -0400, Kristian Høgsberg wrote:
> Indeed. I'll commit this patch for now, since I've had enough of
> failing to set EGL_PLATFORM and then trying to figure out why it
> breaks. The best solution I know of at this point is a "magic" way to
> look at the native display argument and detect what kind it is. So
> for example, stat it to see if it's a char device, in which case we
> decide it's the drm platform. If not, assume it's a pointer a struct
> and see if the first field looks like a valid pointer (not NULL and a
> multiple of 4), in which case we assume it's a X display pointer
> (Xlib.h, line 506). For the wl_display struct we can make the first
> field a pointer to a wayland symbol which will let us distinguish it
> from an X display pointer.
>
The way I thought to do it was to make eglDisplay take none of those as
arguments, but instead take a struct mesaEglDisplay * where said struct was
defined:
struct mesaEglDisplay {
/* uint64_t magic; */
char[8] platform;
void *display;
}
The reason it works is obvious, and its well within the egl spec. If you wanted
backward compatiblity, you could leave the magic uncommented and always fill
with 0xdeadbeefb4b3f00d, which would let you distinguish the new mechanism with
magic detection (though much more deterministic magic detection than what you
outlined) and otherwise just use the present system.
--CJD
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
Kristian Høgsberg wrote: I had a quick read through this and there is a lot of overlap with how Wayland works today... are you proposing to change how Wayland works or are you not familiar with what's already in place? A lot of this is based on my understanding of how Wayland works, and from the XML description of the protocol. I tried to document what I believe but has never been really stated for Wayland. Main addition I made without previous knowledge was the parent and the task objects (so that a task manager client can figure out what to display), and the window management events (rather than try to guess what happens based on movements of the windows, which seemed to be what was planned for Wayland). Anyway, for decorations and tiling window managers, bear in mind that CSD is not about insisting that clients always draws decorations, but about making clients draw the decorations *when* decorations are desired. I mostly see CSD as meaning "the server never draws any kind of decorations". I agree it is a good idea for the server to be able to tell the client to not to draw decorations (done in this proposal with the resize events having 4 flags to turn the edges on/off and another flag for the title bar). But the server must *never* draw them, because that would require the api by which the client describes the decorations to the server, which is the source of the complexity and interface lock-in that we have in X and Windows. I also believe window actions such as move, map, and raise must be client-side. Otherwise correct movement of child windows will require an equally-complex api to send this information to the server. So I really tried to make it clear how I see this working. Proper child windows where the app has complete control could be a major user interface advantage over Windows and OS/X. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
On Tue, May 10, 2011 at 8:35 PM, Bill Spitzak wrote: > With all the discussion about client side decorations, I thought I would try > to write how window management could actually be done in Wayland. This is a > really serious attempt to get the simplest system I could come up with, > while still allowing for some of the legitimate gripes, in particular to > make it not be impossible to do tiled window management. I had a quick read through this and there is a lot of overlap with how Wayland works today... are you proposing to change how Wayland works or are you not familiar with what's already in place? Anyway, for decorations and tiling window managers, bear in mind that CSD is not about insisting that clients always draws decorations, but about making clients draw the decorations *when* decorations are desired. Kristian > This I hope is in enough detail that it that it is not ambiguous whether > this design does something or fails to do it. Too much of the client side > decoration argument is making false assumptions about what the system will > do. > > = Wayland Window Management proposal = > > == Object Parent == > > All Wayland objects have a single "parent", which is another object or > NULL. When an object is first created it's parent is NULL, but it can > be set to any other object afterwards. If the attempt to set the > parent produces a loop that is an error and the parent is > unchanged. If a parent is deleted the child's parent is set to > NULL. All parent changes produce events. > > The purpose is to build hierarchies that task managers need in order > to display everything in a useful way to users. This has no effect on > the display or how windows act. > > == Object Name == > > All objects have a single UTF-8 string attached to them that is the > "name". The purpose of the name is to provide something to show the > user when a program can't or does not want to display an image. > > == Task objects == > > Task objects are windows but their purpose is to appear in a "task > list". They probably don't have an actual image allocated. > > There is a global task created by the compositor, tasks that should be > visible are attached to this as children. Below that can be a > hierarchy of more tasks and then actual windows (i'm not sure if there > will need to be a way to distinguish tasks from windows). > > The image that appears in the task list may be the surface attached to > the task object, or maybe some children with specific names. Not sure > exactly how to do this but it would be nice if clients could control > this to draw indicators, etc. Compositors can fall back to showing the > name if no other image is found. > > == Multiple-surface windows == > > What appears to be a single window to the user may be several Wayland > windows. In particlar a video-playback program may have a YUV surface > resized on screen to zoom the pixels, overlaid with a "frame" window > which is an unscaled RGBA image of all the controls around and > overlaid on the video. It is important that window management support > this and them move and resize in exact lock. > > To indicate this the YUV surface should be a child of the frame > and below the frame. > > == Client side decorations == > > The client is responsible for drawing every single pixel in a window > that the user would click on and expect to go to the client. This > includes the window title and the borders on all sides of the window. > > Non-rectangular windows are done by leaving the portion between the > window and the rectangle transparent black (all zero). > > "shadows" are done by the compositor as the pixels they occupy belong > to the windows the shadows fall on. It can produce shadows for > non-rectangular windows by using the alpha to create the shadow. > > "blurry opacity" is done by the compositor. It must not blur video > playback children and not blur 100% transparent areas or the > antialiased edges of these areas. I don't know how clients can control > the blur, but perhaps color values greater than alpha can indicate > blurring. > > == Compositor Window Management == > > The compositor can produce events that clients are expected to respond > to and update their windows appropriately. The compositor *NEVER* > moves or does anything to the windows, as this would produce > asynchronous updates. The clients must do this so they can immediatly > draw the new contents. > > These events are produced by task manager windows, or by Alt+mouse > style overrides, NOT by the user clicking on the window borders or > contents. Clicks actually in the windows are expected to be handled by > the clients or by the filtering described below. > > === Close === > > Sent to a task or window indicating that the user wants it to go > away. A typical response is to ask the user if they are sure, to > destroy or unmap the window, to destroy or unmap other child windows, > and for the client to exit. > > === Hide === > > Sent to a task or window indicatin
Wayland Window Management Proposal
With all the discussion about client side decorations, I thought I would try to write how window management could actually be done in Wayland. This is a really serious attempt to get the simplest system I could come up with, while still allowing for some of the legitimate gripes, in particular to make it not be impossible to do tiled window management. This I hope is in enough detail that it that it is not ambiguous whether this design does something or fails to do it. Too much of the client side decoration argument is making false assumptions about what the system will do. = Wayland Window Management proposal = == Object Parent == All Wayland objects have a single "parent", which is another object or NULL. When an object is first created it's parent is NULL, but it can be set to any other object afterwards. If the attempt to set the parent produces a loop that is an error and the parent is unchanged. If a parent is deleted the child's parent is set to NULL. All parent changes produce events. The purpose is to build hierarchies that task managers need in order to display everything in a useful way to users. This has no effect on the display or how windows act. == Object Name == All objects have a single UTF-8 string attached to them that is the "name". The purpose of the name is to provide something to show the user when a program can't or does not want to display an image. == Task objects == Task objects are windows but their purpose is to appear in a "task list". They probably don't have an actual image allocated. There is a global task created by the compositor, tasks that should be visible are attached to this as children. Below that can be a hierarchy of more tasks and then actual windows (i'm not sure if there will need to be a way to distinguish tasks from windows). The image that appears in the task list may be the surface attached to the task object, or maybe some children with specific names. Not sure exactly how to do this but it would be nice if clients could control this to draw indicators, etc. Compositors can fall back to showing the name if no other image is found. == Multiple-surface windows == What appears to be a single window to the user may be several Wayland windows. In particlar a video-playback program may have a YUV surface resized on screen to zoom the pixels, overlaid with a "frame" window which is an unscaled RGBA image of all the controls around and overlaid on the video. It is important that window management support this and them move and resize in exact lock. To indicate this the YUV surface should be a child of the frame and below the frame. == Client side decorations == The client is responsible for drawing every single pixel in a window that the user would click on and expect to go to the client. This includes the window title and the borders on all sides of the window. Non-rectangular windows are done by leaving the portion between the window and the rectangle transparent black (all zero). "shadows" are done by the compositor as the pixels they occupy belong to the windows the shadows fall on. It can produce shadows for non-rectangular windows by using the alpha to create the shadow. "blurry opacity" is done by the compositor. It must not blur video playback children and not blur 100% transparent areas or the antialiased edges of these areas. I don't know how clients can control the blur, but perhaps color values greater than alpha can indicate blurring. == Compositor Window Management == The compositor can produce events that clients are expected to respond to and update their windows appropriately. The compositor *NEVER* moves or does anything to the windows, as this would produce asynchronous updates. The clients must do this so they can immediatly draw the new contents. These events are produced by task manager windows, or by Alt+mouse style overrides, NOT by the user clicking on the window borders or contents. Clicks actually in the windows are expected to be handled by the clients or by the filtering described below. === Close === Sent to a task or window indicating that the user wants it to go away. A typical response is to ask the user if they are sure, to destroy or unmap the window, to destroy or unmap other child windows, and for the client to exit. === Hide === Sent to a task or window indicating that the user wants it off the screen but wants to bring it back later. Typical response is to unmap windows. === Show === Sent to a task or window indicating that the user wants it on the screen. Typical response is to map windows. === Activate === Sent to a task or window, includes a non-pointer input device (usually the keyboard). Indicates that the device's events will be sent to that task or window. Typical response is to change the graphics to show this and to make toolboxes appear. Note that the events may be sent to the task, not a visible window, the client is responsible for figuring out where they should go. === Deac
Re: [PATCH] compositor: Set EGL_PLATFORM env variable for each backend.
On Tue, May 10, 2011 at 4:13 PM, Casey Dahlin wrote:
> On Tue, May 10, 2011 at 08:00:19PM +, Egbert Eich wrote:
>> I may have missed something, but - since the Wayland compositor
>> already picks a platform backend, opens a connection and initializes the
>> backend specific display data structure it doesn't make sense
>> to let egl pick a platform. If it picks a different one the
>> display specific data structure will most likely not match.
>> Thus determine the platform in the Wayland rendering backend by setting
>> the EGL_PLATFORM env variable.
>> For the client any other platform than 'wayland' doesn't seem to make
>> sense.
>> I'm not sure if I've got the the platform ofr openfwd right.
>>
>> Signed-off-by: Egbert Eich
>
> This is one of many ways to hack around the somewhat deficient platform
> selection in EGL (which in turn is a product of attempting to implement
> the spec as best as they can).
>
> Some sort of architectural fix for mesa would probably be preferred, but
> nobody has yet found one that people will agree on.
Indeed. I'll commit this patch for now, since I've had enough of
failing to set EGL_PLATFORM and then trying to figure out why it
breaks. The best solution I know of at this point is a "magic" way to
look at the native display argument and detect what kind it is. So
for example, stat it to see if it's a char device, in which case we
decide it's the drm platform. If not, assume it's a pointer a struct
and see if the first field looks like a valid pointer (not NULL and a
multiple of 4), in which case we assume it's a X display pointer
(Xlib.h, line 506). For the wl_display struct we can make the first
field a pointer to a wayland symbol which will let us distinguish it
from an X display pointer.
It's ugly and magic, but given the API we're stuck with, it's a fine workaround.
Kristian
> --CJD
>
>> ---
>> clients/window.c | 1 +
>> compositor/compositor-drm.c | 1 +
>> compositor/compositor-openwfd.c | 1 +
>> compositor/compositor-wayland.c | 1 +
>> compositor/compositor-x11.c | 1 +
>> 5 files changed, 5 insertions(+), 0 deletions(-)
>>
>> diff --git a/clients/window.c b/clients/window.c
>> index 9d0b753..8c3f8d2 100644
>> --- a/clients/window.c
>> +++ b/clients/window.c
>> @@ -1757,6 +1757,7 @@ init_egl(struct display *d)
>> EGL_NONE
>> };
>>
>> + setenv("EGL_PLATFORM", "wayland", 1);
>> d->dpy = eglGetDisplay(d->display);
>> if (!eglInitialize(d->dpy, &major, &minor)) {
>> fprintf(stderr, "failed to initialize display\n");
>> diff --git a/compositor/compositor-drm.c b/compositor/compositor-drm.c
>> index 4897b38..9fc5b49 100644
>> --- a/compositor/compositor-drm.c
>> +++ b/compositor/compositor-drm.c
>> @@ -269,6 +269,7 @@ init_egl(struct drm_compositor *ec, struct udev_device
>> *device)
>> return -1;
>> }
>>
>> + setenv("EGL_PLATFORM", "drm", 1);
>> ec->drm.fd = fd;
>> ec->base.display = eglGetDisplay(FD_TO_EGL_NATIVE_DPY(ec->drm.fd));
>> if (ec->base.display == NULL) {
>> diff --git a/compositor/compositor-openwfd.c
>> b/compositor/compositor-openwfd.c
>> index 0ddde52..ccd3dce 100644
>> --- a/compositor/compositor-openwfd.c
>> +++ b/compositor/compositor-openwfd.c
>> @@ -118,6 +118,7 @@ init_egl(struct wfd_compositor *ec)
>> return -1;
>>
>> ec->wfd_fd = fd;
>> + setenv("EGL_PLATFORM", "drm", 1);
>> ec->base.display = eglGetDisplay(FD_TO_EGL_NATIVE_DPY(ec->wfd_fd));
>> if (ec->base.display == NULL) {
>> fprintf(stderr, "failed to create display\n");
>> diff --git a/compositor/compositor-wayland.c
>> b/compositor/compositor-wayland.c
>> index 1a53e8d..6cd02ed 100644
>> --- a/compositor/compositor-wayland.c
>> +++ b/compositor/compositor-wayland.c
>> @@ -111,6 +111,7 @@ wayland_compositor_init_egl(struct wayland_compositor *c)
>> EGL_NONE
>> };
>>
>> + setenv("EGL_PLATFORM", "wayland", 1);
>> c->base.display = eglGetDisplay(c->parent.display);
>> if (c->base.display == NULL) {
>> fprintf(stderr, "failed to create display\n");
>> diff --git a/compositor/compositor-x11.c b/compositor/compositor-x11.c
>> index ac31881..3517fad 100644
>> --- a/compositor/compositor-x11.c
>> +++ b/compositor/compositor-x11.c
>> @@ -113,6 +113,7 @@ x11_compositor_init_egl(struct x11_compositor *c)
>> EGL_NONE
>> };
>>
>> + setenv("EGL_PLATFORM", "x11", 1);
>> c->base.display = eglGetDisplay(c->dpy);
>> if (c->base.display == NULL) {
>> fprintf(stderr, "failed to create display\n");
>> --
>> 1.7.3.4
>>
>>
>> ___
>> wayland-devel mailing list
>> wayland-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> htt
[PATCH] egl/wayland: flush connection data in eglSwapBuffers
This ensures we call wl_display_flush () as part of handling
eglSwapBuffers. The spec for SwapBuffers only explicitly requires
flushing commands for the current rendering API (e.g. glFlush() for GL
or vgFlush() for OpenVG) but it also seems appropriate to flush the swap
request itself too and arguably it feels more consistent with how other
EGL platform bindings behave besides slightly simplifying porting
existing EGL apps to wayland.
---
src/egl/drivers/dri2/platform_wayland.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/egl/drivers/dri2/platform_wayland.c
b/src/egl/drivers/dri2/platform_wayland.c
index 1b75ffe..35c91ae 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -504,11 +504,11 @@ dri2_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp,
_EGLSurface *draw)
dri2_surf->base.Width, dri2_surf->base.Height);
}
- _EGLContext *ctx;
- if (dri2_drv->glFlush) {
- ctx = _eglGetCurrentContext();
- if (ctx && ctx->DrawSurface == &dri2_surf->base)
+ _EGLContext *ctx = _eglGetCurrentContext();
+ if (ctx && ctx->DrawSurface == &dri2_surf->base) {
+ if (dri2_drv->glFlush)
dri2_drv->glFlush();
+ wl_display_flush (dri2_dpy->wl_dpy->display);
}
(*dri2_dpy->flush->flush)(dri2_surf->dri_drawable);
--
1.7.0.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] compositor: Set EGL_PLATFORM env variable for each backend.
On Tue, May 10, 2011 at 08:00:19PM +, Egbert Eich wrote:
> I may have missed something, but - since the Wayland compositor
> already picks a platform backend, opens a connection and initializes the
> backend specific display data structure it doesn't make sense
> to let egl pick a platform. If it picks a different one the
> display specific data structure will most likely not match.
> Thus determine the platform in the Wayland rendering backend by setting
> the EGL_PLATFORM env variable.
> For the client any other platform than 'wayland' doesn't seem to make
> sense.
> I'm not sure if I've got the the platform ofr openfwd right.
>
> Signed-off-by: Egbert Eich
This is one of many ways to hack around the somewhat deficient platform
selection in EGL (which in turn is a product of attempting to implement
the spec as best as they can).
Some sort of architectural fix for mesa would probably be preferred, but
nobody has yet found one that people will agree on.
--CJD
> ---
> clients/window.c|1 +
> compositor/compositor-drm.c |1 +
> compositor/compositor-openwfd.c |1 +
> compositor/compositor-wayland.c |1 +
> compositor/compositor-x11.c |1 +
> 5 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/clients/window.c b/clients/window.c
> index 9d0b753..8c3f8d2 100644
> --- a/clients/window.c
> +++ b/clients/window.c
> @@ -1757,6 +1757,7 @@ init_egl(struct display *d)
> EGL_NONE
> };
>
> + setenv("EGL_PLATFORM", "wayland", 1);
> d->dpy = eglGetDisplay(d->display);
> if (!eglInitialize(d->dpy, &major, &minor)) {
> fprintf(stderr, "failed to initialize display\n");
> diff --git a/compositor/compositor-drm.c b/compositor/compositor-drm.c
> index 4897b38..9fc5b49 100644
> --- a/compositor/compositor-drm.c
> +++ b/compositor/compositor-drm.c
> @@ -269,6 +269,7 @@ init_egl(struct drm_compositor *ec, struct udev_device
> *device)
> return -1;
> }
>
> + setenv("EGL_PLATFORM", "drm", 1);
> ec->drm.fd = fd;
> ec->base.display = eglGetDisplay(FD_TO_EGL_NATIVE_DPY(ec->drm.fd));
> if (ec->base.display == NULL) {
> diff --git a/compositor/compositor-openwfd.c b/compositor/compositor-openwfd.c
> index 0ddde52..ccd3dce 100644
> --- a/compositor/compositor-openwfd.c
> +++ b/compositor/compositor-openwfd.c
> @@ -118,6 +118,7 @@ init_egl(struct wfd_compositor *ec)
> return -1;
>
> ec->wfd_fd = fd;
> + setenv("EGL_PLATFORM", "drm", 1);
> ec->base.display = eglGetDisplay(FD_TO_EGL_NATIVE_DPY(ec->wfd_fd));
> if (ec->base.display == NULL) {
> fprintf(stderr, "failed to create display\n");
> diff --git a/compositor/compositor-wayland.c b/compositor/compositor-wayland.c
> index 1a53e8d..6cd02ed 100644
> --- a/compositor/compositor-wayland.c
> +++ b/compositor/compositor-wayland.c
> @@ -111,6 +111,7 @@ wayland_compositor_init_egl(struct wayland_compositor *c)
> EGL_NONE
> };
>
> + setenv("EGL_PLATFORM", "wayland", 1);
> c->base.display = eglGetDisplay(c->parent.display);
> if (c->base.display == NULL) {
> fprintf(stderr, "failed to create display\n");
> diff --git a/compositor/compositor-x11.c b/compositor/compositor-x11.c
> index ac31881..3517fad 100644
> --- a/compositor/compositor-x11.c
> +++ b/compositor/compositor-x11.c
> @@ -113,6 +113,7 @@ x11_compositor_init_egl(struct x11_compositor *c)
> EGL_NONE
> };
>
> + setenv("EGL_PLATFORM", "x11", 1);
> c->base.display = eglGetDisplay(c->dpy);
> if (c->base.display == NULL) {
> fprintf(stderr, "failed to create display\n");
> --
> 1.7.3.4
>
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] compositor: Set EGL_PLATFORM env variable for each backend.
I may have missed something, but - since the Wayland compositor
already picks a platform backend, opens a connection and initializes the
backend specific display data structure it doesn't make sense
to let egl pick a platform. If it picks a different one the
display specific data structure will most likely not match.
Thus determine the platform in the Wayland rendering backend by setting
the EGL_PLATFORM env variable.
For the client any other platform than 'wayland' doesn't seem to make
sense.
I'm not sure if I've got the the platform ofr openfwd right.
Signed-off-by: Egbert Eich
---
clients/window.c|1 +
compositor/compositor-drm.c |1 +
compositor/compositor-openwfd.c |1 +
compositor/compositor-wayland.c |1 +
compositor/compositor-x11.c |1 +
5 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/clients/window.c b/clients/window.c
index 9d0b753..8c3f8d2 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -1757,6 +1757,7 @@ init_egl(struct display *d)
EGL_NONE
};
+ setenv("EGL_PLATFORM", "wayland", 1);
d->dpy = eglGetDisplay(d->display);
if (!eglInitialize(d->dpy, &major, &minor)) {
fprintf(stderr, "failed to initialize display\n");
diff --git a/compositor/compositor-drm.c b/compositor/compositor-drm.c
index 4897b38..9fc5b49 100644
--- a/compositor/compositor-drm.c
+++ b/compositor/compositor-drm.c
@@ -269,6 +269,7 @@ init_egl(struct drm_compositor *ec, struct udev_device
*device)
return -1;
}
+ setenv("EGL_PLATFORM", "drm", 1);
ec->drm.fd = fd;
ec->base.display = eglGetDisplay(FD_TO_EGL_NATIVE_DPY(ec->drm.fd));
if (ec->base.display == NULL) {
diff --git a/compositor/compositor-openwfd.c b/compositor/compositor-openwfd.c
index 0ddde52..ccd3dce 100644
--- a/compositor/compositor-openwfd.c
+++ b/compositor/compositor-openwfd.c
@@ -118,6 +118,7 @@ init_egl(struct wfd_compositor *ec)
return -1;
ec->wfd_fd = fd;
+ setenv("EGL_PLATFORM", "drm", 1);
ec->base.display = eglGetDisplay(FD_TO_EGL_NATIVE_DPY(ec->wfd_fd));
if (ec->base.display == NULL) {
fprintf(stderr, "failed to create display\n");
diff --git a/compositor/compositor-wayland.c b/compositor/compositor-wayland.c
index 1a53e8d..6cd02ed 100644
--- a/compositor/compositor-wayland.c
+++ b/compositor/compositor-wayland.c
@@ -111,6 +111,7 @@ wayland_compositor_init_egl(struct wayland_compositor *c)
EGL_NONE
};
+ setenv("EGL_PLATFORM", "wayland", 1);
c->base.display = eglGetDisplay(c->parent.display);
if (c->base.display == NULL) {
fprintf(stderr, "failed to create display\n");
diff --git a/compositor/compositor-x11.c b/compositor/compositor-x11.c
index ac31881..3517fad 100644
--- a/compositor/compositor-x11.c
+++ b/compositor/compositor-x11.c
@@ -113,6 +113,7 @@ x11_compositor_init_egl(struct x11_compositor *c)
EGL_NONE
};
+ setenv("EGL_PLATFORM", "x11", 1);
c->base.display = eglGetDisplay(c->dpy);
if (c->base.display == NULL) {
fprintf(stderr, "failed to create display\n");
--
1.7.3.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] display: Adds wl_display_flush to send buffered commands
On Tue, May 10, 2011 at 12:51 PM, Robert Bragg wrote: > Previously for wayland clients to flush buffered connection data to the > compositor they needed to first register an event-mask-update-callback > via wl_display_get_fd() to determine if there is anything writeable > pending. (NB: It's considered an error to iterate connection data with > an invalid mask) > > Since it's only possible to register a single update callback currently > it's a bit awkward if you want to allow multiple orthogonal components > to flush the connection data, such as Cogl and Clutter which both want > to interact with wayland and may want to flush commands at different > times. > > This adds a mechanism, wl_display_flush(), which makes it possible to > flush writeable connection data without first checking the event mask. Yup, good point. Patch pushed. Kristian ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] display: Adds wl_display_flush to send buffered commands
Previously for wayland clients to flush buffered connection data to the
compositor they needed to first register an event-mask-update-callback
via wl_display_get_fd() to determine if there is anything writeable
pending. (NB: It's considered an error to iterate connection data with
an invalid mask)
Since it's only possible to register a single update callback currently
it's a bit awkward if you want to allow multiple orthogonal components
to flush the connection data, such as Cogl and Clutter which both want
to interact with wayland and may want to flush commands at different
times.
This adds a mechanism, wl_display_flush(), which makes it possible to
flush writeable connection data without first checking the event mask.
---
wayland/wayland-client.c |7 +++
wayland/wayland-client.h |1 +
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/wayland/wayland-client.c b/wayland/wayland-client.c
index 531807d..59c68f7 100644
--- a/wayland/wayland-client.c
+++ b/wayland/wayland-client.c
@@ -593,6 +593,13 @@ wl_display_iterate(struct wl_display *display, uint32_t
mask)
}
}
+WL_EXPORT void
+wl_display_flush(struct wl_display *display)
+{
+ while (display->mask & WL_DISPLAY_WRITABLE)
+ wl_display_iterate (display, WL_DISPLAY_WRITABLE);
+}
+
WL_EXPORT uint32_t
wl_display_allocate_id(struct wl_display *display)
{
diff --git a/wayland/wayland-client.h b/wayland/wayland-client.h
index f1ac797..eefb840 100644
--- a/wayland/wayland-client.h
+++ b/wayland/wayland-client.h
@@ -60,6 +60,7 @@ int wl_display_get_fd(struct wl_display *display,
wl_display_update_func_t update, void *data);
uint32_t wl_display_allocate_id(struct wl_display *display);
void wl_display_iterate(struct wl_display *display, uint32_t mask);
+void wl_display_flush(struct wl_display *display);
int wl_display_sync_callback(struct wl_display *display,
wl_display_sync_func_t func, void *data);
int wl_display_frame_callback(struct wl_display *display,
--
1.7.0.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
