[PATCH weston] Support axis source, axis discreet, axis frame and axis stop events

[Peter Hutterer]

Signed-off-by: Peter Hutterer 
---
The client-side is the simplest implementation here, and I went the easy
route since most clients won't care to register a multitude of handlers for
axis events.

The eventdemo client merely prints the events, it doesn't accumulate them as
they should be. That'd be the job of a slightly more sophisticated toolkit.

Possibly contentious: there's no notify_axis_stop(), it's folded into
notify_axis(). Easy fix if needed.

Also, I recommend not merging this one until we have a test implementation
in mutter + GTK to make sure the protocol is sane enough to use from complex
clients.

 clients/eventdemo.c  | 55 -
 clients/window.c | 91 +++-
 clients/window.h | 28 +++
 src/compositor-wayland.c | 39 +
 src/compositor-x11.c | 16 ++---
 src/compositor.h | 10 ++
 src/input.c  | 74 ++-
 src/libinput-device.c| 63 +++--
 8 files changed, 360 insertions(+), 16 deletions(-)

diff --git a/clients/eventdemo.c b/clients/eventdemo.c
index bdad6fd..f520233 100644
--- a/clients/eventdemo.c
+++ b/clients/eventdemo.c
@@ -259,6 +259,54 @@ axis_handler(struct widget *widget, struct input *input, 
uint32_t time,
   wl_fixed_to_double(value));
 }
 
+static void
+axis_frame_handler(struct widget *widget, struct input *input, void *data)
+{
+   printf("axis frame\n");
+}
+
+static void
+axis_source_handler(struct widget *widget, struct input *input,
+   uint32_t source, void *data)
+{
+   const char *axis_source;
+
+   switch (source) {
+   case WL_POINTER_AXIS_SOURCE_WHEEL:
+   axis_source = "wheel";
+   break;
+   case WL_POINTER_AXIS_SOURCE_FINGER:
+   axis_source = "finger";
+   break;
+   case WL_POINTER_AXIS_SOURCE_CONTINUOUS:
+   axis_source = "continuous";
+   break;
+   default:
+   axis_source = "";
+   break;
+   }
+
+   printf("axis source: %s\n", axis_source);
+}
+
+static void
+axis_stop_handler(struct widget *widget, struct input *input,
+ uint32_t time, uint32_t axis,
+ void *data)
+{
+   printf("axis stop time: %d, axis: %s\n",
+  time,
+  axis == WL_POINTER_AXIS_VERTICAL_SCROLL ? "vertical" :
+"horizontal");
+}
+
+static void
+axis_discrete_handler(struct widget *widget, struct input *input,
+ int32_t discrete, void *data)
+{
+   printf("axis discrete value: %d\n", discrete);
+}
+
 /**
  * \brief CALLBACK function, Waylands informs about pointer motion
  * \param widget widget
@@ -348,7 +396,12 @@ eventdemo_create(struct display *d)
widget_set_motion_handler(e->widget, motion_handler);
 
/* Set the callback axis handler for the window */
-   widget_set_axis_handler(e->widget, axis_handler);
+   widget_set_axis_handlers(e->widget,
+axis_handler,
+axis_frame_handler,
+axis_source_handler,
+axis_stop_handler,
+axis_discrete_handler);
 
/* Initial drawing of the window */
window_schedule_resize(e->window, width, height);
diff --git a/clients/window.c b/clients/window.c
index 6d3e944..121037b 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -288,6 +288,10 @@ struct widget {
widget_touch_frame_handler_t touch_frame_handler;
widget_touch_cancel_handler_t touch_cancel_handler;
widget_axis_handler_t axis_handler;
+   widget_axis_frame_handler_t axis_frame_handler;
+   widget_axis_source_handler_t axis_source_handler;
+   widget_axis_stop_handler_t axis_stop_handler;
+   widget_axis_discrete_handler_t axis_discrete_handler;
void *user_data;
int opaque;
int tooltip_count;
@@ -1935,6 +1939,21 @@ widget_set_axis_handler(struct widget *widget,
widget->axis_handler = handler;
 }
 
+void
+widget_set_axis_handlers(struct widget *widget,
+   widget_axis_handler_t axis_handler,
+   widget_axis_frame_handler_t axis_frame_handler,
+   widget_axis_source_handler_t axis_source_handler,
+   widget_axis_stop_handler_t axis_stop_handler,
+   widget_axis_discrete_handler_t axis_discrete_handler)
+{
+   widget->axis_handler = axis_handler;
+   widget->axis_frame_handler = axis_frame_handler;
+   widget->axis_source_handler = axis_source_handler;
+   widget->axis_stop_handler = axis_stop_handler;
+   widget->axis_discrete_handler = axis_discrete_handler;
+}
+
 static void
 window_schedule_redraw_task(struct 

[PATCH v4 wayland] protocol: add wl_pointer.axis_source, axis_stop, axis_discrete and axis_frame

[Peter Hutterer]

The axis_source event determines how an axis event was generated. That 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.

To axis_frame event groups separate vertical/horizontal scroll events
together. Likewise it enables axis_stop events to be grouped so that the final
vector for kinetic scrolling may be calculated correctly.

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. The
wl_pointer.axis_frame trails the wl_pointer.axis event and groups any
preceeding events together.

i.e. a sequence may be:

wl_pointer.axis_source
wl_pointer.axis
wl_pointer.axis
wl_pointer.axis_frame
wl_pointer.axis_source
wl_pointer.axis
wl_pointer.axis_frame
wl_pointer.axis_source
wl_pointer.axis
wl_pointer.axis_frame
wl_pointer.axis_source
wl_pointer.axis_stop
wl_pointer.axis_stop
wl_pointer.axis_frame

Note how the first set includes two axis events, with the same source, the
second and third set include a single axis change each, the last frame stops
both axis movements in the same frame.

With wl_pointer.axis_discrete added, a single event may look like this:

wl_pointer.axis_source
wl_pointer.axis_discrete
wl_pointer.axis_axis
wl_pointer.axis_frame

Clients need to combine the state of all events where needed.

Signed-off-by: Peter Hutterer 
---
Changes to v3:
- axis_stop contains a single axis rather than the array of axes stopped.
  This makes it effectively equivalent to axis, and with the axis_frame
  event we don't need the array, it's simpler to send multiple events.
- added more documentation, see
  http://lists.freedesktop.org/archives/wayland-devel/2015-July/023324.html
- squashed the patch for axis source/discrete/stop together with the patch
  adding axis frame events, updated the commit message accordingly.
- xml fix, axis_discrete had the args inside the  tag
- actually implemented this version in weston, see follow-up patch :)

 protocol/wayland.xml | 124 +--
 1 file changed, 121 insertions(+), 3 deletions(-)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index 59819e9..c321b59 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,127 @@
   
 
 
+
+
+  
+   Indicates the end of a set of wl_pointer.axis events that logically
+   belong together.
+
+   All wl_pointer.axis, wl_pointer.axis_stop, and
+   wl_pointer.axis_source before a wl_pointer.axis_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) and finally a
+   wl_pointer.axis_frame event. The client may use this information to
+   calculate a diagonal vector for scrolling.
+
+   When multiple wl_pointer.axis events occur within the same frame,
+   the motion vector is the combined motion of all events.
+   When a wl_pointer.axis and a wl_pointer.axis_stop event occur within
+   the same frame, this indicates that axis movement in one axis has
+   stopped but continues in the other axis.
+   When multiple wl_pointer.axis_stop events occur within in the same
+   frame, this indicates that these axes stopped in the same instance.
+
+   Only one wl_pointer.axis_source event is permitted per axis frame.
+
+   A wl_pointer.axis_frame event is sent for every logical axis event
+   group, even if the group only contains a single wl_pointer.axis or
+   wl_pointer.axis_stop event. In other words, a client may get the
+   sequence: axis, axis_frame, axis, axis_frame, ...
+  
+
+
+
+  
+   Describes the source types for axis events. This indicates to the
+   client how an axis event was physically generated; a client may
+   adjust the user interface accordingly. For example, scroll events
+   from a "finger" source may be in a smooth coordinate space with
+   kinetic scrolling whereas a "wheel" source may be in discrete steps
+   of a number of lines.
+
+   The "continous" axis source is a device generating events in a
+   continuous coordinate space, but using something other than a
+   finger. One example for this source is button-based scr

Re: [PATCH wayland v2] Remove protocol/wayland.dtd

[Peter Hutterer]

On Fri, Oct 09, 2015 at 01:16:49PM +0200, Nils Chr. Brause wrote:
> Hi,
> 
> Reviewed-by: Nils Christopher Brause 
> 
> I ran distcheck and it worked. :)

a bit late, but I would like to register my disagreement with this patch :)

Having the DTD is a much simpler and less bug-prone description of what the
protocol should look like. Having the scanner define the protocol means the
protocol is whatever the current version of the scanner supports, which is
not a good contract.

I'd argue for reverting this and fixing any mismatch if there is one. And
using the DTD to validate before the scanner even runs.

Cheers,
   Peter

> On Fri, Oct 9, 2015 at 10:01 AM, Auke Booij  wrote:
> > Yeah, that was a pretty embarrassing mistake by me, for such a simple
> > patch. Thanks to Bryce for catching it.
> >
> > On 8 October 2015 at 15:05, Pekka Paalanen  wrote:
> >> On Thu,  8 Oct 2015 14:35:34 +0100
> >> Auke Booij  wrote:
> >>
> >>> The wayland scanner defines the protocol. The DTD specification is not 
> >>> used.
> >>> ---
> >>>  Makefile.am  |  4 ++--
> >>>  protocol/wayland.dtd | 29 -
> >>>  2 files changed, 2 insertions(+), 31 deletions(-)
> >>>  delete mode 100644 protocol/wayland.dtd
> >>
> >> Reviewed-by: Pekka Paalanen 
> >>
> >> No, I didn't run distcheck this time either. ;-)
> >>
> >>
> >> Thanks,
> >> pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [weston] Terminal client could not open window

[Bryce Harrington]

On Tue, Oct 13, 2015 at 03:23:12PM +0200, Joaquim Duran wrote:
> This is the backtrace but not much information is provided:
> 
> Starting program: /usr/var/lib/weston-fullscreen
> [Thread debugging using libthread_db enabled]
> [New Thread 0x40105000 (LWP 325)]
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x40105000 (LWP 325)]
> 0x0008 in ?? ()
> (gdb) where
> #0  0x0008 in ?? ()
> #1  0x0006 in ?? ()
> #2  0x0006 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Try 'bt full'?

> Joaquim Duran
> 
> 
> 2015-10-13 14:58 GMT+02:00 Joaquim Duran :
> > Pekka,
> >
> > Thanks for your information. I've compiled simple clients and I've
> > executed fullscreen clients:
> >
> > DM-37x# ./weston-fullscreen
> > Segmentation fault
> >
> > And finishes with a segmentation fault. I'll rerun with debug
> > information to provide more information.
> >
> >
> > 2015-10-13 14:37 GMT+02:00 Pekka Paalanen :
> >> On Tue, 13 Oct 2015 14:26:21 +0200
> >> Joaquim Duran  wrote:
> >>
> >>> Hello,
> >>>
> >>> We could execute the Weston compositor (using fbdev backend) in a
> >>> terminal, we could execute the weston-info client and it prints
> >>> information, however when we execute the weston-terminal client, it
> >>> couldn't open a window on the compositor.
> >>>
> >>> We start the Weston compositor in a terminal:
> >>>
> >>> mkdir -p /var/lib/xdg
> >>> chmod 0700 /var/lib/xdg
> >>> export XDG_RUNTIME_DIR=/var/lib/xdg
> >>> mkdir -p /usr/share/X11/xkb
> >>>
> >>> weston --tty=1 --backend=fbdev-backend.so --shell=fullscreen-shell.so
> >>> Date: 2015-10-13 UTC
> >>> [14:16:17.765] weston 1.9.0
> >>>http://wayland.freedesktop.org
> >>>Bug reports to:
> >>> https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=weston&version=1.9.0
> >>>Build: 1.9.0 configure.ac: bump to version 1.9.0 for
> >>> the official release (2015-09-21 18:11:26 -0700)
> >>> [14:16:17.772] OS: Linux, 3.0.101-BSP-dm37x-2.4-4, #33 Tue Oct 13
> >>> 12:33:51 CEST 2015, armv7l
> >>> [14:16:17.777] Starting with no config file.
> >>> [14:16:17.781] Loading module '/usr/lib/weston/fbdev-backend.so'
> >>> [14:16:17.810] Output repaint window is 7 ms maximum.
> >>> [14:16:17.814] initializing fbdev backend
> >>> [14:16:17.820] Creating fbdev output.
> >>> [14:16:17.823] Opening fbdev frame buffer.
> >>> [14:16:17.826] Calculating pixman format from:
> >>> - type: 0 (aux: 0)
> >>> - visual: 2
> >>> - bpp: 32 (grayscale: 0)
> >>> - red: offset: 16, length: 8, MSB: 0
> >>> - green: offset: 8, length: 8, MSB: 0
> >>> - blue: offset: 0, length: 8, MSB: 0
> >>> - transp: offset: 0, length: 0, MSB: 0
> >>> [14:16:17.829] Mapping fbdev frame buffer.
> >>> [14:16:17.834] fbdev output 800×600 px
> >>>guessing 60 Hz and 96 dpi
> >>> [14:16:17.863] input device 'NOVATEK USB Keyboard', /dev/input/event2
> >>> is tagged by udev as: Keyboard
> >>> [14:16:17.866] input device 'NOVATEK USB Keyboard', /dev/input/event2
> >>> is a keyboard
> >>> [14:16:17.881] input device 'NOVATEK USB Keyboard', /dev/input/event3
> >>> is tagged by udev as: Keyboard
> >>> [14:16:17.884] input device 'NOVATEK USB Keyboard', /dev/input/event3
> >>> is a keyboard
> >>> [14:16:17.898] input device 'twl4030_pwrbutton', /dev/input/event1 is
> >>> tagged by udev as: Keyboard
> >>> [14:16:17.900] input device 'twl4030_pwrbutton', /dev/input/event1 is a 
> >>> keyboard
> >>> [14:16:17.914] input device 'ft5x06-i2c', /dev/input/event0 is tagged
> >>> by udev as: Keyboard Touchscreen
> >>> [14:16:17.918] input device 'ft5x06-i2c', /dev/input/event0 is a keyboard
> >>> [14:16:17.921] input device 'ft5x06-i2c', /dev/input/event0 is a touch 
> >>> device
> >>> [14:16:17.931] Compositor capabilities:
> >>>arbitrary surface rotation: yes
> >>>screen capture uses y-flip: yes
> >>>presentation clock: CLOCK_MONOTONIC_RAW, id 4
> >>> [14:16:17.940] Loading module '/usr/lib/weston/fullscreen-shell.so'
> >>
> >> Hi,
> >>
> >> you are using the fullscreen-shell.so, so this is not a bug.
> >> weston-terminal (clients/window.c to be more specific) does not
> >> implement support for the fullscreen-shell.
> >>
> >> You have to either use a program specifically written to use the
> >> fullscreen-shell protocol, or use desktop-shell.so instead.
> >>
> >> Grep for _wl_fullscreen to see which Weston demo programs support
> >> running on fullscreen-shell.
> >>
> >> weston-info is different, because it never even tries to create a
> >> window. The shell protocol is needed to properly create and show a
> >> window.
> >>
> >> (Your other bug reports do look valid at first hand.)
> >>
> >>
> >> Thanks,
> >> pq
> ___
> wayland-devel mailing list
> wayland-devel@lists.freed

Re: [weston] xkbcommon library is not optional.

[Bryce Harrington]

On Tue, Oct 13, 2015 at 01:59:13PM +0200, Joaquim Duran wrote:
> Hello,
> 
> When configuring the Weston project, it is possible to disable (don't
> include) the library libxkbcommon. To compile Weston successfully,
> even if the option --disable-xkbcommon is specified, the library must
> be installed because the file src/compositor.h requires it.

Joaquim, good find.

From the comments in configure.ac:

  AS_HELP_STRING([--disable-xkbcommon], [Disable libxkbcommon
  support: This is only useful in environments
  where you do not have a hardware keyboard. If
  libxkbcommon support is disabled clients will not
  be sent a keymap and and must know how to
  interpret the keycode sent for any key event.]),,

So it sounds like this is a special case that is intended to work.

The header include was from commit 855028fe three years ago, while the
--disable-xkbcommon was added by 382ff46f just two years ago.  That
makes me think that your situation was simply overlooked.

If that's true, then presumably the fix would involve peppering
compositor.* and other files with tests like,

#ifdef ENABLE_XKBCOMMON
...
#endif

For example it looks like the weston_xkb_info struct would need to
either be removed or stubbed out, and users of it be disabled.  There
are also some weston calls that use xkb_keymap, xkb_rule_names,
etc. structures for params that'd need addressed.

On the face of it, seems like it could be a fair amount of work, and a
bit invasive, but maybe there's some tricks to make it simpler
(typedeffing the unsupported struct args and so on.)

Alternatively, --disable-xkbcommon could be dropped.  However I get the
sense it actually solves a real world need, and functional regression is
rarely a good idea.

Would you mind filing a bug report about this?  At the least we probably
ought to at least fix the documentation, to admit the fact if xkbcommon
still needs to be present.

Is this a situation that affects what you're working on, or just
something you noticed via analysis?  If the former, would you be open to
working on a patch to address it?

Bryce

> Some code of file src/compositor.h should only be compiled if
> xkbcommon library is enabed, but this is not the case. Here I include
> some lines from that file:
> 
> 
> 34 #include 
> 35 #include 
> 36 #include 
> 37 #include<--- Always included
> 
> 450
> 451 struct weston_xkb_info {  <--- Always compiled
> 452 struct xkb_keymap *keymap;
> 453 int keymap_fd;
> 454 size_t keymap_size;
> 455 char *keymap_area;
> 456 int32_t ref_count;
> 457 xkb_mod_index_t shift_mod;
> 458 xkb_mod_index_t caps_mod;
> 459 xkb_mod_index_t ctrl_mod;
> 460 xkb_mod_index_t alt_mod;
> 461 xkb_mod_index_t mod2_mod;
> 462 xkb_mod_index_t mod3_mod;
> 463 xkb_mod_index_t super_mod;
> 464 xkb_mod_index_t mod5_mod;
> 465 xkb_led_index_t num_led;
> 466 xkb_led_index_t caps_led;
> 467 xkb_led_index_t scroll_led;
> 468 };
> 469
> 
> 
> Configuration of weston:
> 
> ./autogen.sh \
> --disable-devdocs \
> --disable-dbus \
> --disable-xwayland \
> --disable-xwayland-test \
> --disable-x11-compositor \
> --disable-drm-compositor \
> --disable-wayland-compositor \
> --disable-headless-compositor \
> --disable-rpi-compositor \
> --enable-fbdev-compositor \
> --disable-rdp-compositor \
> --disable-weston-launch \
> --disable-wcap-tools \
> --with-cairo=image \
> --disable-xkbcommon \
> --enable-clients \
> --disable-simple-clients \
> --disable-simple-egl-clients \
> --build=i686-linux --host=arm-none-linux-gnueabi
> --target=arm-none-linux-gnueabi \
> --prefix=$INSTALL_DIR --with-sysroot=${SYSROOT_DIR}
> 
> 
> Error:
> 
> gem-med@gemmed-VirtualBox:~/Logic_BSPs/Linux_3.0/src/weston$ make
> make  all-am
> make[1]: Entering directory `/home/gem-med/Logic_BSPs/Linux_3.0/src/weston'
>   CC src/gl_renderer_la-gl-renderer.lo
> cc1: warning: include location "/usr/include/libdrm" is unsafe for
> cross-compilation [-Wpoison-system-directories]
> In file included from src/gl-renderer.h:28:0,
>  from src/gl-renderer.c:41:
> src/compositor.h:37:33: fatal error: xkbcommon/xkbcommon.h: No such
> file or directory
> compilation terminated.
> make[1]: *** [src/gl_renderer_la-gl-renderer.lo] Error 1
> make[1]: Leaving directory `/home/gem-med/Logic_BSPs/Linux_3.0/src/weston'
> make: *** [all] Error 2
> 
> Joaquim Duran
> ___
> 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.

Re: [PATCH] configure: Up the libwayland version requirement

[Bryce Harrington]

On Thu, Oct 15, 2015 at 11:34:50AM +0300, Pekka Paalanen wrote:
> On Wed, 14 Oct 2015 20:22:18 -0500
> Derek Foreman  wrote:
> 
> > On 14/10/15 05:40 PM, Bryce Harrington wrote:
> > > weston commit f7bb9352 requires recent libwayland changes for providing
> > > ‘WL_POINTER_RELEASE_SINCE_VERSION’.  Increase the version requirement to
> > > indicate that current weston git requires development version of
> > > wayland.
> > > 
> > > NOTE: At release we should probably increase the wayland requirement for
> > > weston to 1.10.0.
> > > 
> > > Signed-off-by: Bryce Harrington 
> > 
> > Turns a compile time barf into a configure time one, at least for anyone
> > trying to build a git weston with a stable wayland right now...
> > 
> > Reviewed-by: Derek Foreman 

Pushed

remote: Updating patchwork state for 
http://patchwork.freedesktop.org/project/wayland/list/
remote: I: patch #61896 updated using rev 
c6e6dc78c1ed2ac28a76c5724e7f3f067f1b2214
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/wayland/weston
   ae2541d..c6e6dc7  master -> master


> > > ---
> > >  configure.ac | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/configure.ac b/configure.ac
> > > index 67e80d0..e5afbc0 100644
> > > --- a/configure.ac
> > > +++ b/configure.ac
> > > @@ -59,7 +59,7 @@ AC_CHECK_HEADERS([execinfo.h])
> > >  
> > >  AC_CHECK_FUNCS([mkostemp strchrnul initgroups posix_fallocate])
> > >  
> > > -COMPOSITOR_MODULES="wayland-server >= 1.9.0 pixman-1 >= 0.25.2"
> > > +COMPOSITOR_MODULES="wayland-server >= 1.9.90 pixman-1 >= 0.25.2"
> > >  
> > >  AC_CONFIG_FILES([doc/doxygen/tools.doxygen doc/doxygen/tooldev.doxygen])
> > >  
> > > @@ -317,7 +317,7 @@ AC_SUBST(JPEG_LIBS)
> > >  
> > >  PKG_CHECK_MODULES(CAIRO, [cairo])
> > >  
> > > -PKG_CHECK_MODULES(TEST_CLIENT, [wayland-client >= 1.9.0])
> > > +PKG_CHECK_MODULES(TEST_CLIENT, [wayland-client >= 1.9.90])
> > >  
> > >  AC_ARG_ENABLE(simple-clients,
> > >AS_HELP_STRING([--disable-simple-clients],
> 
> I see configure.ac has two wayland-server and nine wayland-client
> pkg-config references. The two you bump are the ones that are
> unconditionally required, AFAICT.
> 
> Reviewed-by: Pekka Paalanen 
> 
> 
> Thanks,
> pq

> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> 
> iQIVAwUBVh9lNiNf5bQRqqqnAQjxyA//YZRS5NoM7ZEkc9NAQheqbjIqQmu8ZPE4
> kAzf/Y7JFygDnSezURrzleD0ETUYw6xMQvMHIM12TaHHPuNoYMVJ+A05DL9LuA3B
> ygqesDd2JqvdScTHpPGnYFMHCdtyH1lt/yZwtz4H+r4Ya8NFrxpxTssZ3BBt1lDL
> IaQFIkwyplujuSmCvUL8I2rNjESiokqRqptWUSeJwR68wsDqeB7DvIWxyX8pKYsK
> 1AXkaxJQrkbtQO/Xda5rgLP6d5QYGDOPRcjxji9StsnL0a3kX1sApX1DcKOnThyG
> bg2H/BiEYMxPeaRQ2XTgY5v5EkfpkUBk/ace03Ws4prINyvFsb+ujj6OwJktbunj
> 9CzYLNiWfw6LCLJs8/4sd/r05LBzeDVbkj9g6eDKI7ZbZhF7dANQ5SPvc0/AgvfD
> 36/4uNbrenoUnhcrai3hJCgQqDK7TLpnUJiVEE3adh3DWYnJ47pqdS9CI+TzyqUg
> 8J8ePAQA4e5ffL7cTlAUJs8pOy7FfQJWV77+j/xYyx3fg70j3zyp9cmcFIlBjsAh
> vrFfXDnKkr1QrOCWZliaH3wIttizW2CIw3SUVOwddIqSgfJNLaBu0VJo76TslKrD
> 16pGBlMo8yJPQemY2oeTc44PSfPEzCWIg97ZyyeTZY4FFyR3hb7Lle2B9jPxrrcp
> bj7THTobx94=
> =fXIs
> -END PGP SIGNATURE-

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

Re: [PATCH] ivi-shell: install ivi-layout-export.h

[Bryce Harrington]

On Thu, Oct 15, 2015 at 02:51:43PM +, Ucan, Emre (ADITG/SW1) wrote:
> IVI-Shell is designed to be used with other controller modules
> than hmi-controller.These controller modules require
> the ivi-layout-export header file to properly integrate
> with the ivi-shell. The header file should be installed
> when ivi-shell is enabled, because these controller modules
> are not a part of the weston repository.
> 
> Signed-off-by: Emre Ucan 

LGTM
Reviewed-by: Bryce Harrington 

Pushed:
remote: Updating patchwork state for 
http://patchwork.freedesktop.org/project/wayland/list/
remote: I: patch #61943 updated using rev 
ae2541d3f2923cfb300a42ab333906bea350ce91
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/wayland/weston
   c7ee760..ae2541d  master -> master


> ---
>  Makefile.am |5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Makefile.am b/Makefile.am
> index 1900390..13c43bf 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -215,6 +215,11 @@ westoninclude_HEADERS =  \
>   shared/zalloc.h \
>   shared/platform.h
>  
> +if ENABLE_IVI_SHELL
> +westoninclude_HEADERS += \
> + ivi-shell/ivi-layout-export.h
> +endif
> +
>  if ENABLE_EGL
>  module_LTLIBRARIES += gl-renderer.la
>  gl_renderer_la_LDFLAGS = -module -avoid-version
> -- 
> 1.7.9.5
> 
> ___
> 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

Request for Proposal for XDC 2016

[Daniel Vetter]

Hi all,

The X.Org board is solicting further proposals to organize XDC
somewhere in Europe. The board has already received a proposal for
Helsinki and plans to vote on that in the next meeting on the 29th
Oct, but if there is anyone else interested in hosting XDC we'd very
much like to hear about that.

Please send in your proposal to bo...@foundation.x.org latest by 28th
Oct to make sure the baord can consider it.

Thanks,
Daniel, secretary of the board
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] Add commented-out option to weston.ini to set Xwayland path

[Bryce Harrington]

On Thu, Oct 15, 2015 at 08:57:47AM -0700, spit...@gmail.com wrote:
> From: Bill Spitzak 
> 
> User can remove the comment marks to make xwayland.so use a local
> installed Xwayland server.
> ---
>  weston.ini.in | 3 +++
>  1 file changed, 3 insertions(+)

remote: I: patch #61949 updated using rev 
c7ee7608ef0dabc93efc2f68b7aca57a45be1a2d
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/wayland/weston
   8743047..c7ee760  master -> master

 
> diff --git a/weston.ini.in b/weston.ini.in
> index 06b51df..dff9e94 100644
> --- a/weston.ini.in
> +++ b/weston.ini.in
> @@ -66,3 +66,6 @@ path=@libexecdir@/weston-keyboard
>  
>  [screen-share]
>  command=@bindir@/weston --backend=rdp-backend.so --shell=fullscreen-shell.so 
> --no-clients-resize
> +
> +#[xwayland]
> +#path=@bindir@/Xwayland
> -- 
> 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

Re: Xwayland location

[Bill Spitzak]

On 10/15/2015 08:41 AM, Giulio Camuffo wrote:


The fact that it finds my xwayland.so file in ~/install, but cannot find the
Xwayland executable in ~/install bothers me a lot, however. It obviously
figured out where xwayland.so is from the --prefix arg to configure and this
really should match.


No, the xwayland.so is a part of weston, Xwayland is an entirely
separate binary coming from an entirely separate project, so i really
don't think weston should assume it is in the same prefix as itself.


Okay, but for all other projects I was able to fix that by making PATH 
and/or LD_LIBRARY_PATH include ~/install.


In any case the weston.ini option works and seems like the 
least-offensive solution to this. Probably should add this to the build 
instructions, or add it commented-out to the default weston.ini.



PS: weston.ini option is like this:

[xwayland]
path=myhome/install/bin/Xwayland



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

[PATCH] Add commented-out option to weston.ini to set Xwayland path

[spitzak]

From: Bill Spitzak 

User can remove the comment marks to make xwayland.so use a local
installed Xwayland server.
---
 weston.ini.in | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/weston.ini.in b/weston.ini.in
index 06b51df..dff9e94 100644
--- a/weston.ini.in
+++ b/weston.ini.in
@@ -66,3 +66,6 @@ path=@libexecdir@/weston-keyboard
 
 [screen-share]
 command=@bindir@/weston --backend=rdp-backend.so --shell=fullscreen-shell.so 
--no-clients-resize
+
+#[xwayland]
+#path=@bindir@/Xwayland
-- 
1.9.1

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

Re: Enums, bitfields and wl_arrays

[Auke Booij]

On 15 October 2015 at 09:18, Erik De Rijcke  wrote:
> If wayland enums would not explicitly declare values, you'd have the same
> problem in C. However since wayland enums do explicitly declare their value,
> *and* because C allows you to override an enum 'internal value', you don't
> have that problem here. Unfortunately, Sun in all it's infinite wisdom
> decided that Java enum 'internal values' can not be overridden. Only new
> 'properties' can be attached.
>
>>
>> But if this is indeed the issue you are discussing, then this must
>> have already been a problem before the introduction of additional XML
>> attributes.
>
>
> Correct. My current Java bindings create a Java enum with the wayland enum
> value as an additional property. If the order would change, that would be a
> potentially breaking change.
>
>> Can we agree on the following? Until there is any firm specification
>> of open/closed enums, every enum should be considered open, and
>> although some legal values might be listed, others might not be, and
>> some might only be legal sometimes.
>
>
> Ok for me but it would be very nice to have the open/closed information ;)
>
>>
>> New values may be added (but not
>> changed or removed) to protocol specifications without introducing any
>> compatibility issues.
>
>
> This is not clear for me. Compatibility issues for the current C bindings or
> for all language bindings? If it's for all language bindings than this might
> introduce a whole explosion of derived implicit specifications for each
> language. Eg. the enum order in Java. Better would be to specify a goal "no
> compatibility issues" and a set of form specifications eg. "the order of an
> enum shall not be changed".

This is exactly the kind of specification that I do not intend to
make, since it is (ostensibly) caused solely by a broken
implementation of enums in Java. It's not a problem in C, and not a
problem in any language that understands the concept of a variable.

On 13 October 2015 at 23:15, Bryce Harrington  wrote:
> On Tue, Oct 13, 2015 at 08:27:58PM +0100, Auke Booij wrote:
>> But if this is indeed the issue you are discussing, then this must
>> have already been a problem before the introduction of additional XML
>> attributes.
>>
>> Can we agree on the following? Until there is any firm specification
>> of open/closed enums, every enum should be considered open, and
>> although some legal values might be listed, others might not be, and
>> some might only be legal sometimes. New values may be added (but not
>> changed or removed) to protocol specifications without introducing any
>> compatibility issues.
>
> So, worst case if the binding language is inflexible here, then it'd
> need to maintain a mapping for the values to resequence them?

Yes, that is my point exactly.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] compositor-drm: fix cursor size test in drm_assign_planes

[Derek Foreman]

Pushed this one with Daniel's review from phabricator.

https://phabricator.freedesktop.org/T3361

(I think we keep the ticket open until we resolve the rest of the issue
- incorrectly promoting xrgb and stuff with opaque regions to cursor planes)

If this wasn't so trivial I'd be inclined to wait a little longer so
people not paying attention to phabricator would have a better change to
review.

On 15/10/15 10:24 AM, Derek Foreman wrote:
> In commit 70d337dfd we changed one cursor size test from a hard coded 64,64
> to the actual device provided width, height.
> 
> The test in drm_assign_planes remained fixed at 64, 64.
> 
> The simple-shm test ended up being small enough to fit into a cursor plane
> by one test, but too large by the test in drm_assign_planes.  We'd assign
> to the cursor plane but not keep a reference.
> 
> weston-simple-shm would disappear and be replaced with the previous
> cursor image.
> 
> This partially "fixes" T3361.
> 
> Signed-off-by: Derek Foreman 
> ---
>  src/compositor-drm.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> index 03c672e..36c3b3e 100644
> --- a/src/compositor-drm.c
> +++ b/src/compositor-drm.c
> @@ -1245,7 +1245,8 @@ drm_assign_planes(struct weston_output *output_base)
>   if (b->use_pixman ||
>   (es->buffer_ref.buffer &&
>   (!wl_shm_buffer_get(es->buffer_ref.buffer->resource) ||
> -  (ev->surface->width <= 64 && ev->surface->height <= 64
> +  (ev->surface->width <= b->cursor_width &&
> +   ev->surface->height <= b->cursor_height
>   es->keep_buffer = true;
>   else
>   es->keep_buffer = false;
> 

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

Re: Xwayland location

[Giulio Camuffo]

2015-10-15 18:36 GMT+03:00 Bill Spitzak :
> On 10/15/2015 12:24 AM, Pekka Paalanen wrote:
>>
>> On Wed, 14 Oct 2015 22:21:31 -0700
>> Bill Spitzak  wrote:
>>
>>> It seems like /usr/bin/Xwayland is hard-coded into xwayland.so. This
>>> makes it not run local installed versions of Xwayland. I could not get X
>>> programs to work under wayland without doing "sudo ln -s
>>> ~/install/bin/Xwayland /usr/bin".
>>>
>>> I noticed this because I had no /usr/bin/Xwayland, but I am concerned
>>> that if it really is installed, a developer will not realize they are
>>> not running their locally installed copy.
>>>
>>> There is a configure option --with-xserver-path but it would help if
>>> --prefix worked as a default (ie $prefix/bin/Xwayland).
>>
>>
>> That would be a wrong default for me now, while it would have been the
>> right default earlier this year. Either way, someone loses. That's why
>> there is --with-xserver-path.
>>
>>> Another possible solution is to use an environment variable ($XWAYLAND
>>> maybe?) as the name of the program.
>>>
>>> Maybe a better question is why the path is hard-coded, rather than it
>>> searching the path for this?
>>
>>
>> There is also a weston.ini option for the Xwayland path, see 'man
>> weston.ini'.
>
>
> The fact that it finds my xwayland.so file in ~/install, but cannot find the
> Xwayland executable in ~/install bothers me a lot, however. It obviously
> figured out where xwayland.so is from the --prefix arg to configure and this
> really should match.

No, the xwayland.so is a part of weston, Xwayland is an entirely
separate binary coming from an entirely separate project, so i really
don't think weston should assume it is in the same prefix as itself.

>
> PS: weston.ini option is like this:
>
> [xwayland]
> path=myhome/install/bin/Xwayland
>
>
>
> ___
> 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: I-beam cursor color changing based on the background

[Jasper St. Pierre]

Most desktop CRTCs support a XOR key in their ROP, since it was
required by Windows for such a long time. I don't think Linux has
support for that in KMS, nor for similar things like alpha keying as
well. Perhaps we'll get it as a plane property at some point.

I don't know of any mobile/embedded chipsets that support XOR keying,
since it's not 1996.

On Thu, Oct 15, 2015 at 8:30 AM, Bill Spitzak  wrote:
> That's xor of the color bits. The blue/red is due to xor'ing with the
> subpixel antialiasing. It is more obvious if you put the cursor over a solid
> colored area where you will see strange colors.
>
> It cannot be achieved with Porter-Duff combinations. I am not sure if OpenGL
> or DirectX supports it. I am also suspicious that overlay hardware designed
> for cursors may not support it either.
>
> This would either require adding something to Wayland to enable xor of a
> cursor, or (more likely) you will have to just set the cursor to blank and
> draw the desired graphics yourself.
>
> Linux programs seem to use a white insertion bar with a black outline, so it
> is visible against all backgrounds. This is despite the fact that X11 still
> supports xor cursors, everybody dropped that as obsolete. OS/X appears to
> use a black insertion bar with a very thin white outline (ie
> partially-transparent white pixels). Both of these work with normal
> compositing.
>
>
> On 10/14/2015 06:13 AM, John Doerthy wrote:
>>
>> Hi,
>> Could you please comment on this issue, if you are currently working on
>> the Windows-like implementation of the I-beam cursor (cursor for text
>> selection) in the graphical interface?
>> In Windows, the I-beam cursor, change color based on the background. So,
>> most of the time it's black, but when you are on the dark background its
>> color cahnges and not only that, but if part of the cursor is on the
>> white background and part on the dark background, only the affected
>> areas of teh I-beam cursor change the color. Plus if you are over a text
>> the part of the cursor that overlays some character has a slightly blue
>> or red color (as you can see in the screenshots below)
>> Here are some real world examples(screenshots) from Windows 7:
>> http://imgur.com/a/IxG7w
>> Thank for your response how far are you guys in implementing this feature.
>> John
>>
>>
>> ___
>> 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



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

Re: Xwayland location

[Bill Spitzak]

On 10/15/2015 12:24 AM, Pekka Paalanen wrote:

On Wed, 14 Oct 2015 22:21:31 -0700
Bill Spitzak  wrote:


It seems like /usr/bin/Xwayland is hard-coded into xwayland.so. This
makes it not run local installed versions of Xwayland. I could not get X
programs to work under wayland without doing "sudo ln -s
~/install/bin/Xwayland /usr/bin".

I noticed this because I had no /usr/bin/Xwayland, but I am concerned
that if it really is installed, a developer will not realize they are
not running their locally installed copy.

There is a configure option --with-xserver-path but it would help if
--prefix worked as a default (ie $prefix/bin/Xwayland).


That would be a wrong default for me now, while it would have been the
right default earlier this year. Either way, someone loses. That's why
there is --with-xserver-path.


Another possible solution is to use an environment variable ($XWAYLAND
maybe?) as the name of the program.

Maybe a better question is why the path is hard-coded, rather than it
searching the path for this?


There is also a weston.ini option for the Xwayland path, see 'man
weston.ini'.


The fact that it finds my xwayland.so file in ~/install, but cannot find 
the Xwayland executable in ~/install bothers me a lot, however. It 
obviously figured out where xwayland.so is from the --prefix arg to 
configure and this really should match.


PS: weston.ini option is like this:

[xwayland]
path=myhome/install/bin/Xwayland


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

Re: I-beam cursor color changing based on the background

[Bill Spitzak]

That's xor of the color bits. The blue/red is due to xor'ing with the 
subpixel antialiasing. It is more obvious if you put the cursor over a 
solid colored area where you will see strange colors.


It cannot be achieved with Porter-Duff combinations. I am not sure if 
OpenGL or DirectX supports it. I am also suspicious that overlay 
hardware designed for cursors may not support it either.


This would either require adding something to Wayland to enable xor of a 
cursor, or (more likely) you will have to just set the cursor to blank 
and draw the desired graphics yourself.


Linux programs seem to use a white insertion bar with a black outline, 
so it is visible against all backgrounds. This is despite the fact that 
X11 still supports xor cursors, everybody dropped that as obsolete. OS/X 
appears to use a black insertion bar with a very thin white outline (ie 
partially-transparent white pixels). Both of these work with normal 
compositing.


On 10/14/2015 06:13 AM, John Doerthy wrote:

Hi,
Could you please comment on this issue, if you are currently working on
the Windows-like implementation of the I-beam cursor (cursor for text
selection) in the graphical interface?
In Windows, the I-beam cursor, change color based on the background. So,
most of the time it's black, but when you are on the dark background its
color cahnges and not only that, but if part of the cursor is on the
white background and part on the dark background, only the affected
areas of teh I-beam cursor change the color. Plus if you are over a text
the part of the cursor that overlays some character has a slightly blue
or red color (as you can see in the screenshots below)
Here are some real world examples(screenshots) from Windows 7:
http://imgur.com/a/IxG7w
Thank for your response how far are you guys in implementing this feature.
John


___
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

[PATCH weston] compositor-drm: fix cursor size test in drm_assign_planes

[Derek Foreman]

In commit 70d337dfd we changed one cursor size test from a hard coded 64,64
to the actual device provided width, height.

The test in drm_assign_planes remained fixed at 64, 64.

The simple-shm test ended up being small enough to fit into a cursor plane
by one test, but too large by the test in drm_assign_planes.  We'd assign
to the cursor plane but not keep a reference.

weston-simple-shm would disappear and be replaced with the previous
cursor image.

This partially "fixes" T3361.

Signed-off-by: Derek Foreman 
---
 src/compositor-drm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 03c672e..36c3b3e 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -1245,7 +1245,8 @@ drm_assign_planes(struct weston_output *output_base)
if (b->use_pixman ||
(es->buffer_ref.buffer &&
(!wl_shm_buffer_get(es->buffer_ref.buffer->resource) ||
-(ev->surface->width <= 64 && ev->surface->height <= 64
+(ev->surface->width <= b->cursor_width &&
+ ev->surface->height <= b->cursor_height
es->keep_buffer = true;
else
es->keep_buffer = false;
-- 
2.6.1

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

[PATCH] ivi-shell: install ivi-layout-export.h

[Ucan, Emre (ADITG/SW1)]

IVI-Shell is designed to be used with other controller modules
than hmi-controller.These controller modules require
the ivi-layout-export header file to properly integrate
with the ivi-shell. The header file should be installed
when ivi-shell is enabled, because these controller modules
are not a part of the weston repository.

Signed-off-by: Emre Ucan 
---
 Makefile.am |5 +
 1 file changed, 5 insertions(+)

diff --git a/Makefile.am b/Makefile.am
index 1900390..13c43bf 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -215,6 +215,11 @@ westoninclude_HEADERS =\
shared/zalloc.h \
shared/platform.h
 
+if ENABLE_IVI_SHELL
+westoninclude_HEADERS +=   \
+   ivi-shell/ivi-layout-export.h
+endif
+
 if ENABLE_EGL
 module_LTLIBRARIES += gl-renderer.la
 gl_renderer_la_LDFLAGS = -module -avoid-version
-- 
1.7.9.5

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

[PATCH] ivi-shell: rename ivi_controller_interface

[Ucan, Emre (ADITG/SW1)]

The name of ivi_controller_interface is changed to ivi_layout_interface
with this patch.

This name is better suited to the interface, because it is implemented
in ivi-layout.c and its methods are linked to ivi_layout* functions.

Furthermore, the controller modules (e.g. hmi-controller) are the users
of this interface and they have their own interfaces,
which are called *_controller_interface,
e.g.: ivi_hmi_controller_interface.

This causes confusion about the software architecture.

Signed-off-by: Emre Ucan 
---
 ivi-shell/hmi-controller.c   |  168 ++--
 ivi-shell/ivi-layout-export.h|2 +-
 ivi-shell/ivi-layout.c   |8 +-
 tests/ivi_layout-internal-test.c |  562 +++---
 tests/ivi_layout-test-plugin.c   |  364 
 5 files changed, 552 insertions(+), 552 deletions(-)

diff --git a/ivi-shell/hmi-controller.c b/ivi-shell/hmi-controller.c
index 5cc76d3..d1ed872 100644
--- a/ivi-shell/hmi-controller.c
+++ b/ivi-shell/hmi-controller.c
@@ -132,12 +132,12 @@ struct launcher_info {
int32_t index;
 };
 
-const struct ivi_controller_interface *ivi_controller_interface;
+const struct ivi_layout_interface *ivi_layout_interface;
 
 int
 controller_module_init(struct weston_compositor *ec,
   int *argc, char *argv[],
-  const struct ivi_controller_interface *interface,
+  const struct ivi_layout_interface *interface,
   size_t interface_version);
 
 /*
@@ -166,7 +166,7 @@ static int32_t
 is_surf_in_ui_widget(struct hmi_controller *hmi_ctrl,
 struct ivi_layout_surface *ivisurf)
 {
-   uint32_t id = ivi_controller_interface->get_id_of_surface(ivisurf);
+   uint32_t id = ivi_layout_interface->get_id_of_surface(ivisurf);
 
uint32_t *ui_widget_id = NULL;
wl_array_for_each(ui_widget_id, &hmi_ctrl->ui_widgets) {
@@ -247,11 +247,11 @@ mode_divided_into_tiling(struct hmi_controller *hmi_ctrl,
surface_y = (int32_t)surface_height;
}
 
-   
ivi_controller_interface->surface_set_transition(ivisurf,
+   ivi_layout_interface->surface_set_transition(ivisurf,
IVI_LAYOUT_TRANSITION_VIEW_DEFAULT,
duration);
-   
ivi_controller_interface->surface_set_visibility(ivisurf, true);
-   
ivi_controller_interface->surface_set_destination_rectangle(ivisurf,
+   ivi_layout_interface->surface_set_visibility(ivisurf, 
true);
+   
ivi_layout_interface->surface_set_destination_rectangle(ivisurf,
surface_x, surface_y,
(int32_t)surface_width,
(int32_t)surface_height);
@@ -259,11 +259,11 @@ mode_divided_into_tiling(struct hmi_controller *hmi_ctrl,
num++;
continue;
}
-   ivi_controller_interface->surface_set_visibility(ivisurf, 
false);
+   ivi_layout_interface->surface_set_visibility(ivisurf, false);
}
 
if (surf_num > 0) {
-   ivi_controller_interface->layer_set_transition(layer->ivilayer,
+   ivi_layout_interface->layer_set_transition(layer->ivilayer,
IVI_LAYOUT_TRANSITION_LAYER_VIEW_ORDER,
duration);
}
@@ -294,11 +294,11 @@ mode_divided_into_sidebyside(struct hmi_controller 
*hmi_ctrl,
continue;
 
if (num == 1) {
-   
ivi_controller_interface->surface_set_transition(ivisurf,
+   ivi_layout_interface->surface_set_transition(ivisurf,
IVI_LAYOUT_TRANSITION_VIEW_DEFAULT,
duration);
-   
ivi_controller_interface->surface_set_visibility(ivisurf, true);
-   
ivi_controller_interface->surface_set_destination_rectangle(ivisurf,
+   ivi_layout_interface->surface_set_visibility(ivisurf, 
true);
+   
ivi_layout_interface->surface_set_destination_rectangle(ivisurf,
0, 0,
surface_width,
surface_height);
@@ -306,11 +306,11 @@ mode_divided_into_sidebyside(struct hmi_controller 
*hmi_ctrl,
num++;
continue;
} else if (num == 2) {
-   
ivi_controller_interface->surface_set_transition(ivisurf,
+   ivi_layout_interface

I-beam cursor color changing based on the background

[John Doerthy]

Hi,

 

Could you please comment on this issue, if you are currently working on the Windows-like implementation of the I-beam cursor (cursor for text selection) in the graphical interface?

 

In Windows, the I-beam cursor, change color based on the background. So, most of the time it's black, but when you are on the dark background its color cahnges and not only that, but if part of the cursor is on the white background and part on the dark background, only the affected areas of teh I-beam cursor change the color. Plus if you are over a text the part of the cursor that overlays some character has a slightly blue or red color (as you can see in the screenshots below)

 

Here are some real world examples(screenshots) from Windows 7:

http://imgur.com/a/IxG7w

 

Thank for your response how far are you guys in implementing this feature.

 

John

 

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

[PATCH] Fix implicit declaration of function 'xf86Msg' in xf86libinput.c

[Stanislav Ochotnicky]

Addition of xf86.h header fixes compilation issues in some cases.

See: https://bugs.gentoo.org/show_bug.cgi?id=560970
Signed-off-by: Stanislav Ochotnicky 
---
 src/xf86libinput.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/xf86libinput.c b/src/xf86libinput.c
index c1b13ff..c6b651c 100644
--- a/src/xf86libinput.c
+++ b/src/xf86libinput.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.4.9

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

Re: xdg_surface_move Segmentation fault (core dumped)

[Pekka Paalanen]

On Wed, 14 Oct 2015 10:19:44 -0600
Vinicio Cordero  wrote:

> Hello,
> 
> I am making a simple wayland client using the simple-shm, simple-egl and
> fullscreen as a guide; while the surface is displayed and updated correctly
> on weston attempting to move the surface on pointer move event by calling
> xdg_surface_move will sometimes(almost always, sometimes the surface
> actually moves with no problems) make the client crash with a Segmentation
> fault (core dumped). Is there any minimum requirement I am missing to
> handle this feature the right way? Or is my main loop handled incorrectly?

Get a backtrace in gdb. There should be nothing mysterious here, it's a
simple program like any. Valgrind is useful too.

> Is the double buffer swapping implemented on simple-shm really neccesary?

Yes, see
http://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_buffer
and the references to wl_surface.

You can see the difference in buffer handling if you compare running
simple-shm on Weston with gl-renderer vs. Weston with pixman-renderer
(cmdline: --use-pixman). Pixman-renderer will not release a wl_shm
buffer until it has received another buffer. GL-renderer does release
earlier, because it makes a copy of the contents (glTexImage2D).

If the app uses sub-surfaces in a certain way, it is possible to need
three buffers.

Note, that the buffer management talked about here is necessary for
visual correctness, not for avoiding crashes. An app can write to a
reserved wl_buffer, there usually is no way to detect that in the
compositor, and it probably won't cause crashes or errors. It may just
cause glitches on the screen.

> Wayland and weston version: 1.9.0,  the code is send as an attachment.

Thanks,
pq


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

Re: State of Wayland protocol development

[Pekka Paalanen]

On Thu, 15 Oct 2015 14:26:05 +0800
Jonas Ådahl  wrote:

> On Thu, Oct 15, 2015 at 02:44:15PM +1000, Peter Hutterer wrote:
> 
> 
> 
> > 
> > one remaining question I have though: what are we to do with changes to the
> > wayland protocol itself, e.g. the pointer axis changes. There are a few that
> > cannot be easily added as separate interface, do we bite the bullet there
> > and merge it into the wayland protocol directly? or can we figure out some
> > overlay protocol where we override the official?
> > 
> 
> An overlay protocol sounds scary. I think we'll just have to accept that
> making changes to wayland.xml will have to go through the wayland
> repository.

For the final stable protocol, yes.

During protocol development though, we could add a bit of extra and ugly
protocol to create experimental add-on intefaces to e.g. wl_seat. This
would be similar to how you plug wl_viewport to wl_surface (scaler.xml).

When the protocol finally gets stabilized, the experimental global
interface will be removed, and the changes to the protocol and code are
hopefully purely mechanical and fairly easy to review.

Can you see that working?

It is a heavy-weight method, so probably not useful for easy additions.


Thanks,
pq


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

Re: [PATCH weston] tests: Adding simple waycheck validation tool.

[Pekka Paalanen]

On Wed, 14 Oct 2015 14:36:33 -0700
Bryce Harrington  wrote:

> On Wed, Oct 14, 2015 at 04:17:53PM +0300, Pekka Paalanen wrote:
> > On Wed,  7 Oct 2015 16:11:43 -0700
> > "Jon A. Cruz"  wrote:
> > 
> > > Adds an initial implementation of a testing tool that uses the unit
> > > test framework to run checks against an arbitrary Wayland compositor.
> > > Note that this is not intended for Weston-specific testing, but for
> > > generic Wayland testing.
> > > 
> > > Signed-off-by: Jon A. Cruz 
> > 
> > Hi Jon,
> > 
> > nice to see progress. :-)
> > 
> > I tested, waycheck runs fine if you run it manually. So this patch is
> > not even intended to hook it up to 'make check' at all, but just
> > compile a program you can run with any compositor?
> > 
> > When you later do hook things up into Weston's 'make check', will that
> > re-use the waycheck code or only the wayland_fixtures code?
> > 
> > I think the commit message should say which existing upstream tests
> > this patch reimplements. If it doesn't, it should say what we are
> > testing instead, in few words. Comments in waycheck.c could explain in
> > more detail about what is being tested.
> 
> Further, I am not sure we should land this until the test cases have
> been reimplemented to use it.  Having two test frameworks in the
> codebase increases complexity, and it's already tough to find folks to
> work on tests.

We are already past that, we already have two frameworks here.

I think it's better to land this stuff in pieces than massage a
humongous replace-the-world patch series, if we can tell the pieces are
going in the right direction. The bits here are mostly just following
the existing weston-test-client-helper.c (which the commit message
forgot to mention).

But yeah, probably makes sense to see how hooking even this stuff up to
'make check' would happen before landing this. That will be one of the
most interesting things here. This patch as is does not add anything to
'make check' which is a little awkward for a series adding new test
code.

As for writing tests in the mean time, people should just ignore the
new framework for now, and write tests as if it didn't exist as long as
it doesn't support what the old framework does.

This way we can incrementally advance on both fronts at the same time.


Thanks,
pq


pgp2ddjHBJ5rX.pgp
Description: OpenPGP digital signature
___
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

[Daniel Stone]

Hi,

On 15 October 2015 at 09:32, Jonas Ådahl  wrote:
> On Thu, Oct 15, 2015 at 09:16:14AM +0100, Daniel Stone wrote:
>> On 15 October 2015 at 04:56, Jonas Ådahl  wrote:
>> > On Thu, Oct 08, 2015 at 12:15:10PM -0500, Derek Foreman wrote:
>> >> Perhaps I should read what's in phabricator before I continue to
>> >> comment, though.
>> >
>> > Hmm. I can't find it any more. It was in the fdo phabricator task
>> >  but all those comments are no
>> > longer there. I have no idea why.
>>
>> Hmm, is it in the individual commits for review?
>>
>> e.g. https://phabricator.freedesktop.org/D13
>
> "You Shall Not Pass: Restricted Differential Revision"

Oops. Given that was the first revision (D1!) ever in there, it was
against an old repository import that I later junked. Phabricator got
confused since it partly inherits the permission from the repository -
fixed now. As you can probably guess from all the spam in your inbox
...

>> > I wonder if we should put "wl_double_fixed" in wayland/ and declare that
>> > an "official mutli part type" thing so we don't have to reimplement the
>> > awkward from/to functions all over the place. Maybe even
>> > a wl_double_fixed_t type as was suggested at an earlier point?
>>
>> I'm still a bit uneasy on the actual need for this: wl_fixed_t gives
>> us 1/256th-pixel precision. Is that not enough? Surely changes less
>> than that cannot affect the viewport, so why would we spam clients
>> with them rather than accumulating internally and sending when it
>> passes the threshold? Is it just about implementing acceleration on
>> the client side?
>
> For absolute motions I agree. For relative, I don't know. I'm no high
> end gaming device expert (or where high precision might be relevant)
> There were discussions about this before that resulted in changing
> from ms to us timestamps and from 32 bit to 64 bit fixed for deltas,
> because we didn't want to pretend to be sure that the precision we had
> was definitely enough for all relative pointer use cases.

Ack, fair enough. Anyone?

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

Re: [PATCH] configure: Up the libwayland version requirement

[Pekka Paalanen]

On Wed, 14 Oct 2015 20:22:18 -0500
Derek Foreman  wrote:

> On 14/10/15 05:40 PM, Bryce Harrington wrote:
> > weston commit f7bb9352 requires recent libwayland changes for providing
> > ‘WL_POINTER_RELEASE_SINCE_VERSION’.  Increase the version requirement to
> > indicate that current weston git requires development version of
> > wayland.
> > 
> > NOTE: At release we should probably increase the wayland requirement for
> > weston to 1.10.0.
> > 
> > Signed-off-by: Bryce Harrington 
> 
> Turns a compile time barf into a configure time one, at least for anyone
> trying to build a git weston with a stable wayland right now...
> 
> Reviewed-by: Derek Foreman 
> 
> > ---
> >  configure.ac | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/configure.ac b/configure.ac
> > index 67e80d0..e5afbc0 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -59,7 +59,7 @@ AC_CHECK_HEADERS([execinfo.h])
> >  
> >  AC_CHECK_FUNCS([mkostemp strchrnul initgroups posix_fallocate])
> >  
> > -COMPOSITOR_MODULES="wayland-server >= 1.9.0 pixman-1 >= 0.25.2"
> > +COMPOSITOR_MODULES="wayland-server >= 1.9.90 pixman-1 >= 0.25.2"
> >  
> >  AC_CONFIG_FILES([doc/doxygen/tools.doxygen doc/doxygen/tooldev.doxygen])
> >  
> > @@ -317,7 +317,7 @@ AC_SUBST(JPEG_LIBS)
> >  
> >  PKG_CHECK_MODULES(CAIRO, [cairo])
> >  
> > -PKG_CHECK_MODULES(TEST_CLIENT, [wayland-client >= 1.9.0])
> > +PKG_CHECK_MODULES(TEST_CLIENT, [wayland-client >= 1.9.90])
> >  
> >  AC_ARG_ENABLE(simple-clients,
> >AS_HELP_STRING([--disable-simple-clients],

I see configure.ac has two wayland-server and nine wayland-client
pkg-config references. The two you bump are the ones that are
unconditionally required, AFAICT.

Reviewed-by: Pekka Paalanen 


Thanks,
pq


pgpWfkhFY4Aor.pgp
Description: OpenPGP digital signature
___
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

[Jonas Ådahl]

On Thu, Oct 15, 2015 at 09:16:14AM +0100, Daniel Stone wrote:
> Hi,
> 
> On 15 October 2015 at 04:56, Jonas Ådahl  wrote:
> > On Thu, Oct 08, 2015 at 12:15:10PM -0500, Derek Foreman wrote:
> >> On 07/10/15 07:41 PM, Jonas Ådahl wrote:
> >> > On Wed, Oct 07, 2015 at 01:32:35PM -0500, Derek Foreman wrote:
> >> >> Would really like to see Daniel's review, time permitting.
> >> >>
> >> >> I think it would be nice to land this in the same release cycle (ie:
> >> >> this one) as pointer confinement, because I think the two features
> >> >> really go hand in hand.
> 
> Ahem, yes. Week o' meetings this week, but then straight back on it. :\
> 
> >> > Initially this request took a seat, since then it has been more
> >> > considered an extension to the pointer object (sharing its focus, etc)
> >> > than its own seat device. It was brought up during an early review (on
> >> > phabricator, so you might not have seen it) that it might be a good idea
> >> > to make the extension-ness more obvious.
> >>
> >> I can't find any of this in phabricator - can you give me a url?  Maybe
> >> I'm just doing a poor search...
> >>
> >> > An besides that, the client will probably want to know the pointer
> >> > focus, it might want to set the cursor and it will probably like to know
> >> > about clicks etc.
> >>
> >> But if it's a 1000hz gaming mouse the compositor will generate 1000
> >> events per second for the client to discard?
> >>
> >> Why not just allow the pointer to be bound as either/both serial and
> >> absolute, and have each be a fully functional interface?
> >>
> >> Perhaps I should read what's in phabricator before I continue to
> >> comment, though.
> >
> > Hmm. I can't find it any more. It was in the fdo phabricator task
> >  but all those comments are no
> > longer there. I have no idea why.
> 
> Hmm, is it in the individual commits for review?
> 
> e.g. https://phabricator.freedesktop.org/D13

"You Shall Not Pass: Restricted Differential Revision"

> 
> >> >>> + wl_double_fixed_from_double(dx, &dx_int, &dx_frac);
> >> >>> + wl_double_fixed_from_double(dy, &dy_int, &dy_frac);
> >> >>
> >> >> Do you have a patch somewhere for wl_double_fixed_from_double?
> >> >
> >> > http://patchwork.freedesktop.org/patch/49211/
> >>
> >> Ah, yes, hung up indefinitely in the pointer confinement review. :/
> >>
> >> It would be nice to unstick some of the preamble bits that require less
> >> fisticuffs than the protocol bits...
> 
> Agreed. There are a good number of preamble commits which did look
> good (see the green-tick ones linked from T1), which I think we should
> just go ahead and merge. If there are any follow-ups that need my
> attention, please ping me and I can do them very very quickly.
> 
> > I wonder if we should put "wl_double_fixed" in wayland/ and declare that
> > an "official mutli part type" thing so we don't have to reimplement the
> > awkward from/to functions all over the place. Maybe even
> > a wl_double_fixed_t type as was suggested at an earlier point?
> 
> I'm still a bit uneasy on the actual need for this: wl_fixed_t gives
> us 1/256th-pixel precision. Is that not enough? Surely changes less
> than that cannot affect the viewport, so why would we spam clients
> with them rather than accumulating internally and sending when it
> passes the threshold? Is it just about implementing acceleration on
> the client side?

For absolute motions I agree. For relative, I don't know. I'm no high
end gaming device expert (or where high precision might be relevant)
There were discussions about this before that resulted in changing
from ms to us timestamps and from 32 bit to 64 bit fixed for deltas,
because we didn't want to pretend to be sure that the precision we had
was definitely enough for all relative pointer use cases.


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

Re: Enums, bitfields and wl_arrays

[Daniel Stone]

Hi,

On 15 October 2015 at 09:18, Erik De Rijcke  wrote:
> On Tue, Oct 13, 2015 at 9:27 PM, Auke Booij  wrote:
>> New values may be added (but not
>> changed or removed) to protocol specifications without introducing any
>> compatibility issues.
>
> This is not clear for me. Compatibility issues for the current C bindings or
> for all language bindings? If it's for all language bindings than this might
> introduce a whole explosion of derived implicit specifications for each
> language. Eg. the enum order in Java. Better would be to specify a goal "no
> compatibility issues" and a set of form specifications eg. "the order of an
> enum shall not be changed".

Yes, agreed. That's the only tractable way: the definition of a closed
enum requires strictly linear append-only additions. Next topic. :)

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

Re: Enums, bitfields and wl_arrays

[Erik De Rijcke]

On Tue, Oct 13, 2015 at 9:27 PM, Auke Booij  wrote:
>
> I really don't understand this discussion. Is the claim that the usage
> of enums in java is problematic, because inserting a new value in an
> existing enum might change the index of later values, thereby creating
> an inconsistency?
>

Correct.


> If so, all I can say that clearly the object you want to associate
> with wayland-style enums is not whatever Java has invented for an
> "enum". The values that are associated to names inside wayland enums
> are very clear-defined, and if a language cannot safely couple names
> back to values, then that is a language that does not understand the
> concept of a variable. If this is a fundamental problem about Java
> enums, you better find a way around it, but I don't see how this is in
> any way a problem on the wayland side: there are enums, and enums
> contain names, and those names have values.
>

If wayland enums would not explicitly declare values, you'd have the same
problem in C. However since wayland enums do explicitly declare their
value, *and* because C allows you to override an enum 'internal value', you
don't have that problem here. Unfortunately, Sun in all it's infinite
wisdom decided that Java enum 'internal values' can not be overridden. Only
new 'properties' can be attached.


> But if this is indeed the issue you are discussing, then this must
> have already been a problem before the introduction of additional XML
> attributes.
>

Correct. My current Java bindings create a Java enum with the wayland enum
value as an additional property. If the order would change, that would be a
potentially breaking change.

Can we agree on the following? Until there is any firm specification
> of open/closed enums, every enum should be considered open, and
> although some legal values might be listed, others might not be, and
> some might only be legal sometimes.


Ok for me but it would be very nice to have the open/closed information ;)


> New values may be added (but not
> changed or removed) to protocol specifications without introducing any
> compatibility issues.
>

This is not clear for me. Compatibility issues for the current C bindings
or for all language bindings? If it's for all language bindings than this
might introduce a whole explosion of derived implicit specifications for
each language. Eg. the enum order in Java. Better would be to specify a
goal "no compatibility issues" and a set of form specifications eg. "the
order of an enum shall not be changed".


> ___
> 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 v3 3/3] Introduce wl_relative_pointer interface

[Daniel Stone]

Hi,

On 15 October 2015 at 04:56, Jonas Ådahl  wrote:
> On Thu, Oct 08, 2015 at 12:15:10PM -0500, Derek Foreman wrote:
>> On 07/10/15 07:41 PM, Jonas Ådahl wrote:
>> > On Wed, Oct 07, 2015 at 01:32:35PM -0500, Derek Foreman wrote:
>> >> Would really like to see Daniel's review, time permitting.
>> >>
>> >> I think it would be nice to land this in the same release cycle (ie:
>> >> this one) as pointer confinement, because I think the two features
>> >> really go hand in hand.

Ahem, yes. Week o' meetings this week, but then straight back on it. :\

>> > Initially this request took a seat, since then it has been more
>> > considered an extension to the pointer object (sharing its focus, etc)
>> > than its own seat device. It was brought up during an early review (on
>> > phabricator, so you might not have seen it) that it might be a good idea
>> > to make the extension-ness more obvious.
>>
>> I can't find any of this in phabricator - can you give me a url?  Maybe
>> I'm just doing a poor search...
>>
>> > An besides that, the client will probably want to know the pointer
>> > focus, it might want to set the cursor and it will probably like to know
>> > about clicks etc.
>>
>> But if it's a 1000hz gaming mouse the compositor will generate 1000
>> events per second for the client to discard?
>>
>> Why not just allow the pointer to be bound as either/both serial and
>> absolute, and have each be a fully functional interface?
>>
>> Perhaps I should read what's in phabricator before I continue to
>> comment, though.
>
> Hmm. I can't find it any more. It was in the fdo phabricator task
>  but all those comments are no
> longer there. I have no idea why.

Hmm, is it in the individual commits for review?

e.g. https://phabricator.freedesktop.org/D13

>> >>> + wl_double_fixed_from_double(dx, &dx_int, &dx_frac);
>> >>> + wl_double_fixed_from_double(dy, &dy_int, &dy_frac);
>> >>
>> >> Do you have a patch somewhere for wl_double_fixed_from_double?
>> >
>> > http://patchwork.freedesktop.org/patch/49211/
>>
>> Ah, yes, hung up indefinitely in the pointer confinement review. :/
>>
>> It would be nice to unstick some of the preamble bits that require less
>> fisticuffs than the protocol bits...

Agreed. There are a good number of preamble commits which did look
good (see the green-tick ones linked from T1), which I think we should
just go ahead and merge. If there are any follow-ups that need my
attention, please ping me and I can do them very very quickly.

> I wonder if we should put "wl_double_fixed" in wayland/ and declare that
> an "official mutli part type" thing so we don't have to reimplement the
> awkward from/to functions all over the place. Maybe even
> a wl_double_fixed_t type as was suggested at an earlier point?

I'm still a bit uneasy on the actual need for this: wl_fixed_t gives
us 1/256th-pixel precision. Is that not enough? Surely changes less
than that cannot affect the viewport, so why would we spam clients
with them rather than accumulating internally and sending when it
passes the threshold? Is it just about implementing acceleration on
the client side?

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

Re: [PATCH weston] clients: track seat_version per seat, not per display

[Pekka Paalanen]

On Wed, 14 Oct 2015 20:57:35 +0200
Hardening  wrote:

> Le 14/10/2015 16:39, Derek Foreman a écrit :
> > Apparently it's possible for a compositor to advertise seats with
> > different versions on the same connection, so this makes us more robust
> > against that dubious behaviour.
> > 
> > This also tracks the seat version we requested instead of the advertised
> > maximum.
> > 
> > Signed-off-by: Derek Foreman 
> > ---
> > 
> > As penance for my sass, I've gone ahead and "fixed" this - I think
> > tracking the version we requested instead of the one advertised is
> > more robust against catching a failure to increment the requested
> > version though. However, it does seem like the correct thing to do.
> > 
> >  clients/window.c | 20 +++-
> >  1 file changed, 11 insertions(+), 9 deletions(-)
> > 
> > diff --git a/clients/window.c b/clients/window.c
> > index 6d3e944..d8f2ee2 100644
> > --- a/clients/window.c
> > +++ b/clients/window.c
> > @@ -140,7 +140,6 @@ struct display {
> > void *dummy_surface_data;
> >  
> > int has_rgb565;
> > -   int seat_version;
> > int data_device_manager_version;
> >  };
> >  
> > @@ -362,6 +361,7 @@ struct input {
> > uint32_t repeat_sym;
> > uint32_t repeat_key;
> > uint32_t repeat_time;
> > +   int seat_version;
> >  };
> >  
> >  struct output {
> > @@ -3256,7 +3256,7 @@ seat_handle_capabilities(void *data, struct wl_seat 
> > *seat,
> > wl_pointer_add_listener(input->pointer, &pointer_listener,
> > input);
> > } else if (!(caps & WL_SEAT_CAPABILITY_POINTER) && input->pointer) {
> > -   if (input->display->seat_version >= 
> > WL_POINTER_RELEASE_SINCE_VERSION)
> > +   if (input->seat_version >= WL_POINTER_RELEASE_SINCE_VERSION)
> > wl_pointer_release(input->pointer);
> > else
> > wl_pointer_destroy(input->pointer);
> > @@ -3269,7 +3269,7 @@ seat_handle_capabilities(void *data, struct wl_seat 
> > *seat,
> > wl_keyboard_add_listener(input->keyboard, &keyboard_listener,
> >  input);
> > } else if (!(caps & WL_SEAT_CAPABILITY_KEYBOARD) && input->keyboard) {
> > -   if (input->display->seat_version >= 
> > WL_KEYBOARD_RELEASE_SINCE_VERSION)
> > +   if (input->seat_version >= WL_KEYBOARD_RELEASE_SINCE_VERSION)
> > wl_keyboard_release(input->keyboard);
> > else
> > wl_keyboard_destroy(input->keyboard);
> > @@ -3281,7 +3281,7 @@ seat_handle_capabilities(void *data, struct wl_seat 
> > *seat,
> > wl_touch_set_user_data(input->touch, input);
> > wl_touch_add_listener(input->touch, &touch_listener, input);
> > } else if (!(caps & WL_SEAT_CAPABILITY_TOUCH) && input->touch) {
> > -   if (input->display->seat_version >= 
> > WL_TOUCH_RELEASE_SINCE_VERSION)
> > +   if (input->seat_version >= WL_TOUCH_RELEASE_SINCE_VERSION)
> > wl_touch_release(input->touch);
> > else
> > wl_touch_destroy(input->touch);
> > @@ -5218,17 +5218,20 @@ fini_xkb(struct input *input)
> >  }
> >  
> >  static void
> > -display_add_input(struct display *d, uint32_t id)
> > +display_add_input(struct display *d, uint32_t id, int display_seat_version)
> >  {
> > struct input *input;
> > +   int seat_version = MIN(display_seat_version, 4);
> >  
> > input = xzalloc(sizeof *input);
> > input->display = d;
> > input->seat = wl_registry_bind(d->registry, id, &wl_seat_interface,
> > -  MIN(d->seat_version, 4));
> > +  seat_version);
> > input->touch_focus = NULL;
> > input->pointer_focus = NULL;
> > input->keyboard_focus = NULL;
> > +   input->seat_version = seat_version;
> > +
> > wl_list_init(&input->touch_point_list);
> > wl_list_insert(d->input_list.prev, &input->link);
> >  
> > @@ -5278,7 +5281,7 @@ input_destroy(struct input *input)
> > else
> > wl_data_device_destroy(input->data_device);
> > }
> > -   if (input->display->seat_version >= WL_POINTER_RELEASE_SINCE_VERSION) {
> > +   if (input->seat_version >= WL_POINTER_RELEASE_SINCE_VERSION) {
> > if (input->touch)
> > wl_touch_release(input->touch);
> > if (input->pointer)
> > @@ -5365,8 +5368,7 @@ registry_handle_global(void *data, struct wl_registry 
> > *registry, uint32_t id,
> > } else if (strcmp(interface, "wl_output") == 0) {
> > display_add_output(d, id);
> > } else if (strcmp(interface, "wl_seat") == 0) {
> > -   d->seat_version = version;
> > -   display_add_input(d, id);
> > +   display_add_input(d, id, version);
> > } else if (strcmp(interface, "wl_shm") == 0) {
> > d->shm = wl_registry_bind(registry, id, &wl_shm_interface, 1);
> > wl_

Re: Xwayland location

[Pekka Paalanen]

On Wed, 14 Oct 2015 22:21:31 -0700
Bill Spitzak  wrote:

> It seems like /usr/bin/Xwayland is hard-coded into xwayland.so. This 
> makes it not run local installed versions of Xwayland. I could not get X 
> programs to work under wayland without doing "sudo ln -s 
> ~/install/bin/Xwayland /usr/bin".
> 
> I noticed this because I had no /usr/bin/Xwayland, but I am concerned 
> that if it really is installed, a developer will not realize they are 
> not running their locally installed copy.
> 
> There is a configure option --with-xserver-path but it would help if 
> --prefix worked as a default (ie $prefix/bin/Xwayland).

That would be a wrong default for me now, while it would have been the
right default earlier this year. Either way, someone loses. That's why
there is --with-xserver-path.

> Another possible solution is to use an environment variable ($XWAYLAND 
> maybe?) as the name of the program.
> 
> Maybe a better question is why the path is hard-coded, rather than it 
> searching the path for this?

There is also a weston.ini option for the Xwayland path, see 'man
weston.ini'.


Thanks,
pq


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

Re: Wayland Programming.

[Pekka Paalanen]

On Thu, 15 Oct 2015 10:15:03 +0300
Pekka Paalanen  wrote:

> On Wed, 14 Oct 2015 13:20:30 -0700
>  wrote:
> 
> > 
> > I was looking at your blog.
> > 
> > Some people are claiming that you have to create a wl_buffer before a
> > wl_surface.
> > Some people are claiming that you don't have to create a wl_buffer at
> > all.
> > 
> > Do you know what's going on?
> > 
> > How do you create a wl_surface?
> > 
> 
> Hi,
> 
> first, let's put this on the proper mailing list for everyone's benefit.
> 
> You create a wl_surface with the wl_compositor.create_surface request.
> That is all. Only the wl_compositor is required, nothing else.
> 
> Of course, such a wl_surface will be useless until you do two more
> things:
> - give it a role
> - give it content (create a wl_buffer, fill it with data, and
>   wl_surface.damage+attach+commit it)
> Only after these you may see something on the screen.
> 
> Refer to
> http://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_surface
> for how to do things after you created a wl_surface.
> 
> There is no difference in which you create first, a wl_surface or a
> wl_buffer.

Oh, I should add that you may not know what size of a wl_buffer to
create until you have created the wl_surface and given it a role.
Certain role specific actions trigger the server to tell you what size
you should or must use.


Thanks,
pq


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

Re: Wayland Programming.

[Pekka Paalanen]

On Wed, 14 Oct 2015 13:20:30 -0700
 wrote:

> 
> I was looking at your blog.
> 
> Some people are claiming that you have to create a wl_buffer before a
> wl_surface.
> Some people are claiming that you don't have to create a wl_buffer at
> all.
> 
> Do you know what's going on?
> 
> How do you create a wl_surface?
> 

Hi,

first, let's put this on the proper mailing list for everyone's benefit.

You create a wl_surface with the wl_compositor.create_surface request.
That is all. Only the wl_compositor is required, nothing else.

Of course, such a wl_surface will be useless until you do two more
things:
- give it a role
- give it content (create a wl_buffer, fill it with data, and
  wl_surface.damage+attach+commit it)
Only after these you may see something on the screen.

Refer to
http://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_surface
for how to do things after you created a wl_surface.

There is no difference in which you create first, a wl_surface or a
wl_buffer.

There are different kinds of wl_buffers created in different ways,
because of different ways to associate data with them: drawing with the
CPU, rendering with the GPU, hardware-decoded video...


Thanks,
pq


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