[PATCH libinput] udev: update the hwdb matches to avoid use of ( and )

[Peter Hutterer]

libudev's util_replace_chars() replaces the () with underscores so that match
would work too but let's use ? instead to make it look like a regex.

This now activates the rules for all cyapa touchpads, before they wouldn't
have applied to any device.

https://bugs.freedesktop.org/show_bug.cgi?id=93846#c12

Signed-off-by: Peter Hutterer 
---
 udev/90-libinput-model-quirks.hwdb | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/udev/90-libinput-model-quirks.hwdb 
b/udev/90-libinput-model-quirks.hwdb
index d5978f7..242c444 100644
--- a/udev/90-libinput-model-quirks.hwdb
+++ b/udev/90-libinput-model-quirks.hwdb
@@ -62,22 +62,22 @@ libinput:name:*ETPS/2 Elantech Touchpad*:dmi:*
 # The various chromebooks, info from modinfo chromeos_laptop, touchpad names
 # extrapolated from the chromiumos touchad-tests repo
 # https://chromium.googlesource.com/chromiumos/platform/touchpad-tests
-libinput:name:Cypress APA Trackpad (cyapa):dmi:*pnFalco:pvr*
+libinput:name:Cypress APA Trackpad ?cyapa?:dmi:*pnFalco:pvr*
 libinput:name:SynPS/2 Synaptics TouchPad:dmi:*pn*Mario*
-libinput:name:Cypress APA Trackpad (cyapa):dmi:*pn*Butterfly*
-libinput:name:Cypress APA Trackpad (cyapa):dmi:*pn*Peppy*
+libinput:name:Cypress APA Trackpad ?cyapa?:dmi:*pn*Butterfly*
+libinput:name:Cypress APA Trackpad ?cyapa?:dmi:*pn*Peppy*
 libinput:name:SynPS/2 Synaptics TouchPad:dmi:*pn*ZGB*
-libinput:name:Cypress APA Trackpad (cyapa):dmi:*pn*Parrot*
-libinput:name:Cypress APA Trackpad (cyapa):dmi:*bvn*coreboot*:pn*Leon*
-libinput:name:Cypress APA Trackpad (cyapa):dmi:*bvn*coreboot*:pn*Falco*
-libinput:name:Cypress APA Trackpad (cyapa):dmi:*bvn*coreboot*:pn*Wolf*
-libinput:name:Cypress APA Trackpad (cyapa):dmi:*svn*GOOGLE*:pn*Link*
+libinput:name:Cypress APA Trackpad ?cyapa?:dmi:*pn*Parrot*
+libinput:name:Cypress APA Trackpad ?cyapa?:dmi:*bvn*coreboot*:pn*Leon*
+libinput:name:Cypress APA Trackpad ?cyapa?:dmi:*bvn*coreboot*:pn*Falco*
+libinput:name:Cypress APA Trackpad ?cyapa?:dmi:*bvn*coreboot*:pn*Wolf*
+libinput:name:Cypress APA Trackpad ?cyapa?:dmi:*svn*GOOGLE*:pn*Link*
 libinput:name:SynPS/2 Synaptics TouchPad:dmi:*pn*Alex*
-libinput:name:Cypress APA Trackpad (cyapa):dmi:*svn*SAMSUNG*:pn*Lumpy*
+libinput:name:Cypress APA Trackpad ?cyapa?:dmi:*svn*SAMSUNG*:pn*Lumpy*
 libinput:name:Atmel maXTouch Touchpad:dmi:*svn*GOOGLE*:pn*Samus*
  LIBINPUT_MODEL_CHROMEBOOK=1
 
-libinput:name:Cypress APA Trackpad (cyapa):dmi:*
+libinput:name:Cypress APA Trackpad ?cyapa?:dmi:*
  LIBINPUT_MODEL_CYAPA=1
 
 ##
-- 
2.5.5

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 4/5] compositor: Version the backend configuration structures

[Bryce Harrington]

On Tue, Apr 12, 2016 at 09:44:10PM -0700, Bryce Harrington wrote:
> On Wed, Apr 06, 2016 at 11:43:54AM +0300, Pekka Paalanen wrote:
> > On Mon, 21 Mar 2016 23:11:29 +0100
> > Benoit Gschwind  wrote:
> > 
> > > Hello,
> > > 
> > > I think that struct_version and struct_size should not be belong
> > > compositor.h. I think those versioning should be back-end detail, and
> > > each back-end should provide a major version number through #define in
> > > the backend header.
> > 
> > Hi!
> > 
> > No, the struct fields do belong in compositor.h. These fields are
> > common to all backend-specific structs, and must be handled the same
> > everywhere, so they make perfect sense in compositor.h, in the
> > definition of struct weston_backend_config.
> > 
> > However, you are right in that backends must define the struct_version
> > values in a backend-specific header. That #define can (only) be used for
> > build time compatibility checks in #if directives in main.c.
> 
> Agreed.  How should this #define be named?
> 
> > > Reviewed-by: Benoit Gschwind 
> > > 
> > > Le 10/03/2016 01:49, Bryce Harrington a écrit :
> > > > With this struct versioning, it is possible to add new options without
> > > > breaking the ABI, as long as all additions are made to the end of a
> > > > struct and nothing existing is modified or removed.  When things are
> > > > added, the structure's size will increase, and we'll use this size as
> > > > our minor version number.  If existing things need to be changed, then
> > > > the major version, struct_version, is incremented to indicate the ABI
> > > > break.
> > > > 
> > > > From our call site in main we record these major and minor version as
> > > > struct_version and struct_size.  The backend then verifies these against
> > > > its own assumptions.  So long as the backend's struct is equal or larger
> > > > than what was passed in and the major versions are equal, we're good;
> > > > but if it is larger, then this is a fatal error.
> > > > 
> > > > Signed-off-by: Bryce Harrington 
> > > > ---
> > > >  src/compositor-drm.c | 10 --
> > > >  src/compositor.h | 16 
> > > >  src/main.c   |  2 ++
> > > >  3 files changed, 26 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> > > > index 5ddedb9..9bce285 100644
> > > > --- a/src/compositor-drm.c
> > > > +++ b/src/compositor-drm.c
> > > > @@ -3203,8 +3203,14 @@ backend_init(struct weston_compositor 
> > > > *compositor, int *argc, char *argv[],
> > > >   struct weston_backend_config *config_base)
> > > >  {
> > > > struct drm_backend *b;
> > > > -   struct weston_drm_backend_config *config =
> > > > -   (struct weston_drm_backend_config 
> > > > *)config_base;
> > > > +   struct weston_drm_backend_config *config;
> > > > +
> > > > +   if (config_base == NULL ||
> > > > +   config_base->struct_version != 1 ||
> > > > +   config_base->struct_size > sizeof(struct 
> > > > weston_drm_backend_config))
> > > > +   return -1;
> > > > +
> > > > +   config = (struct weston_drm_backend_config *)config_base;
> > 
> > Like Quentin has suggested in IRC, this should be done as follows:
> 
> Is there a log of that discussion?
>  
> > - allocate a private struct weston_drm_backend_config
> > - init the private config with all defaults
> > - copy the first struct_size bytes from the passed-in config to the
> >   private config
> > 
> > This allows the backend to add more fields to the end with default
> > values, and maintain compatiblity with the older main.c.
> 
> So like in place of the cast line, do you mean something like:
> 
> config = zalloc(sizeof weston_drm_backend_config);
> if (config == NULL)
>  return -1;
> memcpy(config, config_base, config_base->struct_size);
> 
> ?

(with a struct and a set of parens thrown in there obviously...
this seems to work.)
  
> > The reason is that sizeof(struct weston_drm_backend_config) is
> > different between the caller and callee, and we still need to get the
> > defaults in somehow. Using this copy trick allows the version check to
> > be in just one place, and all other code can trust that all the fields
> > are properly initialized (not dependent on version).
> > 
> > It is a shallow copy, which is a bit awkward, but I'm not sure there is
> > a simple and better way.
> > 
> > > >  
> > > > b = drm_backend_create(compositor, config);
> > > > if (b == NULL)
> > > > diff --git a/src/compositor.h b/src/compositor.h
> > > > index 30462cf..3e52703 100644
> > > > --- a/src/compositor.h
> > > > +++ b/src/compositor.h
> > > > @@ -684,6 +684,22 @@ struct weston_backend_output_config {
> > > >   * data.
> > > >   */
> > > >  struct weston_backend_config {
> > > > +   /** Major version for the backend-specific config struct
> 

Re: [PATCH 5/5] compositor: Document refs for alternatives/assumptions for backend configs

[Bryce Harrington]

On Wed, Apr 06, 2016 at 11:46:28AM +0300, Pekka Paalanen wrote:
> On Wed,  9 Mar 2016 16:49:32 -0800
> Bryce Harrington  wrote:
> 
> > Signed-off-by: Bryce Harrington 
> > ---
> >  src/main.c | 13 +
> >  1 file changed, 13 insertions(+)
> > 
> > diff --git a/src/main.c b/src/main.c
> > index 7370292..310382a 100644
> > --- a/src/main.c
> > +++ b/src/main.c
> > @@ -748,6 +748,19 @@ load_drm_backend(struct weston_compositor *c, const 
> > char *backend,
> >  "gbm-format", >base.format,
> >  NULL);
> >  
> > +   /* Use a major/minor versioning scheme to enable backends to detect
> > +* ABI changes in the config struct we're passing in.
> > +*
> > +* NOTE: Alternate designs were proposed for using opaque structures[1]
> > +* and for section+key/value getter/setters[2].  The rationale for
> > +* selecting the transparent structure design is based on several
> > +* assumptions[3] which may require re-evaluating the design choice
> > +* if they fail to hold.
> > +*
> > +* 1: 
> > https://lists.freedesktop.org/archives/wayland-devel/2016-February/026989.html
> > +* 2: 
> > https://lists.freedesktop.org/archives/wayland-devel/2016-February/026929.html
> > +* 3: 
> > https://lists.freedesktop.org/archives/wayland-devel/2016-February/027228.html
> > +*/
> > config->base.base.struct_version = 1;
> > config->base.base.struct_size = sizeof(struct 
> > weston_drm_backend_config);
> > config->base.configure_output = drm_configure_output;
> 
> Hi,
> 
> shouldn't this be in compositor.h, with the struct
> weston_backend_config definition?

Yep, for the next patchset I've moved it.
 
> Otherwise looks good.
> 
> 
> Thanks,
> pq

> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> 
> iQIVAwUBVwTM5CNf5bQRqqqnAQj8Eg/8C1JTvLKA93EGbRkTtyD6qfUeO5ZnWweD
> osVK8GC3af0KD63bItZAJ7MhxVO87fXVINfY5sLHkczTK/csCYdagcQHBxDyeP1/
> zl4ScGhbnFQmcBClbs9/ISb3BXtBijerUdFYUbYRYeAEgL0iavfePyE0xzvCWwff
> El0nbdinEfS5N4b8gKIYyNl5kK1nGcHQ+DgePrlZoUb6a/ZpQNqFZ4NwPlkgcWRI
> uOK2AoKOy/OQZek1NRmvH9iZKicnH7B0DSkho6gWEJiPGEJ7siqIlo1HHXXlfHZ3
> 7nhr6fJ5zDsigLaJb5XuirAmpgD8bocUhXyB1wLnQn1yQ+sqBFTQDUufObR/zD6u
> xF8xmTnV2YQT8Tg6KZ0LxLQN5k1kV7U8V4YeN2P7VSsHeeyD/WOJYxa2idANS8zb
> mK0uSEBr9V8lzeFCfcZD6fMEuhMDF9elBFVcI7xm7EDFtvE38P3xvd1lWV/kGRIx
> H30H7qOyyko/UB6n5uh/VqNZ1bKEuJB7vE+ykEwxNtJNEpRTrOJGs8K5GyN/IJsY
> YKjzgsvNBDqGYO2+w1xGyvz3fiaW3iFsmBuhh9oKQO5qqYApXYz/PDfnoV9rcTH5
> O0wMjc3Ln8VO3SWxXXECG62d8orhh1I9zPB+1GumsEFqD8aMBZ2y4Ti6sW+/aPOX
> b6W8L3GiOzk=
> =lHNr
> -END PGP SIGNATURE-

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 4/5] compositor: Version the backend configuration structures

[Bryce Harrington]

On Wed, Apr 06, 2016 at 11:43:54AM +0300, Pekka Paalanen wrote:
> On Mon, 21 Mar 2016 23:11:29 +0100
> Benoit Gschwind  wrote:
> 
> > Hello,
> > 
> > I think that struct_version and struct_size should not be belong
> > compositor.h. I think those versioning should be back-end detail, and
> > each back-end should provide a major version number through #define in
> > the backend header.
> 
> Hi!
> 
> No, the struct fields do belong in compositor.h. These fields are
> common to all backend-specific structs, and must be handled the same
> everywhere, so they make perfect sense in compositor.h, in the
> definition of struct weston_backend_config.
> 
> However, you are right in that backends must define the struct_version
> values in a backend-specific header. That #define can (only) be used for
> build time compatibility checks in #if directives in main.c.

Agreed.  How should this #define be named?

> > Reviewed-by: Benoit Gschwind 
> > 
> > Le 10/03/2016 01:49, Bryce Harrington a écrit :
> > > With this struct versioning, it is possible to add new options without
> > > breaking the ABI, as long as all additions are made to the end of a
> > > struct and nothing existing is modified or removed.  When things are
> > > added, the structure's size will increase, and we'll use this size as
> > > our minor version number.  If existing things need to be changed, then
> > > the major version, struct_version, is incremented to indicate the ABI
> > > break.
> > > 
> > > From our call site in main we record these major and minor version as
> > > struct_version and struct_size.  The backend then verifies these against
> > > its own assumptions.  So long as the backend's struct is equal or larger
> > > than what was passed in and the major versions are equal, we're good;
> > > but if it is larger, then this is a fatal error.
> > > 
> > > Signed-off-by: Bryce Harrington 
> > > ---
> > >  src/compositor-drm.c | 10 --
> > >  src/compositor.h | 16 
> > >  src/main.c   |  2 ++
> > >  3 files changed, 26 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> > > index 5ddedb9..9bce285 100644
> > > --- a/src/compositor-drm.c
> > > +++ b/src/compositor-drm.c
> > > @@ -3203,8 +3203,14 @@ backend_init(struct weston_compositor *compositor, 
> > > int *argc, char *argv[],
> > >   struct weston_backend_config *config_base)
> > >  {
> > >   struct drm_backend *b;
> > > - struct weston_drm_backend_config *config =
> > > - (struct weston_drm_backend_config *)config_base;
> > > + struct weston_drm_backend_config *config;
> > > +
> > > + if (config_base == NULL ||
> > > + config_base->struct_version != 1 ||
> > > + config_base->struct_size > sizeof(struct weston_drm_backend_config))
> > > + return -1;
> > > +
> > > + config = (struct weston_drm_backend_config *)config_base;
> 
> Like Quentin has suggested in IRC, this should be done as follows:

Is there a log of that discussion?
 
> - allocate a private struct weston_drm_backend_config
> - init the private config with all defaults
> - copy the first struct_size bytes from the passed-in config to the
>   private config
> 
> This allows the backend to add more fields to the end with default
> values, and maintain compatiblity with the older main.c.

So like in place of the cast line, do you mean something like:

config = zalloc(sizeof weston_drm_backend_config);
if (config == NULL)
   return -1;
memcpy(config, config_base, config_base->struct_size);

?
 
> The reason is that sizeof(struct weston_drm_backend_config) is
> different between the caller and callee, and we still need to get the
> defaults in somehow. Using this copy trick allows the version check to
> be in just one place, and all other code can trust that all the fields
> are properly initialized (not dependent on version).
> 
> It is a shallow copy, which is a bit awkward, but I'm not sure there is
> a simple and better way.
> 
> > >  
> > >   b = drm_backend_create(compositor, config);
> > >   if (b == NULL)
> > > diff --git a/src/compositor.h b/src/compositor.h
> > > index 30462cf..3e52703 100644
> > > --- a/src/compositor.h
> > > +++ b/src/compositor.h
> > > @@ -684,6 +684,22 @@ struct weston_backend_output_config {
> > >   * data.
> > >   */
> > >  struct weston_backend_config {
> > > + /** Major version for the backend-specific config struct
> > > +  *
> > > +  * This version must match exactly what the backend expects, otherwise
> > > +  * the struct is incompatible.
> > > +  */
> > > + uint32_t struct_version;
> > > +
> > > + /** Minor version of the backend-specific config struct
> > > +  *
> > > +  * This must be set to sizeof(struct backend-specific config).
> > > +  * If the value here is smaller than what the backend expects, the
> > > +  * extra config members will assume their default 

Re: [PATCH 2/5] drm: port the drm backend to the new init api

[Bryce Harrington]

On Wed, Apr 06, 2016 at 11:37:57AM +0300, Pekka Paalanen wrote:
> On Wed,  9 Mar 2016 16:49:29 -0800
> Bryce Harrington  wrote:
> 
> > From: Giulio Camuffo 
> > 
> > Signed-off-by: Bryce Harrington 
> > Reviewed-by: Quentin Glidic 
> > Acked-by: Pekka Paalanen 
> > ---
> > v4: Update to current trunk
> > - Add missing param doc for mode in drm_output_choose_initial_mode
> > - Rebase to account for code changes by 91880f1e to make vt
> >   switching configurable.
> > 
> >  Makefile.am  |   3 +
> >  src/compositor-drm.c | 196 
> > ++-
> >  src/compositor.h |   2 -
> >  src/main.c   |  94 +++-
> >  4 files changed, 165 insertions(+), 130 deletions(-)
> 
> Hi Giulio and Bryce,
> 
> I'm sorry it has taken so long for me to come back to this.
> 
> > diff --git a/Makefile.am b/Makefile.am
> > index fe08d94..9330f0e 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -72,6 +72,7 @@ weston_SOURCES =  \
> > src/log.c   \
> > src/compositor.c\
> > src/compositor.h\
> > +   src/compositor-drm.h\
> > src/input.c \
> > src/data-device.c   \
> > src/screenshooter.c \
> > @@ -207,6 +208,7 @@ westonincludedir = $(includedir)/weston
> >  westoninclude_HEADERS =\
> > src/version.h   \
> > src/compositor.h\
> > +   src/compositor-drm.h\
> > src/timeline-object.h   \
> > shared/matrix.h \
> > shared/config-parser.h  \
> > @@ -276,6 +278,7 @@ drm_backend_la_CFLAGS = \
> > $(AM_CFLAGS)
> >  drm_backend_la_SOURCES =   \
> > src/compositor-drm.c\
> > +   src/compositor-drm.h\
> > $(INPUT_BACKEND_SOURCES)\
> > shared/helpers.h\
> > shared/timespec-util.h  \
> > diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> > index e01f6b9..111c882 100644
> > --- a/src/compositor-drm.c
> > +++ b/src/compositor-drm.c
> 
> > @@ -2185,30 +2162,45 @@ get_gbm_format_from_section(struct 
> > weston_config_section *section,
> >   * Find the most suitable mode to use for initial setup (or 
> > reconfiguration on
> >   * hotplug etc) for a DRM output.
> >   *
> > + * @param backend The DRM backend object
> >   * @param output DRM output to choose mode for
> > - * @param kind Strategy and preference to use when choosing mode
> > - * @param width Desired width for this output
> > - * @param height Desired height for this output
> > + * @param mode Controls how to select the mode
> > + * @param config Desired configuration for the output
> >   * @param current_mode Mode currently being displayed on this output
> > - * @param modeline Manually-entered mode (may be NULL)
> >   * @returns A mode from the output's mode list, or NULL if none available
> >   */
> >  static struct drm_mode *
> > -drm_output_choose_initial_mode(struct drm_output *output,
> > -  enum output_config kind,
> > -  int width, int height,
> > -  const drmModeModeInfo *current_mode,
> > -  const drmModeModeInfo *modeline)
> > +drm_output_choose_initial_mode(struct drm_backend *backend,
> > +  struct drm_output *output,
> > +  enum weston_drm_backend_output_mode mode,
> > +  struct weston_drm_backend_output_config *config,
> > +  const drmModeModeInfo *current_mode)
> >  {
> > struct drm_mode *preferred = NULL;
> > struct drm_mode *current = NULL;
> > struct drm_mode *configured = NULL;
> > struct drm_mode *best = NULL;
> > struct drm_mode *drm_mode;
> > +   drmModeModeInfo modeline;
> > +   int32_t width, height;
> > +
> > +   if (mode == WESTON_DRM_BACKEND_OUTPUT_PREFERRED && config->modeline) {
> > +   if (sscanf(config->modeline, "%dx%d", , ) != 2) {
> > +   width = -1;
> > +
> > +   if (parse_modeline(config->modeline, ) == 0) {
> > +   configured = drm_output_add_mode(output, 
> > );
> > +   if (!configured)
> > +   return NULL;
> > +   } else {
> > +   weston_log("Invalid modeline \"%s\" for output 
> > %s\n",
> > +  config->modeline, 

Re: [PATCH v5 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

[The Rasterman]

On Tue, 12 Apr 2016 15:25:36 + Mike Blumenkrantz
 said:

> Sure, that sounds good to me!

i like the idea of keeping < 0 invalid for now... it leaves wiggle room in
future to maybe make it valid and have special meaning but for now is invalid
thus can be assumed to not be used.

> On Tue, Apr 12, 2016 at 11:24 AM Olivier Fourdan 
> wrote:
> 
> > Hi Mike.
> >
> > > Okay, if we're not going with uints then at the least can the "use 0 to
> > > unset min/max" be changed to "use <= 0 to unset min/max" to explicitly
> > > cover that case?
> >
> > I think we should simply indicate that the width and height must be
> > greater than or equal to zero, so we remain consistent with the other
> > descriptions (namely set_window_geometry).
> >
> > Then we could also state that using strictly negative values would raise a
> > protocol error?
> >
> > Cheers,
> > Olivier
> >


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH libinput] test: add test for no scroll events before the scroll button timeout

[Peter Hutterer]

Signed-off-by: Peter Hutterer 
---
 src/evdev.c|  2 ++
 test/pointer.c | 31 +++
 2 files changed, 33 insertions(+)

diff --git a/src/evdev.c b/src/evdev.c
index f0311c6..a237ce6 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -280,6 +280,8 @@ evdev_post_trackpoint_scroll(struct evdev_device *device,
evdev_post_scroll(device, time,
  LIBINPUT_POINTER_AXIS_SOURCE_CONTINUOUS,
  );
+   /* if the button is down but scroll is not active, we're within the
+  timeout where swallow motion events but don't post scroll buttons */
 
return true;
 }
diff --git a/test/pointer.c b/test/pointer.c
index a34740a..8c7ad46 100644
--- a/test/pointer.c
+++ b/test/pointer.c
@@ -893,6 +893,36 @@ START_TEST(pointer_scroll_button)
 }
 END_TEST
 
+START_TEST(pointer_scroll_button_no_event_before_timeout)
+{
+   struct litest_device *device = litest_current_device();
+   struct libinput *li = device->libinput;
+   int i;
+
+   disable_button_scrolling(device);
+
+   libinput_device_config_scroll_set_method(device->libinput_device,
+   LIBINPUT_CONFIG_SCROLL_ON_BUTTON_DOWN);
+   libinput_device_config_scroll_set_button(device->libinput_device,
+BTN_LEFT);
+   litest_drain_events(li);
+
+   litest_button_click(device, BTN_LEFT, true);
+   litest_assert_empty_queue(li);
+
+   for (i = 0; i < 10; i++) {
+   litest_event(device, EV_REL, REL_Y, 1);
+   litest_event(device, EV_SYN, SYN_REPORT, 0);
+   }
+   litest_assert_empty_queue(li);
+
+   litest_timeout_buttonscroll();
+   libinput_dispatch(li);
+   litest_button_click(device, BTN_LEFT, false);
+   litest_assert_empty_queue(li);
+}
+END_TEST
+
 START_TEST(pointer_scroll_nowheel_defaults)
 {
struct litest_device *dev = litest_current_device();
@@ -1600,6 +1630,7 @@ litest_setup_tests(void)
litest_add_no_device("pointer:button", pointer_seat_button_count);
litest_add("pointer:scroll", pointer_scroll_wheel, LITEST_WHEEL, 
LITEST_TABLET);
litest_add("pointer:scroll", pointer_scroll_button, 
LITEST_RELATIVE|LITEST_BUTTON, LITEST_ANY);
+   litest_add("pointer:scroll", 
pointer_scroll_button_no_event_before_timeout, LITEST_RELATIVE|LITEST_BUTTON, 
LITEST_ANY);
litest_add("pointer:scroll", pointer_scroll_nowheel_defaults, 
LITEST_RELATIVE|LITEST_BUTTON, LITEST_WHEEL);
litest_add("pointer:scroll", pointer_scroll_natural_defaults, 
LITEST_WHEEL, LITEST_TABLET);
litest_add("pointer:scroll", pointer_scroll_natural_enable_config, 
LITEST_WHEEL, LITEST_TABLET);
-- 
2.5.5

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v5 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

[Olivier Fourdan]

> On 04/12/2016 08:17 AM, Olivier Fourdan wrote:
> [...]
> >
> > But that raise another point, what if the client itself specifies a
> > geometry (using set_window_geometry) outside of the min/max?
> >
> > I reckon that would be a protocol error as well. if so, I guess it means I
> > have to update the descriptions of set_window_geometry accordingly.
> 
> No, that is explicitly allowed.
> 
> It allows a client to say "I look best below this size, but if the
> compositor wants to fill a larger rectangle, I can draw something nicer
> than the compositor can do (the compositor can only pad or scale)".

That's something different, isn't it? The compositor sending a configure event 
and the size specified there must be obeyed by the client (as specified in the 
spec for maximize and fullscreen state, but the point of using min/max is 
precisely to let the compositor know that such states are not desirable for 
that given surface).

If the compositor insist of maximizing a window that has set a max size smaller 
than the output, then yes, the client must obey.a

> An example is a calculator that may want to continue expanding the
> output text area, while restricting the size of the buttons.

Err, that's the internal layout of the app, not something xdg-shell would 
interfere with, or I misunderstand you?

My point was more about the client itself setting min/max and then setting a 
geometry that falls outside of the limits it sets itself, I reckon that should 
be a protocol error, the client is sending incompatible requests to the 
compositor.

Cheers,
Olivier
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v5 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

[Mike Blumenkrantz]

Sure, that sounds good to me!

On Tue, Apr 12, 2016 at 11:24 AM Olivier Fourdan 
wrote:

> Hi Mike.
>
> > Okay, if we're not going with uints then at the least can the "use 0 to
> > unset min/max" be changed to "use <= 0 to unset min/max" to explicitly
> > cover that case?
>
> I think we should simply indicate that the width and height must be
> greater than or equal to zero, so we remain consistent with the other
> descriptions (namely set_window_geometry).
>
> Then we could also state that using strictly negative values would raise a
> protocol error?
>
> Cheers,
> Olivier
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v5 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

[Olivier Fourdan]

Hi Mike.

> Okay, if we're not going with uints then at the least can the "use 0 to
> unset min/max" be changed to "use <= 0 to unset min/max" to explicitly
> cover that case?

I think we should simply indicate that the width and height must be greater 
than or equal to zero, so we remain consistent with the other descriptions 
(namely set_window_geometry).

Then we could also state that using strictly negative values would raise a 
protocol error?

Cheers,
Olivier
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v5 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

[Olivier Fourdan]

> > > Good point. Setting an invalid state should probably result in a
> > > protocol error.
> > 
> > No this cannot be a protocol error because that makes it difficult to
> > change the size range to a new one that does not intersect the old one.
> > 
> > Perhaps having the commit of an invalid state be a protocol error is ok.
> 
> We'd reach an invalid state only once it's applied, ie after the commit.
> 
> So the client can (and must) set a Min <= Max before the commit, otherwise
> it's an invalid state that will lead to a protocol error.
> 
> That's what I've tried to specify in v6:
> 
>   Values set in this way are double-buffered. They will get applied
>   on the next commit.
> 
>   [...]
> 
>   Requesting a minimum size to be larger than the maximum size of
>   a surface is illegal and will result in a protocol error.

But that raise another point, what if the client itself specifies a geometry 
(using set_window_geometry) outside of the min/max?

I reckon that would be a protocol error as well. if so, I guess it means I have 
to update the descriptions of set_window_geometry accordingly.

Cheers,
Olivier
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v5 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

[Mike Blumenkrantz]

Okay, if we're not going with uints then at the least can the "use 0 to
unset min/max" be changed to "use <= 0 to unset min/max" to explicitly
cover that case?

On Tue, Apr 12, 2016 at 10:40 AM Olivier Fourdan 
wrote:

> Hi,
>
>
> > > Good point. Setting an invalid state should probably result in a
> > > protocol error.
> >
> > No this cannot be a protocol error because that makes it difficult to
> > change the size range to a new one that does not intersect the old one.
> >
> > Perhaps having the commit of an invalid state be a protocol error is ok.
>
> We'd reach an invalid state only once it's applied, ie after the commit.
>
> So the client can (and must) set a Min <= Max before the commit, otherwise
> it's an invalid state that will lead to a protocol error.
>
> That's what I've tried to specify in v6:
>
> Values set in this way are double-buffered. They will get applied
> on the next commit.
>
> [...]
>
> Requesting a minimum size to be larger than the maximum size of
> a surface is illegal and will result in a protocol error.
>
> Cheers,
> Olivier
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v5 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

[Olivier Fourdan]

Hi,


> > Good point. Setting an invalid state should probably result in a
> > protocol error.
> 
> No this cannot be a protocol error because that makes it difficult to
> change the size range to a new one that does not intersect the old one.
> 
> Perhaps having the commit of an invalid state be a protocol error is ok.

We'd reach an invalid state only once it's applied, ie after the commit.

So the client can (and must) set a Min <= Max before the commit, otherwise it's 
an invalid state that will lead to a protocol error.

That's what I've tried to specify in v6:

Values set in this way are double-buffered. They will get applied
on the next commit.

[...]

Requesting a minimum size to be larger than the maximum size of
a surface is illegal and will result in a protocol error.

Cheers,
Olivier
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH v6 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

[Olivier Fourdan]

Some application may wish to restrict their window in size, but
xdg-shell has no mechanism for the client to specify a maximum or
minimum size.

As a result, the compositor may try to maximize or fullscreen a window
while the client would not allow for the requested size.

Add new requests "set_max_size" and "set_min_size" to xdg-shell so that
the client can tell the compositor what would be its smallest/largest
acceptable size, and that the compositor can decide if maximize or
fullscreen is achievable, draw an accurate animation, etc.

Signed-off-by: Olivier Fourdan 
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764413
---
 v2: Rename the request to "set_preferred_max_size",
 add "set_preferred_min_size" as well
 v3: Rebase above patch 72427 in branch xdg-shell-unstable-v6
 Rephrase description to clarify the unscaled size and using 0 to
 reset back the preferred size to an unspecified state
 v4: Patch the correct xml file (v6, not v5 )
 Fix multiple mismatch of min/max in the description
 Remove mention of "unscaled", specify window geometry coordinates
 and refer to set_window_geometry.
 v5: Fix typos and remove "preferred" from the name and description as
 requested by several people on the ML and irc.
 v6: Specify the requests are double-buffered and require a commit,
 rephrase the values never set as suggested by Jasper, state
 that min > max is an invalid state and result in a protocol error
 as suggested by Bill, Yong and Jonas.
 
 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 66 
 1 file changed, 66 insertions(+)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index 3fc7d42..9d9923f 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -489,6 +489,72 @@
   
 
 
+
+  
+   Set a maximum size for the window.
+
+   The client can specify a maximum size so that the compositor does
+   not try to configure the window beyond this size.
+
+   The width and height arguments are in window geometry coordinates.
+   See set_window_geometry.
+
+   Values set in this way are double-buffered. They will get applied
+   on the next commit.
+
+   The compositor can use this information to allow or disallow
+   different states like maximize or fullscreen and draw accurate
+   animations.
+
+   Similarly, a tiling window manager may use this information to
+   place and resize client windows in a more effective way.
+
+   If never set, or a value of zero in the request, means that the
+   client has no expected maximum size in the given dimension.
+   As a result, a client wishing to reset the maximum size
+   to an unspecified state can use zero for width and height in the
+   request.
+
+   Requesting a maximum size to be smaller than the minimum size of
+   a surface is illegal and will result in a protocol error.
+  
+  
+  
+
+
+
+  
+   Set a minimum size for the window.
+
+   The client can specify a minimum size so that the compositor does
+   not try to configure the window below this size.
+
+   The width and height arguments are in window geometry coordinates.
+   See set_window_geometry.
+
+   Values set in this way are double-buffered. They will get applied
+   on the next commit.
+
+   The compositor can use this information to allow or disallow
+   different states like maximize or fullscreen and draw accurate
+   animations.
+
+   Similarly, a tiling window manager may use this information to
+   place and resize client windows in a more effective way.
+
+   If never set, or a value of zero in the request, means that the
+   client has no expected minimum size in the given dimension.
+   As a result, a client wishing to reset the minimum size
+   to an unspecified state can use zero for width and height in the
+   request.
+
+   Requesting a minimum size to be larger than the maximum size of
+   a surface is illegal and will result in a protocol error.
+  
+  
+  
+
+
 
   
Maximize the surface.
-- 
2.5.5

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v5 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

[Yong Bakos]

On Apr 12, 2016, at 2:22 AM, Jonas Ådahl  wrote:
> 
> On Tue, Apr 12, 2016 at 03:20:27AM -0400, Olivier Fourdan wrote:
>> Hi Mike,
>> 
>> - Original Message -
>>> I think this should probably use uint instead of int for params since zero
>>> is the "unset" number. Otherwise you have to write something about negative
>>> sizes.
>> 
>> Reason I used "int" is because these are limits for size, which are 
>> expressed with int as well. "set_window_geometry" uses "int" and specifies 
>> that width and height must be greater than zero.
>> 
>> Similarly, the configure event uses "int" as well, not uint", and also use 
>> zero for a special case (zero means the client should decide its own 
>> dimension) so it made sense to me to remain consistent by using "int".
>> 
>> But I can switch to uint if everyone agrees.
>> 
>> Cheers,
>> Olivier
> 
> I think using ints makes most sense. Lets not end up with a salad of
> different signedness for the same thing.
> 
> 
> Jonas

Just wanted to say that everyone's comments on this thread have been
educational for me, especially regarding the review process. I agree that
ints should be used since uints have not been used for width/height parameters
elsewhere in the Wayland core protocol.

But this begs a question, and please forgive my naïveté. Why aren't the
width/height arguments in the core protocol unsigned? Wouldn't this afford us
a little more type safety?

I also think that Bill's prior comment about min/max conflicts, despite double-
buffering, may deserve some attention in the documentation. In other words,
what does happen when the min and max conflict? Is it undefined, or should the
protocol state that the compositor should ignore such a conflict?

yong

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v5 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

[Jonas Ådahl]

On Tue, Apr 12, 2016 at 08:05:03AM -0500, Yong Bakos wrote:
> On Apr 12, 2016, at 2:22 AM, Jonas Ådahl  wrote:
> > 
> > On Tue, Apr 12, 2016 at 03:20:27AM -0400, Olivier Fourdan wrote:
> >> Hi Mike,
> >> 
> >> - Original Message -
> >>> I think this should probably use uint instead of int for params since zero
> >>> is the "unset" number. Otherwise you have to write something about 
> >>> negative
> >>> sizes.
> >> 
> >> Reason I used "int" is because these are limits for size, which are 
> >> expressed with int as well. "set_window_geometry" uses "int" and specifies 
> >> that width and height must be greater than zero.
> >> 
> >> Similarly, the configure event uses "int" as well, not uint", and also use 
> >> zero for a special case (zero means the client should decide its own 
> >> dimension) so it made sense to me to remain consistent by using "int".
> >> 
> >> But I can switch to uint if everyone agrees.
> >> 
> >> Cheers,
> >> Olivier
> > 
> > I think using ints makes most sense. Lets not end up with a salad of
> > different signedness for the same thing.
> > 
> > 
> > Jonas
> 
> Just wanted to say that everyone's comments on this thread have been
> educational for me, especially regarding the review process. I agree that
> ints should be used since uints have not been used for width/height parameters
> elsewhere in the Wayland core protocol.
> 
> But this begs a question, and please forgive my naïveté. Why aren't the
> width/height arguments in the core protocol unsigned? Wouldn't this afford us
> a little more type safety?

Because if x/y are ints and the x's and y's often needs to be combined
mathematically with the width's and height's. If we'd use different
signedness it'd be more error prone and confusing.

> 
> I also think that Bill's prior comment about min/max conflicts, despite 
> double-
> buffering, may deserve some attention in the documentation. In other words,
> what does happen when the min and max conflict? Is it undefined, or should the
> protocol state that the compositor should ignore such a conflict?

Good point. Setting an invalid state should probably result in a
protocol error.


Jonas

> 
> yong
> 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] ivi-layout : clear on_layer when layer_destroy

[Pekka Paalanen]

On Mon, 11 Apr 2016 21:34:52 +0900
Wataru Natsume  wrote:

> On_layer of ivi_layout_surface should be NULL in the layer_destroy.
> Previous code might access to removed ivilayer and cause SEGV.
> 
> Signed-off-by: Wataru Natsume 
> ---
>  ivi-shell/ivi-layout.c |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
> index 5c0e8f4..23e3269 100644
> --- a/ivi-shell/ivi-layout.c
> +++ b/ivi-shell/ivi-layout.c
> @@ -973,6 +973,7 @@ clear_surface_order_list(struct ivi_layout_layer 
> *ivilayer)
> >order.surface_list, order.link) {
>   wl_list_remove(_link->order.link);
>   wl_list_init(_link->order.link);
> + surface_link->on_layer = NULL;
>   }
>  }
>  

Hi,

layer_destroy seems to be an immediate action as opposed to needing a
commit, so looks good. Pushed:
   48fbb54..7b3a52a  master -> master


Thanks,
pq


pgpaGkJ_JeMbK.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] client: use the thread reader_count to fix deadlock.

[Daniel Stone]

Hi Boram,

On 8 April 2016 at 00:58, Boram Park  wrote:
> This patch solves the deadlock issue of the below scenario.
>
>   1. A thread polls several fds including the wayland's fd.
>   2. This thread probably calls wl_display_prepare_read() before polling
>  fds.
>   3. This thread could be awake by other event source which isn't related
>  with wayland fd.
>   4. After wake up, this thread could call wl_display_dispatch or
>  wl_display_roundtrip for sync operation.

This patch is not correct, and this is the reason why. If the Wayland
FD has no activity, then read_events should not be called (as it will
block), and cancel_read should be called instead.

>   5. Then, when this thread got a done event. this thread will stuck in
>  deadlock because this thread increases +2 reader_count in the same
>  thread.

The API definition of prepare_read is that it must be balanced with
read_events or cancel_read. If you call either read_events or
prepare_read - depending on whether or not the FD has activity -
before you attempt to dispatch/roundtrip, the reader_count will be
correct. This is as per the documentation in
wl_display_prepare_read_queue.

I would prefer not to support this usecase, for much the same reason
that nested mutexes are a very bad idea.

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] client: use the thread reader_count to fix deadlock.

[Boram Park]

This patch solves the deadlock issue of the below scenario.

  1. A thread polls several fds including the wayland's fd.
  2. This thread probably calls wl_display_prepare_read() before polling
 fds.
  3. This thread could be awake by other event source which isn't related
 with wayland fd.
  4. After wake up, this thread could call wl_display_dispatch or
 wl_display_roundtrip for sync operation.
  5. Then, when this thread got a done event. this thread will stuck in
 deadlock because this thread increases +2 reader_count in the same
 thread.

The read_event or cancel_read for the first prepare_read is not going to
happen because this thread sleeps by pthread_cond_wait() of read_event.

This problem can be solved by using the reader_count per thread.

The thread reader_count will be increased/decreased whenever prepare_read,
cancel_read and read_event are called.

However, the original display reader_count will be increased only once per
thread. And, when cancel_read and read_event are called, it will be
decreased for this thread to read event from fd and wake up other threads.
After that, if the thread reader_count is still more than 0, it will be
increased because it means this thread is still polling in somewhere.

Signed-off-by: Boram Park 
---
 src/wayland-client.c | 79 +++-
 1 file changed, 78 insertions(+), 1 deletion(-)

diff --git a/src/wayland-client.c b/src/wayland-client.c
index 33033e7..3b80dfa 100644
--- a/src/wayland-client.c
+++ b/src/wayland-client.c
@@ -77,6 +77,10 @@ struct wl_event_queue {
struct wl_display *display;
 };
 
+struct wl_thread_data {
+   int reader_count_in_thread;
+};
+
 struct wl_display {
struct wl_proxy proxy;
struct wl_connection *connection;
@@ -107,6 +111,8 @@ struct wl_display {
int reader_count;
uint32_t read_serial;
pthread_cond_t reader_cond;
+
+   pthread_key_t thread_data_key;
 };
 
 /** \endcond */
@@ -785,6 +791,31 @@ wl_proxy_marshal_array(struct wl_proxy *proxy, uint32_t 
opcode,
 }
 
 static void
+destroy_thread_data(void *data)
+{
+   struct wl_thread_data *thread_data = data;
+
+   free(thread_data);
+}
+
+static struct wl_thread_data*
+get_thread_data(struct wl_display *display)
+{
+   struct wl_thread_data *thread_data;
+
+   thread_data = pthread_getspecific(display->thread_data_key);
+   if (!thread_data) {
+   thread_data = zalloc(sizeof *thread_data);
+   if (!thread_data)
+   return NULL;
+   thread_data->reader_count_in_thread = 0;
+   pthread_setspecific(display->thread_data_key, thread_data);
+   }
+
+   return thread_data;
+}
+
+static void
 display_handle_error(void *data,
 struct wl_display *display, void *object,
 uint32_t code, const char *message)
@@ -905,6 +936,7 @@ WL_EXPORT struct wl_display *
 wl_display_connect_to_fd(int fd)
 {
struct wl_display *display;
+   struct wl_thread_data *thread_data;
const char *debug;
 
debug = getenv("WAYLAND_DEBUG");
@@ -960,6 +992,13 @@ wl_display_connect_to_fd(int fd)
if (display->connection == NULL)
goto err_connection;
 
+   if (pthread_key_create(>thread_data_key, destroy_thread_data) 
< 0)
+   goto err_connection;
+
+   thread_data = get_thread_data(display);
+   if (!thread_data)
+   goto err_connection;
+
return display;
 
  err_connection:
@@ -1023,6 +1062,12 @@ wl_display_connect(const char *name)
 WL_EXPORT void
 wl_display_disconnect(struct wl_display *display)
 {
+   struct wl_thread_data *thread_data;
+
+   thread_data = get_thread_data(display);
+   free(thread_data);
+   pthread_key_delete(display->thread_data_key);
+
wl_connection_destroy(display->connection);
wl_map_release(>objects);
wl_event_queue_release(>default_queue);
@@ -1297,9 +1342,14 @@ dispatch_event(struct wl_display *display, struct 
wl_event_queue *queue)
 static int
 read_events(struct wl_display *display)
 {
+   struct wl_thread_data *thread_data;
int total, rem, size;
uint32_t serial;
 
+   thread_data = get_thread_data(display);
+   assert(thread_data);
+
+   thread_data->reader_count_in_thread--;
display->reader_count--;
if (display->reader_count == 0) {
total = wl_connection_read(display->connection);
@@ -1309,6 +1359,9 @@ read_events(struct wl_display *display)
 * the reader_count dropped to 0 */
display_wakeup_threads(display);
 
+   if (thread_data->reader_count_in_thread > 0)
+   display->reader_count++;
+
return 0;
}
 
@@ -1346,15 +1399,30 @@ 

Allow easy disabling of PRIMARY selection thru configuration?

[Jeremy Morton]

One of the long-term bugbears of users coming to Linux from just about 
any other GUI is the existence of two totally separate clipboards; the 
PRIMARY selection and the CLIPBOARD selection.  I doubt I'm gonna get 
the default behaviour changed, even though I think this default is 
terribly confusing.  However, how about we at least allow easy 
configuration of this through some settings in /etc?


As far as I understand it, X11 is responsible for the double-clipboard 
behaviour so X11 (or Wayland) is where it needs to be configurable.  I 
propose this: provide easy configuration of Wayland that allows the 
PRIMARY selection to be silently ignored.  When text is selected, 
Wayland will acknowledge to the application ownership of PRIMARY, and 
silently drop the content.  It will not inform other programs that 
PRIMARY has been taken ownership of, so other programs will not (IMHO 
unintuitively) deselect their selections.  When it comes to pasting 
from PRIMARY (ie. via middle-click), Wayland will paste from the 
CLIPBOARD selection instead of PRIMARY.


Would this be feasible?  It would finally allow Windows-style 
clipboard behaviour and satisfy many users (myself included).


--
Best regards,
Jeremy Morton (Jez)
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] weston-info: do not round refresh rates

[Pekka Paalanen]

On Tue, 12 Apr 2016 10:23:54 +0200
Quentin Glidic  wrote:

> On 12/04/2016 10:13, Pekka Paalanen wrote:
> > From: Pekka Paalanen 
> >
> > Weston-info was accidentally rounding refresh rates to integer Hz.
> >
> > Fix it to print 3 decimals, as the protocol carries exactly that.
> >
> > Reported-by: Michel Dänzer 
> > Cc: John Galt 
> > Signed-off-by: Pekka Paalanen 
> > ---
> >  clients/weston-info.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/clients/weston-info.c b/clients/weston-info.c
> > index 8ba80c0..aa81816 100644
> > --- a/clients/weston-info.c
> > +++ b/clients/weston-info.c
> > @@ -226,7 +226,7 @@ print_output_info(void *data)
> > wl_list_for_each(mode, >modes, link) {
> > printf("\tmode:\n");
> >
> > -   printf("\t\twidth: %d px, height: %d px, refresh: %.f Hz,\n",
> > +   printf("\t\twidth: %d px, height: %d px, refresh: %.3f Hz,\n",
> >mode->width, mode->height,
> >(float) mode->refresh / 1000);
> >
> >  
> 
> Trivial enough, LGTM.
> Reviewed-by: Quentin Glidic 

Plus Michel's R-b from IRC.

Pushed:
   265aeb3..48fbb54  master -> master


Thanks,
pq


pgpGA8auZNI0L.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] weston-info: do not round refresh rates

[Quentin Glidic]

On 12/04/2016 10:13, Pekka Paalanen wrote:

From: Pekka Paalanen 

Weston-info was accidentally rounding refresh rates to integer Hz.

Fix it to print 3 decimals, as the protocol carries exactly that.

Reported-by: Michel Dänzer 
Cc: John Galt 
Signed-off-by: Pekka Paalanen 
---
 clients/weston-info.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/clients/weston-info.c b/clients/weston-info.c
index 8ba80c0..aa81816 100644
--- a/clients/weston-info.c
+++ b/clients/weston-info.c
@@ -226,7 +226,7 @@ print_output_info(void *data)
wl_list_for_each(mode, >modes, link) {
printf("\tmode:\n");

-   printf("\t\twidth: %d px, height: %d px, refresh: %.f Hz,\n",
+   printf("\t\twidth: %d px, height: %d px, refresh: %.3f Hz,\n",
   mode->width, mode->height,
   (float) mode->refresh / 1000);




Trivial enough, LGTM.
Reviewed-by: Quentin Glidic 

--

Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston] weston-info: do not round refresh rates

[Pekka Paalanen]

From: Pekka Paalanen 

Weston-info was accidentally rounding refresh rates to integer Hz.

Fix it to print 3 decimals, as the protocol carries exactly that.

Reported-by: Michel Dänzer 
Cc: John Galt 
Signed-off-by: Pekka Paalanen 
---
 clients/weston-info.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/clients/weston-info.c b/clients/weston-info.c
index 8ba80c0..aa81816 100644
--- a/clients/weston-info.c
+++ b/clients/weston-info.c
@@ -226,7 +226,7 @@ print_output_info(void *data)
wl_list_for_each(mode, >modes, link) {
printf("\tmode:\n");
 
-   printf("\t\twidth: %d px, height: %d px, refresh: %.f Hz,\n",
+   printf("\t\twidth: %d px, height: %d px, refresh: %.3f Hz,\n",
   mode->width, mode->height,
   (float) mode->refresh / 1000);
 
-- 
2.7.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v5 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

[Olivier Fourdan]

Hi Jasper,

- Original Message -
> I figured min/max would be double-buffered state and require a commit
> to take affect. In fact, anything else means that we can't extend with
> additional size constraints in the future, since they couldn't be
> applied atomically.

Completely agree, I'll add a note similar to the one from "set_window_geometry" 
to make it clear it's double-buffered and applied on the next commit.

Cheers,
Olivier
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v5 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

[Jonas Ådahl]

On Tue, Apr 12, 2016 at 03:20:27AM -0400, Olivier Fourdan wrote:
> Hi Mike,
> 
> - Original Message -
> > I think this should probably use uint instead of int for params since zero
> > is the "unset" number. Otherwise you have to write something about negative
> > sizes.
> 
> Reason I used "int" is because these are limits for size, which are expressed 
> with int as well. "set_window_geometry" uses "int" and specifies that width 
> and height must be greater than zero.
> 
> Similarly, the configure event uses "int" as well, not uint", and also use 
> zero for a special case (zero means the client should decide its own 
> dimension) so it made sense to me to remain consistent by using "int".
> 
> But I can switch to uint if everyone agrees.

I think using ints makes most sense. Lets not end up with a salad of
different signedness for the same thing.


Jonas

> 
> Cheers,
> Olivier
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v5 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

[Olivier Fourdan]

Hi Mike,

- Original Message -
> I think this should probably use uint instead of int for params since zero
> is the "unset" number. Otherwise you have to write something about negative
> sizes.

Reason I used "int" is because these are limits for size, which are expressed 
with int as well. "set_window_geometry" uses "int" and specifies that width and 
height must be greater than zero.

Similarly, the configure event uses "int" as well, not uint", and also use zero 
for a special case (zero means the client should decide its own dimension) so 
it made sense to me to remain consistent by using "int".

But I can switch to uint if everyone agrees.

Cheers,
Olivier
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput] test: set the umask before msktemp to silence coverity

[Hans de Goede]

Hi,

On 12-04-16 07:11, Peter Hutterer wrote:

Signed-off-by: Peter Hutterer 


Reviewed-by: Hans de Goede 

Regards,

Hans



---
  test/path.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/test/path.c b/test/path.c
index 7d7c445..729ad86 100644
--- a/test/path.c
+++ b/test/path.c
@@ -28,6 +28,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 

  #include "litest.h"
@@ -131,6 +132,7 @@ START_TEST(path_create_invalid_file)
char path[] = "/tmp/litest_path_XX";
int fd;

+   umask(002);
fd = mkstemp(path);
ck_assert_int_ge(fd, 0);
close(fd);


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel