[PATCH] Update .gitignore
--- compositor/.gitignore |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/compositor/.gitignore b/compositor/.gitignore index 847efbd..6e8eb59 100644 --- a/compositor/.gitignore +++ b/compositor/.gitignore @@ -1,4 +1,4 @@ -compositor +wayland-compositor screenshooter-protocol.c screenshooter-server-protocol.h meego-tablet-protocol.c -- 1.7.5.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] egl: Link wayland-drm.a into libEGL after egl_dri2
Fixes the following build error in wayland-demos: CCLD wayland-compositor /usr/lib/libEGL.so: undefined reference to `wayland_drm_buffer_get_buffer' /usr/lib/libEGL.so: undefined reference to `wayland_drm_uninit' /usr/lib/libEGL.so: undefined reference to `wayland_buffer_is_drm' /usr/lib/libEGL.so: undefined reference to `wayland_drm_init' /usr/lib/libEGL.so: undefined reference to `wl_drm_interface' --- src/egl/main/Makefile |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/egl/main/Makefile b/src/egl/main/Makefile index 6c24255..6c4a392 100644 --- a/src/egl/main/Makefile +++ b/src/egl/main/Makefile @@ -54,10 +54,6 @@ OBJECTS = $(SOURCES:.c=.o) LOCAL_CFLAGS = -D_EGL_OS_UNIX=1 LOCAL_LIBS = -ifneq ($(findstring wayland, $(EGL_PLATFORMS)),) -LOCAL_LIBS += $(TOP)/src/egl/wayland/wayland-drm/libwayland-drm.a -endif - # egl_dri2 and egl_glx are built-ins ifeq ($(filter dri2, $(EGL_DRIVERS_DIRS)),dri2) LOCAL_CFLAGS += -D_EGL_BUILT_IN_DRIVER_DRI2 @@ -68,6 +64,10 @@ endif EGL_LIB_DEPS += $(LIBUDEV_LIBS) $(DLOPEN_LIBS) $(LIBDRM_LIB) $(WAYLAND_LIBS) endif +ifneq ($(findstring wayland, $(EGL_PLATFORMS)),) +LOCAL_LIBS += $(TOP)/src/egl/wayland/wayland-drm/libwayland-drm.a +endif + ifeq ($(filter glx, $(EGL_DRIVERS_DIRS)),glx) LOCAL_CFLAGS += -D_EGL_BUILT_IN_DRIVER_GLX LOCAL_LIBS += $(TOP)/src/egl/drivers/glx/libegl_glx.a -- 1.7.5.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
Michal Suchanek wrote: In the case of a resize event the response includes submitting a buffer containing resized window content to the compositor. The compositor requires this new resized content to draw the window so it cannot be avoided. I think the concern was when a client decided that the current window size is correct. This can happen if the window is not resizable, or size limits or increments or anything else cause the requested size to be rounded to the same size as it is currently. I think there is also a problem in that the compositor cannot be absolutely certain that a given resize is in response to a resize request. What I was proposing is that there is a clear "echo" of all events back to the compositor, so the compositor can know that event has been handled by the client. This would be sent after the resizing, or sent by itself if the client decided not to resize. Echos can be consolidated. An echo saying a given event was handled would also indicate that all earlier events were handled. This is necessary to make it easier to write clients that want to consolidate incoming events, for instance to only handle the last of a whole string of resize requests. The echo can also indicate that the client explicitly did not handle an event and it wants the compoitor to do so. This can allow reuse of the compositor locked-client window handling by normal clients. It also would allow clients to indicate ignored keystrokes so the compositor can do something with them, allowing a lot more global shortcut possibilities. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Window Management Proposal
On 17 May 2011 18:01, Sam Spilsbury wrote: >> I think the wayland compositor could track how long the clients take to >> respond to events. They would only disable if they suddenly took several >> times longer than before. If the recorded lag exceeds a threshold the >> compositor could resort to rubber-band resize. > > What is a "response to an event"? > > Avoiding a system where clients are making needless communication with > the compositor all the time just so that you can implement a fall-back > policy when client-side policy doesn't work would probably be a good > thing. In the case of a resize event the response includes submitting a buffer containing resized window content to the compositor. The compositor requires this new resized content to draw the window so it cannot be avoided. Thanks Michal ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
