Re: Texture object locking

Jason wrote: Kristian and I were looking at this today, and there seems to be a substantial race in the way that we are doing texture locking. Yes, it does look like this is a problem. I also noticed another dodgy-looking pattern when implementing the GL_ARB_clear_texture extension. Whenever

[PATCH weston] Apply output transform to the cursor while copying into a plane

Previously if the output had a transform then the cursor plane would be disabled. However as we have to copy the cursor image into a buffer with the CPU anyway it probably won't cost much extra to also apply the transform in the process and then we can avoid disabling the plane. If the transform

Re: [PATCH 3/4] Add a macro to get the opcode number of a request given the interface

Jason Ekstrand ja...@jlekstrand.net writes: Ooh, I like this. I thought about having wayland-scanner emit more #defines, but this works rather nicely. One question: do we want it in wayland-util or wayland-server? Putting it in wayland-util exposes it client-side as well. --Jason Yeah, I

Re: [PATCH weston 1/4] Handle requests using outputs that have been unplugged

Jason Ekstrand ja...@jlekstrand.net writes: Yeah, these are the wrong semantics. If they specify an output and it turns out to be a zombie, we should do nothing. A null output in wl_fullscreen_shell.present_surface means put it somewhere. In the case of weston's implementation, it goes on

Re: [PATCH weston 1/4] Handle requests using outputs that have been unplugged

Jason Ekstrand ja...@jlekstrand.net writes: The destructor passed in here should be 0, why is it ~0? Also, it might be a good idea to throw it in a #define or enum for clarity. The ~0 is meant to signify ‘there is no destructor’, ie, it's a fake opcode that will never match a request. The

[PATCH] Add wl_resource_get_implementation

This gets the implementation for a resource that was set in the implementation argument of wl_resource_set_implementation or wl_resource_set_dispatcher. This is mostly useful in conjuction with a dispatcher which may want to dispatch via the implementation pointers or just store some extra

[PATCH v2] Add a macro to get the opcode number of a request given the interface

Here is a version two of the patch which moves the macro to wayland-server.h and fixes a typo in the docs. - Neil --- 8 --- (use git am --scissors to automatically chop here) This adds a macro called WL_REQUEST_OPCODE which takes the name of the struct for the interface and the

[PATCH weston v2] Handle wl_output.release

Here is a version two of the patch which is just needed so that the patches can be reordered and this can come before the patch to handle zombies. --- 8 --- (use git am --scissors to automatically chop here) The wl_output.release request is now handled. It just causes the

[PATCH weston v2] Handle requests using outputs that have been unplugged

Version 2 of the patch makes the following changes: • The patch is reordered to be on top of the patch to handle wl_output.release so that it doesn't need to have a dummy marker for zombifying without a destructor. • The destructor opcode is stored in the implementation pointer rather than

[PATCH weston 1/4] Handle requests using outputs that have been unplugged

Previously when an output was unplugged the clients' resources for it were left around and if they were used in a request it could cause Weston to access invalid memory. Now when an output is unplugged the resources for it are marked as zombies. This is done by setting a dummy dispatcher and

[PATCH 2/4] Add a release request to wl_output

Outputs can come and go within the compositor. If we don't have a way for the client to destroy the resource then the resources within the compositor will effectively leak until the client disconnects. This is similar to the release event for wl_pointer. --- protocol/wayland.xml | 8 +++- 1

[PATCH weston 4/4] Handle wl_output.release

The wl_output.release request is now handled. It just causes the resource to be destroyed. This is also set as the destructor when zombifying the resource. --- src/compositor.c | 23 +++ 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/src/compositor.c

[PATCH 3/4] Add a macro to get the opcode number of a request given the interface

This adds a macro called WL_REQUEST_OPCODE which takes the name of the struct for the interface and the name of one of its members. It then calculates the opcode number by dividing the offsetof the member by the size of a function pointer. This assumes the interface struct only contains function

Re: [PATCH v2] configure.ac: Change in build system to use the path from pkg-config for wayland-scanner.

Hi, Srivardhan Hebbar sri.heb...@samsung.com writes: +AC_PATH_PROG([wayland_scanner], [wayland-scanner],, + [${WAYLAND_SCANNER_PATH}]) I don't think it makes much sense to search the path for wayland-scanner when pkg-config already gives you the complete filename. Instead of

Re: [PATCH] Destroy resources when destroying input and output

After looking at it a bit more I don't think we can really make the automatic zombie idea work. The trouble is that libwayland-server would need to know when the client has destroyed the proxy in order to destroy the zombie resource. However the destroy semantics are interface-dependent so only an

Re: [PATCH] Destroy resources when destroying input and output

Perhaps we should consider applying the patch anyway even though it's not ideal. Currently if a client uses a dead output in a request such as xdg_surface.set_output Weston will end up with a weston_output pointer that points to freed memory. This could cause the compositor to crash. That is worse

Re: [PATCH] Destroy resources when destroying input and output

Jason Ekstrand ja...@jlekstrand.net writes: Most of the magic there is in allowing resources with no handler in libwayland-server. The patch would be about 4 lines. Right now, client-side wl_proxy objects are allowed to have a NULL implementation and there's no problem; server-side, this is

[PATCH weston] Destroy resources when destroying an output

When an output is destroyed it now also destroys any resources that were pointing to it. Otherwise if the resource is destroyed after the output then the resource would try to remove itself from the resource list but the head of the resource list would no longer be valid and it would write to

[PATCH weston] simple-touch: Handle multiple seats

Previously simple-touch would only handle one seat. If there were multiple seats it would lose track of whether there is a touch device available depending on what order the capability events arrive in. This makes it keep a linked list of seats and to track a separate touch device for each seat so

Re: [PATCH weston 2/3] simple-touch: Handle multiple seats properly

Oh no, I didn't notice this patch buried in the patch series and implemented the same thing: http://lists.freedesktop.org/archives/wayland-devel/2014-May/014690.html Ander, it would be really helpful if you could leave a little note on the bug report if you post a patch to reduce that chance

Re: [PATCH 1/3] protocol: Add an event to specify the name of an output

Pekka Paalanen ppaala...@gmail.com writes: were you aware of […] perhaps? :-) Ah, no, I hadn't noticed those patches. Oops! Your series is almost identical to Quanxian's, except: - wording differences, of course - patch 2 checks if output-name is set before sending (can it ever be NULL?)

[PATCH weston] Apply the zoom transformation before the output transformation

The zoom translation is just a scale and a translate. The translation is calculated based on the coordinates of the pointer which are in global space. Previously the calculated translation was transformed by the output transformation so that when the zoom transform is applied after the output

Thoughts on getting surfaces to appear on the right output

Hi, Currently Weston has a problem that it always puts new surfaces on the same output as the one the first pointer is in. I guess the idea is that most of the time surfaces are created as a result of mouse events and there is usually only one pointer so it works most of the time. However of

Re: Thoughts on getting surfaces to appear on the right output

Bill Spitzak spit...@gmail.com writes: 1. It would seem more useful for the desktop shell to send some info about how the client was launched in environment variables. Yes, maybe it would be cleaner to agree on some protocol for the parent process to send the information directly to the child.

[PATCH weston] Take into account the zoom when applying the output transform

When converting output-relative coordinates (such as from an input event) to global coordinates it now takes into account the zoom transform. Previously this would only work for the primary pointer because the transform doesn't affect the primary pointer position due to that way zoom follows the

[PATCH weston] drm: Don't use the cursor overlay if the scale doesn't match

If the scale for the cursor surface doesn't match that of the output then we shouldn't use the cursor overlay because otherwise it will be drawn at the wrong size. This problem is particularly noticable with multiple pointers because it randomly alternates between drawing one cursor or the other

[PATCH 1/3] protocol: Add an event to specify the name of an output

This bumps the version of the wl_output interface to 3 and adds a separate event to report the output's name. --- protocol/wayland.xml | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 330f8ab..60fa81e 100644 ---

[PATCH weston 2/3] Send the new wl_output.name event when binding an output

This version for the wl_output interface has been changed to 3 and it now sends out the name event when a client binds an output. --- src/compositor.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/compositor.c b/src/compositor.c index ee8dc24..6a333df 100644 ---

[PATCH weston 3/3] weston-info: Display the name from the new wl_output.name event

If the compositor supports version 3 of the wl_output interface and sends a name event then this will now be displayed in the info. --- clients/weston-info.c | 39 ++- 1 file changed, 38 insertions(+), 1 deletion(-) diff --git a/clients/weston-info.c

[PATCH weston] Simply the matrix calculation for zooming

In order to apply the zoom transformation to the output matrix, Weston was doing the following: • Create a temporary matrix to hold the translation • Invert the translation matrix using weston_matrix_invert into another temporary matrix • Scale that matrix by the scale factor • Multiply the

Re: [PATCH weston 3/4] evdev: Fix assertion error for unplugged output with paired touchscreen

I think I wrote the goto handled code. The advantage of that over putting the assert in the default handler is that if a new event type is added to the evdev_event_type enum then GCC will give a nice warning for that switch statement so we'd know we need to add a handler for it. I think I would

[PATCH weston] Assign any output to a seat if it doesn't have one

Commit 4ade0e4a29 changed the order of initialising the seats and outputs so that the seats would be done before the outputs. However the device_added function in libinput-seat and udev-seat which gets called during initialisation was trying to use the output list to assign an output to the

Re: [PATCH weston 4/4] input: Fix errors due to initializing input before creating outputs

I think we accientally wrote nearly identical patches at the same time: http://lists.freedesktop.org/archives/wayland-devel/2014-April/014392.html However, I still get the crash with Ander's patch because it looks like it is missing the check for wl_list_empty in the libinput-seat.c version of

[PATCH weston] clients/window: Don't remove the touch listener on a frame event

It looks like the handler for frame events from the wl_touch interface for widgets may have been erroneously copied from the cancel handler so that it removes all handlers as they are processed. I don't think this makes much sense for the frame event. This was stopping the panel icons from being

Re: [PATCH weston] compositor-drm: Fix crash when setting up seat constrained by an output

It looks like this patch makes Weston crash on touch events. The device_added functions in udev-seat.c and libinput-seat.c try to use the output list in order to assign the output for the newly created device. These functions get called via udev_input_init so I guess that means this function and

Re: An idea for a newbie project: Wayland protocol dumper

I think this could be really useful. I've struggled a few times trying to filter the output from WAYLAND_DEBUG=server when I only want to know about a particular client. Pekka Paalanen ppaala...@gmail.com writes: - Some messages carry file descriptors. Is it possible to write a proxy without

[PATCH weston 1/2] Reset focus on unknown seats when restoring focus state

The focus_state list on a workspace only contains entries for seats which have a keyboard focus on that workspace. For workspaces that have no surfaces the list will be empty. That means that when a workspace with no surfaces is switched to it would previously leave the keyboard focus unaffected

[PATCH weston 2/2] Reset the keyboard focus on all seats when the compositor is locked

Before commit 2f5faff7f9142 when the compositor is locked it would reset the keyboard focus on all of the seats as part of pushing the focus_state. This was removed because it now always keeps track of the focus_state in the workspace instead of waiting until the state is pushed. However this had

Re: [PATCH weston 2/2] Reset the keyboard focus on all seats when the compositor is locked

Jasper St. Pierre jstpie...@mecheye.net writes: Why is this necessary? Won't events never be delivered while locked anyway? Events do seem to get delivered, you can try it if you run weston -i5 and then open a terminal and let it lock. You can still type in the terminal and launch programs.

[PATCH weston] gl-renderer: Keep track of the GL format used for SHM buffers

Jason Ekstrand wrote: We may still have a problem if the client changes buffer formats mid-stream. Say it starts out with RGB565 to save memory but latter decides it wants alpha so it switches to ARGB. We should probably detect this and make sure glTexImage2D gets called again to reset

[PATCH weston] Always use glTexImage2D instead of glTexSubImage2D for first upload

Previously when uploading SHM data we would initialise the texture with glTexImage2D and NULL data when the buffer is attached. Then if the GL_EXT_unpack_subimage extension is available we would always use glTexSubImage2D to upload the data. The problem with that is that the first glTexImage2D was

Re: [Mesa-dev] [PATCH 0/7] EGL_MESA_configless_context

Kristian Høgsberg k...@bitplanet.net writes: Thanks Neil, series applied to mesa and weston. Great, thanks! I've reposted the piglit patch to the piglit list in case someone wants to review it there. Regards, - Neil ___ wayland-devel mailing list

[PATCH mesa 3/7] eglCreateContext: Remove the check for whether config == 0

In eglCreateContext there is a check for whether the config parameter is zero and in this case it will avoid reporting an error if the EGL_KHR_surfacless_context extension is supported. However there is nothing in that extension which says you can create a context without a config and Mesa breaks

[PATCH mesa 4/7] Add the EGL_MESA_configless_context extension

/null +++ b/docs/specs/MESA_configless_context.spec @@ -0,0 +1,120 @@ +Name + +MESA_configless_context + +Name Strings + +EGL_MESA_configless_context + +Contact + +Neil Roberts neil.s.robe...@intel.com + +Status + +Proposal + +Version + +Version 1, February 28, 2014 + +Number

[PATCH piglit 5/7] Add a test for EGL_MESA_configless_context

OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS + * IN THE SOFTWARE. + * + * Authors: Neil Roberts neil.s.robe...@intel.com + * Kristian Høgsberg k...@bitplanet.net + */ + +/** @file egl-configless-context.c + * + * Test

[PATCH 0/7] EGL_MESA_configless_context

Here is a series of patches to add an extension which makes it possible to create an EGL context without specifying a config. A context created in this way can be bound with any surface using the same EGLDisplay rather than being restricted to those using the same config. The main use case is that

[PATCH weston 7/7] Add support for having different GBM formats for different outputs

The gbm-format configuration option can now be specified per-output as well as in the core config section. If it is not specified it will default to the format specified in the core section. The EGL_MESA_configless_context extension is required for this to work. If this extension is available it

[PATCH mesa 2/7] Fix the initial value of glDrawBuffers for GLES

Under GLES 3 it is not valid to pass GL_FRONT to glDrawBuffers. Instead, GL_BACK has a magic interpretation which means it will render to the front buffer on single-buffered contexts and the back buffer on double-buffered. We were incorrectly setting the initial value to GL_FRONT for

[PATCH mesa 1/7] Use the magic behaviour of GL_BACK in GLES 1 and 2 as well as 3

In GLES 3 it is not possible to select rendering to the front buffer and instead selecting GL_BACK has the magic interpretation that it is either the front buffer on single-buffered configs or the back buffer on double-buffered. GLES 1 and 2 have no way of selecting the draw buffer at all. In that

[PATCH weston v2] Add a nested YUV client to the weston-nested example

Here is a second version of the patch to match with the changes in v2 of the extension. Regards, - Neil --- 8 --- (use git am --scissors to automatically chop here) This adds a separate nested client to the weston-nested example which will create YUV buffers using libva. The

[PATCH weston] nested: Disable cairo on the subsurfaces

The subsurface widgets on the nested example aren't using Cairo to render so we should turn it off to prevent the toy toolkit from creating a redundant extra surface for it. This is particularly important since Mesa commit 6c9d6898fdfd7e2 because the surface that the toolkit tries to create is

[PATCH v2] Adapt the EGL_WL_create_wayland_buffer_from_image extension for YUV

pixel format. @@ -99,3 +143,6 @@ Revision History Initial draft (Neil Roberts) Version 2, October 25, 2013 Added a note about more possible reasons for returning EGL_BAD_FORMAT. +Version 3, February 5, 2014 +Support for passing multiple images in order

[PATCH mesa 3/3] Adapt the EGL_WL_create_wayland_buffer_from_image extension for YUV

, these problems can be but are not limited to unsupported tiling modes, inaccessible memory or an unsupported pixel format. @@ -99,3 +133,6 @@ Revision History Initial draft (Neil Roberts) Version 2, October 25, 2013 Added a note about more possible reasons

[PATCH mesa 1/3] wayland: Keep track of the formats in a sorted array instead of flags

In order to support YUV formats in CreateWaylandBufferFromImageWL we need to be able to check whether the compositor supports a larger number of formats so storing them in flags is a bit awkard. Instead all of the formats are now stored in a sorted array using wl_array. A binary search is used to

[PATCH] Don't deref the sample pointer in the wl_container_of macro

The previous implementation of the wl_container_of macro was dereferencing the sample pointer in order to get an address of the member to calculate the offset. Ideally this shouldn't cause any problems because the dereference doesn't actually cause the address to be read from so it shouldn't

Re: Make safe double remove?

Jonathan Howard jonat...@unbiased.name writes: wl_list_remove changed isn't 100% guaranteed to not break anything, on the other hand there is no guarantee the code does not have the fatal double remove already. We definitely do already have a double-remove bug in Weston as described here:

Re: weston crash in destroy_shell_surface

It looks like the rest of the code assumes that shsurf-children_link is always a consistent list. For example, shell_surface_set_parent resets children_link to the empty list after it unlinks a child from its parent. The destroy_shell_surface code just calls wl_list_remove which leaves the list

[PATCH weston] westoy: Add an option to explicitly disable cairo on a widget

This problem was found while looking at the following bug: https://bugs.freedesktop.org/show_bug.cgi?id=72612 It turns out the patch doesn't help to fix the bug but I think it would be a good thing to do anyway. --- 8 --- (use git am --scissors to automatically chop here) The

[PATCH weston] tests: Test whether a simple EGL main loop uses too many buffers

Hi, Here is a rebased version of the patch. The old one didn't apply cleanly anymore because of some changes in tests/Makefile.am I think there is some confusion about why it ends up using 3 buffers and I also keep getting in a muddle about it. I'll try to describe what I think is happening

Re: [PATCH] Flush the wl_display at the end of SwapBuffers

a dispatch. That patch also moves the call to dri2_dpy-flush-flush further up. I'm not sure if that is necessary. It also adds a pointer to the wl_display in struct dri2_egl_surface which definitely looks unnecessary. So I think Axel's patch makes more sense. Reviewed-by: Neil Roberts n

Re: [PATCH weston] Automatically generate weston.ini with the right paths

Kristian Høgsberg hoegsb...@gmail.com writes: That's a nice idea. Could we just generate it from configure.ac by listing it in AC_CONFIG_FILES? Sadly that doesn't work because the autoconf expansions still include variables for make. Eg, @bindir@ expands to ${exec_prefix}/bin. I think that is

Re: [PATCH 0/10] Add a mechanism for nested compositors to use subsurfaces without blitting

Hi, I think this thread has gotten a bit tangled so I've done a bit of minor rebasing for the patches and pushed them all to github: https://github.com/bpeel/wayland/commits/wip/wayland-subcompositor https://github.com/bpeel/mesa/commits/wip/wayland-subcompositor

[PATCH weston] Automatically generate weston.ini with the right paths

Previously weston.ini had hardcoded paths for the weston-* clients in /usr/bin and /usr/libexec. This was a bit annoying when testing Weston because you wouldn't usually install those in the system prefix. This patch adds a make rule to automatically generate weston.ini from a template file with

Re: Thoughts about decoration information in the xdg_shell

Thiago Macieira thiago.macie...@intel.com writes: Make it simpler: all clients MUST be able to draw decorations. That's what Wayland up until now requires anyway. I think it's a shame to throw out the idea of making the policy be that clients are allowed to expect SSD if they don't want to

[PATCH mesa 1/2] wayland: Block for the frame callback in get_back_bo not dri2_swap_buffers

As per Kristian's suggestion we can avoid the problem of effectively disabling the event queuing mechanism by only doing the sync request when the swap interval is zero. To fix the bug of using three buffers we can just block for the frame callback in get_back_bo instead of swap_buffers. I was

[PATCH mesa v5 2/2] wayland: Add support for eglSwapInterval

The Wayland EGL platform now respects the eglSwapInterval value. The value is clamped to either 0 or 1 because it is difficult (and probably not useful) to sync to more than 1 redraw. The main change is that if the swap interval is 0 then Mesa won't install a frame callback so that eglSwapBuffers

[PATCH] Add documentation for wl_shm_buffer_begin/end_access

It's not obvious that these functions are needed so it would be good to have some documentation for them. --- doc/doxygen/Makefile.am | 3 ++- src/wayland-shm.c | 64 + 2 files changed, 66 insertions(+), 1 deletion(-) diff --git

[PATCH v2] server: Add API to protect access to an SHM buffer

Ok, here is a second version of the patch which leaves the signal handler permanently installed and uses thread-local storage to keep track of the current pool. Regards, - Neil --- 8 --- (use git am --scissors to automatically chop here) Linux will let you mmap a region of a

[PATCH weston v2] Add calls to wl_shm_buffer_begin/end_access

Thanks for the feedback. Here is a version two of the patch which fixes some merge conflicts on master and adds support for the pixman renderer. Kristian wrote: As for the pixman renderer it should be a matter of just wrapping the calls to pixman_image_composite32() in

Re: [PATCH mesa v4] wayland: Add support for eglSwapInterval

Tomeu Vizoso to...@tomeuvizoso.net writes: What I fail to see is why a single sync should be enough, as we don't know when the GPU will signal that it's done with the buffer that we are waiting to be released. You are right that we don't know when the GPU will release the buffer. However we

Re: [PATCH mesa v4] wayland: Add support for eglSwapInterval

Jason Ekstrand ja...@jlekstrand.net writes: You don't have to continuously sync, just sync after every attach/commit. While it may be somewhat non-obvious, I don't see how calling sync once per frame is any worse than setting some flag somewhere. Hrmm thinking about it, I suppose sending the

[PATCH weston] tests: Test whether a simple EGL main loop uses too many buffers

Here is a test case which demonstrates the 3 buffers problem. It is fixed by the eglSwapInterval patch because that installs a sync event, but note the problem isn't really related to eglSwapInterval and is something we should probably fix anyway. Regards, - Neil --- 8 --- (use

Re: [PATCH mesa v4] wayland: Add support for eglSwapInterval

Just to be clear, I think the discussion about whether to queue release events is no longer related to implementing eglSwapInterval(0) so it shouldn't hold up the patch. As far as I understand if you want to render at the maximum rate you need four buffer slots and being able to disable the

[PATCH mesa v3] wayland: Add an extension to create wl_buffers from EGLImages

Roberts +Axel Davy +Daniel Stone + +Contact + +Neil Roberts neil.s.robe...@intel.com + +Status + +Proposal + +Version + +Version 2, October 25, 2013 + +Number + +EGL Extension #not assigned + +Dependencies + +Requires EGL 1.4 or later. This extension is written against

[PATCH mesa v4] wayland: Add support for eglSwapInterval

Ok, here is version 4 of the patch taking into account the discussion with Jason Ekstrand. The assumption is that if we have enough buffer slots then we should always get a release event immediately after one of the attaches. That means we can just rely on sending a sync request after the commit

Re: Buffer release events (was: Add support for eglSwapInterval)

Hi Thanks for the interesting insights. It seems to me as if the default should always be to just send the event. I think I would vote for leaving the default as it is, ie, queuing the release events. It's really quite a corner case that delaying events has any effect on an application

[PATCH] protocol: Add a request to disable queuing of buffer release events

Adds a request called wl_surface.set_release which provides a way for a client to explicitly disable the queuing mechanism for buffer release events so that it can get them as soon as the buffer is no longer being used. This is useful for example when doing eglSwapInterval(0) because in that case

[PATCH weston 1/2] Implement wl_surface.set_release

Implements the wl_surface.set_release request which just causes the buffer release events to be sent with wl_resource_post_event instead of wl_resource_queue_event. The release mode is part of the double-buffered surface state and gets reset to the default as soon as a commit is performed on the

Re: Buffer release events (was: Add support for eglSwapInterval)

Neil Roberts n...@linux.intel.com writes: Currently the only proposed complete solution is just to add a request to explicitly disable the queuing mechanism. I started writing this patch but I've hit a stumbling block while trying to make use of it in Mesa. Adding the new request requires

[PATCH weston 2/2] Add a test for wl_surface.set_release

The test attaches a buffer and then verifies that it doesn't get the release event until a roundtrip is issued causing the event queue to flush. It then sets the release mode to immediate and then verifies that it doesn't need to do a roundtrip to get the release event. The default mode is then

Re: [PATCH v2] Post buffer release events instead of queue when no frame callback

Neil Roberts n...@linux.intel.com writes: I think that would mean you could cause tearing if you are using eglSwapInterval(0) because you could write into the released buffer while the GPU is actually still rendering the previous frame using the buffer in a texture. I think this doesn't

Re: Buffer release events (was: Add support for eglSwapInterval)

Here is a quick summary of the discussion about the release event handling that has partially happened on this list and partially on IRC. Currently the release events are put into a queue so that they are only sent alongside another event sent by the compositor in order to avoid waking up the

[PATCH weston 1/4] Add a touch binding to activate a surface

Adds a new binding type for touch events via the new function weston_compositor_add_touch_binding. The binding can only be added for a touch down with the first finger. The shell now uses this to install a binding to activate the current surface. --- src/bindings.c | 36

[PATCH weston 2/4] Add a touch move binding

When holding the compositor super key the touch events can now be used to move a window. --- src/shell.c | 21 + 1 file changed, 21 insertions(+) diff --git a/src/shell.c b/src/shell.c index 4a0c122..2822a2b 100644 --- a/src/shell.c +++ b/src/shell.c @@ -2774,6 +2774,26 @@

[PATCH weston 4/4] Don't remove the touch grab until the last touch point is removed

Previously if you move a window around and temporarily add a second finger then it will cancel the grab even though the original finger is still held on the screen. It seems more robust to avoid cancelling the grab until all fingers have been removed. --- src/shell.c | 4 +++- 1 file changed, 3

[PATCH weston 3/4] Only update the touch grab position for the first finger

Previously if you add a second finger while moving a window with a touch grab then the position will keep jumping between the position of each finger as you move them around. This patch changes it so that it keeps track of the first touch id that starts the grab and only updates the grab position

Re: [PATCH v2] Post buffer release events instead of queue when no frame callback

I don't think this function would help in cases where the buffer is released after the frame is drawn but the compositor is not drawing anything else. Ie, if the events were like this: 1 - client attaches a buffer and waits for the next release 2 - compositor redraws a frame 3 - the redraw

Re: [PATCH] server: Add API to protect access to an SHM buffer

Hi José Bollo jo...@nonadev.net writes: That is a really interesting point. I have two questions about it: - Is it normal that the client trucates the buffer? Is your patch designed to allow normal operations? or to allow forbiden uses? - If it is not normal, is there good reasons to

[PATCH] server: Add API to protect access to an SHM buffer

Linux will let you mmap a region of a file that is larger than the size of the file. If you then try to read from that region the process will get a SIGBUS signal. Currently the clients can use this to crash a compositor because it can create a pool and lie about the size of the file which will

[PATCH weston] Add calls to wl_shm_buffer_begin/end_access

This wraps all accesses to an SHM buffer between wl_shm_buffer_begin and end so that wayland-shm can install a handler for SIGBUS and catch attempts to pass the compositor a buffer that is too small. Note, this patch doesn't do anything to fix the pixman renderer. --- src/compositor-drm.c | 3

Re: idle tasks starving in toytoolkit

Pekka Paalanen ppaala...@gmail.com writes: If not, is there not a possibility to break existing applications by blocking too early? Yes, you're right, the patch is nonsense because it won't work when the application does wl_display_dispatch_pending because it might end up with some events

RE: idle tasks starving in toytoolkit

One idea to fix this might be to make dispatch_queue only ever dispatch the events that were current when the loop is started. That way if any further events are added while processing the current events it will give control back to the main loop before processing them. Here's a

[PATCH v2] client: Fix handling display-reader_count if poll fails

In wl_display_dispatch_queue, if poll fails then it would previously return immediately and leak a reference in display-reader_count. Then if the application ignores the error and tries to read again it will block forever. This can happen for example if the poll fails with EINTR which the

[PATCH 1/3 wayland-fits] core/pointer: Keep track of the focus serial

The focus serial is needed to correctly send a cursor so it is useful to be able to verify that this is working correctly. --- src/test/core/pointer.cpp | 2 ++ src/test/core/pointer.h | 2 ++ 2 files changed, 4 insertions(+) diff --git a/src/test/core/pointer.cpp b/src/test/core/pointer.cpp

[PATCH 2/3 wayland-fits] core: Add a wrapper for the keyboard

This adds a wrapper for a wl_keyboard in a similar way to the pointer wrapper. It keeps track of the keys that are pressed so that they can be quickly verified. wayland-fits now depends on libxkbcommon so that the keyboard wrapper can pass the keymap to it and get the modifier indices. ---

[PATCH 3/3 wayland-fits] core: Add a test for multiple pointer and keyboard resources

This adds a test which creates multiple pointer and keyboard resources for the same client and verifies that they all receive events. It also tests various combiniations of pointer and keyboard focus and ensures that for example a keyboard created while the surface already has focus will correctly

[PATCH 1/2] Fix a typo in a log message

Without the space it would end up printing ‘downbut’. --- src/input.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/input.c b/src/input.c index 1313b52..0c3e480 100644 --- a/src/input.c +++ b/src/input.c @@ -1115,7 +1115,7 @@ notify_touch(struct weston_seat *seat,

Re: [PATCH weston 1/2 v2] input: Emit events on all resources for a client

Kristian Høgsberg hoegsb...@gmail.com writes: Instead of this manual marker, you can add comments like the above below the three dashes that git inserts between the commit message and the actual patch. git am will take the text up until the --- marker as the commit message and discard

[PATCH weston 1/2 v2] input: Emit events on all resources for a client

the keyboard then the modifiers might not be up-to-date. Co-author: Neil Roberts n...@linux.intel.com --- src/bindings.c| 21 +-- src/compositor.h | 9 +- src/data-device.c | 16 ++- src/input.c | 399 +++--- src/shell.c | 34 +++-- 5

[PATCH 2/2] Add a hacky client to test multiple pointer/keyboard resources

** I don't expect this patch to be landed but it might be useful if anyone wants to test the multi-resource stuff ** This adds a hacked version of simple-shm which can create multiple pointer and keyboard resources. The resources are created with the command line options -p and -k. Both take

  1   2   >