FreeGLUT has now a Wayland backend
Hello fellow developers, Just a little message to let you know that the well-known FreeGLUT (1) library (open-source fork of the legacy GLUT (2) library) can now use Wayland natively. The particular commit enables it : https://github.com/dcnieho/FreeGLUT/commit/9b30564b6d9c9f106c7d079d6cf9207363a49111 And here is a video demonstrating the backend : https://www.youtube.com/watch?v=FQvRIoALQyg Thanks to the wonderful maintainers (most notably, John Tsiombikas and Diederick C. Niehorster), for having made this possible ! (1) http://freeglut.sourceforge.net/ (2) https://www.opengl.org/resources/libraries/glut/ -- Regards, *Manuel BACHMANN Tizen Project VANNES-FR* ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput v2] evdev: Add support for POINTINGSTICK_CONST_ACCEL udev property
On Fri, Apr 03, 2015 at 04:15:18PM +0200, Hans de Goede wrote:
> There is quite a wide spread in the delta events generated by trackpoints,
> some generate deltas of 1-2 under normal use, while others generate deltas
> from 1-20.
>
> It is desirable to normalize trackpoint deltas just like we are normalizing
> mouse deltas to 1000 dpi, so as to give different model laptops aprox.
> the same trackpoint cursor speed ootb.
>
> Recent versions of udev + hwdb set a POINTINGSTICK_CONST_ACCEL udev property
> which can be used to adjust trackpoints which are too slow / too fast
> ootb, this commit implements support for that property.
>
> Signed-off-by: Hans de Goede
> ---
> Changes in v2:
> -Use POINTINGSTICK_CONST_ACCEL instead of TRACKPOINT_CONST_ACCEL to match
> changes to the udev patchset
> ---
> src/evdev.c | 33 +
> src/evdev.h | 7 +++
> src/libinput-util.c | 31 +++
> src/libinput-util.h | 1 +
> 4 files changed, 72 insertions(+)
>
> diff --git a/src/evdev.c b/src/evdev.c
> index 2808c30..e54d559 100644
> --- a/src/evdev.c
> +++ b/src/evdev.c
> @@ -1319,6 +1319,31 @@ evdev_read_wheel_click_prop(struct evdev_device
> *device)
>
> return angle;
> }
> +
> +static inline int
> +evdev_get_trackpoint_dpi(struct evdev_device *device)
> +{
> + struct libinput *libinput = device->base.seat->libinput;
> + const char *trackpoint_accel;
> + double accel = DEFAULT_TRACKPOINT_ACCEL;
> +
> + trackpoint_accel = udev_device_get_property_value(
> + device->udev_device,
> "POINTINGSTICK_CONST_ACCEL");
> + if (trackpoint_accel) {
> + accel = parse_trackpoint_accel_property(trackpoint_accel);
> + if (accel == 0.0) {
> + log_error(libinput, "Trackpoint accel property for "
> + "'%s' is present but invalid, "
> + "using %.2f instead\n",
> + device->devname,
> + DEFAULT_TRACKPOINT_ACCEL);
> + accel = DEFAULT_TRACKPOINT_ACCEL;
> + }
> + }
needs an entry in the udev property list in
doc/device-configuration-via-udev.dox
> +
> + return DEFAULT_MOUSE_DPI * accel;
> +}
> +
> static inline int
> evdev_read_dpi_prop(struct evdev_device *device)
> {
> @@ -1326,6 +1351,14 @@ evdev_read_dpi_prop(struct evdev_device *device)
> const char *mouse_dpi;
> int dpi = DEFAULT_MOUSE_DPI;
>
> + /*
> + * Trackpoints do not have dpi, instead hwdb may contain a
> + * POINTINGSTICK_CONST_ACCEL value to compensate for sensitity
> differences
sensitivity
> + * between different models, we translate this to a fake dpi.
> + */
> + if (libevdev_has_property(device->evdev, INPUT_PROP_POINTING_STICK))
> + return evdev_get_trackpoint_dpi(device);
> +
> mouse_dpi = udev_device_get_property_value(device->udev_device,
> "MOUSE_DPI");
> if (mouse_dpi) {
> diff --git a/src/evdev.h b/src/evdev.h
> index c7a9e75..b63ae86 100644
> --- a/src/evdev.h
> +++ b/src/evdev.h
> @@ -36,6 +36,13 @@
>
> /* The HW DPI rate we normalize to before calculating pointer acceleration */
> #define DEFAULT_MOUSE_DPI 1000
> +
> +/*
> + * The constant (linear) acceleration factor we use to normalize trackpoint
> + * deltas before calculating pointer acceleration.
> + */
> +#define DEFAULT_TRACKPOINT_ACCEL 1.0
> +
> /* The fake resolution value for abs devices without resolution */
> #define EVDEV_FAKE_RESOLUTION 1
>
> diff --git a/src/libinput-util.c b/src/libinput-util.c
> index 49e297a..5891012 100644
> --- a/src/libinput-util.c
> +++ b/src/libinput-util.c
> @@ -29,6 +29,7 @@
> #include "config.h"
>
> #include
> +#include
> #include
> #include
> #include
> @@ -201,3 +202,33 @@ parse_mouse_wheel_click_angle_property(const char *prop)
>
> return angle;
> }
> +
> +/**
> + * Helper function to parse the TRACKPOINT_CONST_ACCEL property from udev.
> + * Property is of the form:
> + * TRACKPOINT_CONST_ACCEL=
> + *
> + * @param prop The value of the udev property (without the
> TRACKPOINT_CONST_ACCEL=)
> + * @return The acceleration, or 0.0 on error.
> + */
> +double
> +parse_trackpoint_accel_property(const char *prop)
> +{
> + locale_t c_locale;
> + double accel;
> + char *endp;
> +
> + /* Create a "C" locale to force strtod to use '.' as seperator */
"separator"
> + c_locale = newlocale(LC_NUMERIC_MASK, "C", (locale_t)0);
> + if (c_locale == (locale_t)0)
> + return 0.0;
> +
> + accel = strtod_l(prop, &endp, c_locale);
> +
> + freelocale(c_locale);
> +
> + if (*endp != '\0')
> + return 0.0;
> +
> + return accel;
> +}
add a couple of basic tests for this please, should mostly be copy/paste
Re: [RFC v2 libinput 2/2] buttonset: implement buttonset handling for Wacom tablet pads
On Fri, Mar 27, 2015 at 02:52:15PM -0700, Jason Gerecke wrote:
> Did some practical testing of these patches and noticed two issues with the
> touchstrips:
>
> On 3/17/2015 11:58 PM, Peter Hutterer wrote:
> >From: Benjamin Tissoires
> >
> >Same approach as evdev-tablet (started as copy/paste), with axis and buttons
> >adjusted. Wacom's handling of pad devices requires a lot of non-obvious
> >handling, e.g. ABS_THROTTLE is the second ring, ABS_RX is the strip, etc.
> >
> >This is not generic buttonset code, if we start supporting other devices for
> >buttonsets we'll factor out a couple of the functions.
> >
> >The wheel and strip events are a bit of a problem: Wacom sends a 0 event on
> >the
> >axis when the finger is released. We can detect this if there is an ABS_MISC > >0
> >present in the same event and suppress it. Won't work if any finger is down
> >on any other wheel, strip or button but that's a kernel bug we'll fix once we
> >figure out how.
> >
> >Signed-off-by: Benjamin Tissoires
> >Signed-off-by: Peter Hutterer
> >---
> > src/Makefile.am | 2 +
> > src/evdev-buttonset-wacom.c | 533
> >
> > src/evdev-buttonset-wacom.h | 63 ++
> > src/evdev.c | 18 +-
> > src/evdev.h | 3 +
> > src/libinput-private.h | 16 ++
> > src/libinput.c | 65 ++
> > 7 files changed, 691 insertions(+), 9 deletions(-)
> > create mode 100644 src/evdev-buttonset-wacom.c
> > create mode 100644 src/evdev-buttonset-wacom.h
> >
> >[...]
> >
> >+static inline double
> >+normalize_strip(const struct input_absinfo *absinfo)
> >+{
> >+/* strip axes don't use a proper value, they just shift the bit left
> >+ * for each position. 0 isn't a real value either, it's only sent on
> >+ * finger release */
> >+double min = 1,
>
> Min should be set to 0 (i.e., log2(1)) here.
fixed, thanks.
> >+ max = log2(absinfo->maximum);
> >+double range = max - min;
> >+double value = (log2(absinfo->value) - min) / range;
> >+
> >+return value;
> >+}
> >+
> >+/* Detect ring wraparound, current and old are normalized to [0, 1[ */
> >+static inline double
> >+guess_ring_delta(double current, double old)
> >+{
> >+double d1, d2, d3;
> >+
> >+d1 = current - old;
> >+d2 = (current + 1) - old;
> >+d3 = current - (old + 1);
> >+
> >+if (fabs(d2) < fabs(d1))
> >+d1 = d2;
> >+
> >+if (fabs(d3) < fabs(d1))
> >+d1 = d3;
> >+
> >+return d1;
> >+}
> >+
> >+static void
> >+buttonset_check_notify_axes(struct buttonset_dispatch *buttonset,
> >+struct evdev_device *device,
> >+uint32_t time)
> >+{
> >+struct libinput_device *base = &device->base;
> >+bool axis_update_needed = false;
> >+double deltas[LIBINPUT_BUTTONSET_MAX_NUM_AXES] = {0};
> >+double deltas_discrete[LIBINPUT_BUTTONSET_MAX_NUM_AXES] = {0};
> >+unsigned int a;
> >+unsigned int code;
> >+
> >+for (a = 0; a <= buttonset->naxes; a++) {
> >+const struct input_absinfo *absinfo;
> >+
> >+if (!bit_is_set(buttonset->changed_axes, a))
> >+continue;
> >+
> >+code = buttonset->axis_map[a];
> >+assert(code != 0);
> >+absinfo = libevdev_get_abs_info(device->evdev, code);
> >+assert(absinfo);
> >+
> >+switch (buttonset->types[a]) {
> >+case LIBINPUT_BUTTONSET_AXIS_RING:
> >+buttonset->axes[a] = normalize_ring(absinfo);
> >+deltas[a] = guess_ring_delta(buttonset->axes[a],
> >+ buttonset->axes_prev[a]);
> >+deltas_discrete[a] = unnormalize_ring_value(absinfo,
> >+deltas[a]);
> >+break;
> >+case LIBINPUT_BUTTONSET_AXIS_STRIP:
> >+buttonset->axes[a] = normalize_strip(absinfo);
> >+deltas[a] = buttonset->axes[a] -
> >buttonset->axes_prev[a];
> >+break;
>
> When a touch goes up, normalize_strip will return a normalized value of
> negative infinity. You should add suppression logic like for the ABS_MISC
> case since it isn't a real value.
added, thanks.
Cheers,
Peter
>
> >+default:
> >+log_bug_libinput(device->base.seat->libinput,
> >+ "Invalid axis update: %u\n", a);
> >+break;
> >+}
> >+
> >+if (buttonset->have_abs_misc_terminator) {
> >+/* Suppress the reset to 0 on finger up. See the
> >+ comment in buttonset_process_absolute */
> >+if (libevdev_get_event_value(device->evdev,
> >+ EV_ABS,
> >+
Re: [RFC PATCH v2 wayland] protocol: add wl_pointer.axis_source, axis_stop and axis_discrete events
On Fri, Mar 27, 2015 at 10:23:43AM +0800, Jonas Ådahl wrote: > On Fri, Mar 27, 2015 at 11:04:42AM +1000, Peter Hutterer wrote: > > On Wed, Mar 25, 2015 at 09:14:08AM +0800, Jonas Ådahl wrote: > > > On Wed, Mar 25, 2015 at 10:27:10AM +1000, Peter Hutterer wrote: > > > > The axis_source event determines how an axis event was generated. This > > > > enables > > > > clients to judge when to use kinetic scrolling. > > > > > > > > The axis_stop event notifies a client about the termination of a scroll > > > > sequence, likewise needed to calculate kinetic scrolling parameters. > > > > > > > > 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 (axis_source and axis_discrete) > > > > are prefixed before a wl_pointer.axis or axis_stop event, i.e. the > > > > sequence > > > > becomes: > > > > > > > > wl_pointer.axis_source > > > > wl_pointer.axis > > > > wl_pointer.axis_source > > > > wl_pointer.axis > > > > wl_pointer.axis_source > > > > wl_pointer.axis > > > > wl_pointer.axis_source > > > > wl_pointer.axis_stop > > > > > > > > or: > > > > > > > > wl_pointer.axis_source > > > > wl_pointer.axis_discrete > > > > wl_pointer.axis_axis > > > > > > > > Clients need to combine the state of all events where needed. > > > > --- > > > > Changes to v1: > > > > - introduce axis_stop and axis_discrete as separate events instead of > > > > flags > > > > - couple of documentation updates > > > > - wl_seat/keyboard/touch/pointer bumped to version 5 > > > > > > > > This is for the API review only so far, I don't have the weston patches > > > > to > > > > match yet. > > > > > > > > protocol/wayland.xml | 87 > > > > +--- > > > > 1 file changed, 83 insertions(+), 4 deletions(-) > > > > > > > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > > > > index c5963e8..29e6f01 100644 > > > > --- a/protocol/wayland.xml > > > > +++ b/protocol/wayland.xml > > > > @@ -1337,7 +1337,7 @@ > > > > wl_seat.get_keyboard or wl_seat.get_touch, the returned object > > > > is > > > > always of the same version as the wl_seat. > > > > --> > > > > - > > > > + > > > > > > > >A seat is a group of keyboards, pointer and touch devices. This > > > >object is published as a global during start up, or when such a > > > > @@ -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 > > > > @@ -1572,10 +1572,89 @@ > > > > > > > > > > > > > > > > + > > > > > > Usually don't tend to add these it seems. If we'd want to be consistent, > > > we'd have to add comments like this in several other places. > > > > ACK, removed locally. > > > > > > > > > + > > > > + > > > > + > > > > + > > > > + > > > > + Describes the axis types of scroll events. > > > > + > > > > + > > Should we really send events that has an unknown source? How would the > client interpret it? If we want to change the source from 'unknown' to > some new source, wouldn't that break backward compatibility? ACK, removed locally. > > > > + > > > > + > > > > + > > > > + > > > > + > > > > + > > > > + > > > > +Scroll and other axis source notification. > > > > + > > > > +This event does not occur on its own. It is sent before a > > > > +wl_pointer.axis or wl_pointer.axis_stop event and carries the > > > > source > > > > +information for that event. A client is expected to accumulate > > > > the > > > > +data in both events before proceeding. > > > > + > > > > +The axis and timestamp values are identical to the one in the > > > > +subsequent wl_pointer.axis or wl_pointer.axis_stop event. For > > > > the > > > > +interpretation of the axis value, see the wl_pointer.axis event > > > > +documentation. > > > > + > > > > +The source specifies how this event was generated. If the > > > > source is > > > > +finger, a wl_pointer.axis_stop event will be sent when the user > > > > +lifts the finger off the device. > > > > + > > > > + > > > > > > Why have a "time" parameter here, considering that this state does > > > nothing on its own and which data should simply be just kept around until > > > the committing event is received? Feels redundant. > > > > > > > + > > > > > > This one seems also redundant. > >
Re: [PATCH libinput] tools: List relative wheel among axis capabilities
On Wed, Apr 01, 2015 at 02:01:01PM -0700, Jason Gerecke wrote:
> Signed-off-by: Jason Gerecke
> ---
> For Peter's tablet-support branch.
applied, thanks.
Cheers,
Peter
>
> tools/event-debug.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/tools/event-debug.c b/tools/event-debug.c
> index d2ac415..e8e49cd 100644
> --- a/tools/event-debug.c
> +++ b/tools/event-debug.c
> @@ -480,6 +480,8 @@ print_proximity_event(struct libinput_event *ev)
> printf("r");
> if (libinput_tool_has_axis(tool, LIBINPUT_TABLET_AXIS_SLIDER))
> printf("s");
> + if (libinput_tool_has_axis(tool, LIBINPUT_TABLET_AXIS_REL_WHEEL))
> + printf("w");
>
> printf("\tbtn:");
> if (libinput_tool_has_button(tool, BTN_TOUCH))
> --
> 2.3.4
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] evdev: Do not mark tablet touchscreens as tablets
On Mon, Mar 30, 2015 at 03:04:52PM -0400, Benjamin Tissoires wrote:
> On Fri, Mar 27, 2015 at 6:34 PM, Jason Gerecke wrote:
> > Devices like the Cintiq 24HDT are marked with both ID_INPUT_TABLET and
> > ID_INPUT_TOUCHSCREEN in udev. Be sure that we don't try to use such a
> > device as a tablet.
> >
> > Signed-off-by: Jason Gerecke
> > ---
>
> Reviewed-by: Benjamin Tissoires
I reshuffled things a bit for readability but the end result is the same.
pushed: 10ca39cf80698cedf92c38fc49a1f9784d2ab385. thanks
Cheers,
Peter
> > For Peter's tablet-support branch.
> >
> > src/evdev.c | 10 +-
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/src/evdev.c b/src/evdev.c
> > index 19226fe..c57ac4f 100644
> > --- a/src/evdev.c
> > +++ b/src/evdev.c
> > @@ -1636,11 +1636,11 @@ evdev_configure_device(struct evdev_device *device)
> > }
> > }
> >
> > - /* libwacom assigns touchpad _and_ tablet to the tablet touch bits,
> > - so make sure we don't initialize the tablet interface for the
> > - touch device */
> > - if ((udev_tags & (EVDEV_UDEV_TAG_TABLET|EVDEV_UDEV_TAG_TOUCHPAD)) ==
> > -EVDEV_UDEV_TAG_TABLET) {
> > + /* libwacom assigns touchpad (or touchscreen) _and_ tablet to the
> > + tablet touch bits, so make sure we don't initialize the tablet
> > + interface for the touch device */
> > + if ((udev_tags & (EVDEV_UDEV_TAG_TABLET|EVDEV_UDEV_TAG_TOUCHPAD|
> > + EVDEV_UDEV_TAG_TOUCHSCREEN)) == EVDEV_UDEV_TAG_TABLET) {
> > device->dispatch = evdev_tablet_create(device);
> > device->seat_caps |= EVDEV_DEVICE_TABLET;
> > log_info(libinput,
> > --
> > 2.3.3
> >
> > ___
> > 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 4/9] ivi-layout: abort without controller_module_init
On 02/04/15 07:11 AM, Pekka Paalanen wrote: > On Thu, 2 Apr 2015 01:04:12 + > "Tanibata, Nobuhiko (ADITJ/SWG)" wrote: > >> >> >>> -Original Message- >>> From: wayland-devel >>> [mailto:wayland-devel-boun...@lists.freedesktop.org] On Behalf Of Pekka >>> Paalanen >>> Sent: Monday, March 30, 2015 6:21 PM >>> To: wayland-devel@lists.freedesktop.org >>> Cc: Pekka Paalanen; Nobuhiko Tanibata >>> Subject: [PATCH weston 4/9] ivi-layout: abort without >>> controller_module_init >>> >>> From: Pekka Paalanen >>> >>> When loading a controller module, if we do not find a controller_module_init >>> symbol, return failure to the caller instead of ignoring the failure. >>> >>> Signed-off-by: Pekka Paalanen >> [ntanibata] >> Tested-by: Nobuhiko Tanibata >> > > I've pushed two more patches from this series: > ivi-shell: add cmdline option for controller module > ivi-layout: abort without controller_module_init >4ac06ff..97246c0 master -> master > > Patches 5-9 are remaining, now in force-pushed: > http://cgit.collabora.com/git/user/pq/weston.git/log/?h=ivi-test-5 > > The force-push is a simple rebase to account for added tags in commit > messages. No code changes. Just finished looking at 5-9... Just a couple of questions: in 8, What does 0xffc01200 mean? in 9 you have copies of pretty much the same assert macros from 8, do you think they're useful enough to put somewhere shared instead of duplicating them? Reviewed-by: Derek Foreman ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] desktop-shell: Fix a crash when right-clicking the panel
Yeah, the logic is pretty sketchy now - "if it's a shell surface, do the
error checking; otherwise, do nothing" - but I don't understand the code
well enough to know if this is the expected behavior.
Should the panel just be a shell surface? Then we could require that the
popup's parent is a shell surface and simplify the error check.
On Mon, Apr 6, 2015 at 12:33 PM, Derek Foreman
wrote:
> This bug was introduced in commits da6ecd0cc52 and 24185e2561
>
> I guess nobody right clicked on the panel for over a month. :)
>
> I've CC'd Jasper and Jonas in case they haven't noticed this yet...
>
> On 06/04/15 01:52 AM, Dima Ryazanov wrote:
> > It looks like the error-checking code assumes the popup's parent is
> > a shell surface - but that's not always the case.
> >
> > Signed-off-by: Dima Ryazanov
> > ---
> > desktop-shell/shell.c | 9 +
> > 1 file changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
> > index f7c928e..0159547 100644
> > --- a/desktop-shell/shell.c
> > +++ b/desktop-shell/shell.c
> > @@ -3392,7 +3392,7 @@ add_popup_grab(struct shell_surface *shsurf,
> >
> > parent = get_shell_surface(shsurf->parent);
> > top_surface = get_top_popup(shseat);
> > - if (shell_surface_is_xdg_popup(shsurf) &&
> > + if (parent && shell_surface_is_xdg_popup(shsurf) &&
>
> This part broke in da6ecd0cc52
>
> Your patch definitely stops the crash for me, which is good. :)
>
> I think this part's ok, but I'm not 100% sure we're still going to send
> the new not-top-level-popup error when we're supposed to now...
>
> > ((top_surface == NULL &&
> !shell_surface_is_xdg_surface(parent)) ||
> >(top_surface != NULL && parent != top_surface))) {
> > wl_resource_post_error(shsurf->owner->resource,
> > @@ -4098,12 +4098,13 @@ create_xdg_popup(struct shell_client *owner,
> void *shell,
> > {
> > struct shell_surface *shsurf, *parent_shsurf;
> >
> > - /* Verify that we are creating the top most popup when mapping,
> > - * as its not until then we know whether it was mapped as most
> > + /* Verify that we are creating the topmost popup when mapping,
> > + * as it's not until then we know whether it was mapped as most
> >* top level or not. */
>
> The grammar fix-ups look good to me.
>
> > parent_shsurf = get_shell_surface(parent);
> > - if (!shell_surface_is_xdg_popup(parent_shsurf) &&
> > + if (parent_shsurf &&
>
> This part broke in 24185e2561...
>
> I wonder if we should be doing a more comprehensive test here - it looks
> like some invalid parent resources could get past this test?
>
> > + !shell_surface_is_xdg_popup(parent_shsurf) &&
> > !shell_surface_is_xdg_surface(parent_shsurf)) {
> > wl_resource_post_error(owner->resource,
> > XDG_POPUP_ERROR_INVALID_PARENT,
> >
>
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] desktop-shell: Fix a crash when right-clicking the panel
This bug was introduced in commits da6ecd0cc52 and 24185e2561
I guess nobody right clicked on the panel for over a month. :)
I've CC'd Jasper and Jonas in case they haven't noticed this yet...
On 06/04/15 01:52 AM, Dima Ryazanov wrote:
> It looks like the error-checking code assumes the popup's parent is
> a shell surface - but that's not always the case.
>
> Signed-off-by: Dima Ryazanov
> ---
> desktop-shell/shell.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
> index f7c928e..0159547 100644
> --- a/desktop-shell/shell.c
> +++ b/desktop-shell/shell.c
> @@ -3392,7 +3392,7 @@ add_popup_grab(struct shell_surface *shsurf,
>
> parent = get_shell_surface(shsurf->parent);
> top_surface = get_top_popup(shseat);
> - if (shell_surface_is_xdg_popup(shsurf) &&
> + if (parent && shell_surface_is_xdg_popup(shsurf) &&
This part broke in da6ecd0cc52
Your patch definitely stops the crash for me, which is good. :)
I think this part's ok, but I'm not 100% sure we're still going to send
the new not-top-level-popup error when we're supposed to now...
> ((top_surface == NULL && !shell_surface_is_xdg_surface(parent)) ||
>(top_surface != NULL && parent != top_surface))) {
> wl_resource_post_error(shsurf->owner->resource,
> @@ -4098,12 +4098,13 @@ create_xdg_popup(struct shell_client *owner, void
> *shell,
> {
> struct shell_surface *shsurf, *parent_shsurf;
>
> - /* Verify that we are creating the top most popup when mapping,
> - * as its not until then we know whether it was mapped as most
> + /* Verify that we are creating the topmost popup when mapping,
> + * as it's not until then we know whether it was mapped as most
>* top level or not. */
The grammar fix-ups look good to me.
> parent_shsurf = get_shell_surface(parent);
> - if (!shell_surface_is_xdg_popup(parent_shsurf) &&
> + if (parent_shsurf &&
This part broke in 24185e2561...
I wonder if we should be doing a more comprehensive test here - it looks
like some invalid parent resources could get past this test?
> + !shell_surface_is_xdg_popup(parent_shsurf) &&
> !shell_surface_is_xdg_surface(parent_shsurf)) {
> wl_resource_post_error(owner->resource,
> XDG_POPUP_ERROR_INVALID_PARENT,
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Xfig menus don't appear - bug?
No, sorry. I'll take a look today. On Mon, Apr 6, 2015 at 10:22 AM, Felix E. Klee wrote: > Should I report this somewhere? > ___ > 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: Xfig menus don't appear - bug?
Should I report this somewhere? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] xwayland: Stack windows on top when activating them
Hi, On 22 March 2015 at 17:14, Jasper St. Pierre wrote: > Now that we've removed the XYToWindow handler in Xwayland, we actually > have to stack windows properly. This stacks windows on top when > activating them. > > Note that for a fully robust Xwayland implementation, we'll need a > complete stack tracker implementation, unfortunately. R-b and pushed. This is still incomplete, but certainly better than what came before. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] wayland-drm: add a description for every item.
On Wed, 25 Mar 2015 13:10:24 +0100 Emmanuel Gil Peyrot wrote: > This makes the generated protocol headers a lot more readable. > --- > src/egl/wayland/wayland-drm/wayland-drm.xml | 159 > +--- > 1 file changed, 100 insertions(+), 59 deletions(-) > > diff --git a/src/egl/wayland/wayland-drm/wayland-drm.xml > b/src/egl/wayland/wayland-drm/wayland-drm.xml > index 5e64622..7cf06d9 100644 > --- a/src/egl/wayland/wayland-drm/wayland-drm.xml > +++ b/src/egl/wayland/wayland-drm/wayland-drm.xml > @@ -27,19 +27,31 @@ > THIS SOFTWARE. > > > - > > + > + This object is created by the server and published using the > + display's global event. Hi, you can say that a lot shorter: "This is a global object interface." But you could also say more: - is this a singleton? - this is a detail of an EGL implementation - this is specific to Mesa, an internal implementation detail that no-one outside Mesa is supposed to access. > + > + > > - > - > - > + > +These errors can be emitted in response to wl_drm requests. That's obvious, isn't it? > + > + + summary="authentication failure"/> > + + summary="buffer format is not supported"/> > + + summary="invalid name for buffer creation"/> Ok. > > > > - > + > +The drm format codes match the #defines in drm_fourcc.h. > + > +The formats actually supported by the compositor will be > +reported by the format event. > + Ok. > > > > @@ -100,84 +112,113 @@ > > > > - > > - > + > +Call this request with the magic received from drmGetMagic(). > + > +It will be passed on to the drmAuthMagic() or > +DRIAuthConnection() call. This authentication must be > +completed before create_buffer could be used. > + > + Ok. > > > - > > - > - > - > - > - > - > + > +Create a wayland buffer for the named DRM buffer. > + > +The DRM surface must have a name using the flink ioctl. > + > + + summary="wl_buffer assigned to this drm buffer"/> > + Would be much more explicit to say that is a flink name, not just any freely chosen unique number. > + > + Units? > + Units? Without specifying the units, you are not really adding any information here. > + > > > - > > - > - > - > - > - > - > - > - > - > - > - > + > +Create a wayland buffer for the named planar DRM buffer. > + > +The DRM surface must have a name using the flink ioctl. > + > + + summary="wl_buffer assigned to this drm buffer"/> > + Flink name. > + > + > + > + > + > + > + > + > + Units? > > > - > > - > + > +Notification of the path of the drm device which is used by the > +server. > + > +The client should use this device for creating local buffers. > +Only buffers created from this device should be be passed to > +the server using this drm object's create_buffer request. > + > + Ok. > > > > - > + > +Informs the client about a valid pixel format that can be used > +for buffers. > + > + > > > - > - > + > + > +Raised if the authenticate request succeeded. > + > + Ok. > > > - > -Bitmask of capabilities. > + > +Lists the available capabilities the server can expose. You lost the most important word of the description: "bitmask". It tells how to add new values to this enum. > > > > > > - > + > +Bitmask of capabilities supported by the server. > + > + Ok. Might add "see wl_drm_capability". > > > > > - > > - > - > - > - > - > - > - > - > - > - > - > + > +Create a wayland buffer for the prime fd. > + > +Use for regular and planar buffers. Pass 0 for offset and > +stride for unused planes. > + > + + summary="wl_buffer assigned to this drm buffer"/> > + I'm not really sure what a "prime fd" is, care to explain it in the description? Is it a dmabuf fd? Any additional semantics or constraints? > + > + > + > + > + > + > + > + > + > > > I don't mind if you don't add the extra information I asked for. So, if you put the "bitmask" back, then this would be: Revieved-by: Pekka Paalanen Thanks, pq PS. the proper mailing lists woul
