[PATCH weston v2 1/3] compositor: introduce structs to handle backends configuration
This commit introduces the structs weston_backend_config and
weston_backend_output_config, to prepare for the new config
system for the backends.
---
v2: use uints for the width and height
src/compositor.h | 36 ++--
1 file changed, 34 insertions(+), 2 deletions(-)
diff --git a/src/compositor.h b/src/compositor.h
index 2e2a185..b065f11 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -610,9 +610,41 @@ enum weston_capability {
WESTON_CAP_VIEW_CLIP_MASK = 0x0010,
};
+/* Configuration struct for an output.
+ *
+ * This struct is used to pass the configuration for an output
+ * to the compositor backend when creating a new output.
+ * The backend can subclass this struct to handle backend
+ * specific data.
+ */
+struct weston_backend_output_config {
+ uint32_t transform;
+ uint32_t width;
+ uint32_t height;
+ int scale;
+};
+
+/* Configuration struct for a backend.
+ *
+ * This struct carries the configuration for a backend, and it's
+ * passed to the backend's init entry point. The backend will
+ * likely want to subclass this in order to handle backend specific
+ * data.
+ */
+struct weston_backend_config {
+};
+
struct weston_backend {
- void (*destroy)(struct weston_compositor *ec);
- void (*restore)(struct weston_compositor *ec);
+ void (*destroy)(struct weston_compositor *compositor);
+ void (*restore)(struct weston_compositor *compositor);
+ /* vfunc to create a new output with a given name and config.
+* backends not supporting the functionality will set this
+* to NULL.
+*/
+ struct weston_output *
+ (*create_output)(struct weston_compositor *compositor,
+const char *name,
+struct weston_backend_output_config *config);
};
struct weston_compositor {
--
2.6.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Unstable protocol name breakage
On Mon, Oct 19, 2015 at 7:22 PM, Jonas Ådahl wrote: > Hi again, ... snip ... > xdg-shell.xml: Should we bite the bullet and rename this one, or just continue > letting its stability state be non-discoverable? It's clearly already used, > and > renaming it will be painful, so not sure about this one. People are clearly unhappy with the status quo, so I'd be fine to rename this one to zxdg_shell. > Jonas > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Jasper ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] Support axis source, axis discreet, axis frame and axis stop events
On Tue, Oct 20, 2015 at 09:19:59AM +0800, Jonas Ådahl wrote:
> On Mon, Oct 19, 2015 at 06:17:31PM -0700, Bryce Harrington wrote:
> > On Fri, Oct 16, 2015 at 12:39:22PM +1000, Peter Hutterer wrote:
> > > Signed-off-by: Peter Hutterer
> > > ---
> > > The client-side is the simplest implementation here, and I went the easy
> > > route since most clients won't care to register a multitude of handlers
> > > for
> > > axis events.
> > >
> > > The eventdemo client merely prints the events, it doesn't accumulate them
> > > as
> > > they should be. That'd be the job of a slightly more sophisticated
> > > toolkit.
> > >
> > > Possibly contentious: there's no notify_axis_stop(), it's folded into
> > > notify_axis(). Easy fix if needed.
> > >
> > > Also, I recommend not merging this one until we have a test implementation
> > > in mutter + GTK to make sure the protocol is sane enough to use from
> > > complex
> > > clients.
> >
> > Thanks for resending these patches. Since the main goal here is
> > assuring the protocol is right, should we also hold off on landing the
> > wayland piece until there's consensus around this one too, or is the
> > protocol part ok to land?
>
> I'm planning to do a second review of the protocol patches, and there
> will at least be minor changes needed, so please don't merge anything
> yet. Will try to get that done as soon as possible.
Thanks, sounds good.
Bryce
> Jonas
>
> >
> > Bryce
> >
> > > clients/eventdemo.c | 55 -
> > > clients/window.c | 91
> > > +++-
> > > clients/window.h | 28 +++
> > > src/compositor-wayland.c | 39 +
> > > src/compositor-x11.c | 16 ++---
> > > src/compositor.h | 10 ++
> > > src/input.c | 74 ++-
> > > src/libinput-device.c| 63 +++--
> > > 8 files changed, 360 insertions(+), 16 deletions(-)
> > >
> > > diff --git a/clients/eventdemo.c b/clients/eventdemo.c
> > > index bdad6fd..f520233 100644
> > > --- a/clients/eventdemo.c
> > > +++ b/clients/eventdemo.c
> > > @@ -259,6 +259,54 @@ axis_handler(struct widget *widget, struct input
> > > *input, uint32_t time,
> > > wl_fixed_to_double(value));
> > > }
> > >
> > > +static void
> > > +axis_frame_handler(struct widget *widget, struct input *input, void
> > > *data)
> > > +{
> > > + printf("axis frame\n");
> > > +}
> > > +
> > > +static void
> > > +axis_source_handler(struct widget *widget, struct input *input,
> > > + uint32_t source, void *data)
> > > +{
> > > + const char *axis_source;
> > > +
> > > + switch (source) {
> > > + case WL_POINTER_AXIS_SOURCE_WHEEL:
> > > + axis_source = "wheel";
> > > + break;
> > > + case WL_POINTER_AXIS_SOURCE_FINGER:
> > > + axis_source = "finger";
> > > + break;
> > > + case WL_POINTER_AXIS_SOURCE_CONTINUOUS:
> > > + axis_source = "continuous";
> > > + break;
> > > + default:
> > > + axis_source = "";
> > > + break;
> > > + }
> > > +
> > > + printf("axis source: %s\n", axis_source);
> > > +}
> > > +
> > > +static void
> > > +axis_stop_handler(struct widget *widget, struct input *input,
> > > + uint32_t time, uint32_t axis,
> > > + void *data)
> > > +{
> > > + printf("axis stop time: %d, axis: %s\n",
> > > +time,
> > > +axis == WL_POINTER_AXIS_VERTICAL_SCROLL ? "vertical" :
> > > + "horizontal");
> > > +}
> > > +
> > > +static void
> > > +axis_discrete_handler(struct widget *widget, struct input *input,
> > > + int32_t discrete, void *data)
> > > +{
> > > + printf("axis discrete value: %d\n", discrete);
> > > +}
> > > +
> > > /**
> > > * \brief CALLBACK function, Waylands informs about pointer motion
> > > * \param widget widget
> > > @@ -348,7 +396,12 @@ eventdemo_create(struct display *d)
> > > widget_set_motion_handler(e->widget, motion_handler);
> > >
> > > /* Set the callback axis handler for the window */
> > > - widget_set_axis_handler(e->widget, axis_handler);
> > > + widget_set_axis_handlers(e->widget,
> > > + axis_handler,
> > > + axis_frame_handler,
> > > + axis_source_handler,
> > > + axis_stop_handler,
> > > + axis_discrete_handler);
> > >
> > > /* Initial drawing of the window */
> > > window_schedule_resize(e->window, width, height);
> > > diff --git a/clients/window.c b/clients/window.c
> > > index 6d3e944..121037b 100644
> > > --- a/clients/window.c
> > > +++ b/clients/window.c
> > > @@ -288,6 +288,10 @@ struct widget {
> > > widget_touch_frame_handler_t touch_frame_handler;
> > > widget_touch_cancel_handler_t touch_cancel_handler;
> > > widget_axis_handler_t axis_handler;
> > > + widget_
Re: Unstable protocol name breakage
On 20 October 2015 at 05:59, Jonas Ådahl wrote: > On Tue, Oct 20, 2015 at 05:26:45AM +0200, Mariusz Ceier wrote: > > Hi, > > > > On 20 October 2015 at 04:22, Jonas Ådahl wrote: > > > > > Hi again, > > > > > > I was about to start migrating generic protocols away from weston into > > > wayland-protocols. The idea was to start with input-method.xml, > text.xml, > > > linux-dmabuf.xml, presentation_timing.xml, scaler.xml and > xdg-shell.xml. > > > The > > > question, however, is what to do with the names, because some names > already > > > have the form "wl_[name]", and renaming such an interface to > "zwl_[name]1" > > > during the unstable period, and then back to "wl_[name]" will cause > > > potential > > > breakage because some implementations in the wild might expect the > > > "wl_[name]" > > > to be the original (ancient) version. > > > > > > As mentioned before, I have already moved the fullscreen shell > protocol, > > > and > > > with the naming schema changes in place, it ended up with the protocol > name > > > "fullscreen-shell-unstable-v1", the interfaces zwl_fullscreen_shell1, > and > > > zwl_fullscreen_shell_mode_feedback1. > > > > > > linux-dmabuf.xml is also easy. Since it is already 'z' prefix, to > comply > > > with > > > the intended naming schema, I'd just need to rename the interfaces to > > > zlinux_dmabuf1 and zlinux_buffer_params1, and the protocol to > > > linux-dmabuf-unstable-v1. > > > > > > presentation_timing.xml: I suppose this one can be renamed without any > > > significant implications, since it currently is completely prefix > free. I > > > imagine it'd be zwl_presentation1 and zwl_presentation_feedback1 in a > > > presentation-timing-unstable-v1(.xml) protocol. > > > > > > The problem is the rest of the protocols, since they all already have > the > > > intended stable names. This means we cannot apply a naming schema that > > > intends > > > to finally remove the prefix and postfix when declaring stable, since > that > > > would collide with the initial name. How to deal with these names > needs to > > > be > > > decided, and probably so protocol by protocol. > > > > > > scalar.xml: As far as I know, Pekka has plans to change scalar.xml, and > > > plan to > > > do so with a name change. So as far as I understand, we need to rename > this > > > one. > > > > > > input-method.xml: This one I think might actually be fine to just > apply the > > > naming schema, as the protocol itself has Wayland core principle > violations > > > that need to be solved, i.e. any implementor of this is already broken > (by > > > principle). > > > > > > > > Since it's broken by principle, can't input-method.xml be marked as > > deprecated (e.g. by implementing/using top-level deprecated attribute ) ? > > Then leave it in weston as weston-specific protocol, that generates > > deprecation warnings during compilation and maybe when used by clients > > connecting to weston; and in wayland-protocols add new protocol that's > not > > broken by principle (but may be based on input-method). > > Not sure what you mean with top-level deprecated attribute (attributes > on some C code? or disable the text-backend by default whith a warning > if its enabled?). I meant adding deprecated attribute to top-level element in .xml file, that would instruct wayland scanner to generate deprecated attributes for every interface that's defined in this xml file. If we disable it by default we'd just break third > party clients (and can just as well move and rename), and I don't think > we should have compiler warning by default. > > I didn't mean disabling it - just generate deprecation warning at runtime (in weston) and compile time when client uses deprecated protocol. I don't know if it should be deprecated though; the broken-ness is that > it breaks the single-origin of object factories because it creates a > wl_keyboard, but that can be fixed. > > Will the fix most likely break existing clients ? If yes - do we care about that (since protocol is not yet stable, we don't have to) ? If yes - IMO current input-method should be deprecated, left in weston (as weston-specific) and new protocol created in wayland-protocols. In all other situations - input-method.xml should be fixed, 'z' prefix added and such modified protocol moved to wayland-protocols. If wl_input_method is no longer expected to be used by anyone, nor be > fixed, then I think we should deprecate it, or even easier, just remove > it. > > > > > Deprecation can also be used for other problematic protocols, but I'm not > > sure if that's good idea if such protocol is not broken. > > If a protocol is replaced by another, I think it makes sense to > deprecate it. Or if it is problematic for any other reason for that > matter. What compositor implements deprecated protocols is not a > question for wayland-protocols however. > > > > > text.xml: This one I'm not so sure about. Has it ever been implemented > > > outside > > > of weston except only as a proof
Re: Unstable protocol name breakage
On Tue, Oct 20, 2015 at 05:26:45AM +0200, Mariusz Ceier wrote: > Hi, > > On 20 October 2015 at 04:22, Jonas Ådahl wrote: > > > Hi again, > > > > I was about to start migrating generic protocols away from weston into > > wayland-protocols. The idea was to start with input-method.xml, text.xml, > > linux-dmabuf.xml, presentation_timing.xml, scaler.xml and xdg-shell.xml. > > The > > question, however, is what to do with the names, because some names already > > have the form "wl_[name]", and renaming such an interface to "zwl_[name]1" > > during the unstable period, and then back to "wl_[name]" will cause > > potential > > breakage because some implementations in the wild might expect the > > "wl_[name]" > > to be the original (ancient) version. > > > > As mentioned before, I have already moved the fullscreen shell protocol, > > and > > with the naming schema changes in place, it ended up with the protocol name > > "fullscreen-shell-unstable-v1", the interfaces zwl_fullscreen_shell1, and > > zwl_fullscreen_shell_mode_feedback1. > > > > linux-dmabuf.xml is also easy. Since it is already 'z' prefix, to comply > > with > > the intended naming schema, I'd just need to rename the interfaces to > > zlinux_dmabuf1 and zlinux_buffer_params1, and the protocol to > > linux-dmabuf-unstable-v1. > > > > presentation_timing.xml: I suppose this one can be renamed without any > > significant implications, since it currently is completely prefix free. I > > imagine it'd be zwl_presentation1 and zwl_presentation_feedback1 in a > > presentation-timing-unstable-v1(.xml) protocol. > > > > The problem is the rest of the protocols, since they all already have the > > intended stable names. This means we cannot apply a naming schema that > > intends > > to finally remove the prefix and postfix when declaring stable, since that > > would collide with the initial name. How to deal with these names needs to > > be > > decided, and probably so protocol by protocol. > > > > scalar.xml: As far as I know, Pekka has plans to change scalar.xml, and > > plan to > > do so with a name change. So as far as I understand, we need to rename this > > one. > > > > input-method.xml: This one I think might actually be fine to just apply the > > naming schema, as the protocol itself has Wayland core principle violations > > that need to be solved, i.e. any implementor of this is already broken (by > > principle). > > > > > Since it's broken by principle, can't input-method.xml be marked as > deprecated (e.g. by implementing/using top-level deprecated attribute ) ? > Then leave it in weston as weston-specific protocol, that generates > deprecation warnings during compilation and maybe when used by clients > connecting to weston; and in wayland-protocols add new protocol that's not > broken by principle (but may be based on input-method). Not sure what you mean with top-level deprecated attribute (attributes on some C code? or disable the text-backend by default whith a warning if its enabled?). If we disable it by default we'd just break third party clients (and can just as well move and rename), and I don't think we should have compiler warning by default. I don't know if it should be deprecated though; the broken-ness is that it breaks the single-origin of object factories because it creates a wl_keyboard, but that can be fixed. If wl_input_method is no longer expected to be used by anyone, nor be fixed, then I think we should deprecate it, or even easier, just remove it. > > Deprecation can also be used for other problematic protocols, but I'm not > sure if that's good idea if such protocol is not broken. If a protocol is replaced by another, I think it makes sense to deprecate it. Or if it is problematic for any other reason for that matter. What compositor implements deprecated protocols is not a question for wayland-protocols however. > > text.xml: This one I'm not so sure about. Has it ever been implemented > > outside > > of weston except only as a proof of concept? Would it be fine to use the > > same > > name? > > > > xdg-shell.xml: Should we bite the bullet and rename this one, or just > > continue > > letting its stability state be non-discoverable? It's clearly already > > used, and > > renaming it will be painful, so not sure about this one. > > > > > Maybe we should at first stabilise protocols that are used, not broken and > renaming them will be painful ? We should not declare protocols stable that are not ready just because they happen to be used in the wild. For the protocols that can be declared stable as is with the reason they are actually ready, now is a good time to do so indeed, but the reason should be right. Jonas > > > > Then comes the IVI protocols. I have no opinions about these, and I don't > > know > > what any plan with them might be. Should they be moved, or are they purely > > a > > weston thing? > > > > For the rest of the protocols (desktop-shell.xml, screenshooter.xml, > > text-cursor-position.xml, w
Re: Unstable protocol name breakage
Hi, On 20 October 2015 at 04:22, Jonas Ådahl wrote: > Hi again, > > I was about to start migrating generic protocols away from weston into > wayland-protocols. The idea was to start with input-method.xml, text.xml, > linux-dmabuf.xml, presentation_timing.xml, scaler.xml and xdg-shell.xml. > The > question, however, is what to do with the names, because some names already > have the form "wl_[name]", and renaming such an interface to "zwl_[name]1" > during the unstable period, and then back to "wl_[name]" will cause > potential > breakage because some implementations in the wild might expect the > "wl_[name]" > to be the original (ancient) version. > > As mentioned before, I have already moved the fullscreen shell protocol, > and > with the naming schema changes in place, it ended up with the protocol name > "fullscreen-shell-unstable-v1", the interfaces zwl_fullscreen_shell1, and > zwl_fullscreen_shell_mode_feedback1. > > linux-dmabuf.xml is also easy. Since it is already 'z' prefix, to comply > with > the intended naming schema, I'd just need to rename the interfaces to > zlinux_dmabuf1 and zlinux_buffer_params1, and the protocol to > linux-dmabuf-unstable-v1. > > presentation_timing.xml: I suppose this one can be renamed without any > significant implications, since it currently is completely prefix free. I > imagine it'd be zwl_presentation1 and zwl_presentation_feedback1 in a > presentation-timing-unstable-v1(.xml) protocol. > > The problem is the rest of the protocols, since they all already have the > intended stable names. This means we cannot apply a naming schema that > intends > to finally remove the prefix and postfix when declaring stable, since that > would collide with the initial name. How to deal with these names needs to > be > decided, and probably so protocol by protocol. > > scalar.xml: As far as I know, Pekka has plans to change scalar.xml, and > plan to > do so with a name change. So as far as I understand, we need to rename this > one. > > input-method.xml: This one I think might actually be fine to just apply the > naming schema, as the protocol itself has Wayland core principle violations > that need to be solved, i.e. any implementor of this is already broken (by > principle). > > Since it's broken by principle, can't input-method.xml be marked as deprecated (e.g. by implementing/using top-level deprecated attribute ) ? Then leave it in weston as weston-specific protocol, that generates deprecation warnings during compilation and maybe when used by clients connecting to weston; and in wayland-protocols add new protocol that's not broken by principle (but may be based on input-method). Deprecation can also be used for other problematic protocols, but I'm not sure if that's good idea if such protocol is not broken. text.xml: This one I'm not so sure about. Has it ever been implemented > outside > of weston except only as a proof of concept? Would it be fine to use the > same > name? > > xdg-shell.xml: Should we bite the bullet and rename this one, or just > continue > letting its stability state be non-discoverable? It's clearly already > used, and > renaming it will be painful, so not sure about this one. > > Maybe we should at first stabilise protocols that are used, not broken and renaming them will be painful ? > Then comes the IVI protocols. I have no opinions about these, and I don't > know > what any plan with them might be. Should they be moved, or are they purely > a > weston thing? > > For the rest of the protocols (desktop-shell.xml, screenshooter.xml, > text-cursor-position.xml, weston-test.xml, workspaces.xml) I plan to leave > them > be, as they either are purely weston internal, simple toy protocols or > have no > consesus that they are to be ever be official protocols. > > So what should we do about these naming issues? It should have been clear > that > all of these are experimental protocols, but due to the fact that some may > have > started to use these outside of weston anyway even though they being > experimental, is it Ok for us to start causing them to break? If not, what > may > some alternative names be? > > > Jonas > Mariusz Ceier ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Unstable protocol name breakage
Hi again, I was about to start migrating generic protocols away from weston into wayland-protocols. The idea was to start with input-method.xml, text.xml, linux-dmabuf.xml, presentation_timing.xml, scaler.xml and xdg-shell.xml. The question, however, is what to do with the names, because some names already have the form "wl_[name]", and renaming such an interface to "zwl_[name]1" during the unstable period, and then back to "wl_[name]" will cause potential breakage because some implementations in the wild might expect the "wl_[name]" to be the original (ancient) version. As mentioned before, I have already moved the fullscreen shell protocol, and with the naming schema changes in place, it ended up with the protocol name "fullscreen-shell-unstable-v1", the interfaces zwl_fullscreen_shell1, and zwl_fullscreen_shell_mode_feedback1. linux-dmabuf.xml is also easy. Since it is already 'z' prefix, to comply with the intended naming schema, I'd just need to rename the interfaces to zlinux_dmabuf1 and zlinux_buffer_params1, and the protocol to linux-dmabuf-unstable-v1. presentation_timing.xml: I suppose this one can be renamed without any significant implications, since it currently is completely prefix free. I imagine it'd be zwl_presentation1 and zwl_presentation_feedback1 in a presentation-timing-unstable-v1(.xml) protocol. The problem is the rest of the protocols, since they all already have the intended stable names. This means we cannot apply a naming schema that intends to finally remove the prefix and postfix when declaring stable, since that would collide with the initial name. How to deal with these names needs to be decided, and probably so protocol by protocol. scalar.xml: As far as I know, Pekka has plans to change scalar.xml, and plan to do so with a name change. So as far as I understand, we need to rename this one. input-method.xml: This one I think might actually be fine to just apply the naming schema, as the protocol itself has Wayland core principle violations that need to be solved, i.e. any implementor of this is already broken (by principle). text.xml: This one I'm not so sure about. Has it ever been implemented outside of weston except only as a proof of concept? Would it be fine to use the same name? xdg-shell.xml: Should we bite the bullet and rename this one, or just continue letting its stability state be non-discoverable? It's clearly already used, and renaming it will be painful, so not sure about this one. Then comes the IVI protocols. I have no opinions about these, and I don't know what any plan with them might be. Should they be moved, or are they purely a weston thing? For the rest of the protocols (desktop-shell.xml, screenshooter.xml, text-cursor-position.xml, weston-test.xml, workspaces.xml) I plan to leave them be, as they either are purely weston internal, simple toy protocols or have no consesus that they are to be ever be official protocols. So what should we do about these naming issues? It should have been clear that all of these are experimental protocols, but due to the fact that some may have started to use these outside of weston anyway even though they being experimental, is it Ok for us to start causing them to break? If not, what may some alternative names be? Jonas ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland v3] shm: Add shm_buffer ref and shm_pool unref functions
Sometimes the compositor wants to make sure a shm pool doesn't disappear
out from under it.
For example, in Enlightenment, rendering happens in a separate thread
while the main thread can still dispatch events. If a client is destroyed
during rendering, all its resources are cleaned up and its shm pools are
unmapped. This causes the rendering thread to segfault.
This patch adds a way for the compositor to increment the refcount of the
shm pool so it can't disappear, and decrement it when it's finished.
The ref/unref are asymmetrical (ref returns the pool) because it's
possible the buffer itself will be gone when you need to unref the pool.
Reviewed-by: Pekka Paalanen
Signed-off-by: Derek Foreman
---
Changes from v2:
Slightly improved doxygen
Changes from v1:
renamed functions to wl_shm_buffer_ref_pool and wl_shm_pool_unref
added doxy
src/wayland-server-core.h | 7 +++
src/wayland-shm.c | 42 ++
2 files changed, 49 insertions(+)
src/wayland-server-core.h | 7 +++
src/wayland-shm.c | 42 ++
2 files changed, 49 insertions(+)
diff --git a/src/wayland-server-core.h b/src/wayland-server-core.h
index e605432..4c2bdfe 100644
--- a/src/wayland-server-core.h
+++ b/src/wayland-server-core.h
@@ -362,6 +362,7 @@ wl_resource_get_destroy_listener(struct wl_resource
*resource,
resource = tmp,
\
tmp = wl_resource_from_link(wl_resource_get_link(resource)->next))
+struct wl_shm_pool;
struct wl_shm_buffer;
void
@@ -388,6 +389,12 @@ wl_shm_buffer_get_width(struct wl_shm_buffer *buffer);
int32_t
wl_shm_buffer_get_height(struct wl_shm_buffer *buffer);
+struct wl_shm_pool *
+wl_shm_buffer_ref_pool(struct wl_shm_buffer *buffer);
+
+void
+wl_shm_pool_unref(struct wl_shm_pool *pool);
+
int
wl_display_init_shm(struct wl_display *display);
diff --git a/src/wayland-shm.c b/src/wayland-shm.c
index 5c419fa..1ab8f89 100644
--- a/src/wayland-shm.c
+++ b/src/wayland-shm.c
@@ -412,6 +412,48 @@ wl_shm_buffer_get_height(struct wl_shm_buffer *buffer)
return buffer->height;
}
+/** Get a reference to a shm_buffer's shm_pool
+ *
+ * \param buffer The buffer object
+ *
+ * Returns a pointer to a buffer's shm_pool and increases the
+ * shm_pool refcount.
+ *
+ * The compositor must remember to call wl_shm_pool_unref when
+ * it no longer needs the reference to ensure proper destruction
+ * of the pool.
+ *
+ * \memberof wl_shm_buffer
+ * \sa wl_shm_pool_unref
+ */
+WL_EXPORT struct wl_shm_pool *
+wl_shm_buffer_ref_pool(struct wl_shm_buffer *buffer)
+{
+ assert(buffer->pool->refcount);
+
+ buffer->pool->refcount++;
+ return buffer->pool;
+}
+
+/** Unreference a shm_pool
+ *
+ * \param buffer The pool object
+ *
+ * Drops a reference to a wl_shm_pool object.
+ *
+ * This is only necessary if the compositor has explicitly
+ * taken a reference with wl_shm_buffer_ref_pool(), otherwise
+ * the pool will be automatically destroyed when appropriate.
+ *
+ * \memberof wl_shm_pool
+ * \sa wl_shm_buffer_ref_pool
+ */
+WL_EXPORT void
+wl_shm_pool_unref(struct wl_shm_pool *pool)
+{
+ shm_pool_unref(pool);
+}
+
static void
reraise_sigbus(void)
{
--
2.6.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v2 wayland] shm: Add shm_buffer ref and shm_pool unref functions
On 16/10/15 08:34 AM, Pekka Paalanen wrote:
> On Mon, 5 Oct 2015 13:12:12 -0500
> Derek Foreman wrote:
>
>> Sometimes the compositor wants to make sure a shm pool doesn't disappear
>> out from under it.
>>
>> For example, in Enlightenment, rendering happens in a separate thread
>> while the main thread can still dispatch events. If a client is destroyed
>> during rendering, all its resources are cleaned up and its shm pools are
>> unmapped. This causes the rendering thread to segfault.
>>
>> This patch adds a way for the compositor to increment the refcount of the
>> shm pool so it can't disappear, and decrement it when it's finished.
>>
>> The ref/unref are asymmetrical (ref returns the pool) because it's
>> possible the buffer itself will be gone when you need to unref the pool.
>>
>> Signed-off-by: Derek Foreman
>> ---
>>
>> Changes from v1:
>> renamed functions to wl_shm_buffer_ref_pool and wl_shm_pool_unref
>> added doxy
>>
>> src/wayland-server-core.h | 7 +++
>> src/wayland-shm.c | 36
>> 2 files changed, 43 insertions(+)
>>
>> diff --git a/src/wayland-server-core.h b/src/wayland-server-core.h
>> index e605432..4c2bdfe 100644
>> --- a/src/wayland-server-core.h
>> +++ b/src/wayland-server-core.h
>> @@ -362,6 +362,7 @@ wl_resource_get_destroy_listener(struct wl_resource
>> *resource,
>> resource = tmp,
>> \
>> tmp = wl_resource_from_link(wl_resource_get_link(resource)->next))
>>
>> +struct wl_shm_pool;
>> struct wl_shm_buffer;
>>
>> void
>> @@ -388,6 +389,12 @@ wl_shm_buffer_get_width(struct wl_shm_buffer *buffer);
>> int32_t
>> wl_shm_buffer_get_height(struct wl_shm_buffer *buffer);
>>
>> +struct wl_shm_pool *
>> +wl_shm_buffer_ref_pool(struct wl_shm_buffer *buffer);
>> +
>> +void
>> +wl_shm_pool_unref(struct wl_shm_pool *pool);
>> +
>> int
>> wl_display_init_shm(struct wl_display *display);
>>
>> diff --git a/src/wayland-shm.c b/src/wayland-shm.c
>> index 5c419fa..4f9d9d0 100644
>> --- a/src/wayland-shm.c
>> +++ b/src/wayland-shm.c
>> @@ -412,6 +412,42 @@ wl_shm_buffer_get_height(struct wl_shm_buffer *buffer)
>> return buffer->height;
>> }
>>
>> +/** Get a reference to a shm_buffer's shm_pool
>> + *
>> + * \param buffer The buffer object
>> + *
>> + * Returns a pointer to a buffer's shm_pool and increases the
>> + * shm_pool refcount.
>> + *
>> + * This refcount keeps the shm pool from being destroyed on client
>> + * disconnect, so the compositor must call wl_shm_pool_unref on it
>> + * when finished.
>
> It's not the disconnect directly, but cleaning up all wl_resources
> after a disconnect causes the side-effect of the pool refcount dropping
> to zero. Not sure that's an important detail to mention here, though.
> The client can also do this without a disconnect, by just destroying
> all relevant wl_proxies.
>
Yeah, true - the only information I want to convey is that the
programmer must remember to call the other function to decrease the
refcount. That is, the programmer has interfered with the normal
refcounting.
>> + *
>> + * \memberof wl_shm_buffer
>
> See also: wl_shm_pool_unref.
>
>> + */
>> +WL_EXPORT struct wl_shm_pool *
>> +wl_shm_buffer_ref_pool(struct wl_shm_buffer *buffer)
>> +{
>> +assert(buffer->pool->refcount);
>> +
>> +buffer->pool->refcount++;
>> +return buffer->pool;
>> +}
>> +
>> +/** Unreference a shm_pool
>> + *
>> + * \param buffer The pool object
>> + *
>> + * Drops a reference to a wl_shm_pool object.
>> + *
>> + * \memberof wl_shm_buffer
>
> wl_shm_buffer?
>
> I think we already have an empty wl_shm_pool section in the docs,
> wouldn't this belong there, with a see also wl_shm_buffer_ref_pool()?
Yes.
> If Giulio or anyone still needs to get the fd of a shm buffer or
> anything, that would be naturally done by taking a ref for the
> wl_shm_pool, and then asking the pool for its fd and size.
That's my thinking too...
I've been griefing him on that fd getter patch because it keeps fds open
for every pool, but I'm wondering if that's a silly complaint. Seems my
per process limit is 65535 open fds here - it could be easily exhausted
by a rogue client, but in reasonable usage that's probably not going to
be hit. But that's a concern for another email thread. :)
>> + */
>> +WL_EXPORT void
>> +wl_shm_pool_unref(struct wl_shm_pool *pool)
>> +{
>> +shm_pool_unref(pool);
>> +}
>> +
>> static void
>> reraise_sigbus(void)
>> {
>
> Anyway, documentation bikeshedding apart, this patch looks good to me,
> so:
>
> Reviewed-by: Pekka Paalanen
>
> I did not test this in any way.
I'll post a v3 with some doc changes in case anyone wants to bike shed
and land it if there are no complaints.
Thanks,
Derek
> Thanks,
> pq
>
>
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-dev
Re: [PATCH v2 libinput] Fix premature flushing of evdev event on mx4 touchscreen
sorry for the delay, travelling and only slowly catching up with email.
On Mon, Sep 07, 2015 at 09:57:44PM +0200, Andreas Pokorny wrote:
> The mx4 touchscreen driver emits BTN_TOUCH and BTN_TOOL_FINGER key events
> on a new contact. Prior to this patch only the BTN_TOUCH event was filtered
> out. Now the whole range of BTN_ events for tool types and certain builtin
> multi finger gestures are marked as non-key type.
>
> Signed-off-by: Andreas Pokorny
Reviewed-by: Peter Hutterer
Cheers,
Peter
> ---
> src/evdev.c | 10 +++---
> test/touch.c | 110
> +++
> 2 files changed, 115 insertions(+), 5 deletions(-)
>
> diff --git a/src/evdev.c b/src/evdev.c
> index 04df275..3e22aa9 100644
> --- a/src/evdev.c
> +++ b/src/evdev.c
> @@ -557,7 +557,7 @@ evdev_flush_pending_event(struct evdev_device *device,
> uint64_t time)
> static enum evdev_key_type
> get_key_type(uint16_t code)
> {
> - if (code == BTN_TOUCH)
> + if (code >= BTN_DIGI && code <= BTN_TOOL_QUADTAP)
> return EVDEV_KEY_TYPE_NONE;
>
> if (code >= KEY_ESC && code <= KEY_MICMUTE)
> @@ -630,16 +630,16 @@ evdev_process_key(struct evdev_device *device,
> if (e->value == 2)
> return;
>
> - if (e->code == BTN_TOUCH) {
> - if (!device->is_mt)
> + type = get_key_type(e->code);
> +
> + if (type == EVDEV_KEY_TYPE_NONE) {
> + if (e->code == BTN_TOUCH && !device->is_mt)
> evdev_process_touch_button(device, time, e->value);
> return;
> }
>
> evdev_flush_pending_event(device, time);
>
> - type = get_key_type(e->code);
> -
> /* Ignore key release events from the kernel for keys that libinput
>* never got a pressed event for. */
> if (e->value == 0) {
> diff --git a/test/touch.c b/test/touch.c
> index 875d94d..0e7f893 100644
> --- a/test/touch.c
> +++ b/test/touch.c
> @@ -912,6 +912,114 @@ START_TEST(touch_point_no_minor_or_orientation)
> }
> END_TEST
>
> +START_TEST(touchscreen_with_btn_tool_finger_on_down)
> +{
> + struct libevdev_uinput *uinput;
> + struct libinput *li;
> + struct libinput_device *device;
> + struct libinput_event *event;
> + struct libinput_event_touch *tev;
> + const struct input_absinfo abs[] = {
> + { ABS_X, 0, 1152, 0, 0, 0 },
> + { ABS_Y, 0, 1920, 0, 0, 0 },
> + { ABS_MT_SLOT, 0, 9, 0, 0, 0 },
> + { ABS_MT_TRACKING_ID, 0, 65535, 0, 0, 0 },
> + { ABS_MT_POSITION_X, 0, 1152, 0, 0, 0 },
> + { ABS_MT_POSITION_Y, 0, 1920, 0, 0, 0 },
> + { ABS_MT_TOUCH_MAJOR, 0, 23, 0, 0, 0 },
> + { ABS_MT_TOUCH_MINOR, 0, 23, 0, 0, 0 },
> + { -1, -1, -1, -1, -1, -1 }
> + };
> + const struct input_event input_sequence[] = {
> + { {0}, EV_ABS, ABS_MT_SLOT, 0},
> + { {0}, EV_ABS, ABS_MT_TRACKING_ID, 9},
> + { {0}, EV_KEY, BTN_TOUCH, 1},
> + { {0}, EV_KEY, BTN_TOOL_FINGER, 1},
> + { {0}, EV_ABS, ABS_MT_POSITION_X, 128},
> + { {0}, EV_ABS, ABS_MT_POSITION_Y, 240},
> + { {0}, EV_ABS, ABS_MT_TOUCH_MAJOR, 5},
> + { {0}, EV_ABS, ABS_MT_TOUCH_MINOR, 4},
> + { {0}, EV_SYN, SYN_REPORT, 0},
> + { {0}, EV_ABS, ABS_MT_TOUCH_MAJOR, 6},
> + { {0}, EV_SYN, SYN_REPORT, 0},
> + { {0}, EV_ABS, ABS_MT_TRACKING_ID, -1},
> + { {0}, EV_KEY, BTN_TOUCH, 0},
> + { {0}, EV_KEY, BTN_TOOL_FINGER, 0},
> + { {0}, EV_SYN, SYN_REPORT, 0}
> + };
> + const int num_events = ARRAY_LENGTH(input_sequence);
> + const int width = 1152;
> + const int height = 1920;
> + int x, y, major, minor;
> +
> + uinput = litest_create_uinput_abs_device(
> + "test device",
> + NULL, abs,
> + EV_KEY, BTN_TOUCH,
> + EV_KEY, BTN_TOOL_FINGER,
> + INPUT_PROP_MAX, INPUT_PROP_DIRECT,
> + -1, -1);
> +
> + li = litest_create_context();
> + device = libinput_path_add_device(li,
> + libevdev_uinput_get_devnode(uinput));
> + ck_assert(device != NULL);
> + device = libinput_device_ref(device);
> + litest_drain_events(li);
> +
> + for (int i = 0; i!=num_events; ++i)
> + libevdev_uinput_write_event(uinput,
> + input_sequence[i].type,
> + input_sequence[i].code,
> + input_sequence[i].value);
> +
> + litest_wait_for_event(li);
> +
> + event = libinput_get_event(li);
> + tev = litest_is_touch_event(event, LIBINPUT_EVENT_TOUCH_DOWN);
> + x = round(libinput_event_touch_get_x_transformed(tev, width));
> + y = round(libinput_event_touch_get_y_transformed(tev, height)),
> + major = round(
>
Re: [PATCH weston] Support axis source, axis discreet, axis frame and axis stop events
On Mon, Oct 19, 2015 at 06:17:31PM -0700, Bryce Harrington wrote:
> On Fri, Oct 16, 2015 at 12:39:22PM +1000, Peter Hutterer wrote:
> > Signed-off-by: Peter Hutterer
> > ---
> > The client-side is the simplest implementation here, and I went the easy
> > route since most clients won't care to register a multitude of handlers for
> > axis events.
> >
> > The eventdemo client merely prints the events, it doesn't accumulate them as
> > they should be. That'd be the job of a slightly more sophisticated toolkit.
> >
> > Possibly contentious: there's no notify_axis_stop(), it's folded into
> > notify_axis(). Easy fix if needed.
> >
> > Also, I recommend not merging this one until we have a test implementation
> > in mutter + GTK to make sure the protocol is sane enough to use from complex
> > clients.
>
> Thanks for resending these patches. Since the main goal here is
> assuring the protocol is right, should we also hold off on landing the
> wayland piece until there's consensus around this one too, or is the
> protocol part ok to land?
I'm planning to do a second review of the protocol patches, and there
will at least be minor changes needed, so please don't merge anything
yet. Will try to get that done as soon as possible.
Jonas
>
> Bryce
>
> > clients/eventdemo.c | 55 -
> > clients/window.c | 91
> > +++-
> > clients/window.h | 28 +++
> > src/compositor-wayland.c | 39 +
> > src/compositor-x11.c | 16 ++---
> > src/compositor.h | 10 ++
> > src/input.c | 74 ++-
> > src/libinput-device.c| 63 +++--
> > 8 files changed, 360 insertions(+), 16 deletions(-)
> >
> > diff --git a/clients/eventdemo.c b/clients/eventdemo.c
> > index bdad6fd..f520233 100644
> > --- a/clients/eventdemo.c
> > +++ b/clients/eventdemo.c
> > @@ -259,6 +259,54 @@ axis_handler(struct widget *widget, struct input
> > *input, uint32_t time,
> >wl_fixed_to_double(value));
> > }
> >
> > +static void
> > +axis_frame_handler(struct widget *widget, struct input *input, void *data)
> > +{
> > + printf("axis frame\n");
> > +}
> > +
> > +static void
> > +axis_source_handler(struct widget *widget, struct input *input,
> > + uint32_t source, void *data)
> > +{
> > + const char *axis_source;
> > +
> > + switch (source) {
> > + case WL_POINTER_AXIS_SOURCE_WHEEL:
> > + axis_source = "wheel";
> > + break;
> > + case WL_POINTER_AXIS_SOURCE_FINGER:
> > + axis_source = "finger";
> > + break;
> > + case WL_POINTER_AXIS_SOURCE_CONTINUOUS:
> > + axis_source = "continuous";
> > + break;
> > + default:
> > + axis_source = "";
> > + break;
> > + }
> > +
> > + printf("axis source: %s\n", axis_source);
> > +}
> > +
> > +static void
> > +axis_stop_handler(struct widget *widget, struct input *input,
> > + uint32_t time, uint32_t axis,
> > + void *data)
> > +{
> > + printf("axis stop time: %d, axis: %s\n",
> > + time,
> > + axis == WL_POINTER_AXIS_VERTICAL_SCROLL ? "vertical" :
> > +"horizontal");
> > +}
> > +
> > +static void
> > +axis_discrete_handler(struct widget *widget, struct input *input,
> > + int32_t discrete, void *data)
> > +{
> > + printf("axis discrete value: %d\n", discrete);
> > +}
> > +
> > /**
> > * \brief CALLBACK function, Waylands informs about pointer motion
> > * \param widget widget
> > @@ -348,7 +396,12 @@ eventdemo_create(struct display *d)
> > widget_set_motion_handler(e->widget, motion_handler);
> >
> > /* Set the callback axis handler for the window */
> > - widget_set_axis_handler(e->widget, axis_handler);
> > + widget_set_axis_handlers(e->widget,
> > +axis_handler,
> > +axis_frame_handler,
> > +axis_source_handler,
> > +axis_stop_handler,
> > +axis_discrete_handler);
> >
> > /* Initial drawing of the window */
> > window_schedule_resize(e->window, width, height);
> > diff --git a/clients/window.c b/clients/window.c
> > index 6d3e944..121037b 100644
> > --- a/clients/window.c
> > +++ b/clients/window.c
> > @@ -288,6 +288,10 @@ struct widget {
> > widget_touch_frame_handler_t touch_frame_handler;
> > widget_touch_cancel_handler_t touch_cancel_handler;
> > widget_axis_handler_t axis_handler;
> > + widget_axis_frame_handler_t axis_frame_handler;
> > + widget_axis_source_handler_t axis_source_handler;
> > + widget_axis_stop_handler_t axis_stop_handler;
> > + widget_axis_discrete_handler_t axis_discrete_handler;
> > void *user_data;
> > int opaque;
> > int tooltip_count;
>
Re: [PATCH weston] Support axis source, axis discreet, axis frame and axis stop events
On Fri, Oct 16, 2015 at 12:39:22PM +1000, Peter Hutterer wrote:
> Signed-off-by: Peter Hutterer
> ---
> The client-side is the simplest implementation here, and I went the easy
> route since most clients won't care to register a multitude of handlers for
> axis events.
>
> The eventdemo client merely prints the events, it doesn't accumulate them as
> they should be. That'd be the job of a slightly more sophisticated toolkit.
>
> Possibly contentious: there's no notify_axis_stop(), it's folded into
> notify_axis(). Easy fix if needed.
>
> Also, I recommend not merging this one until we have a test implementation
> in mutter + GTK to make sure the protocol is sane enough to use from complex
> clients.
Thanks for resending these patches. Since the main goal here is
assuring the protocol is right, should we also hold off on landing the
wayland piece until there's consensus around this one too, or is the
protocol part ok to land?
Bryce
> clients/eventdemo.c | 55 -
> clients/window.c | 91
> +++-
> clients/window.h | 28 +++
> src/compositor-wayland.c | 39 +
> src/compositor-x11.c | 16 ++---
> src/compositor.h | 10 ++
> src/input.c | 74 ++-
> src/libinput-device.c| 63 +++--
> 8 files changed, 360 insertions(+), 16 deletions(-)
>
> diff --git a/clients/eventdemo.c b/clients/eventdemo.c
> index bdad6fd..f520233 100644
> --- a/clients/eventdemo.c
> +++ b/clients/eventdemo.c
> @@ -259,6 +259,54 @@ axis_handler(struct widget *widget, struct input *input,
> uint32_t time,
> wl_fixed_to_double(value));
> }
>
> +static void
> +axis_frame_handler(struct widget *widget, struct input *input, void *data)
> +{
> + printf("axis frame\n");
> +}
> +
> +static void
> +axis_source_handler(struct widget *widget, struct input *input,
> + uint32_t source, void *data)
> +{
> + const char *axis_source;
> +
> + switch (source) {
> + case WL_POINTER_AXIS_SOURCE_WHEEL:
> + axis_source = "wheel";
> + break;
> + case WL_POINTER_AXIS_SOURCE_FINGER:
> + axis_source = "finger";
> + break;
> + case WL_POINTER_AXIS_SOURCE_CONTINUOUS:
> + axis_source = "continuous";
> + break;
> + default:
> + axis_source = "";
> + break;
> + }
> +
> + printf("axis source: %s\n", axis_source);
> +}
> +
> +static void
> +axis_stop_handler(struct widget *widget, struct input *input,
> + uint32_t time, uint32_t axis,
> + void *data)
> +{
> + printf("axis stop time: %d, axis: %s\n",
> +time,
> +axis == WL_POINTER_AXIS_VERTICAL_SCROLL ? "vertical" :
> + "horizontal");
> +}
> +
> +static void
> +axis_discrete_handler(struct widget *widget, struct input *input,
> + int32_t discrete, void *data)
> +{
> + printf("axis discrete value: %d\n", discrete);
> +}
> +
> /**
> * \brief CALLBACK function, Waylands informs about pointer motion
> * \param widget widget
> @@ -348,7 +396,12 @@ eventdemo_create(struct display *d)
> widget_set_motion_handler(e->widget, motion_handler);
>
> /* Set the callback axis handler for the window */
> - widget_set_axis_handler(e->widget, axis_handler);
> + widget_set_axis_handlers(e->widget,
> + axis_handler,
> + axis_frame_handler,
> + axis_source_handler,
> + axis_stop_handler,
> + axis_discrete_handler);
>
> /* Initial drawing of the window */
> window_schedule_resize(e->window, width, height);
> diff --git a/clients/window.c b/clients/window.c
> index 6d3e944..121037b 100644
> --- a/clients/window.c
> +++ b/clients/window.c
> @@ -288,6 +288,10 @@ struct widget {
> widget_touch_frame_handler_t touch_frame_handler;
> widget_touch_cancel_handler_t touch_cancel_handler;
> widget_axis_handler_t axis_handler;
> + widget_axis_frame_handler_t axis_frame_handler;
> + widget_axis_source_handler_t axis_source_handler;
> + widget_axis_stop_handler_t axis_stop_handler;
> + widget_axis_discrete_handler_t axis_discrete_handler;
> void *user_data;
> int opaque;
> int tooltip_count;
> @@ -1935,6 +1939,21 @@ widget_set_axis_handler(struct widget *widget,
> widget->axis_handler = handler;
> }
>
> +void
> +widget_set_axis_handlers(struct widget *widget,
> + widget_axis_handler_t axis_handler,
> + widget_axis_frame_handler_t axis_frame_handler,
> + widget_axis_source_handler_t axis_source_handler,
> + widget_axis_
Re: [PATCH weston 2/3] compositor: pass the backend config struct to the backends init function
On Sat, Oct 17, 2015 at 07:24:14PM +0300, Giulio Camuffo wrote:
> Add new configuration argument to the backend_init() function, which
> will replace the current argc, argv, and config arguments.
> After each backend is converted individually the unused parameters
> will be removed.
Thanks for breaking the patches out separately. Looks good.
Reviewed-by: Bryce Harrington
> ---
> src/compositor-drm.c | 3 ++-
> src/compositor-fbdev.c| 3 ++-
> src/compositor-headless.c | 3 ++-
> src/compositor-rdp.c | 3 ++-
> src/compositor-rpi.c | 3 ++-
> src/compositor-wayland.c | 3 ++-
> src/compositor-x11.c | 3 ++-
> src/compositor.h | 3 ++-
> src/main.c| 5 +++--
> 9 files changed, 19 insertions(+), 10 deletions(-)
>
> diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> index 36c3b3e..41f9a82 100644
> --- a/src/compositor-drm.c
> +++ b/src/compositor-drm.c
> @@ -3238,7 +3238,8 @@ err_base:
>
> WL_EXPORT int
> backend_init(struct weston_compositor *compositor, int *argc, char *argv[],
> - struct weston_config *config)
> + struct weston_config *config,
> + struct weston_backend_config *config_base)
> {
> struct drm_backend *b;
> struct drm_parameters param = { 0, };
> diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
> index 7465df6..57c54c2 100644
> --- a/src/compositor-fbdev.c
> +++ b/src/compositor-fbdev.c
> @@ -904,7 +904,8 @@ out_compositor:
>
> WL_EXPORT int
> backend_init(struct weston_compositor *compositor, int *argc, char *argv[],
> - struct weston_config *config)
> + struct weston_config *config,
> + struct weston_backend_config *config_base)
> {
> struct fbdev_backend *b;
> /* TODO: Ideally, available frame buffers should be enumerated using
> diff --git a/src/compositor-headless.c b/src/compositor-headless.c
> index dba21a6..ba0d8d7 100644
> --- a/src/compositor-headless.c
> +++ b/src/compositor-headless.c
> @@ -260,7 +260,8 @@ err_free:
> WL_EXPORT int
> backend_init(struct weston_compositor *compositor,
>int *argc, char *argv[],
> - struct weston_config *config)
> + struct weston_config *config,
> + struct weston_backend_config *config_base)
> {
> int width = 1024, height = 640;
> char *display_name = NULL;
> diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
> index 7272f41..1098f01 100644
> --- a/src/compositor-rdp.c
> +++ b/src/compositor-rdp.c
> @@ -1269,7 +1269,8 @@ err_free_strings:
>
> WL_EXPORT int
> backend_init(struct weston_compositor *compositor, int *argc, char *argv[],
> - struct weston_config *wconfig)
> + struct weston_config *wconfig,
> + struct weston_backend_config *config_base)
> {
> struct rdp_backend *b;
> struct rdp_backend_config config;
> diff --git a/src/compositor-rpi.c b/src/compositor-rpi.c
> index 83c01b4..4d7ea7b 100644
> --- a/src/compositor-rpi.c
> +++ b/src/compositor-rpi.c
> @@ -555,7 +555,8 @@ out_compositor:
> WL_EXPORT int
> backend_init(struct weston_compositor *compositor,
>int *argc, char *argv[],
> - struct weston_config *config)
> + struct weston_config *config,
> + struct weston_backend_config *config_base)
> {
> const char *transform = "normal";
> struct rpi_backend *b;
> diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
> index 7b11ae4..a819867 100644
> --- a/src/compositor-wayland.c
> +++ b/src/compositor-wayland.c
> @@ -2056,7 +2056,8 @@ wayland_backend_destroy(struct wayland_backend *b)
>
> WL_EXPORT int
> backend_init(struct weston_compositor *compositor, int *argc, char *argv[],
> - struct weston_config *config)
> + struct weston_config *config,
> + struct weston_backend_config *config_base)
> {
> struct wayland_backend *b;
> struct wayland_output *output;
> diff --git a/src/compositor-x11.c b/src/compositor-x11.c
> index 9a23996..ccb7867 100644
> --- a/src/compositor-x11.c
> +++ b/src/compositor-x11.c
> @@ -1701,7 +1701,8 @@ err_free:
>
> WL_EXPORT int
> backend_init(struct weston_compositor *compositor, int *argc, char *argv[],
> - struct weston_config *config)
> + struct weston_config *config,
> + struct weston_backend_config *config_base)
> {
> struct x11_backend *b;
> int fullscreen = 0;
> diff --git a/src/compositor.h b/src/compositor.h
> index 172de6f..6bb6222 100644
> --- a/src/compositor.h
> +++ b/src/compositor.h
> @@ -1599,7 +1599,8 @@ noop_renderer_init(struct weston_compositor *ec);
> int
> backend_init(struct weston_compositor *c,
>int *argc, char *argv[],
> - struct weston_config *config);
> + struct weston_config *config,
> + struct weston_backend_config *config_base);
> int
> module_init(struct weston_compositor *compositor,
> int *argc, char *argv[]);
> diff --git
Re: [PATCH weston 3/3] main: stub the functions to load the backends with the new config system
On Sat, Oct 17, 2015 at 07:24:15PM +0300, Giulio Camuffo wrote:
> ---
> src/main.c | 68
> +-
> 1 file changed, 59 insertions(+), 9 deletions(-)
Reviewed-by: Bryce Harrington
> diff --git a/src/main.c b/src/main.c
> index 11ade46..8c7b853 100644
> --- a/src/main.c
> +++ b/src/main.c
> @@ -629,6 +629,64 @@ handle_exit(struct weston_compositor *c)
> wl_display_terminate(c->wl_display);
> }
>
> +/* Temporary function to be removed when all backends are converted. */
> +static int
> +load_backend_old(struct weston_compositor *compositor, const char *backend,
> + int *argc, char **argv, struct weston_config *wc)
> +{
> + int (*backend_init)(struct weston_compositor *c,
> + int *argc, char *argv[],
> + struct weston_config *config,
> + struct weston_backend_config *config_base);
> +
> + backend_init = weston_load_module(backend, "backend_init");
> + if (!backend_init)
> + return -1;
> +
> + return backend_init(compositor, argc, argv, wc, NULL);
> +}
> +
> +/* Temporary function to be replaced by weston_compositor_load_backend(). */
> +static int
> +load_backend_new(struct weston_compositor *compositor, const char *backend,
> + struct weston_backend_config *config_base)
> +{
> + int (*backend_init)(struct weston_compositor *c,
> + int *argc, char *argv[],
> + struct weston_config *config,
> + struct weston_backend_config *config_base);
> +
> + backend_init = weston_load_module(backend, "backend_init");
> + if (!backend_init)
> + return -1;
> +
> + return backend_init(compositor, NULL, NULL, NULL, config_base);
> +}
> +
> +static int
> +load_backend(struct weston_compositor *compositor, const char *backend,
> + int *argc, char **argv, struct weston_config *config)
> +{
> +#if 0
> + if (strstr(backend, "drm-backend.so"))
> + return load_drm_backend(compositor, backend, argc, argv,
> config);
> + else if (strstr(backend, "wayland-backend.so"))
> + return load_wayland_backend(compositor, backend, argc, argv,
> config);
> + else if (strstr(backend, "x11-backend.so"))
> + return load_x11_backend(compositor, backend, argc, argv,
> config);
> + else if (strstr(backend, "fbdev-backend.so"))
> + return load_fbdev_backend(compositor, backend, argc, argv,
> config);
> + else if (strstr(backend, "headless-backend.so"))
> + return load_headless_backend(compositor, backend, argc, argv,
> config);
> + else if (strstr(backend, "rpi-backend.so"))
> + return load_rpi_backend(compositor, backend, argc, argv,
> config);
> + else if (strstr(backend, "rdp-backend.so"))
> + return load_rdp_backend(compositor, backend, argc, argv,
> config);
> +#endif
> +
> + return load_backend_old(compositor, backend, argc, argv, config);
> +}
> +
> int main(int argc, char *argv[])
> {
> int ret = EXIT_FAILURE;
> @@ -636,10 +694,6 @@ int main(int argc, char *argv[])
> struct weston_compositor *ec;
> struct wl_event_source *signals[4];
> struct wl_event_loop *loop;
> - int (*backend_init)(struct weston_compositor *c,
> - int *argc, char *argv[],
> - struct weston_config *config,
> - struct weston_backend_config *config_base);
> int i, fd;
> char *backend = NULL;
> char *shell = NULL;
> @@ -724,10 +778,6 @@ int main(int argc, char *argv[])
> backend = weston_choose_default_backend();
> }
>
> - backend_init = weston_load_module(backend, "backend_init");
> - if (!backend_init)
> - goto out_signals;
> -
> ec = weston_compositor_create(display, NULL);
> if (ec == NULL) {
> weston_log("fatal: failed to create compositor\n");
> @@ -738,7 +788,7 @@ int main(int argc, char *argv[])
> if (weston_compositor_init_config(ec, config) < 0)
> goto out;
>
> - if (backend_init(ec, &argc, argv, config, NULL) < 0) {
> + if (load_backend(ec, backend, &argc, argv, config) < 0) {
> weston_log("fatal: failed to create compositor backend\n");
> goto out;
> }
> --
> 2.6.1
>
> ___
> 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
Re: [PATCH weston 1/3] compositor: introduce structs to handle backends configuration
On Sat, Oct 17, 2015 at 07:24:13PM +0300, Giulio Camuffo wrote:
> This commit introduces the structs weston_backend_config and
> weston_backend_output_config, to prepare for the new config
> system for the backends.
> ---
> src/compositor.h | 36 ++--
> 1 file changed, 34 insertions(+), 2 deletions(-)
>
> diff --git a/src/compositor.h b/src/compositor.h
> index 2e2a185..172de6f 100644
> --- a/src/compositor.h
> +++ b/src/compositor.h
> @@ -610,9 +610,41 @@ enum weston_capability {
> WESTON_CAP_VIEW_CLIP_MASK = 0x0010,
> };
>
> +/* Configuration struct for an output.
> + *
> + * This struct is used to pass the configuration for an output
> + * to the compositor backend when creating a new output.
> + * The backend can subclass this struct to handle backend
> + * specific data.
> + */
> +struct weston_backend_output_config {
> + uint32_t transform;
> + int32_t width;
> + int32_t height;
> + int scale;
Do we expect to ever have negative values for width, height, or scale?
If not, would it make sense for these to also be uint32_t's?
> +};
> +
> +/* Configuration struct for a backend.
> + *
> + * This struct carries the configuration for a backend, and it's
> + * passed to the backend's init entry point. The backend will
> + * likely want to subclass this in order to handle backend specific
> + * data.
> + */
> +struct weston_backend_config {
> +};
> +
> struct weston_backend {
> - void (*destroy)(struct weston_compositor *ec);
> - void (*restore)(struct weston_compositor *ec);
> + void (*destroy)(struct weston_compositor *compositor);
> + void (*restore)(struct weston_compositor *compositor);
> + /* vfunc to create a new output with a given name and config.
> + * backends not supporting the functionality will set this
> + * to NULL.
> + */
> + struct weston_output *
> + (*create_output)(struct weston_compositor *compositor,
> + const char *name,
> + struct weston_backend_output_config *config);
> };
>
> struct weston_compositor {
> --
> 2.6.1
>
> ___
> 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
Re: iio sensors, acceleration and gyro.
On Mon, Oct 19, 2015 at 12:20:27PM -0500, Mike Mestnik wrote: > Hello, > I've been working on a project called iio-sensor-proxy, it's a > project to take sensor readings and make them available over dbus. I > feel that this takes away from the generic concept that everything is > a file. > > Does this code perhaps have a better home in libinput? > > https://github.com/hadess/iio-sensor-proxy I don't think so. iio-sensor-proxy is not at the same level as libinput, and the dbus API is there for a reason. in theory, a libinput-based solution would be for libinput to read the sensors and have iio-sensor-proxy wrap libinput to provide the dbus API that applications require. That wouldn't add anything to the current solution though, it'd be mostly code churn for little benefit. so unless Bastian requests that we add this to libinput, I don't think this is worth pursuing. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH v2 1/4] doc: document the enum and bitfield attributes
Introduce the enum and bitfield attributes, which allow you to refer to the enum you are expecting in an argument, and specify which enums are to be thought of as bitfields. Signed-off-by: Auke Booij --- doc/publican/sources/Protocol.xml | 35 +-- 1 file changed, 29 insertions(+), 6 deletions(-) diff --git a/doc/publican/sources/Protocol.xml b/doc/publican/sources/Protocol.xml index 477063b..c6178b7 100644 --- a/doc/publican/sources/Protocol.xml +++ b/doc/publican/sources/Protocol.xml @@ -15,6 +15,32 @@ identifies which method in the interface to invoke. + The protocol is message-based. A message sent by a client to the server + is called request. A message from the server to a client is called event. + A message has a number of arguments, each of which has a certain type (see + for a list of argument types). + Additionally, the protocol can specify enums. These are used + to list options for int and uint type arguments. + Arguments can refer to the specific enumeration that is semantically + implied. Only in the case that the argument is of type uint, + it can be specified that the primary interface to its numeric value deals + with bitwise operations, for example when arbitrarily many choices of the + enum can be ORed together. + + + The purpose of the enum and bitfield attributes + is to document what arguments refer to which enums, and to document which + numeric enum values are primarily accessed using bitwise operations. + Additionally, the enum and bitfield attributes may be used by other code, + such as bindings to other languages, for example to enhance type safety of + code. However, such usage is only supported if the following property is + satisfied: code written prior to the specification of these attributes + still works after their specification. In other words, specifying an + attribute for an argument, that previously did not have an enum or + bitfield attribute, should not break API. Code that does not satisfy this + rule is not guaranteed to obey backwards compatibility. + + The server sends back events to the client, each event is emitted from an object. Events can be error conditions. The event includes the object ID and the event opcode, from which the client can determine @@ -62,14 +88,11 @@ The protocol is sent over a UNIX domain stream socket, where the endpoint usually is named wayland-0 (although it can be changed via WAYLAND_DISPLAY - in the environment). The protocol is message-based. A - message sent by a client to the server is called request. A message - from the server to a client is called event. Every message is - structured as 32-bit words, values are represented in the host's - byte-order. + in the environment). - The message header has 2 words in it: + Every message is structured as 32-bit words, values are represented in the + host's byte-order. The message header has 2 words in it: -- 2.6.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH v2 0/4] Enum and bitfield XML attributes
There has been plenty of discussion regarding the introduction of new XML attributes. This series of patches improves on my earlier attempt to find common ground in this. Major exclusions from these patches are: - Support for cross-interface enum referencing (e.g. wl_shm_pool::create_buffer::format to wl_shm::format, and wl_surface::set_buffer_transform::transform to wl_output::transform). - Open/closed enum specification. There is still too much debate in this. Until there is any firm specification of open/closed enums, every enum should be considered open, and although some legal values might be listed, others might not be, and some might only be legal sometimes. New values may be added (but not changed or removed) to protocol specifications without introducing any compatibility issues. Auke Booij (4): doc: document the enum and bitfield attributes protocol: specify enum and bitfield attributes scanner: enforce correct argument type for enums doc: output enum and bitfield attributes in the documentation doc/publican/protocol-to-docbook.xsl | 9 + doc/publican/sources/Protocol.xml| 35 ++ protocol/wayland.xml | 34 +- src/scanner.c| 70 4 files changed, 125 insertions(+), 23 deletions(-) -- 2.6.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH v2 4/4] doc: output enum and bitfield attributes in the documentation
Signed-off-by: Auke Booij --- doc/publican/protocol-to-docbook.xsl | 9 + 1 file changed, 9 insertions(+) diff --git a/doc/publican/protocol-to-docbook.xsl b/doc/publican/protocol-to-docbook.xsl index 7b45969..fad207a 100644 --- a/doc/publican/protocol-to-docbook.xsl +++ b/doc/publican/protocol-to-docbook.xsl @@ -102,6 +102,12 @@ + + + + + + - @@ -171,6 +177,9 @@ :: + +- bitfield + - -- 2.6.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH v2 2/4] protocol: specify enum and bitfield attributes
Signed-off-by: Auke Booij --- protocol/wayland.xml | 34 +- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 59819e9..a3e6900 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -367,7 +367,7 @@ can be used for buffers. Known formats include argb and xrgb. - + @@ -774,7 +774,7 @@ - + @@ -785,7 +785,7 @@ - + These flags specify details of the expected behaviour of transient surfaces. Used in the set_transient request. @@ -807,7 +807,7 @@ - + @@ -858,7 +858,7 @@ with the dimensions for the output on which the surface will be made fullscreen. - + @@ -891,7 +891,7 @@ - + @@ -972,7 +972,7 @@ in surface local coordinates. - + @@ -1337,7 +1337,7 @@ maintains a keyboard focus and a pointer focus. - + This is a bitmask of capabilities this seat has; if a member is set, then it is present on the seat. @@ -1353,7 +1353,7 @@ keyboard or touch capabilities. The argument is a capability enum containing the complete set of capabilities this seat has. - + @@ -1530,7 +1530,7 @@ - + @@ -1562,7 +1562,7 @@ - + @@ -1602,7 +1602,7 @@ This event provides a file descriptor to the client which can be memory-mapped to provide a keyboard mapping description. - + @@ -1647,7 +1647,7 @@ - + @@ -1828,17 +1828,17 @@ summary="width in millimeters of the output"/> - - - + These flags describe properties of an output mode. They are used in the flags bitfield of the mode event. @@ -1865,7 +1865,7 @@ the output may be scaled, as described in wl_output.scale, or transformed , as described in wl_output.transform. - + -- 2.6.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH v2 3/4] scanner: enforce correct argument type for enums
The scanner now checks whether arguments that have an associated
have the right type.
An argument with an enum attribute must be of type int or uint,
and if the with that name has the bitfield attribute
set to true, then the argument must be of type uint.
Signed-off-by: Auke Booij
---
src/scanner.c | 70 +++
1 file changed, 70 insertions(+)
diff --git a/src/scanner.c b/src/scanner.c
index f456aa5..9856475 100644
--- a/src/scanner.c
+++ b/src/scanner.c
@@ -128,6 +128,7 @@ struct arg {
char *interface_name;
struct wl_list link;
char *summary;
+ char *enumeration_name;
};
struct enumeration {
@@ -136,6 +137,7 @@ struct enumeration {
struct wl_list entry_list;
struct wl_list link;
struct description *description;
+ int bitfield;
};
struct entry {
@@ -540,6 +542,8 @@ start_element(void *data, const char *element_name, const
char **atts)
const char *summary = NULL;
const char *since = NULL;
const char *allow_null = NULL;
+ const char *enumeration_name = NULL;
+ const char *bitfield = NULL;
int i, version = 0;
ctx->loc.line_number = XML_GetCurrentLineNumber(ctx->parser);
@@ -562,6 +566,10 @@ start_element(void *data, const char *element_name, const
char **atts)
since = atts[i + 1];
if (strcmp(atts[i], "allow-null") == 0)
allow_null = atts[i + 1];
+ if (strcmp(atts[i], "enum") == 0)
+ enumeration_name = atts[i + 1];
+ if (strcmp(atts[i], "bitfield") == 0)
+ bitfield = atts[i + 1];
}
ctx->character_data_length = 0;
@@ -655,6 +663,14 @@ start_element(void *data, const char *element_name, const
char **atts)
"allow-null is only valid for objects,
strings, and arrays");
}
+ if (enumeration_name == NULL || strcmp(enumeration_name, "") ==
0)
+ arg->enumeration_name = NULL;
+ else
+ arg->enumeration_name = xstrdup(enumeration_name);
+
+ if (allow_null != NULL && !is_nullable_type(arg))
+ fail(&ctx->loc, "allow-null is only valid for objects,
strings, and arrays");
+
if (summary)
arg->summary = xstrdup(summary);
@@ -665,6 +681,14 @@ start_element(void *data, const char *element_name, const
char **atts)
fail(&ctx->loc, "no enum name given");
enumeration = create_enumeration(name);
+
+ if (bitfield == NULL || strcmp(bitfield, "false") == 0)
+ enumeration->bitfield = 0;
+ else if (strcmp(bitfield, "true") == 0)
+ enumeration->bitfield =1;
+ else
+ fail(&ctx->loc, "invalid value for bitfield attribute
(%s)", bitfield);
+
wl_list_insert(ctx->interface->enumeration_list.prev,
&enumeration->link);
@@ -701,6 +725,46 @@ start_element(void *data, const char *element_name, const
char **atts)
}
static void
+verify_arguments(struct parse_context *ctx, struct wl_list *messages, struct
wl_list *enumerations)
+{
+ struct message *m;
+ wl_list_for_each(m, messages, link) {
+ struct arg *a;
+ wl_list_for_each(a, &m->arg_list, link) {
+ struct enumeration *e, *f;
+
+ if (!a->enumeration_name)
+ continue;
+
+ f = NULL;
+ wl_list_for_each(e, enumerations, link) {
+ if(strcmp(e->name, a->enumeration_name) == 0)
+ f = e;
+ }
+
+ if (f == NULL)
+ fail(&ctx->loc,
+"could not find enumeration %s",
+a->enumeration_name);
+
+ switch (a->type) {
+ case INT:
+ if (f->bitfield)
+ fail(&ctx->loc,
+"bitfield-style enum must be
referenced by uint");
+ break;
+ case UNSIGNED:
+ break;
+ default:
+ fail(&ctx->loc,
+"enumeration-style argument has wrong
type");
+ }
+ }
+ }
+
+}
+
+static void
end_element(void *data, const XML_Char *name)
{
struct parse_context *ctx = data;
@@ -723,6 +787,12 @@ end_element(void *data, const XML_Char *name)
ctx->enumerat
Re: [PATCH weston] clients: track seat_version per seat, not per display
Pushed
Thanks,
Derek
On 15/10/15 02:30 AM, Pekka Paalanen wrote:
> On Wed, 14 Oct 2015 20:57:35 +0200
> Hardening wrote:
>
>> Le 14/10/2015 16:39, Derek Foreman a écrit :
>>> Apparently it's possible for a compositor to advertise seats with
>>> different versions on the same connection, so this makes us more robust
>>> against that dubious behaviour.
>>>
>>> This also tracks the seat version we requested instead of the advertised
>>> maximum.
>>>
>>> Signed-off-by: Derek Foreman
>>> ---
>>>
>>> As penance for my sass, I've gone ahead and "fixed" this - I think
>>> tracking the version we requested instead of the one advertised is
>>> more robust against catching a failure to increment the requested
>>> version though. However, it does seem like the correct thing to do.
>>>
>>> clients/window.c | 20 +++-
>>> 1 file changed, 11 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/clients/window.c b/clients/window.c
>>> index 6d3e944..d8f2ee2 100644
>>> --- a/clients/window.c
>>> +++ b/clients/window.c
>>> @@ -140,7 +140,6 @@ struct display {
>>> void *dummy_surface_data;
>>>
>>> int has_rgb565;
>>> - int seat_version;
>>> int data_device_manager_version;
>>> };
>>>
>>> @@ -362,6 +361,7 @@ struct input {
>>> uint32_t repeat_sym;
>>> uint32_t repeat_key;
>>> uint32_t repeat_time;
>>> + int seat_version;
>>> };
>>>
>>> struct output {
>>> @@ -3256,7 +3256,7 @@ seat_handle_capabilities(void *data, struct wl_seat
>>> *seat,
>>> wl_pointer_add_listener(input->pointer, &pointer_listener,
>>> input);
>>> } else if (!(caps & WL_SEAT_CAPABILITY_POINTER) && input->pointer) {
>>> - if (input->display->seat_version >=
>>> WL_POINTER_RELEASE_SINCE_VERSION)
>>> + if (input->seat_version >= WL_POINTER_RELEASE_SINCE_VERSION)
>>> wl_pointer_release(input->pointer);
>>> else
>>> wl_pointer_destroy(input->pointer);
>>> @@ -3269,7 +3269,7 @@ seat_handle_capabilities(void *data, struct wl_seat
>>> *seat,
>>> wl_keyboard_add_listener(input->keyboard, &keyboard_listener,
>>> input);
>>> } else if (!(caps & WL_SEAT_CAPABILITY_KEYBOARD) && input->keyboard) {
>>> - if (input->display->seat_version >=
>>> WL_KEYBOARD_RELEASE_SINCE_VERSION)
>>> + if (input->seat_version >= WL_KEYBOARD_RELEASE_SINCE_VERSION)
>>> wl_keyboard_release(input->keyboard);
>>> else
>>> wl_keyboard_destroy(input->keyboard);
>>> @@ -3281,7 +3281,7 @@ seat_handle_capabilities(void *data, struct wl_seat
>>> *seat,
>>> wl_touch_set_user_data(input->touch, input);
>>> wl_touch_add_listener(input->touch, &touch_listener, input);
>>> } else if (!(caps & WL_SEAT_CAPABILITY_TOUCH) && input->touch) {
>>> - if (input->display->seat_version >=
>>> WL_TOUCH_RELEASE_SINCE_VERSION)
>>> + if (input->seat_version >= WL_TOUCH_RELEASE_SINCE_VERSION)
>>> wl_touch_release(input->touch);
>>> else
>>> wl_touch_destroy(input->touch);
>>> @@ -5218,17 +5218,20 @@ fini_xkb(struct input *input)
>>> }
>>>
>>> static void
>>> -display_add_input(struct display *d, uint32_t id)
>>> +display_add_input(struct display *d, uint32_t id, int display_seat_version)
>>> {
>>> struct input *input;
>>> + int seat_version = MIN(display_seat_version, 4);
>>>
>>> input = xzalloc(sizeof *input);
>>> input->display = d;
>>> input->seat = wl_registry_bind(d->registry, id, &wl_seat_interface,
>>> - MIN(d->seat_version, 4));
>>> + seat_version);
>>> input->touch_focus = NULL;
>>> input->pointer_focus = NULL;
>>> input->keyboard_focus = NULL;
>>> + input->seat_version = seat_version;
>>> +
>>> wl_list_init(&input->touch_point_list);
>>> wl_list_insert(d->input_list.prev, &input->link);
>>>
>>> @@ -5278,7 +5281,7 @@ input_destroy(struct input *input)
>>> else
>>> wl_data_device_destroy(input->data_device);
>>> }
>>> - if (input->display->seat_version >= WL_POINTER_RELEASE_SINCE_VERSION) {
>>> + if (input->seat_version >= WL_POINTER_RELEASE_SINCE_VERSION) {
>>> if (input->touch)
>>> wl_touch_release(input->touch);
>>> if (input->pointer)
>>> @@ -5365,8 +5368,7 @@ registry_handle_global(void *data, struct wl_registry
>>> *registry, uint32_t id,
>>> } else if (strcmp(interface, "wl_output") == 0) {
>>> display_add_output(d, id);
>>> } else if (strcmp(interface, "wl_seat") == 0) {
>>> - d->seat_version = version;
>>> - display_add_input(d, id);
>>> + display_add_input(d, id, version);
>>> } else if (strcmp(interface, "wl_shm") == 0) {
>>> d->shm = wl_r
iio sensors, acceleration and gyro.
Hello, I've been working on a project called iio-sensor-proxy, it's a project to take sensor readings and make them available over dbus. I feel that this takes away from the generic concept that everything is a file. Does this code perhaps have a better home in libinput? https://github.com/hadess/iio-sensor-proxy ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] weston: implement inert objects for keyboard/pointer/touch
Hello, On 19 October 2015 at 15:47, David FORT wrote: > This is the second version. I have restored the ref counting of input devices, > I think with the name weston_seat_init_pointer is not accurate, perhaps > weston_seat_add_pointer_device would be better. I'm really wondering if it's > the weston core that should do that refcounting, or if the input backend > should > do it itself. I can't see any case where we would have 2 input backends (which > would be a justification for weston doing it). > Note that with this patch, we don't save the last position of the pointer. I'm > wondering why we wanna do this, does that mean that we want the same kind of > behaviour for other input devices (saving locks state for keyboard device for > example) ? > On widely used systems that have a pointer the position of relative pointer is saved across device reconnect. So users will expect that disconnecting a mouse and connecting another one will not change pointer position. Same with keyboard locks. While buttons on a device should be released on disconnect internal state that is not mechanically represented by device position should stay. Which includes the pointer position for devices that drive the pointer with relative axis and state of keyboard locks that remain locked when the key itself is released. For devices that drive pointer with absolute axis and have axis that can be out of proximity and hence can be in state that provides no pointer position reading the initial pointer position is also needed. This is like almost all devices, actually. Since changing the pointer position or keyboard lock state at random on device reconnect would cause problems for people with USB bus issues I would think that saving the state is not just something current systems randomly happen to do. Note that hardware is sometimes not fixable to work reliably. This is especially true for wireless buses like Bluetooth. Thanks Michal ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[RFC] weston: implement inert objects for keyboard/pointer/touch
This is the second version. I have restored the ref counting of input devices, I think with the name weston_seat_init_pointer is not accurate, perhaps weston_seat_add_pointer_device would be better. I'm really wondering if it's the weston core that should do that refcounting, or if the input backend should do it itself. I can't see any case where we would have 2 input backends (which would be a justification for weston doing it). Note that with this patch, we don't save the last position of the pointer. I'm wondering why we wanna do this, does that mean that we want the same kind of behaviour for other input devices (saving locks state for keyboard device for example) ? David FORT (1): weston: implement inert objects for keyboard/pointer/touch desktop-shell/exposay.c | 16 ++-- desktop-shell/shell.c| 21 ++-- src/compositor-wayland.c | 10 +- src/compositor-x11.c | 12 ++- src/input.c | 242 +++ src/libinput-device.c| 2 +- src/screen-share.c | 2 + src/text-backend.c | 44 + src/zoom.c | 7 +- tests/weston-test.c | 18 ++-- xwayland/dnd.c | 3 +- 11 files changed, 224 insertions(+), 153 deletions(-) -- 1.9.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] weston: implement inert objects for keyboard/pointer/touch
This patch implements inert objects for wl_keyboard, wl_pointer and wl_touch.
The target case is when the server has just send a capability event about a
disappearing object, and the client binds the corresponding object. We bind an
inert object: an object does nothing when it is requested. If the client behave
correctly, this object should be released when the capability event is received
and treated (calling the corresponding release request).
As a consequence, we can rely on seat->[keyboard|pointer|touch]_state to know
if the seat has the corresponding object.
---
desktop-shell/exposay.c | 16 ++--
desktop-shell/shell.c| 21 ++--
src/compositor-wayland.c | 10 +-
src/compositor-x11.c | 12 ++-
src/input.c | 242 +++
src/libinput-device.c| 2 +-
src/screen-share.c | 2 +
src/text-backend.c | 44 +
src/zoom.c | 7 +-
tests/weston-test.c | 18 ++--
xwayland/dnd.c | 3 +-
11 files changed, 224 insertions(+), 153 deletions(-)
diff --git a/desktop-shell/exposay.c b/desktop-shell/exposay.c
index 08b86a3..d6919b3 100644
--- a/desktop-shell/exposay.c
+++ b/desktop-shell/exposay.c
@@ -574,21 +574,23 @@ exposay_transition_active(struct desktop_shell *shell)
bool animate = false;
shell->exposay.workspace = get_current_workspace(shell);
- shell->exposay.focus_prev = get_default_view(keyboard->focus);
- shell->exposay.focus_current = get_default_view(keyboard->focus);
+ if (keyboard) {
+ shell->exposay.focus_prev = get_default_view(keyboard->focus);
+ shell->exposay.focus_current =
get_default_view(keyboard->focus);
+ }
shell->exposay.clicked = NULL;
wl_list_init(&shell->exposay.surface_list);
lower_fullscreen_layer(shell, NULL);
shell->exposay.grab_kbd.interface = &exposay_kbd_grab;
- weston_keyboard_start_grab(keyboard,
- &shell->exposay.grab_kbd);
- weston_keyboard_set_focus(keyboard, NULL);
+ if (keyboard) {
+ weston_keyboard_start_grab(keyboard, &shell->exposay.grab_kbd);
+ weston_keyboard_set_focus(keyboard, NULL);
+ }
shell->exposay.grab_ptr.interface = &exposay_ptr_grab;
if (pointer) {
- weston_pointer_start_grab(pointer,
- &shell->exposay.grab_ptr);
+ weston_pointer_start_grab(pointer, &shell->exposay.grab_ptr);
weston_pointer_clear_focus(pointer);
}
wl_list_for_each(shell_output, &shell->output_list, link) {
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 3eb3f5c..cdddf09 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -380,7 +380,8 @@ shell_grab_start(struct shell_grab *grab,
struct desktop_shell *shell = shsurf->shell;
struct weston_touch *touch = weston_seat_get_touch(pointer->seat);
- popup_grab_end(pointer);
+ if (pointer)
+ popup_grab_end(pointer);
if (touch)
touch_popup_grab_end(touch);
@@ -391,11 +392,13 @@ shell_grab_start(struct shell_grab *grab,
&grab->shsurf_destroy_listener);
shsurf->grabbed = 1;
- weston_pointer_start_grab(pointer, &grab->grab);
+ if (pointer)
+ weston_pointer_start_grab(pointer, &grab->grab);
if (shell->child.desktop_shell) {
desktop_shell_send_grab_cursor(shell->child.desktop_shell,
cursor);
- weston_pointer_set_focus(pointer,
+ if (pointer)
+ weston_pointer_set_focus(pointer,
get_default_view(shell->grab_surface),
wl_fixed_from_int(0),
wl_fixed_from_int(0));
@@ -925,12 +928,10 @@ restore_focus_state(struct desktop_shell *shell, struct
workspace *ws)
wl_list_insert(&shell->compositor->seat_list,
&state->seat->link);
- if (!keyboard)
- continue;
-
surface = state->keyboard_focus;
- weston_keyboard_set_focus(keyboard, surface);
+ if (keyboard)
+ weston_keyboard_set_focus(keyboard, surface);
}
/* For any remaining seats that we don't have a focus state
@@ -955,6 +956,9 @@ replace_focus_state(struct desktop_shell *shell, struct
workspace *ws,
struct weston_keyboard *keyboard = weston_seat_get_keyboard(seat);
struct focus_state *state;
+ if (!keyboard)
+ return;
+
wl_list_for_each(state, &ws->focus_list, link) {
if (state->seat == seat) {
focus_state_set_focus(state, keyboard->focus);
@@ -148
Re: [PATCH weston] input: use doubles in the interfaces to notify of input events
Hi,
send-email continues to be broken so here's the v2:
- remove unneded casts
- avoid naming absolute variables dx/dy
--
Giulio
2015-10-19 4:49 GMT+03:00 Jonas Ådahl :
> On Sat, Oct 17, 2015 at 06:07:06PM +0300, Giulio Camuffo wrote:
>> Hi,
>> git send-email has decided that it doesn't want to send this patch but
>> likely format-patch is more reasonable so i've attached it.
>>
>> --
>> Giulio
>
>> From 060186308dde03279f7a0659e7edec706a0f5123 Mon Sep 17 00:00:00 2001
>> From: Giulio Camuffo
>> Date: Sat, 17 Oct 2015 17:36:08 +0300
>> Subject: [PATCH] input: use doubles in the interfaces to notify of input
>> events
>>
>> This patch is a further step in the wl_fixed_t internal sanitization.
>> It changes the notify_* functions to take doubles instead of wl_fixed_t
>> but does not change how these are stored in the various input structs
>> yet. However this already allows to remove all wl_fixed_t usage in places
>> like the libinput or the x11 backend.
>> ---
>> src/compositor-rdp.c | 13 -
>> src/compositor-wayland.c | 20 ++--
>> src/compositor-x11.c | 18 +-
>> src/compositor.c | 12 ++--
>> src/compositor.h | 14 +++---
>> src/input.c | 24
>> src/libinput-device.c| 33 +
>> src/screen-share.c | 5 +++--
>> tests/weston-test.c | 4 ++--
>> 9 files changed, 74 insertions(+), 69 deletions(-)
>>
>> diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
>> index 7272f41..8d186fa 100644
>> --- a/src/compositor-rdp.c
>> +++ b/src/compositor-rdp.c
>> @@ -70,7 +70,7 @@
>> #include "pixman-renderer.h"
>>
>> #define MAX_FREERDP_FDS 32
>> -#define DEFAULT_AXIS_STEP_DISTANCE wl_fixed_from_int(10)
>> +#define DEFAULT_AXIS_STEP_DISTANCE 10
>> #define RDP_MODE_FREQ 60 * 1000
>>
>> struct rdp_backend_config {
>> @@ -943,7 +943,7 @@ static BOOL xf_peer_post_connect(freerdp_peer *client)
>> static FREERDP_CB_RET_TYPE
>> xf_mouseEvent(rdpInput *input, UINT16 flags, UINT16 x, UINT16 y)
>> {
>> - wl_fixed_t wl_x, wl_y, axis;
>> + double axis;
>> RdpPeerContext *peerContext = (RdpPeerContext *)input->context;
>> struct rdp_output *output;
>> uint32_t button = 0;
>> @@ -951,10 +951,8 @@ xf_mouseEvent(rdpInput *input, UINT16 flags, UINT16 x,
>> UINT16 y)
>> if (flags & PTR_FLAGS_MOVE) {
>> output = peerContext->rdpBackend->output;
>> if (x < output->base.width && y < output->base.height) {
>> - wl_x = wl_fixed_from_int((int)x);
>> - wl_y = wl_fixed_from_int((int)y);
>> notify_motion_absolute(&peerContext->item.seat,
>> weston_compositor_get_time(),
>> - wl_x, wl_y);
>> + x, y);
>> }
>> }
>>
>> @@ -993,16 +991,13 @@ xf_mouseEvent(rdpInput *input, UINT16 flags, UINT16 x,
>> UINT16 y)
>> static FREERDP_CB_RET_TYPE
>> xf_extendedMouseEvent(rdpInput *input, UINT16 flags, UINT16 x, UINT16 y)
>> {
>> - wl_fixed_t wl_x, wl_y;
>> RdpPeerContext *peerContext = (RdpPeerContext *)input->context;
>> struct rdp_output *output;
>>
>> output = peerContext->rdpBackend->output;
>> if (x < output->base.width && y < output->base.height) {
>> - wl_x = wl_fixed_from_int((int)x);
>> - wl_y = wl_fixed_from_int((int)y);
>> notify_motion_absolute(&peerContext->item.seat,
>> weston_compositor_get_time(),
>> - wl_x, wl_y);
>> + x, y);
>> }
>>
>> FREERDP_CB_RETURN(TRUE);
>> diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
>> index 7b11ae4..8f039a9 100644
>> --- a/src/compositor-wayland.c
>> +++ b/src/compositor-wayland.c
>> @@ -1273,6 +1273,7 @@ input_handle_pointer_enter(void *data, struct
>> wl_pointer *pointer,
>> struct wayland_input *input = data;
>> int32_t fx, fy;
>> enum theme_location location;
>> + double dx, dy;
>>
>> /* XXX: If we get a modifier event immediately before the focus,
>>* we should try to keep the same serial. */
>> @@ -1293,11 +1294,14 @@ input_handle_pointer_enter(void *data, struct
>> wl_pointer *pointer,
>> location = THEME_LOCATION_CLIENT_AREA;
>> }
>>
>> - weston_output_transform_coordinate(&input->output->base, x, y, &x, &y);
>> + dx = wl_fixed_to_double(x);
>> + dy = wl_fixed_to_double(y);
>> + weston_output_transform_coordinate(&input->output->base,
>> +dx, dy, &dx, &dy);
>
> dx/dy (d-prefixed x/y) usually mean deltas, but here they are absolute
> numbers, which is quite confusing. I'd rather not use dx/dy for absolute
> numbers. Same here and for all the other non-delta dx/dy's.
>
>>
>> if (location == THEME_LOCATION_CLIENT_AREA) {
>> in
Re: [PATCH weston] input: use doubles in the interfaces to notify of input events
2015-10-19 4:49 GMT+03:00 Jonas Ådahl : > BTW, are you planning on changing the grab interface vfuncs as well? In > the relative pointer branch I made the motion vfunc take a motion event > struct, should we do this for all types of events or just where it seems > needed? Yes, i'm planning to change them too. About the struct, i'm not sure... one advantage would be that we can add future fields in the structs without breaking the API, but i don't really have a strong opinion. Thanks, Giulio > > > Jonas > >> >> notify_pointer_position(test, resource); >> } >> -- >> 2.6.1 >> > >> ___ >> 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
