Ok, here's a second version of the patch with all of the suggested changes.
> So we must only want one xkb context per display. Ok.
Yes, I think we only really want one global xkb context but the
display seemed like a convenient place to attach it and ensure that it
will be destructed.
> We shou
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
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.
---
configu
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
in
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 applicat
Bill Spitzak writes:
> I really really think this idea should be changed. Clients should just
> be prepared for excess up and down events, and excess focus in/out.
> Avoiding them becomes nearly impossible as you are probably noticing,
> and pretty much means the compositor must maintain the stat
The weston_seat struct now keeps a bit mask of the touch points that
are pressed so that it can give a warning if it gets a down event for
a finger that is already down or an up event for one that is already
up.
---
I was using this patch to test bug 67563 but I think it could be a
good idea to la
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, uint32_
Kristian Høgsberg 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 everything from there o
** 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 an
if the client
gets the pointer later than you getting the keyboard then the
modifiers might not be up-to-date.
Co-author: Neil Roberts
---
src/bindings.c| 21 +--
src/compositor.h | 9 +-
src/data-device.c | 16 ++-
src/input.c | 399 +++---
Pekka Paalanen wrote:
> Instead of all this, could you not have made Weston simply use
> wl_resource_post_event() instead of wl_resource_queue_event()?
Yes, posting the event rather than queuing it when there are no frame
callbacks (is that what you meant?) is a lot simpler than having the
queue
(I just accidentally sent this to the mesa-dev list as well. Sorry
about that!)
Here is another version of the patch which brings back the blocking
when there are no buffers available to cope with the situation where
the compositor isn't immediately releasing buffers. Maybe we could
leave the deci
Weston now keeps track of the number of frame callbacks that are
installed for a particular client using some data attached in the
destroy listener of the wl_client. Whenever this number reaches zero,
it will disable the client's event queue using the new
wl_client_disable_queue API. That way if th
Thanks for the explanation. I wasn't considering the fullscreen case
where the compositor is directly scanning out from the client's buffers.
I think for the non-fullscreen case the compositor would only hold on to
a single buffer, right? In that case the sync request is enough.
I think in an idea
Adds wl_client_disable_queue and wl_client_enable_queue. When the
queue is disabled, flushing the client will cause it to send all of
the data regardless of whether ‘want_flush’ is set on the connection.
The ‘want_flush’ mechanism is used to implement the event queue.
Normally queued events are on
I like Kristian's proposal to throttle the swap buffers to sync
callbacks. It has the added benefit that we can stop the client from
unnecessarily using 3 buffers by waiting for the sync event in
get_back_bo. The previous patch would cause the client to use three
buffers because it would only block
Here's a hacked version of simple-egl which modifies eglSwapInterval
every 5 seconds and shows the frame rate to verify that it works.
- Neil
-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pi
This fixes build errors with the eglut_wayland backend. In particular
it now uses the wl_registry and the new main loop mechanism from the
Wayland 1.0 API.
---
src/egl/eglut/eglut_wayland.c | 108 --
1 file changed, 94 insertions(+), 14 deletions(-)
diff --
This reverts commit eccef6aadd142103ed151883e61c0e7a2fd98639.
Queuing the buffer release event instead of posting it immediately
causes problems if the client is not installing a frame callback and
instead is waiting for the buffer release events to throttle its
rendering. This will happen in Mesa
The _EGLSurface struct which is embedded into dri2_egl_surface also contains a
swap interval member so the other member is redundant. Nothing was using it as
far as I can tell.
---
src/egl/drivers/dri2/egl_dri2.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/egl/drivers/dri2/egl_dri2.h b/
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 it simply doesn't
install a frame callback so that the next
Here are some patches to add support for eglSwapInterval in Mesa's Wayland
platform.
The first two patches are for Mesa to actually implement it.
The third patch is a minor tweak to Weston which is needed to get it to send
the buffer release events at the correct time.
The fourth patch is to mes
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 applicat
(I hope you don't remind me replying to the whole list.)
Marc Chalain writes:
> I'm not really agree about Mesa. In my mind it isn't a simple client,
> it's a library with parts of wayland. I'm not sur that simple clients
> need to know the main queue. But I agree with you about the headers.
I
Hi,
Marc Chalain writes:
> I wonder if there isn't a problem when some client application uses
> this function from a child thread. If I remember, only the main thread
> must use the main queue. If you give an API to use it, developers will
> want to use it, and may not understand the usage.
I
I wrote:
> • For some reason if you move the cursor to somewhere near the
> middle of the surface then it will change to the resize grabber and
> it will let you resize the window.
It looks like this is happening because the toy toolkit gets confused
about the pointer position when it gets motion
Adds a function called wl_display_get_main_queue which just returns a
pointer to the default event queue. This will be useful in order to
implement the EGL_WL_create_wayland_buffer_from_image extension. The
buffers created within Mesa's Wayland platform are created using the
the wl_drm object as a
+++ b/docs/specs/WL_create_wayland_buffer_from_image.spec
@@ -0,0 +1,85 @@
+Name
+
+WL_create_wayland_buffer_from_image
+
+Name Strings
+
+EGL_WL_create_wayland_buffer_from_image
+
+Contact
+
+ Neil Roberts
+
+Status
+
+Proposal
+
+Version
+
+Version 1, September 6, 2013
+
+N
I wrote:
> • It seems to cause the nested-client to cycle between three buffers
> while rendering whereas previously it would only use two. I may have
> messed something up with the ordering between the frame callbacks and
> the buffer release events but I'm not sure yet.
I think I got to the bott
Is this problem specific to the extension or is it a general problem?
Would there not be the same issue if the session compositor wasn't using
the extension but was creating textures from the client surfaces
instead? Presumably if cards A and B don't share a tiling mode then it
won't be possible fo
The nested compositor example now responds to damage requests and
tracks them in the pending buffer state. This isn't currently used for
anything and it is immediately discarded when the surface is commited
but it will be used later when the example is converted to use
subsurfaces.
---
clients/nes
The buffer and frame callback state on the surfaces in the nested
compositor example are now double-buffered so that they only take
effect when the commit request is received. This doesn't really make
much difference for the current state that the example has but it will
be useful when more state i
Eventually the nested compositor example will want to be able to cope
with either rendering as it does now with a blit to an intermediate
surface or by attaching the client buffers directly to a subsurface
without copying. This patch moves the code that is specific to the
blitting mechanism into a
Previously the frame callback list was tracked as part of the global
compositor state. This patch moves the list to be part of the surface
state like it is in Weston. The frame callback now iterates the list
of surfaces to flush all of the callbacks. This change will be useful
when the example is c
Hi,
Here is a series of patches to provide a way for a nested compositor to
present its clients using subsurfaces so that it can attach the client's
buffers directly to the subsurface without having to perform a blit to an
intermediate buffer.
The first patch is for Mesa which adds an extension c
This copies the buffer reference busy count implementation from Weston
to the nested compositor example and adds an internal nested_buffer
struct that we could eventually use to attach data. This will be
useful to adapt the example to use subsurfaces so that we can attach
our compositor-side buffer
+++ b/docs/specs/WL_create_wayland_buffer_from_image.spec
@@ -0,0 +1,85 @@
+Name
+
+WL_create_wayland_buffer_from_image
+
+Name Strings
+
+EGL_WL_create_wayland_buffer_from_image
+
+Contact
+
+ Neil Roberts
+
+Status
+
+Proposal
+
+Version
+
+Version 1, September 6, 2013
+
+N
---
clients/.gitignore | 2 ++
1 file changed, 2 insertions(+)
diff --git a/clients/.gitignore b/clients/.gitignore
index 484437b..aa5e53c 100644
--- a/clients/.gitignore
+++ b/clients/.gitignore
@@ -8,6 +8,8 @@ weston-flower
weston-fullscreen
weston-gears
weston-image
+weston-nested
+weston-n
This adds a -b option to force the nested compositor example to use
the old blit renderer even if the appropriate extensions are
available.
---
clients/nested.c | 12
1 file changed, 12 insertions(+)
diff --git a/clients/nested.c b/clients/nested.c
index 1ea91a1..9d10476 100644
--- a
Adds a second renderer implementation to the nested compositor example
that creates a subsurface for each of the client's surfaces. The
client buffers are directly attached to the subsurface using the
EGL_WL_create_wayland_buffer_from_image extension instead of blitting
them in the redraw_handler.
Adds a simple accessor for the wl_subsurface for widgets created with
window_add_subsurface.
---
clients/window.c | 6 ++
clients/window.h | 3 +++
2 files changed, 9 insertions(+)
diff --git a/clients/window.c b/clients/window.c
index 6854745..a837ec8 100644
--- a/clients/window.c
+++ b/clie
Bill Spitzak writes:
> I think that rather than some trick to fool glib into making the poll
> return immmediately, calling dispatch_pending in a loop until it returns
> false will work better, and the poll can be called normally.
I wouldn't consider this to be a ‘trick’. It's normal and docum
Bill Spitzak writes:
> You can call dispatch_pending "last", ie as part of the dispatch
> function. It's in a loop, so doing something at the end of the loop is
> the same as doing it at the start.
I don't think that will work for GLib because you can't really control
the order of the dispatch f
Hi,
[I sent this yesterday too, but I accidentally used the wrong address
and it got stuck in the moderator queue so I'm resending it]
I was wondering whether we should add a function like
wl_event_queue_empty() to query whether there are any pending events in
the queue. This would make it easier
Bill Spitzak writes:
> Maybe it can abort if ...read_events() is called after an error was
> encountered. Then bad toolkits will exit, while ones that check for the
> error state can do something intelligent.
This sounds like a nice idea but it might go a bit wrong if there are
orthogonal bits
> the only thing that confused me was the past tense sentence […]
Ok, that sounds sensible. Here is an updated patch.
> However we'd have to change every client / toolkit and so using a
> fatal display error is nicer since the toolkits should already be
> handling that.
Well, that would be ideal
If EOF is encountered while reading from the Wayland socket,
wl_display_read_events() will now return -1 so that it will be treated
as an error. The documentation for this function states that it will
set errno when there is an error so it additionally makes up an errno
of EPIPE.
If we don't do th
This adds a public header so that applications can get the Wayland
version number at compile time. This can be used to make applications
that support compiling against multiple versions of Wayland.
There is a separate installed header called cogl-version.h which gets
included by both wayland-clien
Commit fdbbc38a added a wl_display_disconnect function to the 0.85
branch so that Mesa can continue to build against both that branch and
master. However it was missing a declaration in the header so Mesa
would still fail to build when -Werror is enabled.
---
src/wayland-client.h |1 +
1 files
It's quite convenient for some compositors to track the 0.85 branch of
Wayland to get the stability but they would probably also want to track
Mesa master to get the gbm surface changes. This combination currently
doesn't work however because Mesa only works with Wayland master. Here
are three patc
On Sun, 18 Mar 2012 17:07:11 -0400, dar...@chaosreigns.com wrote:
> A) Get cairo-gl to only load libGL when an application requests it:
>https://bugs.freedesktop.org/show_bug.cgi?id=47480
I've hacked up a patch¹ to implement this because I think it's a good
idea regardless of the problem with
This copies the algorithm for keeping track of an implicit grab widget
when a button is pressed from Wayland. Instead of just tracking a
single button, Wayland keeps a count of all the mouse buttons that are
down and only releases the grab when all buttons are released. Without
this it could lose b
The code which sends the button events was checking whether there is a
focus widget with a button handler but then always sending the button
event to the grab widget. If the grab widget is different from the
focus widget at this point then it will check the wrong widget for a
button handler and pot
I kept running into this crash with the widget grab for the Weston
demos. Here's some patches to fix it.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
101 - 155 of 155 matches
Mail list logo
