Re: Unstable protocol name breakage
On Tue, Oct 20, 2015 at 10:22:45AM +0800, 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. With Wayland just now starting to be end-user usable, it seems imprudent to risk changes that may lead to breakage or developer frustration, even when the changes may make things better down the road for future Wayland users. However, for protocols that we don't really want exposed to end-users, or that we don't want to be locked down to maintain as stable interfaces, breaking things *now* while adoption is still in flux, is probably better than breaking things later. Plus it might flush out functionality that really should be added to more core protocols. I agree with what others have already said - deprecate protocols that are mostly just clutter now, rename what we intend to continue experimenting with, and things we're worried my have legitimate life in the wild we should leave them named as is but put a priority on getting them officially stabilized. > 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). +1 to renaming scalar.xml and input-method.xml > 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? Looks like it hasn't received changes of significance for a few years. And it's the sort of thing that if people are using it outside Weston we *really* ought to know, so we can maintain it properly. +1 to renaming this one with a vengence. Looks like only editor uses it in weston so shouldn't be too hard to do. > 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. For this renaming effort, maybe skip this one. Probably better to handle as a special case, separately. > 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? I thing these belong to kind of a separate category. I would suggest skipping them as well. If it makes sense to rename for conformance then the IVI team should probably make that determination and undertake the change on their own discretion. > 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. Perhaps protocols that are purely weston-internal should follow suit with weston-test.xml and adopt weston- as the prefix, so as to avoid any future ambiguity? Does this just include screenshooter.xml and desktop-shell.xml? Which are toy protocols? I'd almost prefer to drop these, just to el
Re: [PATCH weston v3] data-device: Implement DnD actions
On Fri, 2015-10-30 at 22:06 +0100, Carlos Garnacho wrote:
> --- a/clients/dnd.c
> +++ b/clients/dnd.c
> @@ -72,6 +72,7 @@ struct dnd_drag {
> struct item *item;
> int x_offset, y_offset;
> int width, height;
> + uint32_t dnd_action;
> const char *mime_type;
>
> struct wl_surface *drag_surface;
> @@ -360,12 +361,21 @@ data_source_drag_finished(void *data, struct
> wl_data_source *source)
> destroy_dnd_drag(dnd_drag);
> }
>
> +static void
> +data_source_action(void *data, struct wl_data_source *source,
> uint32_t dnd_action)
> +{
> + struct dnd_drag *dnd_drag = data;
> +
> + dnd_drag->dnd_action = dnd_action;
> +}
> +
> static const struct wl_data_source_listener data_source_listener = {
> data_source_target,
> data_source_send,
> data_source_cancelled,
> data_source_drop_performed,
> data_source_drag_finished,
> + data_source_action,
> };
>
> static cairo_surface_t *
> @@ -461,6 +471,8 @@ create_drag_source(struct dnd *dnd,
> window_get_wl_surface(dnd
> ->window),
> dnd_drag->drag_surface,
> serial);
> + wl_data_source_set_actions(dnd_drag->data_source,
> +
> WL_DATA_DEVICE_MANAGER_DND_ACTION_MOVE);
>
> dnd_drag->opaque =
> create_drag_icon(dnd_drag, item, x, y, 1);
> diff --git a/clients/window.c b/clients/window.c
> index 24aa517..146d4a7 100644
> --- a/clients/window.c
> +++ b/clients/window.c
> @@ -3362,6 +3362,8 @@ struct data_offer {
> int fd;
> data_func_t func;
> int32_t x, y;
> + uint32_t dnd_action;
> + uint32_t source_actions;
> void *user_data;
> };
>
> @@ -3375,8 +3377,26 @@ data_offer_offer(void *data, struct
> wl_data_offer *wl_data_offer, const char *ty
> *p = strdup(type);
> }
>
> +static void
> +data_offer_source_actions(void *data, struct wl_data_offer
> *wl_data_offer, uint32_t source_actions)
> +{
> + struct data_offer *offer = data;
> +
> + offer->source_actions = source_actions;
> +}
> +
> +static void
> +data_offer_action(void *data, struct wl_data_offer *wl_data_offer,
> uint32_t dnd_action)
> +{
> + struct data_offer *offer = data;
> +
> + offer->dnd_action = dnd_action;
> +}
> +
> static const struct wl_data_offer_listener data_offer_listener = {
> data_offer_offer,
> + data_offer_source_actions,
> + data_offer_action
> };
>
> static void
> @@ -3440,6 +3460,11 @@ data_device_enter(void *data, struct
> wl_data_device *data_device,
> *p = NULL;
>
> types_data = input->drag_offer->types.data;
> + wl_data_offer_set_actions(offer,
> +
> WL_DATA_DEVICE_MANAGER_DND_ACTION_COPY |
> +
> WL_DATA_DEVICE_MANAGER_DND_ACTION_MOVE,
> +
> WL_DATA_DEVICE_MANAGER_DND_ACTION_COPY);
> +
> } else {
> input->drag_offer = NULL;
> types_data = NULL;
Is it normal to add unused variables in the example clients
(dnd_drag.source_action, data_offer.dnd_action,
data_offer.source_actions)? I guess there is some value in terms of
serving as an example -- is that why you've done this? -- but it seems
a bit silly to me; I would have left the implementations of those
functions empty.
Reviewed-by: Michael Catanzaro
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v5 wayland] protocol: add wl_pointer.frame, axis_source, axis_stop, and axis_discrete
On Wed, Oct 28, 2015 at 03:34:31PM +1000, Peter Hutterer wrote: > The frame event groups separate pointer events together. The primary use-case > for this at the moment is diagonal scrolling - a vertical/horizontal scroll > event can be grouped together to calculate the correct motion vector. If I understand correctly, this is an optimization for non-orthogonal cursor movement? Or is there some specialized hardware or usage pattern that needs this functionality specifically? > Frame events group all wl_pointer events. An example sequence of motion events > followed by a diagonal scroll followed by a button event is: > wl_pointer.motion > wl_pointer.frame > wl_pointer.motion > wl_pointer.frame > wl_pointer.axis > wl_pointer.axis > wl_pointer.frame > wl_pointer.button > wl_pointer.frame > > In the future, other extensions may insert additional information about an > event into the frame. For example, an extension may add information about the > physical device that generated an event into the frame. For this reason, > enter/leave events are grouped by a frame event too. > > The axis_source event determines how an axis event was generated. That enables > clients to judge when to use kinetic scrolling. Only one axis_source event is > allowed per frame and applies to all events in this frame. > > The axis_stop event notifies a client about the termination of a scroll > sequence, likewise needed to calculate kinetic scrolling parameters. > Multiple axis_stop events within the same frame indicate that scrolling has > stopped in all these axis at the same time. > > The axis_discrete event provides the wheel click count. Previously the axis > value was some hardcoded number (10), with the discrete steps this enables a > client to differ between line-based scrolling on a mouse wheel and smooth > scrolling with a touchpad. > > We can't extend the existing wl_pointer.axis events so we introduce a new > concept: latching events. Could you briefly explain why that can't be extended? > These events (currently only axis_discrete) > are prefixed before a wl_pointer.axis event. A client must build the full > state of the event until the respective top-level event arrives. > i.e. a single event frame for a diagonal scroll with discrete information may > be: > > wl_pointer.axis_source > wl_pointer.axis_discrete > wl_pointer.axis > wl_pointer.axis_discrete > wl_pointer.axis > wl_pointer.frame > > Signed-off-by: Peter Hutterer Is this a new concept unique to Wayland, or has this design been employed before in X11 or other window systems? (Sorry, my depth in input tech is pretty shallow.) If there is prior art, it might be worth a h/t. A few minor copyedits below. > --- > Changes to v4: > - axis argument added to axis_discrete. While technically redundant since > the axis event carries this information, the lack of this argument leads > to awkward client-side implementation. A single uint32_t value with no > other information attached had to be stacked in a temporary variable, only > the next event can then tell us whether the event was x or y scroll. > Providing the axis in the discrete event means we can immediately stack > this into the right variable. > - the big change is the rename from axis_frame to wl_pointer.frame. > the axis_frame concept was solid but working on other things Carlos and I > discovered that we may need to add additional information to some events. > A generic wl_pointer.frame event gives us the same benefit of the > axis_frame but allows to insert events (even from other extensions) > into a specific frame and augment that event. > > The commit message and comments have been updated accordingly, the logic > for axis events is effectively the same, but all other wl_pointer events > are now too grouped by frame events. > > This includes enter/leave too, even though they are compositor-generated > events. > > protocol/wayland.xml | 127 > +-- > 1 file changed, 124 insertions(+), 3 deletions(-) > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > index 59819e9..12e55cc 100644 > --- a/protocol/wayland.xml > +++ b/protocol/wayland.xml > @@ -1411,7 +1411,7 @@ > > > > - > + > >The wl_pointer interface represents one or more input devices, >such as mice, which control the pointer location and pointer_focus > @@ -1578,9 +1578,130 @@ > > > > + > + > + > + Indicates the end of a set of events that logically belong together. > + A client is expected to accumulate the data in all events events typo: Redundant 'events' > + within the frame before proceeding. > + > + All wl_pointer events before a wl_pointer.frame event belong > + logically together. For example, in a diagonal scroll motion the > + compositor will send an optional wl_pointer.axis_source event, two > + wl_pointer.axis events (horizontal and vertical
Re: [PATCH v4] protocol: Add DnD actions
On Fri, 2015-10-30 at 21:57 +0100, Carlos Garnacho wrote: > + This request mandates the final result of the drag-and-drop > + operation. If the end result is that no action is accepted, > + the drag source will receive drag_source.cancelled. Same nit here about "mandates." Reviewed-by: Michael Catanzaro ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v2] protocol: Improve data source notification around DnD progress
On Fri, 2015-10-30 at 21:55 +0100, Carlos Garnacho wrote: > Changes since v1: > - Renamed events to have a common "dnd" namespace. I don't think this was a great change. The event occurs on drop, and the previous name described that perfectly, whereas with the new name it's not very clear how it's different from dnd_finished. Maybe dnd_drop_performed would be better, if slightly redundant. > @@ -423,7 +423,9 @@ > Indicate that the client can accept the given mime type, or > NULL for not accepted. > > - Used for feedback during drag-and-drop. > + This request mandates the final result of the drag-and-drop > + operation. If the end result is that no mimetype is > accepted, > + the drag source will receive drag_source.cancelled. > > > Nit: "mandates" is not a great choice of word here... how about "determines" instead? Reviewed-by: Michael Catanzaro ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston v2] data-device: Implement DnD progress notification
This fixes the issues I pointed out before. Reviewed-by: Michael Catanzaro ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v4] protocol: Add DnD actions
On Fri, Oct 30, 2015 at 1:57 PM, Carlos Garnacho wrote: > > + > + > +This is a bitmask of the available/preferred actions in a > +drag-and-drop operation. > + > +The current reserved ranges are: > + > +0x - 0x00FF: Reserved for the wayland core protocol. > +0x01FF - 0x: Reserved for future toolkit-specific use. Slots > + may be reserved. > Since this is a bitmap, the above is a little confusing. 0x101 is not toolkit-specific, it is a combination of a toolkit-specific action and a core action. Perhaps this: 0x0001 - 0x0080: wayland core protocol actions 0x0100 - 0x8000: toolkit-specific use In general I don't think this really has to be documented, it sounds just like any other experimental addition to the protocol. Maybe make a comment that clients should ignore bits they don't recognize. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland] doc: generate doxygen html output from the scanner
On Thu, Oct 29, 2015 at 11:48:01AM +1000, Peter Hutterer wrote: > This switches the scanner to generate doxygen-compatible tags for the > generated protocol headers, and hooks up the doxygen build to generate server > and client-side API documentation. > > For the wayland protocol, this generates a mainpage with the copyright > information, all interfaces are separated by doxygen groups and thus listed in > "Modules" in the generated output. > > Function, struct and #defines are documented in doxygen style and associated > with the matching interface. > --- > This is an RFC for now, we need to agree on whether we want to switch to > doxygen style first. Other changes still missing here are: > * afaict, the summary can be dropped for most entries, it doesn't seem > to add any value if a long description is there > * currently parsing too many header files, we should only parse the protocol > ones for a cleaner documentation. > * future work for wayland-protocols is to add the various protocols at the > @page level > * a couple of things don't have the doxygen tag yet (mostly #defines) It would probably help to see what the doxygen output is going to look like. Some codebases produce nice looking reference pages, others seem to generate doxygen that's merely marginally different than browsing the raw source. Does this impact the existing docbook API docs (the appendix sections)? I think if we went this route, rather than getting rid of Docbook entirely as I think Bill may be suggesting, it might be better to use it strictly for the prose portion of the documentation (i.e. remove the appendixes). So we'd still have to have both Docbook and Doxygen, but each would be used more for what they were designed for. This would still allow us to eliminate a lot of conversion code, which I suspect is what Bill finds most advantageous with this change. However, I'm also cognizant that while this may be an overall improvement that may reduce frustration and confusion for future wayland users, our current userbase may be accustomed to the API docs as they are. E.g. they may have bookmarks and memories about where to look for details they need. A sudden change might be jarring for them, especially right now as Wayland is becoming end-user accessible on various desktops, and bindings authors and client developers are starting to ramp up. But if the transition can be done smoothly, this shouldn't be a roadblock. So... if this can be done to provide both the existing style docs as well as generate a new doxygen site, then count me in as +1 for this change. Bryce ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] dmabuf: get supported dmabuf formats from compositor backend
On Fri, Oct 30, 2015 at 09:49:20AM +0200, Giulio Camuffo wrote:
> 2015-10-30 2:27 GMT+02:00 Bryce Harrington :
> > On Tue, Oct 20, 2015 at 08:45:50AM -0700, Bryce Harrington wrote:
> >> On Tue, Oct 20, 2015 at 04:54:30PM +0200, Fabien Dessenne wrote:
> >> > Add the possibility for the compositor backend to provide with the list
> >> > of supported pixel formats for dmabuf-based buffers.
> >> > This information is used by linux_dmabuf to inform clients when binding.
> >> >
> >> > Signed-off-by: Fabien Dessenne
> >>
> >> Reviewed-by
> >>
> >> There's not a way to verify the list is getting sent across to the
> >> client is there?
>
> I'm not sure i understand this question.
I just mean, how would one verify the function is working correctly and
returning the expected set of results.
But given daniels' NAK, sounds like he wants to see this done
differently anyway.
Bryce
> > Also, patch no longer applies since e3c0d8af.
> >
> > I'd like to better understand what this is going to be used for, before
> > landing it. Another R-b on this would be nice as well; Giulio perhaps
> > you could give this patch a review?
>
> Well, it doesn't apply because we now have a new vfunc in
> weston_backend, but rebasing it should be trivial.
>
> >
> > Bryce
> >
> >> Bryce
> >>
> >> > ---
> >> > src/compositor.h | 2 ++
> >> > src/linux-dmabuf.c | 16 +---
> >> > 2 files changed, 15 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/src/compositor.h b/src/compositor.h
> >> > index 2e2a185..f58e0cc 100644
> >> > --- a/src/compositor.h
> >> > +++ b/src/compositor.h
> >> > @@ -613,6 +613,8 @@ enum weston_capability {
> >> > struct weston_backend {
> >> > void (*destroy)(struct weston_compositor *ec);
> >> > void (*restore)(struct weston_compositor *ec);
> >> > + void (*get_dmabuf_formats)(struct weston_compositor *ec,
> >> > + struct wl_array *formats);
> >> > };
> >> >
> >> > struct weston_compositor {
> >> > diff --git a/src/linux-dmabuf.c b/src/linux-dmabuf.c
> >> > index 90c9757..ee02ea4 100644
> >> > --- a/src/linux-dmabuf.c
> >> > +++ b/src/linux-dmabuf.c
> >> > @@ -433,9 +433,19 @@ bind_linux_dmabuf(struct wl_client *client,
> >> > wl_resource_set_implementation(resource,
> >> > &linux_dmabuf_implementation,
> >> >compositor, NULL);
> >> >
> >> > - /* EGL_EXT_image_dma_buf_import does not provide a way to query the
> >> > -* supported pixel formats. */
> >> > - /* XXX: send formats */
> >> > + if (compositor->backend->get_dmabuf_formats) {
>
> Can the formats change in the compositor lifetime? If not, it may be
> better to ask for them once and store the result instead of asking for
> each new client.
>
> >> > + struct wl_array dmabuf_formats;
> >> > + uint32_t *p;
> >> > +
> >> > + wl_array_init(&dmabuf_formats);
> >> > +
> >> > + compositor->backend->get_dmabuf_formats(compositor,
> >> > + &dmabuf_formats);
> >> > + wl_array_for_each(p, &dmabuf_formats)
> >> > + zlinux_dmabuf_send_format(resource, *p);
> >> > +
> >> > + wl_array_release(&dmabuf_formats);
> >> > + }
> >> > }
> >> >
> >> > /** Advertise linux_dmabuf support
> >> > --
> >> > 1.9.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
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v5 wayland] protocol: add wl_pointer.frame, axis_source, axis_stop, and axis_discrete
On Wed, Oct 28, 2015 at 6:34 AM, Peter Hutterer wrote: > The frame event groups separate pointer events together. The primary use-case > for this at the moment is diagonal scrolling - a vertical/horizontal scroll > event can be grouped together to calculate the correct motion vector. > Frame events group all wl_pointer events. An example sequence of motion events > followed by a diagonal scroll followed by a button event is: > wl_pointer.motion > wl_pointer.frame > wl_pointer.motion > wl_pointer.frame > wl_pointer.axis > wl_pointer.axis > wl_pointer.frame > wl_pointer.button > wl_pointer.frame > > In the future, other extensions may insert additional information about an > event into the frame. For example, an extension may add information about the > physical device that generated an event into the frame. For this reason, > enter/leave events are grouped by a frame event too. > > The axis_source event determines how an axis event was generated. That enables > clients to judge when to use kinetic scrolling. Only one axis_source event is > allowed per frame and applies to all events in this frame. > > The axis_stop event notifies a client about the termination of a scroll > sequence, likewise needed to calculate kinetic scrolling parameters. > Multiple axis_stop events within the same frame indicate that scrolling has > stopped in all these axis at the same time. > > The axis_discrete event provides the wheel click count. Previously the axis > value was some hardcoded number (10), with the discrete steps this enables a > client to differ between line-based scrolling on a mouse wheel and smooth > scrolling with a touchpad. > > We can't extend the existing wl_pointer.axis events so we introduce a new > concept: latching events. These events (currently only axis_discrete) > are prefixed before a wl_pointer.axis event. A client must build the full > state of the event until the respective top-level event arrives. > i.e. a single event frame for a diagonal scroll with discrete information may > be: > > wl_pointer.axis_source > wl_pointer.axis_discrete > wl_pointer.axis > wl_pointer.axis_discrete > wl_pointer.axis > wl_pointer.frame > > Signed-off-by: Peter Hutterer FWIW, with mutter/gtk+ implementations at hand: Reviewed-by: Carlos Garnacho ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston v3] data-device: Implement DnD actions
The policy in weston in order to determine the chosen DnD action is
deliberately simple, and is probably the minimals that any compositor
should be doing here.
Besides honoring the set_actions requests on both wl_data_source and
wl_data_offer, weston now will emit the newly added "action" events
notifying both source and dest of the chosen action.
The "dnd" client has been updated too (although minimally), so it
notifies the compositor of a "move" action on both sides.
Changes since v2:
- Split from DnD progress notification changes.
Changes since v1:
- Updated to v2 of DnD actions protocol changes, implement
wl_data_offer.source_actions.
- Fixed coding style issues.
Signed-off-by: Carlos Garnacho
---
clients/dnd.c | 12 +
clients/window.c | 25 +++
src/compositor.h | 4 +++
src/data-device.c | 75 ---
4 files changed, 113 insertions(+), 3 deletions(-)
diff --git a/clients/dnd.c b/clients/dnd.c
index 6c2ed57..75a14f1 100644
--- a/clients/dnd.c
+++ b/clients/dnd.c
@@ -72,6 +72,7 @@ struct dnd_drag {
struct item *item;
int x_offset, y_offset;
int width, height;
+ uint32_t dnd_action;
const char *mime_type;
struct wl_surface *drag_surface;
@@ -360,12 +361,21 @@ data_source_drag_finished(void *data, struct
wl_data_source *source)
destroy_dnd_drag(dnd_drag);
}
+static void
+data_source_action(void *data, struct wl_data_source *source, uint32_t
dnd_action)
+{
+ struct dnd_drag *dnd_drag = data;
+
+ dnd_drag->dnd_action = dnd_action;
+}
+
static const struct wl_data_source_listener data_source_listener = {
data_source_target,
data_source_send,
data_source_cancelled,
data_source_drop_performed,
data_source_drag_finished,
+ data_source_action,
};
static cairo_surface_t *
@@ -461,6 +471,8 @@ create_drag_source(struct dnd *dnd,
window_get_wl_surface(dnd->window),
dnd_drag->drag_surface,
serial);
+ wl_data_source_set_actions(dnd_drag->data_source,
+
WL_DATA_DEVICE_MANAGER_DND_ACTION_MOVE);
dnd_drag->opaque =
create_drag_icon(dnd_drag, item, x, y, 1);
diff --git a/clients/window.c b/clients/window.c
index 24aa517..146d4a7 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -3362,6 +3362,8 @@ struct data_offer {
int fd;
data_func_t func;
int32_t x, y;
+ uint32_t dnd_action;
+ uint32_t source_actions;
void *user_data;
};
@@ -3375,8 +3377,26 @@ data_offer_offer(void *data, struct wl_data_offer
*wl_data_offer, const char *ty
*p = strdup(type);
}
+static void
+data_offer_source_actions(void *data, struct wl_data_offer *wl_data_offer,
uint32_t source_actions)
+{
+ struct data_offer *offer = data;
+
+ offer->source_actions = source_actions;
+}
+
+static void
+data_offer_action(void *data, struct wl_data_offer *wl_data_offer, uint32_t
dnd_action)
+{
+ struct data_offer *offer = data;
+
+ offer->dnd_action = dnd_action;
+}
+
static const struct wl_data_offer_listener data_offer_listener = {
data_offer_offer,
+ data_offer_source_actions,
+ data_offer_action
};
static void
@@ -3440,6 +3460,11 @@ data_device_enter(void *data, struct wl_data_device
*data_device,
*p = NULL;
types_data = input->drag_offer->types.data;
+ wl_data_offer_set_actions(offer,
+
WL_DATA_DEVICE_MANAGER_DND_ACTION_COPY |
+
WL_DATA_DEVICE_MANAGER_DND_ACTION_MOVE,
+
WL_DATA_DEVICE_MANAGER_DND_ACTION_COPY);
+
} else {
input->drag_offer = NULL;
types_data = NULL;
diff --git a/src/compositor.h b/src/compositor.h
index 18266ef..b1c3305 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -298,6 +298,8 @@ struct weston_data_offer {
struct wl_resource *resource;
struct weston_data_source *source;
struct wl_listener source_destroy_listener;
+ uint32_t dnd_actions;
+ uint32_t preferred_dnd_action;
};
struct weston_data_source {
@@ -306,6 +308,8 @@ struct weston_data_source {
struct wl_array mime_types;
struct weston_data_offer *offer;
int accepted;
+ uint32_t dnd_actions;
+ uint32_t current_dnd_action;
void (*accept)(struct weston_data_source *source,
uint32_t serial, const char *mime_type);
diff --git a/src/data-device.c b/src/data-device.c
index 4be392d..e81e8b2 100644
--- a/src/data-device.c
+++ b/src/data-device.c
@@ -94,10 +94,56 @@ data_offer_destroy(struct wl_client *client, struct
wl_res
[PATCH weston v2] data-device: Implement DnD progress notification
Weston now sends wl_data_source.drop_performed and .drag_finished in
order to notify about the different phases of DnD.
wl_data_source.cancelled is also used as mentioned in the docs, being
emitted also on DnD when the operation is meant to fail (eg. source
and dest didn't agree on a mimetype).
The dnd demo is also fixed so the struct dnd_drag isn't leaked.
https://bugs.freedesktop.org/show_bug.cgi?id=91943
https://bugs.freedesktop.org/show_bug.cgi?id=91944
Changes since v1:
- Updated to protocol v2.
Signed-off-by: Carlos Garnacho
---
clients/dnd.c | 39 +++
clients/window.c | 2 +-
src/compositor.h | 2 ++
src/data-device.c | 37 +++--
4 files changed, 65 insertions(+), 15 deletions(-)
diff --git a/clients/dnd.c b/clients/dnd.c
index e6a0c39..6c2ed57 100644
--- a/clients/dnd.c
+++ b/clients/dnd.c
@@ -318,14 +318,8 @@ data_source_send(void *data, struct wl_data_source *source,
}
static void
-data_source_cancelled(void *data, struct wl_data_source *source)
+destroy_dnd_drag(struct dnd_drag *dnd_drag)
{
- struct dnd_drag *dnd_drag = data;
-
- /* The 'cancelled' event means that the source is no longer in
-* use by the drag (or current selection). We need to clean
-* up the drag object created and the local state. */
-
wl_data_source_destroy(dnd_drag->data_source);
/* Destroy the item that has been dragged out */
@@ -339,10 +333,39 @@ data_source_cancelled(void *data, struct wl_data_source
*source)
free(dnd_drag);
}
+static void
+data_source_cancelled(void *data, struct wl_data_source *source)
+{
+ struct dnd_drag *dnd_drag = data;
+
+ /* The 'cancelled' event means that the source is no longer in
+* use by the drag (or current selection). We need to clean
+* up the drag object created and the local state. */
+destroy_dnd_drag(dnd_drag);
+}
+
+static void
+data_source_drop_performed(void *data, struct wl_data_source *source)
+{
+}
+
+static void
+data_source_drag_finished(void *data, struct wl_data_source *source)
+{
+ struct dnd_drag *dnd_drag = data;
+
+/* The operation is already finished, we can destroy all
+ * related data.
+ */
+ destroy_dnd_drag(dnd_drag);
+}
+
static const struct wl_data_source_listener data_source_listener = {
data_source_target,
data_source_send,
- data_source_cancelled
+ data_source_cancelled,
+ data_source_drop_performed,
+ data_source_drag_finished,
};
static cairo_surface_t *
diff --git a/clients/window.c b/clients/window.c
index 47628de..24aa517 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -5376,7 +5376,7 @@ registry_handle_global(void *data, struct wl_registry
*registry, uint32_t id,
d->shm = wl_registry_bind(registry, id, &wl_shm_interface, 1);
wl_shm_add_listener(d->shm, &shm_listener, d);
} else if (strcmp(interface, "wl_data_device_manager") == 0) {
- d->data_device_manager_version = MIN(version, 2);
+ d->data_device_manager_version = MIN(version, 3);
d->data_device_manager =
wl_registry_bind(registry, id,
&wl_data_device_manager_interface,
diff --git a/src/compositor.h b/src/compositor.h
index 4443c72..18266ef 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -304,6 +304,8 @@ struct weston_data_source {
struct wl_resource *resource;
struct wl_signal destroy_signal;
struct wl_array mime_types;
+ struct weston_data_offer *offer;
+ int accepted;
void (*accept)(struct weston_data_source *source,
uint32_t serial, const char *mime_type);
diff --git a/src/data-device.c b/src/data-device.c
index 1612091..4be392d 100644
--- a/src/data-device.c
+++ b/src/data-device.c
@@ -62,12 +62,18 @@ data_offer_accept(struct wl_client *client, struct
wl_resource *resource,
{
struct weston_data_offer *offer = wl_resource_get_user_data(resource);
+ /* Protect against untimely calls from older data offers */
+ if (!offer->source || offer != offer->source->offer)
+ return;
+
/* FIXME: Check that client is currently focused by the input
* device that is currently dragging this data source. Should
* this be a wl_data_device request? */
- if (offer->source)
+ if (offer->source) {
offer->source->accept(offer->source, serial, mime_type);
+ offer->source->accepted = mime_type != NULL;
+ }
}
static void
@@ -76,7 +82,7 @@ data_offer_receive(struct wl_client *client, struct
wl_resource *resource,
{
struct weston_data_offer *offer = wl_resource_get_user_data(resource);
- if (offer->source)
+ if (offer->source && offer == offer->source->offer)
offer->source->
[PATCH v4] protocol: Add DnD actions
These 2 requests have been added: - wl_data_source.set_actions: Notifies the compositor of the available actions on the data source. - wl_data_offer.set_actions: Notifies the compositor of the available actions on the destination side, plus the preferred action. Out of the data from these requests, the compositor can determine the action both parts agree on (and let the user play a role through eg. keyboard modifiers). The chosen option will be notified to both parties through the following two requests: - wl_data_source.action - wl_data_offer.action In addition, the destination side can peek the source side actions through wl_data_offer.source_actions. Compared to the XDND protocol, there's two notable changes: - XDND lets the source suggest an action, whereas wl_data_device lets the destination prefer a given action. The difference is subtle here, it comes off as convenience because it is the drag destination which receives the motion events (unlike in X) and can perform action updates. The drag destination seems also in a better position to update the preferred action based on things like the data being transferred, the place being dropped, and whether the drag is client-local. - That same source-side preferred action is used in XDND to convey the modifier-induced action to the drag destination, which would then ack it, or reply with another action that's accepted (or none), this makes the XdndPosition/XdndStatus messaging very verbose, and synchronous because the drag source always needs to know the latest status/action for every position+action sent. Here it's the compositor which takes care of modifiers and matching available/accepted actions, this allows for the signaling to happen only whenever the actions/modifiers change for real. Roughly based on previous work by Giulio Camuffo Changes since v3: - Splitted from DnD progress notification changes. - Further rationales in commit log. Changes since v2: - Renamed notify_actions to set_actions on both sides, seems more consistent with the rest of the protocol. - Spelled out better which events may be triggered on the compositor side by the requests, the circumstances in which events are emitted, and what are events useful for in clients. - Defined a minimal common ground wrt compositor-side action picking and keybindings. - Acknowledge the possibility of compositor/toolkit defined actions, even though none are used at the moment. Changes since v1: - Added wl_data_offer.source_actions to let know of the actions offered by a data source. - Renamed wl_data_source.finished to "drag_finished" for clarity - Improved wording as suggested by Bryce Signed-off-by: Carlos Garnacho --- protocol/wayland.xml | 129 +++ 1 file changed, 129 insertions(+) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 477ef55..80e1140 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -463,6 +463,56 @@ + + + + + + This event indicates the actions offered by the data source. It + will be sent right after data_device.enter, or anytime the source + side changes its offered actions through data_source.set_actions. + + + + + + + This event indicates the action selected by the compositor after + matching the source/destination side actions. Only one action (or + none) will be offered here. + + This event can be emitted multiple times during the drag-and-drop + operation, mainly in response to source side changes (through + data_source.set_actions), destination side changes (through + data_offer.set_actions), and as pointer enters/leaves surfaces. + + Compositors may also change the selected action on the fly, mainly + in response to keyboard modifier changes during the drag-and-drop + operation. + + The most recent action received is always the valid one. + + + + + + + Sets the actions that the destination side client supports for + this operation. This request may trigger the emission of + data_source.action and data_offer.action events if the compositor + needs changing the selected action. + + This request can be called multiple times throughout the + drag-and-drop operation, typically in response to data_device.enter + or data_device.motion events. + + This request mandates the final result of the drag-and-drop + operation. If the end result is that no action is accepted, + the drag source will receive drag_source.cancelled. + + + + @@ -519,6 +569,9 @@ - The drag-and-drop operation was performed, but the drop destination did not accept any of the mimetypes offered through data_source.target. + - The drag-and-drop operation was performed, but the drop destination
[PATCH v2] protocol: Improve data source notification around DnD progress
Currently, there's no means for the DnD origin to know whether the destination is actually finished with the DnD transaction, short of finalizing it after the first transfer finishes, or leaking it forever. But this poses other interoperation problems, drag destinations might be requesting several mimetypes at once, might be just poking to find out the most suitable format, might want to defer the action to a popup, might be poking contents early before the selection was dropped... In addition, data_source.cancelled is suitable for the situations where the DnD operation fails (not on a drop target, no matching mimetypes, etc..), but seems undocumented for that use (and unused in weston's DnD). In order to improve the situation, the drag source should be notified of all stages of DnD. In addition to documenting the "cancelled" event for DnD purposes, The following 2 events have been added: - wl_data_source.dnd_performed: Happens when the operation has been physically finished (eg. the button is released), it could be the right place to reset the pointer cursor back and undo any other state resulting from the initial button press. - wl_data_source.dnd_finished: Happens when the destination side destroys the wl_data_offer, at this point the source can just forget all data related to the DnD selection as well, plus optionally deleting the data on move operations. Changes since v1: - Renamed events to have a common "dnd" namespace. Made dnd_performed to happen invariably, data_device.cancelled may still happen afterwards. Signed-off-by: Carlos Garnacho --- protocol/wayland.xml | 47 +-- 1 file changed, 41 insertions(+), 6 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 59819e9..477ef55 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -408,7 +408,7 @@ - + A wl_data_offer represents a piece of data offered for transfer by another client (the source client). It is used by the @@ -423,7 +423,9 @@ Indicate that the client can accept the given mime type, or NULL for not accepted. - Used for feedback during drag-and-drop. + This request mandates the final result of the drag-and-drop + operation. If the end result is that no mimetype is accepted, + the drag source will receive drag_source.cancelled. @@ -463,7 +465,7 @@ - + The wl_data_source object is the source side of a wl_data_offer. It is created by the source client in a data transfer and @@ -510,14 +512,47 @@ - This data source has been replaced by another data source. + This data source is no longer valid. There are several reasons why + this could happen: + + - The data source has been replaced by another data source. + - The drag-and-drop operation was performed, but the drop destination + did not accept any of the mimetypes offered through + data_source.target. + - The drag-and-drop operation was performed but didn't happen over a + surface. + - The compositor cancelled the drag-and-drop operation + The client should clean up and destroy this data source. + + + + + The user performed the drop action. This event does not indicate + acceptance, data_source.cancelled may still be emitted afterwards + if the drop destination does not accept any mimetype. + + This event might however not be received if the compositor cancelled + the drag-and-drop operation before this event could happen. + + Note that the data_source may still be used further in the future and + should not be destroyed here. + + + + + + The drop destination finished interoperating with this data + source, the client is now free to destroy this data source and + free all associated data. + + - + There is one wl_data_device per seat which can be obtained from the global wl_data_device_manager singleton. @@ -659,7 +694,7 @@ - + The wl_data_device_manager is a singleton global object that provides access to inter-client data transfer mechanisms such as -- 2.5.0 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] protocol: Improve data source notification around DnD progress
On Fri, Oct 30, 2015 at 5:51 AM, Jonas Ådahl wrote: > On Thu, Oct 29, 2015 at 05:51:04PM +0100, Carlos Garnacho wrote: >> Hey Jonas!, >> >> On Thu, Oct 29, 2015 at 9:37 AM, Jonas Ådahl wrote: >> > Hey Carlos, >> > >> > Finally had a look at this one. >> >> Cheers :) >> >> > >> > On Wed, Sep 30, 2015 at 10:45:39PM +0200, Carlos Garnacho wrote: >> >> Currently, there's no means for the DnD origin to know whether the >> >> destination is actually finished with the DnD transaction, short of >> >> finalizing it after the first transfer finishes, or leaking it forever. >> >> >> >> But this poses other interoperation problems, drag destinations might >> >> be requesting several mimetypes at once, might be just poking to find >> >> out the most suitable format, might want to defer the action to a popup, >> >> might be poking contents early before the selection was dropped... >> >> >> >> In addition, data_source.cancelled is suitable for the situations where >> >> the DnD operation fails (not on a drop target, no matching mimetypes, >> >> etc..), but seems undocumented for that use (and unused in weston's DnD). >> >> >> >> In order to improve the situation, the drag source should be notified >> >> of all stages of DnD. In addition to documenting the "cancelled" event >> >> for DnD purposes, The following 2 events have been added: >> >> >> >> - wl_data_source.drop_performed: Happens when the operation has been >> >> physically finished (eg. the button is released), it could be the right >> >> place to reset the pointer cursor back and undo any other state >> >> resulting >> >> from the initial button press. >> >> - wl_data_source.drag_finished: Happens when the destination side destroys >> >> the wl_data_offer, at this point the source can just forget all data >> >> related to the DnD selection as well, plus optionally deleting the data >> >> on move operations. >> >> >> >> Signed-off-by: Carlos Garnacho >> >> --- >> >> protocol/wayland.xml | 34 +- >> >> 1 file changed, 29 insertions(+), 5 deletions(-) >> >> >> >> diff --git a/protocol/wayland.xml b/protocol/wayland.xml >> >> index 42c9309..1ee143f 100644 >> >> --- a/protocol/wayland.xml >> >> +++ b/protocol/wayland.xml >> >> @@ -408,7 +408,7 @@ >> >> >> >> >> >> >> >> - >> >> + >> >> >> >>A wl_data_offer represents a piece of data offered for transfer >> >>by another client (the source client). It is used by the >> >> @@ -463,7 +463,7 @@ >> >> >> >> >> >> >> >> - >> >> + >> >> >> >>The wl_data_source object is the source side of a wl_data_offer. >> >>It is created by the source client in a data transfer and >> >> @@ -510,14 +510,38 @@ >> >> >> >> >> >> >> >> - This data source has been replaced by another data source. >> >> + This data source is no longer valid. There are several reasons why >> >> + this could happen: >> >> + >> >> + - The data source has been replaced by another data source. >> >> + - The drop operation finished, but the drop destination did not >> >> + accept any of the mimetypes offered through data_source.target. >> >> + - The drop operation finished but didn't happen over a DnD target. >> > >> > That the "operation finished" sounds like the transfer was done as well. >> > "The drop was performed" maybe is better? >> >> Right, plus the name matches with the event that you'd be expecting >> otherwise. >> >> > >> >> + >> >> The client should clean up and destroy this data source. >> >> >> >> >> >> >> >> + >> >> + >> >> + >> >> + >> >> + The user dropped this data onto an accepting destination. Note >> >> + that the data_source will be used further in the future and should >> >> + not be destroyed here. >> >> + >> >> + >> > >> > I too would like some clarifications why this is needed. The cursor and >> > button state, I assume, could be reset on the next enter or by >> > cancelled/finished, but that the client may want update its UI in some >> > way. >> >> Yeah, I think that's nice to have, the drag source might enter some >> special UI mode on DnD that has to be reverted after the operation is >> done. >> >> But this is admittedly non essential information on wayland clients >> done from the ground up. You might consider this similar to how window >> dragging is implemented, where you don't get anything after the button >> press, however there's a difference with DnD face to the traditional >> toolkits: window dragging was already WM territory, toolkits were >> already taught to give up on the implicit grab and let the WM take >> one, but DnD was purely application territory. >> >> In hindsight (I can just talk for GTK+ tbh) much of the DnD machinery >> should have been hidden at the lowest levels, reality is that DnD is >> driven from a quite high level, more namely the active pointer grab >> used, around which everything revolves
Re: [PATCH wayland] protocol: Improve data source notification around DnD progress
On Thu, Oct 29, 2015 at 9:51 PM, Jonas Ådahl wrote: > > > > I too would like some clarifications why this is needed. The cursor and > > > button state, I assume, could be reset on the next enter or by > > > cancelled/finished, but that the client may want update its UI in some > > > way. > > As long as there needs to be no UI/behavioural changes as a result of > ending this grab, ending it at the next 'enter' I guess would be just > fine, but as long as UI needs to react to the drop immediately, it seems > necessary. > I think everybody was confused by the mention of "restoring the cursor". That is *not* something the DnD source would do and it threw everybody off trying to comment on this. I think what is wanted is an indication that the drag really did finish. For instance a file browser acting as the source of a "move" action will want a confirmation that the move actually worked before it actually destroys the source file. This confirmation can happen long after the dnd action is negotiated and after all the data is transferred. Imagine if the destination suddenly encounters an error trying to write the file to the destination disk. It does seem like toolkits are purposely delaying messages that were designed to be sent asap in other DnD protocols in order to achieve this. I guess some kind of event sent to the source would work for this. There should probably be success and failure forms of the event, and maybe even a progress indicator (then you could do movie-style gui where the files gradually vanish as they are deleted). ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput 1/3] evdev: log a bug for missing pointer accel on relative events
Hi,
On 30-10-15 02:19, Peter Hutterer wrote:
And use the unaccelerated motion events. Better than crashing, and better than
a non-moving mouse.
Signed-off-by: Peter Hutterer
The entire set looks good to me and is:
Reviewed-by: Hans de Goede
Regards,
Hans
---
src/evdev.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/src/evdev.c b/src/evdev.c
index 45c1b1b..4c947d6 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -299,11 +299,18 @@ evdev_flush_pending_event(struct evdev_device *device,
uint64_t time)
if (evdev_post_trackpoint_scroll(device, unaccel, time))
break;
- /* Apply pointer acceleration. */
- accel = filter_dispatch(device->pointer.filter,
- &unaccel,
- device,
- time);
+ if (device->pointer.filter) {
+ /* Apply pointer acceleration. */
+ accel = filter_dispatch(device->pointer.filter,
+ &unaccel,
+ device,
+ time);
+ } else {
+ log_bug_libinput(libinput,
+"%s: accel filter missing\n",
+
udev_device_get_devnode(device->udev_device));
+ accel = unaccel;
+ }
if (normalized_is_zero(accel) && normalized_is_zero(unaccel))
break;
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston v3 3/3] Introduce wl_relative_pointer interface
On Fri, Oct 30, 2015 at 08:33:16AM +, Daniel Stone wrote: > Hi, > > On 30 October 2015 at 04:27, Jonas Ådahl wrote: > > On Fri, Oct 30, 2015 at 08:41:18AM +1000, Peter Hutterer wrote: > >> On Thu, Oct 29, 2015 at 09:33:14AM +, Daniel Stone wrote: > >> > Right, so I think we agree here. I'd prefer to keep the types matching > >> > as well; I do struggle to see how wl_fixed_t isn't sufficient, but on > >> > the other hand am not entirely sure I care enough about it, so am > >> > happy with whichever. Keeping it purely raw might in fact just be > >> > easier for everyone. > >> > >> fwiw, I still read this bug as an issue of timestamp granularity, not > >> motion > >> granularity. unless I'm missing this, I can't find anything that says the > >> deltas themselves are insufficient. > >> > >> and deltas are just that - device-specific deltas, and the raw motion isn't > >> accelerated or normalized, so even a 8200 dpi mouse will give you a delta > >> of > >> 1/1 for the minimal movement. > >> Even if we normalize those down to 1000dpi, the minimum delta is ca 1/8, > >> and > >> wl_fixed_t granularity is 1/256, right? > > > > That is true. Where we might have even smaller values would be if we > > normalize to 1000dpi and apply pointer deceleration, but then we still > > wouldn't end up with such small values because usually the smallest > > factor we decelerate with is 0.3, meaning we still wouldn't end up with > > that small deltas. We discussed this on IRC, and after your > > explanations, I think we could just as well just use wl_fixed_t. If > > there would be acceleration profiles that decelerate even more (for > > example 0.03 instead of 0.3 on a 8200dpi mouse normalized to 1000dpi), > > then since the resulting delta doesn't really represent a hardware event > > anyway, accumulating the leftover fraction isn't that big of a deal. > > Daniel, what do you think? > > Right, that makes sense to me. Though in the raw case, surely > deceleration won't be applied? Right. At least not in weston/libinput. What "unaccelerated" actually means is really up to the compositor. Jonas > > Cheers, > Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston v3 3/3] Introduce wl_relative_pointer interface
Hi, On 30 October 2015 at 04:27, Jonas Ådahl wrote: > On Fri, Oct 30, 2015 at 08:41:18AM +1000, Peter Hutterer wrote: >> On Thu, Oct 29, 2015 at 09:33:14AM +, Daniel Stone wrote: >> > Right, so I think we agree here. I'd prefer to keep the types matching >> > as well; I do struggle to see how wl_fixed_t isn't sufficient, but on >> > the other hand am not entirely sure I care enough about it, so am >> > happy with whichever. Keeping it purely raw might in fact just be >> > easier for everyone. >> >> fwiw, I still read this bug as an issue of timestamp granularity, not motion >> granularity. unless I'm missing this, I can't find anything that says the >> deltas themselves are insufficient. >> >> and deltas are just that - device-specific deltas, and the raw motion isn't >> accelerated or normalized, so even a 8200 dpi mouse will give you a delta of >> 1/1 for the minimal movement. >> Even if we normalize those down to 1000dpi, the minimum delta is ca 1/8, and >> wl_fixed_t granularity is 1/256, right? > > That is true. Where we might have even smaller values would be if we > normalize to 1000dpi and apply pointer deceleration, but then we still > wouldn't end up with such small values because usually the smallest > factor we decelerate with is 0.3, meaning we still wouldn't end up with > that small deltas. We discussed this on IRC, and after your > explanations, I think we could just as well just use wl_fixed_t. If > there would be acceleration profiles that decelerate even more (for > example 0.03 instead of 0.3 on a 8200dpi mouse normalized to 1000dpi), > then since the resulting delta doesn't really represent a hardware event > anyway, accumulating the leftover fraction isn't that big of a deal. > Daniel, what do you think? Right, that makes sense to me. Though in the raw case, surely deceleration won't be applied? Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] dmabuf: get supported dmabuf formats from compositor backend
Hi, On 30 October 2015 at 00:27, Bryce Harrington wrote: > On Tue, Oct 20, 2015 at 08:45:50AM -0700, Bryce Harrington wrote: >> On Tue, Oct 20, 2015 at 04:54:30PM +0200, Fabien Dessenne wrote: >> > Add the possibility for the compositor backend to provide with the list >> > of supported pixel formats for dmabuf-based buffers. >> > This information is used by linux_dmabuf to inform clients when binding. >> > >> > Signed-off-by: Fabien Dessenne >> >> Reviewed-by >> >> There's not a way to verify the list is getting sent across to the >> client is there? > > Also, patch no longer applies since e3c0d8af. > > I'd like to better understand what this is going to be used for, before > landing it. Another R-b on this would be nice as well; Giulio perhaps > you could give this patch a review? Hm, to be honest I'd prefer this not land just now, or like this. dmabuf usage in compositor-drm is just an optimisation, where the fallback path is through gl-renderer. Anything gl-renderer doesn't support, we essentially can't display. Those formats are what we need to send to the compositor (possibly with the intersection between gl-renderer and compositor-drm marked as preferred), but right now, as the comment notes, we lack a way to query this through EGL. This is being worked on though. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] dmabuf: get supported dmabuf formats from compositor backend
2015-10-30 2:27 GMT+02:00 Bryce Harrington :
> On Tue, Oct 20, 2015 at 08:45:50AM -0700, Bryce Harrington wrote:
>> On Tue, Oct 20, 2015 at 04:54:30PM +0200, Fabien Dessenne wrote:
>> > Add the possibility for the compositor backend to provide with the list
>> > of supported pixel formats for dmabuf-based buffers.
>> > This information is used by linux_dmabuf to inform clients when binding.
>> >
>> > Signed-off-by: Fabien Dessenne
>>
>> Reviewed-by
>>
>> There's not a way to verify the list is getting sent across to the
>> client is there?
I'm not sure i understand this question.
>
> Also, patch no longer applies since e3c0d8af.
>
> I'd like to better understand what this is going to be used for, before
> landing it. Another R-b on this would be nice as well; Giulio perhaps
> you could give this patch a review?
Well, it doesn't apply because we now have a new vfunc in
weston_backend, but rebasing it should be trivial.
>
> Bryce
>
>> Bryce
>>
>> > ---
>> > src/compositor.h | 2 ++
>> > src/linux-dmabuf.c | 16 +---
>> > 2 files changed, 15 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/src/compositor.h b/src/compositor.h
>> > index 2e2a185..f58e0cc 100644
>> > --- a/src/compositor.h
>> > +++ b/src/compositor.h
>> > @@ -613,6 +613,8 @@ enum weston_capability {
>> > struct weston_backend {
>> > void (*destroy)(struct weston_compositor *ec);
>> > void (*restore)(struct weston_compositor *ec);
>> > + void (*get_dmabuf_formats)(struct weston_compositor *ec,
>> > + struct wl_array *formats);
>> > };
>> >
>> > struct weston_compositor {
>> > diff --git a/src/linux-dmabuf.c b/src/linux-dmabuf.c
>> > index 90c9757..ee02ea4 100644
>> > --- a/src/linux-dmabuf.c
>> > +++ b/src/linux-dmabuf.c
>> > @@ -433,9 +433,19 @@ bind_linux_dmabuf(struct wl_client *client,
>> > wl_resource_set_implementation(resource, &linux_dmabuf_implementation,
>> >compositor, NULL);
>> >
>> > - /* EGL_EXT_image_dma_buf_import does not provide a way to query the
>> > -* supported pixel formats. */
>> > - /* XXX: send formats */
>> > + if (compositor->backend->get_dmabuf_formats) {
Can the formats change in the compositor lifetime? If not, it may be
better to ask for them once and store the result instead of asking for
each new client.
>> > + struct wl_array dmabuf_formats;
>> > + uint32_t *p;
>> > +
>> > + wl_array_init(&dmabuf_formats);
>> > +
>> > + compositor->backend->get_dmabuf_formats(compositor,
>> > + &dmabuf_formats);
>> > + wl_array_for_each(p, &dmabuf_formats)
>> > + zlinux_dmabuf_send_format(resource, *p);
>> > +
>> > + wl_array_release(&dmabuf_formats);
>> > + }
>> > }
>> >
>> > /** Advertise linux_dmabuf support
>> > --
>> > 1.9.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
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
