Re: Kinetic scroll in libinput Xorg driver

[Bill Spitzak]

On Tue, Oct 25, 2016 at 3:06 PM, Peter Hutterer
 wrote:

>> @Bill: What Peter says is that there could be some applications that
>> implement special behaviors when you scroll while at the end of the
>> file/context/whatever.

I don't see

>> Scroll events are sends to the window below the
>> mouse whatever the focus, and so moving the mouse over another window while
>> a kinetic scroll is pending will send scroll events to this new window...
>> Bad behavior...

Actually this seems bad even for normal scroll events. I am using a
trackball with a scroll ring, and it mechanically has some "kinetic"
behavior, and in fact I just tried it and quickly scrolling then
moving the mouse across a border causes both applications to scroll
some. My impression is that this is not desirable, I want all the
scrolling to go to the first program. The compositor could use a
timeout to do this.

My trackball is a good example of why I worry about clients doing
gestures. I probably need to disable kinetic scroll and I am worried
that some clients will not do it. It would be nice if this could
easily be disabled in every app by doing something to the compositor.

I would also look into how kinetic scrolling is being done on other
platforms. If they send events then we are really going to be stuck
trying to make RDP work on those platforms. You would at least have to
turn off the kinetic scrolling in the clients.

>> Well, maybe using a new scroll source
>> like LIBINPUT_POINTER_AXIS_SOURCE_KINETIC could be a solution. I'm very new
>> to wayland and co. and I'm probably not legitimate to make this kind of
>> choices.
>
> I don't think this would help much. Adding a new source means we need it
> supported on the client side by toolkits. And at that point you might
> as well get proper kinetic scrolling implemented there.

The extra field added to the scroll events would be in a new api
version. Old clients would still get all the events but could not tell
if they were kinetic scroll events or not.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Kinetic scroll in libinput Xorg driver

[Bill Spitzak]

On Mon, Oct 24, 2016 at 5:31 PM, Peter Hutterer
 wrote:
> On Mon, Oct 24, 2016 at 06:42:31PM +, Alexis BRENON @Wayland wrote:
>> Hello everyone,
>>
>> I would like to implement kinetic scroll in the libinput driver for Xorg.
>>
>> I know that it's probably not the intended use of libinput ; as explained
>> in the documentation, it's the client that have to manage that.
>>
>> However, as an Xorg user not happy with the synaptics driver, I would like
>> to add a similar feature (fixing small disagreements encountered with
>> synaptics) to libinput, allowing Xorg users to easily move to libinput
>> without losing this feature.
>>
>> My first idea is to implement the kinetic scroll using a thread that sends
>> axis events as long as there is no button event, key event or motion event
>> higher than a threshold.
>>
>> It makes some time since the last time I developed in C, and maybe it's not
>> the better way to do it. I would be happy to hear your advices.
>>
>> One thing I'm thinking of is then to add some options in the Xorg
>> configuration file to enable/disable this feature, choose the events
>> stopping the kinetic scroll and change some thresholds. This will allow to
>> easily disable this feature in the future in case the clients manage the
>> kinetic scroll on their own.
>>
>> What do you think of this? Is there someone already working on it? Is my
>> proposition a good way to implement it?
>
> simple answer - "no". sorry :)
>
> there are two reasons we didn't implement kinetic scrolling in libinput. one
> is the series of bugs we have in synaptics with stopping scrolling at the
> right time (leading to inadvertent zooms, etc.). that's easier in libinput
> because we know about all devices but the fundamental problem remains - a
> driver cannot know when kinetic scrolling is appropriate. e.g. sending
> scroll events when the document is already at the bottom?

What? How about *normal* scroll events. Seems to be no problem with
sending them "when the document is at the bottom". Amazingly the
client apps have logic and are able to ignore these events! Will
wonders never cease!

> What's the
> threshold going to be? A single pixel movement may land you in another
> window that you don't want to send scroll events to.

What? Can you give an example of an api where scrolling that is
accepted by a client can also cause the focus to change? Also it sure
seems like if scrolling can change the focus then the compositor
better be well aware of the events. Of course if "kinetic scrolling"
should not change the focus, but "normal scrolling" does, this is
trivially solved by making these be different events.

? A two-pixel movement
> may be considered acceptable to not stop scroll events.
> A shift+scroll may be acceptable in one application but not in another.

All of these are good reasons for libinput to do it. Then there is
consistent behavior between clients, rather than every toolkit and
client doing it's own thing.

> Pushing this to the toolkits and applications is the only sane long-term
> solution. Anything else gives us a short-term solution that in two-three
> years time we'll just waste time having to working around.

The solution to all your objections is trivial: make the kinetic
scroll events distinguishable from the normal scroll events. Then if a
client really can't deal with the kinetic scrolling supplied by
libinput, it can ignore these events and do it itself.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v4 7/7] xdg-shell: Introduce xdg_positioner

[Bill Spitzak]

As attachement, but I think gmail is messing this up:

On Fri, Jul 22, 2016 at 6:39 PM, Bill Spitzak <spit...@gmail.com> wrote:
> /* Translate xdg_positioner v4 settings to proposed list-of-rectangles api
>  *
>  * I cannot find any proposed implementation, so I have to base this
> off the comments
>  * in the protocol spec, which are somewhat ambiguous. See FIXME notes
> for where I
>  * guessed and may have mis-interpreted the spec.
>  */
>
> #include 
> #include 
>
> /* bits for anchor and gravity */
> #define TOP 1
> #define BOTTOM 2
> #define LEFT 4
> #define RIGHT 8
>
> /* bits for constrain_adjustment */
> #define SLIDE_X 1
> #define SLIDE_Y 2
> #define FLIP_X 4
> #define FLIP_Y 8
>
> /* v4 positioner data */
> typedef struct {
> struct { int width; int height; } size;
> struct { int x; int y; int width; int height; } anchor_rect;
> int anchor;
> int gravity;
> int constrain_adjustment;
> struct { int x; int y; } offset;
> } V4Positioner;
>
> /* The new positioner api */
> extern void add_rectangle( int x0, int y0, int x1, int y1 ) {
> printf("add_rectangle( %d, %d, %d, %d );\n", x0, y0, x1, y1);
> }
>
> /* Possibly the api should support this rather than the 4-number rectangle.
>  * x0,y0 must be upper-left corner, x1,y1 the lower-right corner, x,y
> is preferred
>  * location which must be inside the rectangle.
>  */
> void add_rectangle6( int x, int y, int x0, int y0, int x1, int y1 )
> {
> if (y > y0) {
> if (x > x0)
> add_rectangle(x, y, x0, y0);
> add_rectangle(x, y, x1, y0);
> }
> if (x > x0)
> add_rectangle(x, y, x0, y1);
> add_rectangle(x, y, x1, y1);
> }
>
> /* Do one part of a "flip" */
> void single_anchor(const V4Positioner* v4, int anchor, int gravity,
> int constrain_adjustment) {
>
> int x, y; /* preferred position */
>
> /* Find anchor point */
> if (anchor & LEFT)
> x = v4->anchor_rect.x;
> else if (anchor & RIGHT)
> x = v4->anchor_rect.x + v4->anchor_rect.width;
> else
> x = v4->anchor_rect.x + v4->anchor_rect.width / 2;
>
> if (anchor & TOP)
> y = v4->anchor_rect.y;
> else if (anchor & BOTTOM)
> y = v4->anchor_rect.y + v4->anchor_rect.height;
> else
> y = v4->anchor_rect.y + v4->anchor_rect.height / 2;
>
> /* move to top-left of size */
> if (gravity & LEFT)
> ;
> else if (gravity & RIGHT)
> x -= v4->size.width;
> else
> x -= v4->size.width / 2;
> if (gravity & TOP)
> ;
> else if (gravity & BOTTOM)
> y -= v4->size.height;
> else
> y -= v4->size.height / 2;
>
> /* Handle offset.
>  * FIXME: I am assuming the "widget in the child" is a rectangle
> defined by offset,size.
>  * Documentation seems to imply the meaning of offset depends on
> the gravity, but
>  * that is pretty useless for FLIP setups so I did not do that.
>  */
> x -= v4->offset.x;
> y -= v4->offset.y;
>
> /* Add slide to get resulting rectangles
>  * FIXME: unclear if slide is limited to touch the anchor
> rectangle. I believe
>  * this is not true so I use INT_MAX here.
>  * FIXME: unclear if slide is limited to touch the parent surface.
> My opinion
>  * now is that the compositor can enforce this.
>  */
> int x0, y0, x1, y1;
> if (constrain_adjustment & SLIDE_X) {
> x0 = -INT_MAX;
> x1 = +INT_MAX;
> } else {
> x0 = x1 = x;
> }
> if (constrain_adjustment & SLIDE_Y) {
> y0 = -INT_MAX;
> y1 = +INT_MAX;
> } else {
> y0 = y1 = y;
> }
>
> add_rectangle6(x, y, x0, y0, x1, y1);
> }
>
> /* Do the full conversion.
>  * FIXME: This will produce redundant identical rectangles. Preventing
> this requires more
>  * testing for useless flip states.
>  */
> void convert(const V4Positioner* v4) {
>
> if (v4->constrain_adjustment & FLIP_Y) {
> /* try the preferred position first, no sliding */
> single_anchor(v4, v4->anchor, v4->gravity,
> v4->constrain_adjustment & (~SLIDE_Y));
> /* try the flipped position */
> single_anchor(v4, v4->anchor ^ (TOP|BOTTOM), v4->gravity ^ 
> (TOP|BOTTOM),
>   v4->constrain_adjustment & (~SLIDE_Y));
> /* FIXME: this only does slide on the original side. Unclear
> if slide is on other s

Re: [PATCH wayland-protocols v4 7/7] xdg-shell: Introduce xdg_positioner

[Bill Spitzak]

/* Translate xdg_positioner v4 settings to proposed list-of-rectangles api
 *
 * I cannot find any proposed implementation, so I have to base this
off the comments
 * in the protocol spec, which are somewhat ambiguous. See FIXME notes
for where I
 * guessed and may have mis-interpreted the spec.
 */

#include 
#include 

/* bits for anchor and gravity */
#define TOP 1
#define BOTTOM 2
#define LEFT 4
#define RIGHT 8

/* bits for constrain_adjustment */
#define SLIDE_X 1
#define SLIDE_Y 2
#define FLIP_X 4
#define FLIP_Y 8

/* v4 positioner data */
typedef struct {
struct { int width; int height; } size;
struct { int x; int y; int width; int height; } anchor_rect;
int anchor;
int gravity;
int constrain_adjustment;
struct { int x; int y; } offset;
} V4Positioner;

/* The new positioner api */
extern void add_rectangle( int x0, int y0, int x1, int y1 ) {
printf("add_rectangle( %d, %d, %d, %d );\n", x0, y0, x1, y1);
}

/* Possibly the api should support this rather than the 4-number rectangle.
 * x0,y0 must be upper-left corner, x1,y1 the lower-right corner, x,y
is preferred
 * location which must be inside the rectangle.
 */
void add_rectangle6( int x, int y, int x0, int y0, int x1, int y1 )
{
if (y > y0) {
if (x > x0)
add_rectangle(x, y, x0, y0);
add_rectangle(x, y, x1, y0);
}
if (x > x0)
add_rectangle(x, y, x0, y1);
add_rectangle(x, y, x1, y1);
}

/* Do one part of a "flip" */
void single_anchor(const V4Positioner* v4, int anchor, int gravity,
int constrain_adjustment) {

int x, y; /* preferred position */

/* Find anchor point */
if (anchor & LEFT)
x = v4->anchor_rect.x;
else if (anchor & RIGHT)
x = v4->anchor_rect.x + v4->anchor_rect.width;
else
x = v4->anchor_rect.x + v4->anchor_rect.width / 2;

if (anchor & TOP)
y = v4->anchor_rect.y;
else if (anchor & BOTTOM)
y = v4->anchor_rect.y + v4->anchor_rect.height;
else
y = v4->anchor_rect.y + v4->anchor_rect.height / 2;

/* move to top-left of size */
if (gravity & LEFT)
;
else if (gravity & RIGHT)
x -= v4->size.width;
else
x -= v4->size.width / 2;
if (gravity & TOP)
;
else if (gravity & BOTTOM)
y -= v4->size.height;
else
y -= v4->size.height / 2;

/* Handle offset.
 * FIXME: I am assuming the "widget in the child" is a rectangle
defined by offset,size.
 * Documentation seems to imply the meaning of offset depends on
the gravity, but
 * that is pretty useless for FLIP setups so I did not do that.
 */
x -= v4->offset.x;
y -= v4->offset.y;

/* Add slide to get resulting rectangles
 * FIXME: unclear if slide is limited to touch the anchor
rectangle. I believe
 * this is not true so I use INT_MAX here.
 * FIXME: unclear if slide is limited to touch the parent surface.
My opinion
 * now is that the compositor can enforce this.
 */
int x0, y0, x1, y1;
if (constrain_adjustment & SLIDE_X) {
x0 = -INT_MAX;
x1 = +INT_MAX;
} else {
x0 = x1 = x;
}
if (constrain_adjustment & SLIDE_Y) {
y0 = -INT_MAX;
y1 = +INT_MAX;
} else {
y0 = y1 = y;
}

add_rectangle6(x, y, x0, y0, x1, y1);
}

/* Do the full conversion.
 * FIXME: This will produce redundant identical rectangles. Preventing
this requires more
 * testing for useless flip states.
 */
void convert(const V4Positioner* v4) {

if (v4->constrain_adjustment & FLIP_Y) {
/* try the preferred position first, no sliding */
single_anchor(v4, v4->anchor, v4->gravity,
v4->constrain_adjustment & (~SLIDE_Y));
/* try the flipped position */
single_anchor(v4, v4->anchor ^ (TOP|BOTTOM), v4->gravity ^ (TOP|BOTTOM),
  v4->constrain_adjustment & (~SLIDE_Y));
/* FIXME: this only does slide on the original side. Unclear
if slide is on other side too.
 */
}

/* FIXME: what happens if both FLIP_X and FLIP_Y are set is
unclear. This version only
 * tries three locations, not four.
 */
if (v4->constrain_adjustment & FLIP_X) {
/* try the preferred position first, no sliding */
single_anchor(v4, v4->anchor, v4->gravity,
v4->constrain_adjustment & (~SLIDE_X));
/* try the flipped position */
single_anchor(v4, v4->anchor ^ (LEFT|RIGHT), v4->gravity ^ (LEFT|RIGHT),
  v4->constrain_adjustment & (~SLIDE_X));
}

/* Do the non-flipped position */
single_anchor(v4, v4->anchor, v4->gravity, v4->constrain_adjustment);
}

int main() {
V4Positioner v4;

v4.size.width = 100;
v4.size.height = 100;

v4.anchor_rect.x = 60;
v4.anchor_rect.y = 90;
v4.anchor_rect.width = 0;
v4.anchor_rect.height = 0;

v4.anchor = 0;
v4.gravity = TOP;
v4.constrain_adjustment = FLIP_Y | SLIDE_X;

v4.offset.x = 0;
v4.offset.y = 0;

Re: [PATCH wayland-web] Build instructions for Ubuntu 16.04

[Bill Spitzak]

On 06/18/2016 10:16 PM, dar...@chaosreigns.com wrote:

Most recent Debian based build instructions are for Mint 17, they didn't
work (something failed), and the list of what does and doesn't need to be
built from source has changed significantly.  I tested this on a pristine
install via virtualbox.  It's been a while.  Pretty sweet that weston
actually runs under virtualbox now.


Looks good to me. Nice to see that they updated all that x11proto stuff.

I like adding the error message you got to the comments.

One minor change below.


---
  building.html|   3 ++
  ubuntu16.04.html | 157 +++
  2 files changed, 160 insertions(+)
  create mode 100644 ubuntu16.04.html

diff --git a/building.html b/building.html
index 1ff9ea2..0a26061 100644
--- a/building.html
+++ b/building.html
@@ -48,6 +48,9 @@ or hardware:

  

+Building Weston and XWayland on
+Ubuntu 16.04. May be useful for any Debian-derived system.
+
  Building Weston and XWayland on
  Ubuntu 12.04. May be useful for any Debian-derived system.


I think these links should be sorted by time. Probably in reverse order: 
put yours first, then the Mint 17, then the Ubuntu 12.04 last.




diff --git a/ubuntu16.04.html b/ubuntu16.04.html
new file mode 100644
index 000..0665def
--- /dev/null
+++ b/ubuntu16.04.html
@@ -0,0 +1,157 @@
+http://www.w3.org/TR/html4/strict.dtd;>
+
+
+
+
+
+Building Weston on Ubuntu 16.04
+
+
+
+
+Building Weston on Ubuntu 16.04
+
+The following sequence of commands successfully built Weston and
+XWayland on a pristine Ubuntu 16.04 system, on June 19, 2016. These
+commands will probably work on any system based on Ubuntu 16.04.
+
+
+# setup environment for local install:
+export WLD=$HOME/install
+export LD_LIBRARY_PATH=$WLD/lib
+export PKG_CONFIG_PATH=$WLD/lib/pkgconfig/:$WLD/share/pkgconfig/
+export PATH=$WLD/bin:$PATH
+export ACLOCAL_PATH=$WLD/share/aclocal
+export ACLOCAL="aclocal -I $ACLOCAL_PATH"
+mkdir -p $ACLOCAL_PATH
+export MAKEFLAGS="j5" # run 5 threads, or use your own 
flags
+
+
+# libwayland:
+
+# The program 'git' is currently not installed. You can 
install it by typing:
+sudo apt install git
+
+# ./autogen.sh: 7: ./autogen.sh: autoreconf: not 
found
+sudo apt install autoconf
+
+# Makefile.am:176: error: Libtool library used but 'LIBTOOL' 
is undefined
+sudo apt install libtool
+
+# No package 'libffi' found
+sudo apt install libffi-dev
+
+# configure: error: Can't find expat.h. Please install 
expat.
+sudo apt install libexpat1-dev
+
+# configure: error: Package requirements (libxml-2.0) were not 
met:
+# .pc file is libxml-2.0.pc
+sudo apt install libxml2-dev
+
+# * These three are not necessary with the 
--disable-documentation flag:
+# configure: error: Documentation build requested but doxygen 
not found. Install doxygen or disable the documentation using --disable-documentation
+# configure: error: Documentation build requested but xmlto 
not found. Install xmlto or disable the documentation using --disable-documentation
+# configure: error: Documentation build requested but 
graphviz's dot not found. Install graphviz or disable the documentation using 
--disable-documentation
+sudo apt install doxygen xmlto graphviz
+# * xmlto pulls 814 MB of packages.
+
+git clone git://anongit.freedesktop.org/wayland/wayland
+cd wayland
+./autogen.sh --prefix=$WLD # 
--disable-documentation
+make  make install
+cd ..
+
+
+# wayland-protocols:
+
+git clone git://anongit.freedesktop.org/wayland/wayland-protocols
+cd wayland-protocols
+./autogen.sh --prefix=$WLD
+make  make install
+cd ..
+
+
+# libinput:
+
+# configure: error: Package requirements (mtdev = 1.1.0) 
were not met:
+sudo apt install libmtdev-dev
+
+# configure: error: Package requirements (libudev) were not 
met:
+sudo apt install libudev-dev
+
+# configure: error: Package requirements (libevdev = 0.4) 
were not met:
+sudo apt install libevdev-dev
+
+# configure: error: Package requirements (libwacom = 0.12) 
were not met:
+sudo apt install libwacom-dev
+
+git clone git://anongit.freedesktop.org/wayland/libinput
+cd libinput
+./autogen.sh --prefix=$WLD
+make  make install
+cd ..
+
+
+# weston:
+
+# configure: error: Package requirements (egl glesv2) were not 
met:
+sudo apt install libgles2-mesa-dev
+
+# configure: error: Package requirements (xcb xcb-xfixes 
xcb-composite xcursor cairo-xcb) were not met:
+sudo apt install libxcb-composite0-dev libxcursor-dev libcairo2-dev
+
+# configure: error: Package requirements (libudev = 136 libdrm 
= 2.4.30 gbm mtdev = 1.1.0) were not met:
+sudo apt install libgbm-dev
+
+# configure: error: weston-launch requires pam
+sudo apt install libpam0g-dev
+
+git clone git://anongit.freedesktop.org/wayland/weston
+cd weston
+./autogen.sh --prefix=$WLD --disable-setuid-install
+make  make install
+cd ..
+
+
+# X Server:
+
+sudo apt install xutils-dev # xserver: configure.ac:38: error: 
must install xorg-macros 1.14 or later before running autoconf/autogen
+sudo apt 

Re: [PATCH 1/5] scanner: Fixed doxygen group name for _add_listener

[Bill Spitzak]

I did test this, it makes the add_listener functions show up in the doxygen
output.

I noticed this because I copied the incorrect line to add my own functions
and was wondering why they were not coming out in the doxygen output.
​
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Feedback on xdg-shell v5

[Bill Spitzak]

On Mon, May 9, 2016 at 8:18 PM, Jonas Ådahl  wrote:

> On Fri, Apr 29, 2016 at 12:37:22PM +0300, Pekka Paalanen wrote:
> > On Fri, 29 Apr 2016 15:31:28 +0800
> > Jonas Ådahl  wrote:
> >
> > > On Thu, Apr 28, 2016 at 02:08:07PM +0300, Pekka Paalanen wrote:
> > > > On Thu, 28 Apr 2016 17:36:58 +0800
> > > > Jonas Ådahl  wrote:
> > > >
> > > > > On Thu, Apr 28, 2016 at 10:36:14AM +0200, Martin Graesslin wrote:
> > > > > > Hi Wayland and Plasma,
> > > > > >
> > > > > > I finished the implementation of xdg-shell in KWayland [1] and
> KWin [2].
> > > > > > Overall it was more straight forward than I would have expected.
> Especially
> > > > > > the changes to KWin were surprisingly minor (with one huge
> exception).
> > > > > >
> > > > > > Now some questions/remarks:
> > > >
> > > > > > * Why is the ping on the shell and not on the surface? I would
> have expected
> > > > > > to ping the surface. At least that's how I would want to do it
> from KWin.
> > > > >
> > > > > Because you don't ping a surface, you ping the client. It's the
> client
> > > > > that may be inresponsive, and if the client is in responsive, it's
> safe
> > > > > to assume all its surfaces are as well.
> > > >
> > > > Hi,
> > > >
> > > > I was going to plain agree and say, that all events to a client come
> > > > through the same connection (wl_display), and it does not make sense
> to
> > > > have a series of ping events on different objects when they could
> just
> > > > be collapsed into one equivalent event.
> > > >
> > > > But then I thought about multiple client-side event queues. If a
> client
> > > > has multiple queues, and windows on different queues, it could be
> > > > possible that only some queues get stuck while others are serviced.
> > > > With per-surface pings, the compositor should then "shade out" only
> the
> > > > windows where the queue is actually stuck.
> > > >
> > > > Would it be worth it?
> > >
> > > I doubt it. What would you do? It's not like you can disconnect half of
> > > a client.
> >
> > Wasn't it more about marking unresponsive surfaces and providing UI
> > aids for dealing with them, e.g. moving the window out of the way?
> >
> > If you hover over the "kill this app" option, the compositor could e.g.
> > color all the surfaces that would go, not just the ones unresponsive.
> >
> > > >
> > > > Or, is there an underlying assumption that a client might not send
> pong
> > > > requests as a simple reaction to ping events directly, but delay or
> > > > delegate it to some mechanism responsible for other updates?
> > > >
> > > > That is, is the ping-pong protocol a keep-alive for the Wayland
> > > > connection, for client's event queues, or something deeper in the
> > > > client?
> > >
> > > My understanding of the ping-pong protocol is to make it possible for
> > > the compositor to know when a client has frozen so that it can get rid
> > > of it (ala "Force Quit").
> >
> > Yeah, that's the final action, but there could be some less drastic
> > options too.
> >
> > > > > >
> > > > > > The biggest problem for me is the request set_window_geometry. I
> think I
> > > > > > mentioned it already before on the wayland list. Basically I
> have no idea how
> > > > > > to implement that in KWin. We have only one geometry for a
> window and that's
> > > > > > mapped to the size of the surface/x11 pixmap. This geometry is
> used all over
> > > > > > the place, for positioning, for resizing and for rendering. I
> cannot add
> > > > > > support for this without either breaking code or having to
> introduce a new
> > > > > > internal API. That's lots of work with high potential for
> breakage :-(
> > > >
> > > > Have you looked at what you need to do to support windows that are
> > > > built from non-overlapping sub-surfaces, like what Jonas describes
> below?
> > > >
> > > > I suspect you might end up having to do that major internal API work
> > > > anyway by the sounds of it. A window may be a collection of surfaces,
> > > > not just one.
> > > >
> > > > How do you do the window geometry with server-side decorations? Why
> is
> > > > using only a part of client surface so different from using a
> > > > combination of client and server-only surfaces?
> > > >
> > > > > >
> > > > > > From the description it seems to be only relevant for shadows.
> Could we make
> > > > > > shadows an optional part in xdg-shell? That the server can
> announce that it
> > > > > > supports shadows in the surface?
> > > > >
> > > > > It's not only about shadow. Let me explain a scenario where a
> window
> > > > > geometry is needed, even when there is a mode where no shadow is
> drawn
> > > > > by the client.
> > > > >
> > > > > Consider we have the following window:
> > > > >
> > > > >
> > > > > +---+
> > > > > |   A window  X |
> > > > > +---+
> > > > > |  

Re: [PATCH weston v1 3/3] compositor-x11: remove manual mouse button grab/ungrab

[Bill Spitzak]

Does the x11 compositor have to do this at all? It owns that window so it
gets automatic grabs. This is for one client to eat the events being passed
to another client.


On Fri, May 13, 2016 at 4:34 AM, Benoit Gschwind 
wrote:

> In current compositor-x11, the mouse buttons are grabbed and ungrabbed
> manually that may produce weird cases like starting a grab while the
> buttons are already released, due to asynchronous X11 events dispatching.
>
> The patch avoid the issue by using the better passive button grab, that
> automatically grab buttons as soon as they occur. The passive grab
> include an automatic ungrab when all mouse button are released.
>
> This probably fix some mysterious bugs.
>
> Signed-off-by: Benoit Gschwind 
> ---
>  src/compositor-x11.c | 27 +--
>  1 file changed, 13 insertions(+), 14 deletions(-)
>
> diff --git a/src/compositor-x11.c b/src/compositor-x11.c
> index 5b76dba..ae155d1 100644
> --- a/src/compositor-x11.c
> +++ b/src/compositor-x11.c
> @@ -882,6 +882,19 @@ x11_backend_create_output(struct x11_backend *b, int
> x, int y,
>
> x11_output_set_wm_protocols(b, output);
>
> +   /* Automatically grab and ungrab mouse buttons */
> +   xcb_grab_button(b->conn, 0, output->window,
> +   XCB_EVENT_MASK_BUTTON_PRESS |
> +   XCB_EVENT_MASK_BUTTON_RELEASE |
> +   XCB_EVENT_MASK_POINTER_MOTION |
> +   XCB_EVENT_MASK_ENTER_WINDOW |
> +   XCB_EVENT_MASK_LEAVE_WINDOW,
> +   XCB_GRAB_MODE_ASYNC,
> +   XCB_GRAB_MODE_ASYNC,
> +   output->window, XCB_CURSOR_NONE,
> +   XCB_BUTTON_INDEX_ANY,
> +   XCB_MOD_MASK_ANY);
> +
> xcb_map_window(b->conn, output->window);
>
> if (fullscreen)
> @@ -1052,20 +1065,6 @@ x11_backend_deliver_button_event(struct x11_backend
> *b,
> if (!output)
> return;
>
> -   if (is_button_pressed)
> -   xcb_grab_pointer(b->conn, 0, output->window,
> -XCB_EVENT_MASK_BUTTON_PRESS |
> -XCB_EVENT_MASK_BUTTON_RELEASE |
> -XCB_EVENT_MASK_POINTER_MOTION |
> -XCB_EVENT_MASK_ENTER_WINDOW |
> -XCB_EVENT_MASK_LEAVE_WINDOW,
> -XCB_GRAB_MODE_ASYNC,
> -XCB_GRAB_MODE_ASYNC,
> -output->window, XCB_CURSOR_NONE,
> -button_event->time);
> -   else
> -   xcb_ungrab_pointer(b->conn, button_event->time);
> -
> if (!b->has_xkb)
> update_xkb_state_from_core(b, button_event->state);
>
> --
> 2.7.3
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v2 6/7] xdg-shell: Make xdg_popup non-grabbing by default

[Bill Spitzak]

On Tue, May 10, 2016 at 10:50 PM, Jonas Ådahl  wrote:

> Turn xdg_popup into plain temporary child surfaces without any grabbing
> or mapping order requirements by default.
>
> In order to create grabbing popup chains, a new request 'grab' is
> introduced which enables more or less the same semantics and
> requirements as xdg_popup previously had related to grabbing, stacking
> and mapping order.
>
> This enables using xdg_popup for creating tooltips and other user
> interface elements that does not want to take an explicit grab.
>

YAY

However clients need the ability to "grab" from any surface. Otherwise they
cannot use their own graphics to create popup menus (they can make a dummy
invisible popup window, but that seems like a kludge), or make an interface
that uses multiple popup windows but can be in a state where there are zero
of them displayed. Also necessary if you want to emulate X grabs since they
can be done from any surface. Basically the grab request should be moved to
xdg_surface.

Dismissing a grab should not unmap the popup surfaces (except perhaps if
the client is failing to respond to pings, but in that case I would have a
click anywhere remove the popups whether or not a grab was done). This is a
requirement so the client can synchronize other graphics with the removal
of the popups. It sounds like this is true right now, but the description
of grab contains a lot of text that implies some relationship that should
maybe be deleted.

The idea of sending a copy of every event to every client surface is pretty
ugly. You need at least a 'frame' event so the client can tell which blocks
belong together. Instead the events can go to the surface that did the
grab. The compositor should send events to the client telling the actual
position of any child surface relative to it's parent, this allows a client
to translate an event in any child surface to any other one.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] client: "Ex" versions of constructors, alternative to proxy_wrapper

[Bill Spitzak]

On Mon, May 2, 2016 at 10:42 PM, <spit...@gmail.com> wrote:

> From: Bill Spitzak <spit...@gmail.com>
>
> Scanner produces a xyz_create() for each object that wraps the
> wl_proxy_create function. For each constructor request a new "Ex" version
> is created that takes the created object. This allows the queue to be set
> before creation. The existing code using proxy_wrapper changed to use this.
>
> Comments/questions:
>
> wl_registry_bindEx is nyi and is needed


The comment (the proxy_wrapper does not fix this either) is for the events
and was added to the wrong paragraph:

You cannot use create for an object provided by an event, and I see no good
> way to achieve this. Not very important unless static wl_proxy is
> supported.
>
 (the proxy_wrapper does not fix this either)

It may be better for the create function to take an actual factory proxy
> pointer,
> rather than a wl_proxy*, to avoid casts.
>

I now think trying to reuse wl_proxy_create is a mistake. That function is
not being used by any other Wayland code and I guess is legacy. Instead
data from the factory object can be copied when the request is made, so no
factory has to be passed to create (which would not call wl_proxy_create
and would not need the lock). The example using the wl_callback would then
look like this:

callback = wl_callback_create(); /* sets interface and refcount */
wl_proxy_set_queue((struct wl_proxy *) callback, queue); /* sets
queue */
wl_callback_add_listener(callback, _listener, ); /* sets
dispatcher */
wl_display_syncEx(display, callback); /* sets display, version, id
*/

If set_queue was not called it could also copy the queue from the factory
object, but I'm not sure if that is necessary.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland v4] client: Introduce proxy wrappers

[Bill Spitzak]

On Fri, Apr 29, 2016 at 5:59 AM, Pekka Paalanen  wrote:

>
> > + pthread_mutex_lock(_proxy->display->mutex);
> > +
> > + wrapper->object.interface = wrapped_proxy->object.interface;
> > + wrapper->object.id = wrapped_proxy->object.id;
> > + wrapper->version = wrapped_proxy->version;
> > + wrapper->display = wrapped_proxy->display;
> > + wrapper->queue = wrapped_proxy->queue;
> > + wrapper->flags = WL_PROXY_FLAG_WRAPPER;
> > + wrapper->refcount = 1;
> > +
> > + pthread_mutex_unlock(_proxy->display->mutex);
> > +
> > + return wrapper;
> > +}
>
> I didn't want to postpone the landing of this any longer, but I still
> wonder if we really need that locking at all.
>

That locking is certainly not necessary.

If another thread could change the wrapped_proxy, it could easily change it
after the lock is dropped and this function returns, thus making the
proxy_wrapper incorrect anyway. So this lock is not preventing any problems.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-web] building: Remove deprecated mesa autogen option

[Bill Spitzak]

Seems quite likely to be correct.

Note that I got these instructions from some other Wayland build
instructions and it is quite possible it worked without this switch even in
old versions.


On Wed, Apr 27, 2016 at 6:44 AM, Yong Bakos  wrote:

> From: Yong Bakos 
>
> Using --disable-gallium-egl generates a warning when running autogen.sh,
> because the option has been deprecated. See:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1128372
>
> Signed-off-by: Yong Bakos 
> ---
>  building.html | 8 +---
>  1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/building.html b/building.html
> index b5a83dc..a669e31 100644
> --- a/building.html
> +++ b/building.html
> @@ -163,19 +163,13 @@ more recent releases.
>  
>  $ git clone http://cgit.freedesktop.org/mesa/mesa;>git://
> anongit.freedesktop.org/mesa/mesa
>  $ cd mesa
> -$ ./autogen.sh --prefix=$WLD --enable-gles2 --disable-gallium-egl \
> +$ ./autogen.sh --prefix=$WLD --enable-gles2 \
>--with-egl-platforms=x11,wayland,drm --enable-gbm --enable-shared-glapi
> \
>--with-gallium-drivers=r300,r600,swrast,nouveau
>  $ make  make install
>  $ cd ..
>  
>
> -We disable building the egl_gallium loader
> (--disable-gallium-egl)
> -so that on Intel 915 and 965 hardware we avoid harmless error messages at
> -runtime. The real
> -http://www.freedesktop.org/wiki/Software/gallium/;>Gallium
> -drivers will be built as DRI drivers, which egl_dri2 loader will load
> just fine.
> -
>  
>  Example mesa configure output.
>
> --
> 2.7.2
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
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

[Bill Spitzak]

On 04/12/2016 06:10 AM, Jonas Ådahl wrote:


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.

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

Re: [PATCH] xdg-shell: add set_max_size request

[Bill Spitzak]

I do not like clients having to update this value continuously as
conditions change. I would prefer any kind of design where the calculation
of the maximum size is deferred until it is actually used, ie at the point
that the user does whatever action attemts to make the window larger.

Perhaps an event similar to fullscreen saying "make yourself the largest
size you want" would work. I'm wondering if "maximize" can just be reused
for this.


On Mon, Apr 4, 2016 at 11:15 AM, Mike Blumenkrantz <
michael.blumenkra...@gmail.com> wrote:

>
>
> On Mon, Apr 4, 2016 at 1:17 PM Olivier Fourdan 
> wrote:
>
>> Hi Mike,
>>
>> > Hm, you raise some interesting points. However, I think your argument is
>> > somewhat misled by your claim that "this case is unique". If there is an
>> > application which does not want to be larger than a certain size, why
>> could
>> > there not also be an application which does not want to be smaller than
>> a
>> > certain size?
>>
>> It's unique because switching to maximize/fullscreen is not an
>> interactive resize, ie the client doesn't have its word on the state change
>> that implies the resize, and is mandatory configure event, until it's set
>> by the compositor (ie too late, the client must obey, period).
>>
>
> Maximize can mean different things in different cases. For example,
> suppose a compositor has a maximize policy where it can "maximize" a window
> to take up the top-left 25% of the screen. This size could be too small for
> the application, yet it falls within your non-interactive resize case.
>
>
>>
>> > It seems like continuing to add size hints based on this logic is almost
>> > guaranteed, especially if you then add in the point of tiling
>> > policies--surely handling tiling would be made even easier by adding
>> > min/step/aspect sizes!
>> >
>> > To me, xdg-shell should just be a bare minimum of things required to
>> > implement a UI with Wayland. Perhaps if there's a real need for size
>> hints
>> > (which I really hope there isn't, since it made X11 window sizing very
>> > annoying) then there should be a separate size hints protocol where all
>> of
>> > this can be implemented?
>>
>> One case where a compositor may need a min size hint is a tiling
>> window/compositing manager, so it can base its heuristics on those hints
>> from the clients to get the optimal window size for tiling, but I would let
>> those who implement such a window/compositor manager advocate for that,
>> it's not the specific case I'm interested in here :-)
>>
>> Cheers,
>> Olivier
>>
>
> Yes, I know you are not currently advocating for it, but you've proved my
> point--others will see this go in and then they will push for it. Adding
> any form of size hints is a slipper slope which leads to more size hints
> imo.
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] systemd: take over sockets created by systemd

[Bill Spitzak]

On Sun, Apr 3, 2016 at 1:18 PM, Friedrich, Eugen (ADITG/SW1) <
efriedr...@de.adit-jv.com> wrote:

> systemd provides a feature of socket-based activation, details in [1]
> This commit adds an implementation to check if sockets were provided by
> systemd and adds this as an additional socket to wayland display.
> before adding sockets are checked for the correctness:
> only AF_UNIX of type SOCK_STREAM are accepted
>
> This is usefull for early rendering use-cases where weston and
> early-rendering-application can be started parallel.
>
> [1] https://www.freedesktop.org/software/systemd/man/systemd.socket.html
>
> Signed-off-by: Eugen Friedrich 
> ---
>  configure.ac |  5 -
>  src/systemd-notify.c | 27 +++
>  2 files changed, 31 insertions(+), 1 deletion(-)
>  mode change 100644 => 100755 src/systemd-notify.c
>
> diff --git a/configure.ac b/configure.ac
> index 9e8115a..447cf6b 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -634,7 +634,10 @@ AC_ARG_ENABLE(systemd_notify,
>AS_HELP_STRING([--enable-systemd-notify],
>   [Enables systemd notifications to
>notify systemd about weston state
> -  and update watchdog.]),,
> +  and update watchdog.
> +  Also sockets provided by systemd
> +  in case of socket-base activation
> +  are added to wayland display]),,
>enable_systemd_notify=no)
>  AM_CONDITIONAL(SYSTEMD_NOTIFY_SUPPORT, test x$enable_systemd_notify =
> xyes)
>  if test "x$enable_systemd_notify" = "xyes"; then
> diff --git a/src/systemd-notify.c b/src/systemd-notify.c
> old mode 100644
> new mode 100755
> index e61db0f..0be1f6f
> --- a/src/systemd-notify.c
> +++ b/src/systemd-notify.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include "shared/helpers.h"
>  #include "shared/zalloc.h"
> @@ -79,6 +80,8 @@ module_init(struct weston_compositor *compositor,
> struct wl_event_loop *loop;
> long watchdog_time_conv;
> struct systemd_notifier *notifier;
> +   int fd;
>

I think you can move this declaration into the loop next to "int current_fd
= 0;"


> +   int systemd_socket_fds = 0;
>
> notifier = zalloc(sizeof *notifier);
> if (notifier == NULL)
> @@ -89,6 +92,30 @@ module_init(struct weston_compositor *compositor,
> wl_signal_add(>destroy_signal,
>   >compositor_destroy_listener);
>
> +   /*take additional display sockets if provided by systemd*/
> +   systemd_socket_fds = sd_listen_fds(1);
> +
> +   if (systemd_socket_fds > 0) {
> +   int current_fd = 0;
>

ie put it here.


> +
> +   for (;current_fd < systemd_socket_fds; current_fd++) {
> +   fd = SD_LISTEN_FDS_START + current_fd;
> +
> +   if (sd_is_socket(fd, AF_UNIX, SOCK_STREAM,1) > 0) {
> +   if
> (wl_display_add_socket_fd(compositor->wl_display, fd)) {
> +
>  weston_log("wl_display_add_socket_fd failed\n");
> +   return -1;
> +   }
> +   } else {
> +   weston_log("invalid socket provided from
> systemd\n");
> +   return -1;
> +   }
> +   }
> +
> +   weston_log("info: add %d socket(s) provided by systemd\n",
> +   current_fd);
> +   }
> +
> sd_notify(0, "READY=1");
>
> /* 'WATCHDOG_USEC' is environment variable that is set
> --
> 2.4.11
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] xdg-shell: add set_max_size request

[Bill Spitzak]

I think sending stepping size or aspect is not needed, but steps will 
work only if the client can add a constant. Ie the width can be n*A+B 
where A and B are specified by the client. The X11 version did not allow 
a client to add a border that was not a multiple of the steps thick, 
which made it pretty much impossible.


Aspect also needs the ability for the client to add a constant so a 
frame can be put around the fixed-content area.


Both of these I think are better handled by the client doing the resize 
however, so only min/max should be sent.


On 04/04/2016 07:20 PM, Carsten Haitzler (The Rasterman) wrote:

On Mon, 04 Apr 2016 19:44:58 + "Jasper St. Pierre" 
said:


I think min/max hints are acceptable in xdg-shell.


i agree. they are realistic things a apps have as constraints on their content.
knowing in advance what those constraints might be can make life for a
compositor much easier.

eg. if you set max size and its < screen size (or whatever size a maximized
window might be in the wm) the em/compositor can disable the maximize action
entirely.

already pointed out - tiling wms can alter their layout policy for content eg
placing content that has a small max height along the bottom or top of your
screen.

yes - asking for max size opens up min size too.

i would argue size stepping is kind of needed too - the case of a tiling wm
with eg:

+---+---+
| 1 | 2 |
+---+---+
| 3 | 4 |
+---+---+

if all the windows are terminals whose content is only correct at "size units"
(because otherwise the terminal pads out N pixels without expanding the
terminal grid there just wasting space), then when resizing the dividers across
the middle of the screen -0 dragging them up/down or left/right a wm might want
to limit the sizing to steps of N pixels assuming all clients involved share a
common size step (the implied default is 1 pixel). without this hint a wm is
unable to do anything sensible here.

i am not saying the wm MUST follow the hints. there are impossible cases. one
window (1) uses size step 10x10, and (2) uses 9x9... there are very few points
where they "agree". (at 0x0 +base, 90x90 + base , 180x180 + base etc.) so as a
wm i would assume it would only follow stepping if all steps are multiples of
each other eg 3x3, 6x6, 9x9 or 2x2, 4x4, 6x6, 8x8 etc. ... (or are the same).
clients still have to deal with arbitrary sizing in some sensible way.

aspect hints tho are rather painful. they assume a single piece of content that
has to retain aspect (eg 1 movie). i'd personally not want to go this far. :)


On Mon, Apr 4, 2016, 12:33 PM Mike Blumenkrantz <
michael.blumenkra...@gmail.com> wrote:


On Mon, Apr 4, 2016 at 3:30 PM Olivier Fourdan 
wrote:



Hi Mike,

- Original Message -

[...]

Yes, I know you are not currently advocating for it, but you've proved

my

point--others will see this go in and then they will push for it. Adding
any form of size hints is a slipper slope which leads to more size hints
imo.


My turn to play the Devil's advocate then :-)

And even if we end with more hints eventually, what is wrong with that?

I reckon if we had hints in X11, it's also because people have had a need
for such a mechanism...

Cheers,
Olivier



Sure, and as I said, I have no issues with that if a separate (optional)
protocol  is created for it. I just don't think that the best place for it
is in xdg-shell, which is supposed to be just a small core set of features
that are absolutely required in order to create a usable desktop
environment.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel






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

Re: history/semantics of uint32_t name

[Bill Spitzak]

The word "name" strongly implies that the data is a string. It does not
help that right next to it is "interface" which *is* a string.

Some variation of "server's id" would be clearer.

On Fri, Apr 1, 2016 at 12:59 AM, Pekka Paalanen  wrote:

> On Fri, 1 Apr 2016 09:44:07 +0800
> Jonas Ådahl  wrote:
>
> > On Thu, Mar 31, 2016 at 06:48:06PM -0500, Yong Bakos wrote:
> > > Hi,
> > > I've been investigating the semantics of the name parameter within
> > > the wl_registry interface, prompted by a recent dialog regarding my
> > > patch of arg summary attributes in wayland.xml.
>
> > I can't say for sure the reason behind using "name", but using "id"
> > would potentially be confused with the object "id"'s.
>
> This potential confusion is exactly the reason. Names are not ids.
>
>
> Thanks,
> pq
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v5] text: Create second version of text input protocol

[Bill Spitzak]

On Fri, Mar 25, 2016 at 12:16 AM, Daiki Ueno  wrote:

>
> > +  
> > + Allows to atomically send state updates from client.
> > +
> > + This request should follow after a batch of state updating requests
> > + like set_surrounding_text, set_content_type, set_cursor_rectangle
> and
> > + set_preferred_language.
>
> This sentence indicates that the request is used for some sort of
> synchronization between the client and compositor.  I'm wondering if it
> could perform a roundtrip using wl_callback, instead of generating a
> serial on the client side.  Then the serial could later be obtained from
> the compositor through wl_callback.done.  Would that cause any race
> conditions?
>

It's not a synchronization, all the requests are going from client to
server. It is to batch them or make them atomic, or as the wl_surface calls
it, it is to double-buffer the requests.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 3/7] gl-renderer: Implement & use check_extension

[Bill Spitzak]

On Mon, Mar 21, 2016 at 9:37 AM, Miguel A. Vico 
wrote:

> Using strstr(3) for checking for extensions is an error-prone mechanism
> as extension names can be prefixes of other extension names (see
> https://www.opengl.org/registry/doc/rules.html#using).
>
> This change implements the check_extension() function to properly check
> for an extension and replaces all usages of strstr(3).
>
> Signed-off-by: Miguel A Vico Moya 
> Reviewed-by: Andy Ritger 
> ---
>  src/gl-renderer.c | 56
> +--
>  1 file changed, 42 insertions(+), 14 deletions(-)
>
> diff --git a/src/gl-renderer.c b/src/gl-renderer.c
> index 1d6d98c..3ca1aed 100644
> --- a/src/gl-renderer.c
> +++ b/src/gl-renderer.c
> @@ -2701,6 +2701,34 @@ gl_renderer_destroy(struct weston_compositor *ec)
> free(gr);
>  }
>
> +static
> +bool check_extension(const char *extensions, const char *extension)
> +{
> +   size_t extlen = strlen(extension);
> +   const char *end = extensions + strlen(extensions);
> +
> +   while (extensions < end) {
> +   size_t n = 0;
> +
> +   /* Skip whitespaces, if any */
> +   if (*extensions == ' ') {
> +   extensions++;
> +   continue;
> +   }
> +
> +   n = strcspn(extensions, " ");
> +
> +   /* Compare strings */
> +   if (n == extlen && strncmp(extension, extensions, n) == 0)
> +   return true; /* Found */
> +
> +   extensions += n;
> +   }
> +
> +   /* Not found */
> +   return false;
> +}
> +
>

Slightly faster version that avoids some temporaries and strlen calls:

static
bool check_extension(const char *extensions, const char *extension)
{
while (*extensions) {
size_t n = strcspn(extensions, " ");

/* Skip whitespaces, if any */
if (n < 1) {
extensions++;
continue;
}

/* Compare strings */
if (strncmp(extension, extensions, n) == 0 && !extension[n])
return true; /* Found */

extensions += n;
}

/* Not found */
return false;
}
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-web] Updated build instructions for wayland-protocols and libwacom

[Bill Spitzak]

On Tue, Mar 8, 2016 at 11:49 PM, Bryce Harrington <br...@osg.samsung.com>
wrote:

> On Wed, Mar 09, 2016 at 12:54:11PM +1000, Peter Hutterer wrote:
> > On Tue, Mar 08, 2016 at 06:39:43PM -0800, Bill Spitzak wrote:
> > > On Tue, Mar 8, 2016 at 6:12 PM, Peter Hutterer <
> peter.hutte...@who-t.net>
> > > wrote:
> > >
> > > > On Fri, Mar 04, 2016 at 10:16:30PM -0800, spit...@gmail.com wrote:
> > > > > From: Bill Spitzak <spit...@gmail.com>
> > > > >
> > > > > The Mint instructions have been tested, I had to guess at the
> Ubuntu12
> > > > > instructions as I no longer have that machine.
> > > >
> > > > fwiw, I do question the need for build instructions for a new
> graphics
> > > > stack
> > > > on a >3 year old release.
> > >
> > > I am unsure, but for a lot of people trying to use work machines they
> are
> > > stuck with such old versions. I know my previous job (Oblong
> Industries) is
> > > still using this version of Ubuntu. Here at Dreamworks they are even
> older
> > > RHEL6 and I cannot compile it at all.
> >
> > I don't doubt that some people are trying to compile it, but as I said, I
> > question the need to provide build instructions (which look official when
> > they're on the wayland website). especially if they're untested.
>
> Personally I don't see a problem with it, it's just keeping already
> published documentation updated as stuff changes.
>

I think it should be kept as it contains the hair needed to get Mesa to
compile, which was by far the biggest sticking point in getting Wayland
working. That problem may come up again if Wayland is changed to depend on
a bleeding-edge Mesa dependency.


> That said, I agree with 12.04 we're probably pretty deep into the long
> tail for users.  Especially with 16.04 coming out next month I wouldn't
> see a problem just dropping the 12.04 directions at this point.
>
> Bryce
>
> > > > ---
> > > > >  mint17.html  | 21 ++---
> > > > >  ubuntu12.04.html | 13 +++--
> > > > >  2 files changed, 29 insertions(+), 5 deletions(-)
> > > > >
> > > > > diff --git a/mint17.html b/mint17.html
> > > > > index ae1c5a8..f32ef9e 100644
> > > > > --- a/mint17.html
> > > > > +++ b/mint17.html
> > > > > @@ -12,7 +12,7 @@
> > > > >  Building Weston on Linux Mint 17
> > > > >
> > > > >  The following sequence of commands successfully built Weston
> and
> > > > > -XWayland on a Linux Mint 17 Cinnamon system, on October 28 2014.
> These
> > > > > +XWayland on a Linux Mint 17.3 Cinnamon system, on March 2, 2016.
> These
> > > > >  commands will probably work on any system based on Ubuntu
> 14.04.
> > > > >
> > > > >  This is considerably easier than earlier systems as the
> distributed
> > > > > @@ -32,7 +32,7 @@ mkdir -p $ACLOCAL_PATH
> > > > >
> > > > >  # libwayland:
> > > > >
> > > > > -apt install libffi-dev libexpat-dev
> > > > > +apt install libffi-dev libexpat-dev libxml2-dev
> > > > >  apt install doxygen xmlto # or use
> > > > --disable-documentation
> > > > >
> > > > >  git clone git://anongit.freedesktop.org/wayland/wayland
> > > > > @@ -41,10 +41,25 @@ cd wayland
> > > > >  make -j 9 && make install
> > > > >  cd ..
> > > > >
> > > > > +# wayland-protocols:
> > > > > +
> > > > > +git clone git://anongit.freedesktop.org/wayland/wayland-protocols
> > > > > +cd wayland-protocols
> > > > > +./autogen.sh --prefix=$WLD
> > > > > +make -j 9 && make install
> > > > > +cd ..
> > > > > +
> > > > >  # libinput:
> > > > >
> > > > >  apt install libmtdev-dev libudev-dev libevdev-dev
> > > > >
> > > > > +# newer version of libwacom is needed than
> in apt
> > > > > +apt install libgudev-1.0-dev
> > > > > +git clone git://git.code.sf.net/p/linuxwacom/libwacom
> > > > > +cd libwacom
> > > > > +make -j 9 && make install
> > > > > +cd ..
> > > > > +
> > > > >  git clone git://anongit.freedesktop.org/wayland/libinput
> > > > >  cd libinput
> > &

Re: [PATCH 1/2] clients & tests: Unify multiple definitions of x*alloc and related functions

[Bill Spitzak]

On Tue, Mar 15, 2016 at 3:23 PM, Bryce Harrington 
wrote:

>
> --- a/clients/ivi-shell-user-interface.c
> +++ b/clients/ivi-shell-user-interface.c
> @@ -40,6 +40,7 @@
>  #include "shared/config-parser.h"
>  #include "shared/helpers.h"
>  #include "shared/os-compatibility.h"
> +#include "shared/xalloc.h"
>  #include "shared/zalloc.h"
>  #include "ivi-application-client-protocol.h"
>  #include "ivi-hmi-controller-client-protocol.h"
> @@ -164,18 +165,6 @@ hmi_homescreen_setting {
>  };
>
>  static void *
> -fail_on_null(void *p, size_t size, char *file, int32_t line)
> -{
> -   if (size && !p) {
> -   fprintf(stderr, "%s(%d) %zd: out of memory\n",
> -   file, line, size);
> -   exit(EXIT_FAILURE);
> -   }
> -
> -   return p;
> -}
>

The deleted ones in ivi purposely does not fail if size==0. But it appears
they are only called by the MEM_ALLOC macro and that is only called with
sizeof() which is not going to be zero, so this is ok.

>
> -   fail_on_null(window->xdg_surface);
> +   fail_on_null(window->xdg_surface, 1, __FILE__, __LINE__);
>

I think you either want to use sizeof(*window->xdg_surface) or 0 for the
size.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-web] Updated build instructions for wayland-protocols and libwacom

[Bill Spitzak]

>
>
>> > > > > +# newer version of libwacom is needed than
>> in apt
>> > > > > +apt install libgudev-1.0-dev
>> > > > > +git clone git://git.code.sf.net/p/linuxwacom/libwacom
>> > > > > +cd libwacom
>> > > > > +make -j 9 && make install
>> > > > > +cd ..
>>
>
Is the git repository for libwacom correct here, or did I find some mirror?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] client: ensure thread safety for wl_display_roundtrip_queue()

[Bill Spitzak]

On Mon, Feb 15, 2016 at 7:48 PM, Jonas Ådahl  wrote:

The proxy wrapper approach can be tested out by appling this patch:
> https://lists.freedesktop.org/archives/wayland-devel/2015-June/023054.html


Paraphrased here:

> In short, instead of
>
> bar = wl_foo_get_bar(foo);
> wl_proxy_set_queue((struct wl_proxy *) bar, queue);
> wl_bar_add_listener(bar, ...);
>
> with this RFC a client does
>
> foo_wrapper = wl_proxy_create_wrapper((struct wl_proxy *) foo);
> wl_proxy_set_queue((struct wl_proxy *) foo_wrapper, queue);
> bar = wl_foo_get(foo_wrapper);
> wl_bar_add_listener(bar, ...);

This seems unnecessarily complex. Instead the wl_proxy can be in an
unassigned state (identified by the id being set to a special value that
will never be used otherwise). This avoids the extra object, allows the
same code to be used even if there are different constructors for bar, and
allows other setup before the id is assigned (for instance
wl_bar_add_listener is not thread safe and above examples rely on the queue
being the one belonging to the current thread):

   bar = wl_bar_new();
   wl_proxy_set_queue((struct wl_proxy*)bar, queue);
   wl_bar_add_listener(bar, ...);
   wl_foo_get_bar_id(foo, bar, ...);
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston v3] drm: port the drm backend to the new init api

[Bill Spitzak]

I thought the purpose of this was so that compositors could pass to the
backend DRM configuration data supplied by the clients, therefore the api
that clients use to pass this information seemed pretty important.


On Mon, Feb 8, 2016 at 1:53 PM, Daniel Stone <dan...@fooishbar.org> wrote:

> On Monday, 8 February 2016, Bill Spitzak <spit...@gmail.com> wrote:
>
>> On Mon, Feb 8, 2016 at 2:02 AM, Pekka Paalanen <ppaala...@gmail.com>
>> wrote:
>>
>>> On Fri, 5 Feb 2016 21:03:20 +0100
>>> Benoit Gschwind <gschw...@gnu-log.net> wrote:
>>> > I will add my opinion as called for opinions. First I made a quick
>>> > brainstorm following previous proposals about solutions available. I
>>> see
>>> > 3 mains choice:
>>>
>>> Hi,
>>>
>>> thanks for looking into this.
>>>
>>> > 1. a structure that user fill and pass to the back end;
>>> > 2. an opaque structure that the user fill through helper function;
>>> > 3. a free list of key/value pair.
>>>
>>
>> The Wayland message api only allows sending of a small set of primitive
>> data types. So if you have a "structure" that is more complex than one of
>> those data types, the only way to send it is through multiple arguments to
>> (possibly multiple) Wayland requests. Therefore it seems like it is limited
>> to solutions 2 and 3, right?
>>
>
> ... you do know that libweston is a C library and not a Wayland protocol,
> right?
>
> These are the sorts of things that make it difficult (trending towards
> impossible) to take your review seriously.
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston v3] drm: port the drm backend to the new init api

[Bill Spitzak]

On Mon, Feb 8, 2016 at 2:02 AM, Pekka Paalanen  wrote:

> On Fri, 5 Feb 2016 21:03:20 +0100
> Benoit Gschwind  wrote:
>
> > Hello,
> >
> > I will add my opinion as called for opinions. First I made a quick
> > brainstorm following previous proposals about solutions available. I see
> > 3 mains choice:
>
> Hi,
>
> thanks for looking into this.
>
> > 1. a structure that user fill and pass to the back end;
> > 2. an opaque structure that the user fill through helper function;
> > 3. a free list of key/value pair.
>

The Wayland message api only allows sending of a small set of primitive
data types. So if you have a "structure" that is more complex than one of
those data types, the only way to send it is through multiple arguments to
(possibly multiple) Wayland requests. Therefore it seems like it is limited
to solutions 2 and 3, right?

A list of key/value pairs has a huge advantage that intermediate layers do
not need to know anything about the data.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Using Soft Keys with Weston & Libinput

[Bill Spitzak]

In the attached picture, is there also a strip above the screen that is
part of the touch screen? I would expect the touchpad hardware to be
rectangular. There is also a faint image of a rectangle in the middle, is
this something that lights up depending on the application?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Using Soft Keys with Weston & Libinput

[Bill Spitzak]

I'm just surprised that either the touch area is not a rectangle, or that
you were able to cut a hole for the card reader through the rectangular
touch panel. Then again I don't really know anything about the
manufacturing of these.

On Tue, Feb 9, 2016 at 12:02 AM, Ucan, Emre (ADITG/SW1) <
eu...@de.adit-jv.com> wrote:

> Hello Bill,
>
> Please watch this video for seeing the navigation device in action:
> https://www.youtube.com/watch?v=dUgW5M5ztww
>
> The entire screen is touch panel, and it is rectangular. But the
> compositor gets touch events only from the area of display.
>
> The location of soft keys, volume slider and touch area are defined by
> config files. Please see the attached picture.
> The rectangle in the middle of screen is a card reader.
>
> Later I will answer Peter's email with more information about how we
> configured these areas.
>
> Best regards
>
> Emre Ucan
> Software Group I (ADITG/SW1)
>
> Tel. +49 5121 49 6937
>
> > -Original Message-
> > From: Bill Spitzak [mailto:spit...@gmail.com]
> > Sent: Montag, 8. Februar 2016 19:27
> > To: Ucan, Emre (ADITG/SW1)
> > Cc: Peter Hutterer; Friedrich, Eugen (ADITG/SW1); wayland-
> > de...@lists.freedesktop.org
> > Subject: Re: Using Soft Keys with Weston & Libinput
> >
> > In the attached picture, is there also a strip above the screen that is
> part of
> > the touch screen? I would expect the touchpad hardware to be rectangular.
> > There is also a faint image of a rectangle in the middle, is this
> something that
> > lights up depending on the application?
> >
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland 00/18] Wayland network transparency :)

[Bill Spitzak]

My first reaction was that this is the wrong way to do it, but looking at
it a bit I am thinking it really is correct.

This avoids the need for a "proxy compositor" running on the client machine
that does the remote communication. That may be a big selling point since
that compositor is a whole new service that must be set up and running. And
you don't have to invent the whole protocol between the proxy and real
compositor, or debug all the problems where the proxy and real one have
different ideas about what is going on.

This also means that remote desktop to a Windows machine might mean a
Wayland emulator running on the Windows machine, rather than an RDP
emulator running on the client machine.

I am glad you noticed the problem with repeating keys. I think a fix is to
have wayland produce a repeat event, rather than the client doing timeouts.
Even if there is latency, at least the correct number of repeats would be
delivered. All the other logic in handling of the keyboard can remain the
same (ie it can send repeat events whether or not the key actually
repeats), as the order of press/release and repeat would be preserved. I am
still unclear why you cannot add keysym events to Wayland, but they are not
necessary to fix this.


On Tue, Feb 9, 2016 at 5:57 PM, Jason Ekstrand  wrote:

> On Tue, Feb 9, 2016 at 8:55 AM, Derek Foreman 
> wrote:
>
>> I saw a presentation once where someone said that even the simplest
>> implementation of wayland network transparency that just pushed the
>> existing protocol over tcp/ip would still be better than X.
>>
>> Let's test that theory.
>> Hint - application startup time is shockingly fast due to wayland's
>> excellent protocol design, but my poor damage tracking and lack of
>> compression hurts.  Damage tracking is especially bad for anything
>> that doesn't use wl_surface.damage_buffer() - so weston-terminal may
>> be rough but terminology is much snappier.
>>
>
> Kristian came up with a very nifty little image diffing algorithm based on
> a rolling hash that's used to provide compression for the screen recorder.
> (The actual video recorder, not screenshooter.)  You might want to check
> that out.
>
>
>>
>> To try it out (and open a gaping security hole because I've punted on
>> kind of authentication), just add:
>> wl_display_add_remote_socket(display, "foo");
>> to weston right before load_modules in main.  Use at your own risk.
>>
>> That's a literal "foo" because I haven't bothered defining how that
>> name string changes the port.
>>
>> I've written up a short blog post over here:
>> http://blogs.s-osg.org/wow-wayland-over-wire/
>>
>> (It lists other decisions I haven't bothered to make for this trial
>> run.)
>>
>> For those of you that want to view PDF files over the network, EFL's
>> etui viewer comes highly recommended. ;)
>>
>> Derek Foreman (17):
>>   os-compatability: Allow creation of 0 byte anonymous files
>>   os: make set_cloexec_or_close private instead of static
>>   cursor: use wl_os_set_cloexec_or_close instead of local copy
>>   os-compatability: Remove cursor's private os compat stuff entirely
>>   client: Check remaining connection buffer status after each
>> queue_event()
>>   protocol: Add fd_static type
>>   protocol: Use new fd_static type for keymaps
>>   os: Add wl_os_resize_file()
>>   scanner: Add the concept of "pre hooks"
>>   os: Add wl_os_read() and wl_os_write()
>>   os: Add a wl_os_socket_reuseaddr
>>   connections: Add remote sockets
>>   shm: properly resize remote buffers
>>   connection: support sending the contents of fds as bulk data
>>   connection: Use bulk transfers for fd_static on remote connections
>>   protocol: Add a wl_buffer.transmit
>>   protocol: Add hooks for network transparency
>>
>> Giulio Camuffo (1):
>>   shm: add getters for the fd and offset
>>
>>  Makefile.am   |   5 +-
>>  cursor/os-compatibility.c | 148 -
>>  cursor/os-compatibility.h |  34 --
>>  cursor/wayland-cursor.c   |  15 +--
>>  protocol/wayland.dtd  |   1 +
>>  protocol/wayland.xml  |  40 ---
>>  src/connection.c  | 150 +-
>>  src/network-client.c  | 269
>> ++
>>  src/scanner.c | 117 ++--
>>  src/wayland-client-core.h |  10 ++
>>  src/wayland-client.c  | 120 +
>>  src/wayland-os.c  | 162 ++--
>>  src/wayland-os.h  |  19 
>>  src/wayland-private.h |  13 +++
>>  src/wayland-server-core.h |  13 +++
>>  src/wayland-server.c  | 146 +++--
>>  src/wayland-shm.c |  63 ++-
>>  17 files changed, 1045 insertions(+), 280 deletions(-)
>>  delete mode 100644 cursor/os-compatibility.c
>>  delete mode 100644 cursor/os-compatibility.h
>>  create mode 100644 src/network-client.c
>>
>> --
>> 2.7.0
>>
>> 

Re: [PATCH v4 wayland-protocols] text: Create second version of text input protocol

[Bill Spitzak]

On Mon, Feb 8, 2016 at 7:38 AM, Rui Tiago Cação Matos 
wrote:

>
> > +
> > +  
> > +   Sets the cursor outline as a rectangle relative to the surface.
> > +
> > +   Allows the compositor to put a window with word suggestions near
> the
> > +   cursor.
> > +  
> > +  
> > +  
> > +  
> > +  
>
> These arguments could, and perhaps should, all be type="uint" .
>

The x and y have to be signed. Imagine if the client is scrolled in such a
way that the cursor rectangle is partially outside the surface.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v4 wayland-protocols] text: Create second version of text input protocol

[Bill Spitzak]

Yes that is exactly what I expect.

The input method may, if it wants, clamp the region to the surface, or even
to the input area of the surface. It does not have to put it disconnected
from the visible area like you are showing, though it can if it wants.

On Mon, Feb 8, 2016 at 10:42 AM, Rui Tiago Cação Matos <tiagoma...@gmail.com
> wrote:

> On Mon, Feb 8, 2016 at 7:07 PM, Bill Spitzak <spit...@gmail.com> wrote:
> > The x and y have to be signed. Imagine if the client is scrolled in such
> a
> > way that the cursor rectangle is partially outside the surface.
>
> Are you saying this is an acceptable case:
>
> ++
> |compositor popup|
> ++
>
>   +---+
>   | surface w/|
>   | scrolled  |
>   | contents  |
>   +---+
>
> I would expect the application to scroll its contents automatically so
> that the cursor is visible on the surface...
>
> Rui
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v2] xdg-shell: Introduce xdg_tooltip

[Bill Spitzak]

On Wed, Feb 3, 2016 at 11:36 AM, Jasper St. Pierre 
wrote:

> set_parent was moved to xdg_toplevel. Perhaps that's a good idea,
> perhaps it's not. This does mean that a tooltip's parent can never
> change, and a popup's parent can never change. That can help for
> getting grab semantics right, though it might be an idea if we say
> that set_parent on a popup / tooltip simply emit error if a parent is
> already set. I'm -1 to that, though.
>

xdg_toplevel *must* support the ability to change the parent. It is
impossible to get correct floating windows unless the parent can be set to
a surface that may not exist at the moment the floating surface is first
created (imagine a surface that must float above all opened documents, and
the user can create/destroy documents at will without closing the floating
surface).

Less importantly, setting the parent will avoid the need for a complex
directed acyclic graph api with multiple parents per surface, and avoid
more api to determine whether a parent's mapping controls the mapping of
the child. The client can keep track of which parent is the highest and
only tell the compositor about that, changing as necessary before any
request that will change the stacking order.

I think it is ok if some roles, like tooltip, do not allow the parent to be
changed. But the basic class must.


> Some think that wl_surface.attach's coordinates are confusing and
> built poorly, and I am inclined to agree, however, when I wrote the
> original get_xdg_popup, I simply forgot about them. It might be that
> we do positioning on first-attach, and we say that the tooltip is
> defined to be 0,0 relative to the surface. That is an idea, though I'm
> +0 on it.
>

The toolkits will hide this. I would agree that defining the delta to be
from 0,0 for the initial attach, in cases where the position is usable on
first attach, is a good idea.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v3 wayland-protocols] Add the tablet protocol

[Bill Spitzak]

On Tue, Feb 2, 2016 at 2:37 PM, Jason Gerecke  wrote:

>
> > I think a lot of software treats the tilt information as actually the
> > position of a point some distance up the pen relative to the tip. I would
>
> That's certainly true for GIMP and Krita at least (see [1] and [2]).
> Its incorrect, but its "close enough" that nobody seems to complain
> (though I've been tempted to in the past ;))
>
> > guess the hardware produces this directly (by reusing the proximity
> hardware
> > for a different point higher up in the pen). To get a projection of the
> pen
> > onto the tablet surface, these values can be fed to atan2.
> >
> > If they were actual angles, they must be the angle of the projection of
> the
> > pen onto the two vertical planes of the x and y axis. This is really
> noisy
> > when the pen is near one of the axis, and I would think the
> hardware/driver
> > could not produce this except by calculating atan2 of a more linear
> value.
> >
> > Therefore I would be very suspicious of any claim that the values being
> > produced are angles. The current api reporting them as normalized values
> > seems better.
> >
>
> I've been down this road before a few years back. Does the hardware
> measure and report true angles or does it measure a projection? If its
> a projection, does it report them directly, or does it calculate
> sin^-1 to transform it into an angle?
>
> In the end, the specs from the firmware guys say to interpret the data
> as measured in degrees, so that's what we do.
>
> [1]:
> https://git.gnome.org/browse/gimp/tree/app/core/gimpdynamicsoutput.c#n548
> [2]:
> https://github.com/KDE/krita/blob/master/libs/image/brushengine/kis_paint_information.cc#L507


 Actually it certainly cannot be any angle of a plane the pen is in, as the
atan2 data would not work and get quite incorrect when the pen is tilted
close to a horizontal axis. Though if Gimp is producing very strange angles
when the pen is nearly horizontal along one axis this may indicate that it
really is an angle. For instance if tilting the pen parallel to the x axis
produces angles more like 45 degrees.

Say some point on the pen is at x,y,z relative to the tip.

Possible values for the y tilt are (in order from best to worst imho):

y/D (where D == |x,y,z|). This goes to 1.0 as the pen is tilted horizontal.
atan2(ytilt, xtilt) == atan2(y/D, x/D) == atan2(y, x) and produces the
correct angle.

y/z: This value goes to infinity as the pen is tilted horizontal.
atan2(ytilt, xtilt) == atan2(y/z, x/z) == atan2(y, x) and thus gets the xy
angle exactly right.

atan(y/z): This would be the actual angle of the plane containing the pen
and x axis projected onto the yz plane. The correct xy angle is then
atan2(sin(ytilt),sin(xtilt)) == atan2(y/z, x/z) == atan2(y, x).
atan2(ytilt,xtilt) would have significant errors if the magnitude of xtilt
and ytilt are different.

asin(y/D) could be produced by somebody thinking they know how to convert y
to an angle, but it does not correspond to any actual angle of the pen. The
correct xy angle is again produced by atan2(sin(ytilt),sin(xtilt)) ==
atan2(y/D, x/D) == atan2(y, x), and doing atan2(ytilt,xtilt) would have the
same errors.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols] text: Create second version of text input protocol

[Bill Spitzak]

On Tue, Feb 2, 2016 at 4:58 AM, Jan Arne Petersen <jana...@gmail.com> wrote:

>
>
> On 29/01/16 00:33, Bill Spitzak wrote:
> >
> >
> > On Wed, Jan 27, 2016 at 11:52 PM, Jan Arne Petersen <jana...@gmail.com
> > <mailto:jana...@gmail.com>> wrote:
> >
> >
> > +  Text is generally UTF-8 encoded, indices and lengths are in
> > bytes.
> >
> >
> > Remove the word "generally". *All* text in your api's are UTF-8.
>
> Done
>
> > +
> > +  
> > +   Requests to activate a surface for text input (typically
> when a
> > +   text entry in it gets focus).
> > +
> > +   There can only be one active surface per client and seat.
> > When surface is
> > +   null all surfaces of the client get deactivated.
> > +  
> >
> >
> > I think clients should be allowed to send activate more than once per
> > surface, it is to indicate the input focus switching between widgets.
> > This removes the need for another api to indicate the widget is
> > switching. Sending null for the surface, or a different event, would
> > indicate that the keyboard focus is no longer on a text input widget.
>
> We use enable/disable request now. That should be a bit easier to handle
> from client side.
>
> > +
> > +  
> > +   Should be called by an editor widget when the input state
> > should be
> > +   reset, for example after the text was changed outside of the
> > normal
> > +   input method flow.
> > +  
> > +
> >
> >
> > I believe this request can be replaced by redundant activate requests.
>
> It got integrated into update_state.
>
> > +
> > +  
> > +   Sets the plain surrounding text around the input position.
> > Text is
> > +   UTF-8 encoded. Cursor is the byte offset within the
> > +   surrounding text. Anchor is the byte offset of the
> > +   selection anchor within the surrounding text. If there is no
> > selected
> > +   text anchor is the same as cursor.
> > +  
> > +  
> > +  
> > +  
> > +
> >
> >
> > The anchor could be very far away from the cursor, much farther than any
> > small limit on the request size. I think this means the anchor position
> > could be negative or larger than the text length. Sending this without
> > clamping would be a good idea, the input method would then have a hint
> > where the anchor is, and it can clamp the value itself.
> >
> > If the client wants new text to replace the selected text, the text
> > between anchor+cursor will be deleted, and any input method decisions
> > would depend on the text outside the anchor..cursor range. This may be
> > larger than the allowed buffer size, so I think clients have to send the
> > text as though the selection was deleted.
> >
> > A client that does not want to replace the selected text could still
> > send an anchor, but then I am not clear if the input method can take
> > advantage of knowing what characters are selected to modify the results.
> > So it is possible the anchor is not needed at all.
>
> Ok I use an int for anchor now. It still make sense for an input method
> to know what is in the selection even when it gets replaced by new
> entered text.
>

I am unclear whether it is the input method's job to decide whether
characters replace the selection, or the client's job.

My concern is this:

- The input method has rules so that if the text before the cursor is "A"
and the user types 'x', you get "Ay". If the text is any other letter such
as "C" you get "Cx".

- Assume the text before the cursor is "An" where all the 'n' are
selected, and the length of the selection exceeds the size allowed by the
surrounding text request. Therefore the input method cannot know there is
an 'A' there.

- The user types 'x'. The input method cannot be aware that there is an A
there and the result will be "Ax", not the correct "Ay".

My proposed solution is that the client decides whether input replaces the
selection or is appended to it. If it replaces the selection, the text it
sends the input method is with the selection already deleted.

Other solution is that the above situation does not happen in real input
methods.

>
> > I think you might want non-zero bits to *disable* features. This allows
> > zero to be the default, and means that if s

Re: [PATCH v2 weston 05/13] tablet: handle tablet cursors in the compositor

[Bill Spitzak]

I don't understand this, it seems very redundant with what you propose to
put into the compositor. As far as I can tell, you already require the
compositor to hide the cursor when the tool leaves proximity and to choose
the last-set cursor when a tool enters proximity.

Seems to me your proximity_out handler therefore does not have to do
anything, and toytoolkit does not have to remember any cursors. The client,
if it wants, can set the cursor on proximity-in. Or not set it. Whatever.

It this is wrong them I am very confused as to why you had to add so much
code to the compositor to manager per-tool cursors. You could instead just
reuse the seat cursor, since you seem to have the client setting the cursor
on every proximity-in and out.

On Tue, Feb 2, 2016 at 9:28 PM, Peter Hutterer 
wrote:

> From: Stephen Chandler Paul 
>
> The tablet is given a separate cursor. Most tablet interaction is an
> absolute
> interaction and shouldn't need a cursor at all, but usually the cursor is
> used
> to indicate the type of virtual tool currently assigned.
>
> Co-authored-by: Peter Hutterer 
> Signed-off-by: Stephen Chandler Paul 
> Signed-off-by: Peter Hutterer 
> ---
>  src/compositor.c |   6 +++
>  src/compositor.h |  13 +
>  src/input.c  | 157
> ++-
>  3 files changed, 175 insertions(+), 1 deletion(-)
>
> diff --git a/src/compositor.c b/src/compositor.c
> index cbdb14c..f419818 100644
> --- a/src/compositor.c
> +++ b/src/compositor.c
> @@ -1866,6 +1866,7 @@ weston_view_unmap(struct weston_view *view)
> struct weston_pointer *pointer =
> weston_seat_get_pointer(seat);
> struct weston_keyboard *keyboard =
> weston_seat_get_keyboard(seat);
> +   struct weston_tablet_tool *tool;
>
> if (keyboard && keyboard->focus == view->surface)
> weston_keyboard_set_focus(keyboard, NULL);
> @@ -1873,6 +1874,11 @@ weston_view_unmap(struct weston_view *view)
> weston_pointer_clear_focus(pointer);
> if (touch && touch->focus == view)
> weston_touch_set_focus(touch, NULL);
> +
> +   wl_list_for_each(tool, >tablet_tool_list, link) {
> +   if (tool->focus == view)
> +   weston_tablet_tool_set_focus(tool, NULL,
> 0);
> +   }
> }
>  }
>
> diff --git a/src/compositor.h b/src/compositor.h
> index 784a70d..7960325 100644
> --- a/src/compositor.h
> +++ b/src/compositor.h
> @@ -470,6 +470,12 @@ struct weston_tablet_tool {
>
> int button_count;
> bool tip_is_down;
> +
> +   int32_t hotspot_x, hotspot_y;
> +   struct weston_view *sprite;
> +   struct wl_listener sprite_destroy_listener;
> +
> +   wl_fixed_t x, y;
>  };
>
>  struct weston_tablet {
> @@ -580,6 +586,13 @@ void
>  weston_tablet_tool_end_grab(struct weston_tablet_tool *tool);
>
>  void
> +weston_tablet_tool_clamp(struct weston_tablet_tool *tool,
> +wl_fixed_t *fx, wl_fixed_t *fy);
> +void
> +weston_tablet_tool_cursor_move(struct weston_tablet_tool *tool,
> +  wl_fixed_t x, wl_fixed_t y);
> +
> +void
>  wl_data_device_set_keyboard_focus(struct weston_seat *seat);
>
>  int
> diff --git a/src/input.c b/src/input.c
> index 006ab5a..fc74856 100644
> --- a/src/input.c
> +++ b/src/input.c
> @@ -974,7 +974,13 @@ static void
>  default_grab_tablet_tool_proximity_out(struct weston_tablet_tool_grab
> *grab,
>uint32_t time)
>  {
> -   weston_tablet_tool_set_focus(grab->tool, NULL, time);
> +   struct weston_tablet_tool *tool = grab->tool;
> +
> +   weston_tablet_tool_set_focus(tool, NULL, time);
> +
> +   /* Hide the cursor */
> +   if (weston_surface_is_mapped(tool->sprite->surface))
> +   weston_surface_unmap(tool->sprite->surface);
>  }
>
>  static void
> @@ -989,6 +995,8 @@ default_grab_tablet_tool_motion(struct
> weston_tablet_tool_grab *grab,
> struct wl_resource *resource;
> struct wl_list *resource_list = >focus_resource_list;
>
> +   weston_tablet_tool_cursor_move(tool, x, y);
> +
> current_view = weston_compositor_pick_view(tool->seat->compositor,
>x, y, , );
> if (current_view != tool->focus)
> @@ -1126,6 +1134,29 @@ static struct weston_tablet_tool_grab_interface
> default_tablet_tool_grab_interfa
> default_grab_tablet_tool_cancel,
>  };
>
> +static void
> +tablet_tool_unmap_sprite(struct weston_tablet_tool *tool)
> +{
> +   if (weston_surface_is_mapped(tool->sprite->surface))
> +   weston_surface_unmap(tool->sprite->surface);
> +
> +   wl_list_remove(>sprite_destroy_listener.link);
> + 

Re: [PATCH wayland-protocols] text: Create second version of text input protocol

[Bill Spitzak]

On Tue, Feb 2, 2016 at 5:02 AM, Jan Arne Petersen  wrote:

>
> > Besides allowing the user to return to a misspelled word, it may make
> > sense to return to a preedit. I'm not sure as I have no experience with
> > Asian input methods. But it does seem possible.
>
> Sorry no toolkit supports that. While the current proposed protocol can
> be implemented with current Qt, Gtk+ and EFL. Androids input method API
> is also quite similar to what is proposed here.
>

I'm sorry but I am familiar toolkits that allow the user to return to a
previously misspelled word and invoke the spelling corrector. My browser is
right now drawing squiqqly red lines under "toolkits" and "squiggly".

This means that the "incorrect" highlighting has to be preserved from the
preedit string. I think the easiest way to do this is to merge the commit
and preedit apis, so an input method can commit highlighting. This means it
can commit any preedit string. I guess the client can leave the
highlighting or remove it depending on the client limitations. Returning to
preedit can only work if the preedit state can be determined from the
characters alone, as there is no method for the client to send the
highlighting or previous preedit range to the input method.

I find it difficult to imagine an implementation that is capable of showing
the preedit string yet unable to commit it, so I don't see how any toolkit
could not support this, unless it cannot show spelling error highlight
unless the cursor is right next to them.

I may be misunderstanding how you intend spelling correction / completion
to work, however.

Delete surrounding text also works for pre-edit, i fixed the documentation.
>

I was curious how you intend for it to indicate a misspelling when the
input method is adding a space after a word that may have been typed
previously. Two methods I can think of are to have it delete the entire
word and replace it with the same word with the incorrect highlighting, or
to allow the incorrect highlighting range to be outside the preedit string
and include bytes already in the buffer.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v2 weston 07/13] client: Add tablet cursor support into libtoytoolkit

[Bill Spitzak]

Does toytoolkit really need to support animated cursors?

If so it would be nice to animate the normal cursor, too, and perhaps
demonstrate code reuse for this.


On Tue, Feb 2, 2016 at 9:28 PM, Peter Hutterer 
wrote:

> From: Stephen Chandler Paul 
>
> Again, a lot of this is code that has been reused from the cursor code
> for pointers.
>
> Co-authored-by: Peter Hutterer 
> Signed-off-by: Stephen Chandler Paul 
> Signed-off-by: Peter Hutterer 
> ---
>  clients/window.c | 138
> ++-
>  clients/window.h |  13 --
>  2 files changed, 145 insertions(+), 6 deletions(-)
>
> diff --git a/clients/window.c b/clients/window.c
> index 37c703b..26c2593 100644
> --- a/clients/window.c
> +++ b/clients/window.c
> @@ -159,6 +159,12 @@ struct tablet_tool {
> struct tablet *current_tablet;
> struct window *focus;
> struct widget *focus_widget;
> +   uint32_t enter_serial;
> +   uint32_t cursor_serial;
> +   int current_cursor;
> +   struct wl_surface *cursor_surface;
> +   uint32_t cursor_anim_start;
> +   struct wl_callback *cursor_frame_cb;
>
> enum zwp_tablet_tool_v1_type type;
> uint64_t serial;
> @@ -332,6 +338,7 @@ struct widget {
> int opaque;
> int tooltip_count;
> int default_cursor;
> +   int default_tablet_cursor;
> /* If this is set to false then no cairo surface will be
>  * created before redrawing the surface. This is useful if the
>  * redraw handler is going to do completely custom rendering
> @@ -1676,6 +1683,7 @@ widget_create(struct window *window, struct surface
> *surface, void *data)
> widget->tooltip = NULL;
> widget->tooltip_count = 0;
> widget->default_cursor = CURSOR_LEFT_PTR;
> +   widget->default_tablet_cursor = CURSOR_LEFT_PTR;
> widget->use_cairo = 1;
>
> return widget;
> @@ -1734,6 +1742,12 @@ widget_set_default_cursor(struct widget *widget,
> int cursor)
>  }
>
>  void
> +widget_set_default_tablet_cursor(struct widget *widget, int cursor)
> +{
> +   widget->default_tablet_cursor = cursor;
> +}
> +
> +void
>  widget_get_allocation(struct widget *widget, struct rectangle *allocation)
>  {
> *allocation = widget->allocation;
> @@ -5667,6 +5681,117 @@ tablet_tool_handle_removed(void *data, struct
> zwp_tablet_tool_v1 *zwp_tablet_too
> zwp_tablet_tool_v1_destroy(zwp_tablet_tool_v1);
>  }
>
> +static const struct wl_callback_listener
> tablet_tool_cursor_surface_listener;
> +
> +static void
> +tablet_tool_set_cursor_image_index(struct tablet_tool *tool, int index)
> +{
> +   struct wl_buffer *buffer;
> +   struct wl_cursor *cursor;
> +   struct wl_cursor_image *image;
> +
> +   cursor = tool->input->display->cursors[tool->current_cursor];
> +   if (index >= (int)cursor->image_count) {
> +   fprintf(stderr, "cursor index out of range\n");
> +   return;
> +   }
> +
> +   image = cursor->images[index];
> +   buffer = wl_cursor_image_get_buffer(image);
> +   if (!buffer)
> +   return;
> +
> +   wl_surface_attach(tool->cursor_surface, buffer, 0, 0);
> +   wl_surface_damage(tool->cursor_surface, 0, 0,
> + image->width, image->height);
> +   wl_surface_commit(tool->cursor_surface);
> +   zwp_tablet_tool_v1_set_cursor(tool->tool, tool->enter_serial,
> + tool->cursor_surface,
> + image->hotspot_x, image->hotspot_y);
> +}
> +
> +static void
> +tablet_tool_surface_frame_callback(void *data, struct wl_callback
> *callback,
> +  uint32_t time)
> +{
> +   struct tablet_tool *tool = data;
> +   struct wl_cursor *cursor;
> +   int i;
> +
> +   if (callback) {
> +   assert(callback == tool->cursor_frame_cb);
> +   wl_callback_destroy(callback);
> +   tool->cursor_frame_cb = NULL;
> +   }
> +
> +   if (tool->current_cursor == CURSOR_BLANK) {
> +   zwp_tablet_tool_v1_set_cursor(tool->tool,
> tool->enter_serial,
> + NULL, 0, 0);
> +   return;
> +   }
> +
> +   if (tool->current_cursor == CURSOR_UNSET)
> +   return;
> +
> +   cursor = tool->input->display->cursors[tool->current_cursor];
> +   if (!cursor)
> +   return;
> +
> +   /* FIXME We don't have the current time on the first call so we set
> +* the animation start to the time of the first frame callback. */
> +   if (time == 0)
> +   tool->cursor_anim_start = 0;
> +   else if (tool->cursor_anim_start == 0)
> +   tool->cursor_anim_start = time;
> +
> +   if (time == 0 || 

Re: [PATCH wayland-protocols v2] xdg-shell: Introduce xdg_tooltip

[Bill Spitzak]

On Wed, Feb 3, 2016 at 1:05 PM, Jasper St. Pierre <jstpie...@mecheye.net>
wrote:

> On Wed, Feb 3, 2016 at 1:00 PM, Bill Spitzak <spit...@gmail.com> wrote:
> >
> >
> > On Wed, Feb 3, 2016 at 11:36 AM, Jasper St. Pierre <
> jstpie...@mecheye.net>
> > wrote:
> >>
> >> set_parent was moved to xdg_toplevel. Perhaps that's a good idea,
> >> perhaps it's not. This does mean that a tooltip's parent can never
> >> change, and a popup's parent can never change. That can help for
> >> getting grab semantics right, though it might be an idea if we say
> >> that set_parent on a popup / tooltip simply emit error if a parent is
> >> already set. I'm -1 to that, though.
> >
> >
> > xdg_toplevel *must* support the ability to change the parent.
>
> Somehow I get the feeling you're not even reading the words I'm
> writing. xdg_toplevel still has a set_parent method, I said it was
> moved *to* xdg_toplevel.
>

Sorry I am confused then as to what the text "This does mean that a
tooltip's parent can never change, and a popup's parent can never change".
I think I misread it as "if we use xdg_surface set_parent, you cannot
change the parent", thus implying that xdg_surface set_parent cannot change
it. I think what you actually meant was "the current scheme does not allow
you to change the parent, this proposal *does* allow the parent to change".

If there are problems with making the grabs work, I think it is ok if
attempting to change the parent is either an error or ignored for surfaces
with the popup role.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v3 wayland-protocols] Add the tablet protocol

[Bill Spitzak]

On Mon, Feb 1, 2016 at 6:38 PM, Jason Gerecke  wrote:

>
> Ultimately, the tilt information is almost universally used by
> applications to set brush orientation. To do that, you have to use
> some trig to transform the X and Y tilt values into something like
> Alt-Az form. Tilt on a scale of 0-1 is fine for calculating the
> azimuth, but you can't calculate the altitude angle without knowing
> what 100% physically corresponds to. You can guess (e.g. assume it
> corresponds to the reasonable physical limit of +-90 degrees), get a
> horribly wrong answer (since the hardware limit is actually +-64
> degrees), and then either ignore the discrepancy or fudge other bits
> of the brush engine to not do nonsensical things. Actually, to be
> fair, that's exactly how GIMP does things right now :P
>

I think a lot of software treats the tilt information as actually the
position of a point some distance up the pen relative to the tip. I would
guess the hardware produces this directly (by reusing the proximity
hardware for a different point higher up in the pen). To get a projection
of the pen onto the tablet surface, these values can be fed to atan2.

If they were actual angles, they must be the angle of the projection of the
pen onto the two vertical planes of the x and y axis. This is really noisy
when the pen is near one of the axis, and I would think the hardware/driver
could not produce this except by calculating atan2 of a more linear value.

Therefore I would be very suspicious of any claim that the values being
produced are angles. The current api reporting them as normalized values
seems better.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Moving bugs to Phabricator

[Bill Spitzak]

Can you make a clone of the current Bugzilla state in Phabricator so that
we can see what it looks like?


On Tue, Feb 2, 2016 at 7:43 AM, Daniel Stone  wrote:

> Hi,
> As previously discussed with a few people (when it was much more in
> its infancy than now), I'd like to move our bug tracking from Bugzilla
> to Phabricator.
>
> There's a few reasons behind this. Phabricator is actually a pretty
> decent suite of utilities, including repository browsing and code
> review (Gerrit-style, including iterative revisions of patches,
> line-by-line comments, etc), and having our bugs in that would allow
> us better integration between the two. For instance, putting
> 'Maniphest Tasks: T1234' in a commit message when uploading a diff
> automatically links the commit and the bug, and similarly it also gets
> closed when pushing commits.
>
> We can push this out further as well, including automatically
> triggering CI from commits sent for review. I actually had this
> working last year (running distcheck for every commit), but am in the
> middle of rejigging my setup for a few things and haven't yet fixed
> that to happen again yet.
>
> Personally, just the improved UI (BZ is a nightmare) is enough for me,
> but in terms of what we can do with it in future, I think it's got a
> much better model than Bugzilla. The data store in Phabricator is very
> important to their upstream, and is sensible and extensible. Whilst
>
> We've had an instance at fd.o for a while, which has been used to
> varying degrees by projects such as PiTiVi, GStreamer, et al. Also, we
> use it internally for everything at Collabora, so the tree we maintain
> for use there also gets pushed to fd.o.
>
> In terms of what this would mean mechanically, we already have a
> fairly mature suite of scripts which have been used to do imports for
> quite a few projects. Using this would mirror all the Bugzilla bugs to
> Phabricator, add a link from the existing Bugzilla bugs to their
> replacements on Phabricator, and then redirect all new bug-filers to
> Phabricator. The import process also creates accounts for everyone, so
> once they'd recovered their passwords, so no data will be lost. It
> also ports attachments over.
>
> Beyond that, we can start using code review for it as and when people
> feel comfortable, particularly using git-phab, which submits patchsets
> to Phabricator for review. I'm probably most excited about getting
> review on there, though also fairly cautious; while Bugzilla is just
> trading one antiquated web tool which no-one uses for a nice modern
> one which equally few people will probably look at, review is a bigger
> part. Nonetheless, having things like concrete review approval status,
> line-by-line review separated from wider/conceptual review,
> at-a-glance review status, etc, I think is valuable enough that I
> think it's worth shifting things over at some point.
>
> Anyone have any thoughts/opinions/fears/encouragement?
>
> Cheers,
> Daniel
> ___
> 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 libinput] gitignore: ignore compile script generated by automake >= 1.14

[Bill Spitzak]

You may want to put '/' in front of files that should only occur in the
root of the repository.


On Tue, Jan 19, 2016 at 6:53 PM, Peter Hutterer 
wrote:

> On Tue, Jan 19, 2016 at 03:10:21PM +0100, Olivier Blin wrote:
> > ---
> >  .gitignore | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/.gitignore b/.gitignore
> > index 8893a5f..ba5d0f5 100644
> > --- a/.gitignore
> > +++ b/.gitignore
> > @@ -14,6 +14,7 @@ Makefile
> >  Makefile.in
> >  aclocal.m4
> >  autom4te.cache/
> > +compile
> >  config.guess
> >  config.h
> >  config.h.in
> > --
> > 2.7.0
>
> merged, thanks
>
> Cheers,
>Peter
> ___
> 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 libinput 5/7] tablet: add support for relative x/y motion deltas

[Bill Spitzak]

On Mon, Jan 18, 2016 at 1:57 PM, Peter Hutterer 
wrote:

>
> mapping aspect ratio will be the job of the compositor. In reality, this
> will mean that one of the axes will be shortened to match the ratio.
>

Yes I believe the compositor has to do this. libinput obviously cannot, and
I don't think clients can do this.

if absolute mode on your tablet is "completely useless" that would indicate
> you never looked at wacom(4) or any instructions on how to fix this. We've
> had config options to adjust this for years.
>

I am well aware of the wacom command, and use it. Setting a working
relative mode is really painful, and also does not survive reboot or
sleep/wakeup. I have a batch file that I run every time in order to fix the
tablet, here are the contents:

xsetwacom --set "Wacom Intuos3 6x8 stylus" Mode Relative
xsetwacom --set "Wacom Intuos3 6x8 stylus" Area "0 0 162560 121920"
xsetwacom --set "Wacom Intuos3 6x8 eraser" Mode Relative
xsetwacom --set "Wacom Intuos3 6x8 eraser" Area "0 0 162560 121920"

Absolute mode on my tablet is completely useless, at least for drawing and
3d modelling. The tablet is 8" wide and 6" tall. My two HDTV monitors side
by side are about 43" wide and 12" tall. Therefore the physical scaling
from pen motion to cursor motion is about 5x horizontally and 2x
vertically. This scale makes it impossible to do fine detail without so
much zooming in that I have cropped off all useful context, and the aspect
ratio difference makes it impossible to transfer muscle memory used for
drawing with a physical pen or a tablet on a different device to this one.

I still find it hard to believe my situation is unique. Vastly more small
tablets are sold than big desktop-sized ones.

A few ideas that will make xsetwacom a bit less painful:

1. Should be able to set the relative and absolute mapping with one
command, rather than one per tool. This is independent of whether the tool
is relative or absolute. If you really want add a way to override it per
tool, but setting the default would help. My above code only works because
I only have a pen and eraser, if I added another tool I would have to fix
this.

2. Relative mode should default to some square aspect and the size should
not depend on the screens in any way. I think this basically means that the
relative and absolute rectangles are different. The absolute rectangle is
completely under control of the compositor, which is well aware of the size
of the outputs, or any api by clients to restrict the tablet to an area.

3. (this is my only real proposal that would differ from existing systems):
I think the system could automatically switch to relative mode if the
absolute area exceeds the relative area by too large a factor. In my
experience this is as small as 1, but it is possible other users would
disagree. At least use this to initialize a new device before the user
customizes it.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v2 2/2] Introduce pointer locking and confinement protocol

[Bill Spitzak]

On Fri, Jan 15, 2016 at 8:08 AM, Daniel Stone <dan...@fooishbar.org> wrote:

> Hi,
>
> On 12 January 2016 at 22:28, Bill Spitzak <spit...@gmail.com> wrote:
> > There should *only* be "one shot" requests, which are very quickly
> accepted
> > or denied by the compositor. The client creates it in response to an
> input
> > event, and it includes the input event id.
> >
> > Most/all things that triggers pointer lock (the mouse entering the
> region,
> > the mouse being pressed in the region, a press+release in the region, a
> > keystroke) could be implemented by clients and it does not do any pointer
> > lock protocol until after it has detected the triggering event, and thus
> can
> > include the event id.
>
> For what it's worth - post-hoc expansion on my reasoning - I think
> Bill has the genesis of a point here. Usually, our requests have
> followed one of two patterns: either you request activation in
> response to a specific event (button or key event allows you to create
> a selection), or retained state (creating a wl_data_device gets you
> selection/etc events on that seat until you destroy it).
>
> The proposed one-shot-but-delayed request to me felt like a really
> awkward compromise between the two, and not really one backed up by a
> strong enough usecase to justify a third (delayed but not retained)
> model for requests taking effect.
>
> It's entirely possible that there's something I'm missing here, but
> for consistency if nothing else, having the split instead be between
> these two classic methods (oneshot-immediate vs. fully-retained,
> rather than oneshot-delayed vs. fully-retained) could be good for
> future versions.
>

I would agree there is something missing here.

I do not see any reason for anything other than a "one shot" which is
created by the client *AFTER* it receives the possibly-triggering input
event. I am still waiting for a description of how one of these pre-set
locks is triggered, I have serious doubts that any possible trigger could
be something other than an action that would send an event to the client,
or at a moment the client is doing something like configuring the surface.

Nor do I see any problem with race conditions provided the one-shot request
has an id for the triggering event:

- Client gets event that it thinks should trigger pointer-lock/confine

- Client sends pointer-lock/confine request which includes the event serial
number (and creates the pointer-lock proxy object)

- Client can read relative motion events (these are identical whether or
not pointer lock works, and also correct for motion before the pointer lock
request was received by the compositor). Client can also read absolute
pointer motion events, but it needs to know these change depending on
whether they are before or after the accept event.

- Client can change the confinement region (ie it can move the cursor).
These are ignored if pointer lock has been rejected or has expired

- Client (may) get an accepted event stating that pointer lock worked.

- Client gets a cancelled event. If it did not get an accepted event then
it knows pointer lock did not work.

Imagine the compositor cancels pointer-lock on the next mouse-up event, and
a client tries to grab pointer-lock on mouse down. Normal event sequence
(--> indicates requests)

  button-down event
  --> pointer lock request
  --> set cursor image
  --> cursor motion
  motion event
  --> cursor motion
  motion event
  --> cursor motion
  accepted event
  motion event
  --> cursor motion
  motion event
  --> cursor motion
  button-up event
  cancelled event
  motion/enter/exit events due to grab being lost
  --> set cursor image

Now imagine the simplest race, where the compositor sees the mouse button
being released before it gets the pointer-lock request:

  button-down event
  --> pointer lock request
  --> set cursor image
  --> cursor motion
  motion event
  --> cursor motion
  motion event
  --> cursor motion
  motion event
  --> cursor motion
  motion event
  --> cursor motion
  button-up event
  motion/enter/exit events due to grab being lost
  cancelled event (due to compositor finally seeing the pointer lock
request)
  --> set cursor image

Client can tell this happened because it did not get an accepted event. But
it is also interesting that a client may not care: it should act exactly
the same and to the user it looks like the pointer-lock gesture worked,
except the end position of the cursor is different.

I can imagine schemes where the end cursor position is correct, but I think
it requires putting an event serial number on the cursor motion requests.
The idea is that if the mouse button has not been pressed again, it is
warped back to the set position plus the result of any later motion events.
Compositor 

Re: [PATCH wayland v10 2/2] protocol: Add DnD actions

[Bill Spitzak]

> +   While managing an "ask" action, the destination drag-and-drop
> client
> +   may perform further wl_data_offer.receive requests, and is expected
> +   to perform one last wl_data_offer.set_actions request with a
> preferred
> +   action other than "ask" (and optionally wl_data_offer.accept)
> before
> +   requesting wl_data_offer.finish, in order to convey the action
> selected
> +   by the user. If the preferred action is not in the
> +   wl_data_offer.source_actions mask, an error will be raised.
>

Sorry, this is still not answering the question.

Please describe exactly what happens when a source sends COPY+MOVE, and
contrast it with exactly what happens when a source sends COPY+MOVE+ASK.

My current guess is that the only effect of ASK is to stop the compositor
from restricting the set if there are no modifiers down.

A much more tedious and complete answer that might solve some of this
mystery:

There are three sets of actions in the api:

- The source supplied set
- The destination supplied set
- The compositor-produced intersection of these sets, further modified by
modifier keys.

There are also six different sets of actions of interest:

- The empty set
- A single action other than ASK
- More than one action but without ASK
- ASK by itself
- ASK with a single other action
- ASK with more than one other action

For all eighteen possible combinations of the above three parts of the api
and six types of sets, can you answer:

- Is it valid (can a correctly-operating source, destination, and
compositor produce them?)
- What does it mean? Basically contrast it with what happens if the ASK bit
is inverted.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput 5/7] tablet: add support for relative x/y motion deltas

[Bill Spitzak]

Isn't dx_unaccelerated exactly equal to the differences between x values?

If not then I suspect the only difference is a linear scaling (ie between
tablet-width/height or mm or whatever the xy are using and the pointer-like
coordinates the dx are using).

I think it would be less confusing if everything used the same coordinate
space. However having the driver indicate how big a "pointer like unit" is
in this coordinate system is useful. A client can use this to automatically
switch between absolute and relative mode depending on whether the scaling
from pointer motion in absolute mode exceeds this value too much, or if the
aspect ratio differs too much.


On Thu, Jan 14, 2016 at 4:26 PM, Peter Hutterer 
wrote:

> Instead of an explicit tablet mode that device must be changed into, let
> the
> caller decide which coordinates are preferred. The tablet mode may be
> application-specific and usually depends on the tool as well.
>
> This patch adds an interface to get a motion delta for the x/y axes in
> pixel-like coordinates and as raw unaccelerated delta. In the former case,
> libinput will provide some magic to convert the tablet data into something
> that resembles pixels from a mouse motion. In the latter case, we normalize
> to the x resolution so the caller doesn't have to account for uneven
> resolutions, but otherwise leave the data untouched.
> A caller can either query the x resolution and base the rest on that, or
> just
> guess a magic factor to apply.
>
> Signed-off-by: Peter Hutterer 
> ---
>  doc/normalization-of-relative-motion.dox |  4 ++
>  doc/tablet-support.dox   | 29 +++
>  src/libinput-private.h   |  2 +
>  src/libinput.c   | 52 ++
>  src/libinput.h   | 63
> 
>  src/libinput.sym |  4 ++
>  6 files changed, 154 insertions(+)
>
> diff --git a/doc/normalization-of-relative-motion.dox
> b/doc/normalization-of-relative-motion.dox
> index 31596a9..478e727 100644
> --- a/doc/normalization-of-relative-motion.dox
> +++ b/doc/normalization-of-relative-motion.dox
> @@ -38,6 +38,10 @@ libinput scales unaccelerated touchpad motion to the
> resolution of the
>  touchpad's x axis, i.e. the unaccelerated value for the y axis is:
>   y = (x / resolution_x) * resolution_y
>
> +@section motion_normalization_tablet Normalization of tablet coordinates
> +
> +See @ref tablet-relative-motion
> +
>  @section Setting custom DPI settings
>
>  Devices usually do not advertise their resolution and libinput relies on
> diff --git a/doc/tablet-support.dox b/doc/tablet-support.dox
> index 7207a47..1bc8733 100644
> --- a/doc/tablet-support.dox
> +++ b/doc/tablet-support.dox
> @@ -52,6 +52,35 @@ Note that the pressure threshold to trigger a logical
> tip event may be zero
>  on some devices. On tools without pressure sensitivity, determining when a
>  tip is down is device-specific.
>
> +@section tablet-relative-motion Relative motion for tablet tools
> +
> +libinput calculates the relative motion vector for each event and converts
> +it to the same coordinate space that a normal mouse device would use. For
> +the caller, this means that the delta coordinates returned by
> +libinput_event_tablet_tool_get_dx() and
> +libinput_event_tablet_tool_get_dy() can be used identical to the delta
> +coordinates from any other pointer event. Any resolution differences
> between
> +the x and y axes are accommodated for, a delta of N/N represents a 45
> degree
> +diagonal move on the tablet.
> +
> +The delta coordinates are available for all tablet events, it is up to the
> +caller to decide when a tool should be used in relative mode. It is
> +recommended that mouse and lens cursor tool default to relative mode and
> +all pen-like tools to absolute mode.
> +
> +If a tool in relative mode must not use pointer acceleration, a caller
> +should use the delta coordinates returned by
> +libinput_event_tablet_tool_get_dx_unaccelerated() and
> +libinput_event_tablet_tool_get_dy_unaccelerated() instead. These
> +deltas are in raw device coordinates, it is up to the caller to map the
> raw
> +device units into pixel movements. libinput normalizes the coordinates to
> +the resolution of the x axis. Thus, an unaccelerated delta of N/N
> represents
> +a 45 degree diagonal move on the tablet.
> +
> +Callers that require exact physical distance should use the
> +absolute coordinates provided by libinput_event_tablet_tool_get_x() and
> +libinput_event_tablet_tool_get_y() and calculate the delta themselves.
> +
>  @section tablet-axes Special axes on tablet tools
>
>  A tablet tool usually provides additional information beyond x/y
> positional
> diff --git a/src/libinput-private.h b/src/libinput-private.h
> index ff43d00..1e6ae90 100644
> --- a/src/libinput-private.h
> +++ b/src/libinput-private.h
> @@ -71,6 +71,8 @@ 

Re: [PATCH libinput 5/7] tablet: add support for relative x/y motion deltas

[Bill Spitzak]

On 01/17/2016 02:26 PM, Peter Hutterer wrote:

On Fri, Jan 15, 2016 at 12:06:27PM -0800, Bill Spitzak wrote:

Isn't dx_unaccelerated exactly equal to the differences between x values?


hah, yes. indeed. that actually means we can drop it from the API since a
client can use the mm value instead, they are effectively equivalent (but
more useful) than the raw device coordinates and account for uneven
resolution better anyway.


I think the following text is confusing and is what led me to think that 
the coordinate systems might be different:


>>> +libinput calculates the relative motion vector for each event and 
converts

>>> +it to the same coordinate space that a normal mouse device would use.

I guess that all coordianates except for raw ones are "converted to the 
space that a normal mouse device would use" but this seems to imply that 
dx/dy are special. Maybe this text can be moved somewhere to make it 
clear it applies to everything other than raw output.



Whether you use the device in an absolute or relative mode is a very
user-specific thing, I doubt you can handle this automatically. mode is also
a very tool-specific thing, you may want the mouse to be in relative mode
but the pen in absolute mode.


Although some devices such as the mouse may want to be in relative mode 
all the time, I believe the "absolute" devices will want to be in 
relative mode if the mapping from the tablet to the screen is either too 
large of a scale-up (ie the screen is much larger than the tablet) or 
the aspect ratio is significantly different (though this might just mean 
that one dimension is scaled beyond a maximum). This is certainly true 
of my current setup and I can't believe it is uncommon. Absolute mode on 
this tablet is completely useless! Except for programs that restrict the 
motion to a smaller window that is about the shape of the tablet.


I think this would also help it guess the correct mode automatically 
when the user changes their tablet or their screens.



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

Re: [PATCH wayland v2] client: Fully flush during blocking dispatch

[Bill Spitzak]

Would it make sense for wl_display_flush() to do this always? Ie it will
never return EAGAIN. Then if needed make the non-blocking version be a new
call.



On Thu, Jan 14, 2016 at 6:40 PM, Jonas Ådahl  wrote:

> On Fri, Jan 15, 2016 at 12:12:09AM +, Auke Booij wrote:
> > On 12 January 2016 at 04:31, Jonas Ådahl  wrote:
> > > wl_display_flush() may fail with EAGAIN which means that not all data
> > > waiting in the buffer has been flushed. We later block until there
> >
> > + is
>
> Fixed locally.
>
> >
> > > data to read, which could mean that we block on input from the
> > > compositor without having sent out all data from the client. Avoid this
> > > by fully flushing the socket before starting to wait.
> > >
> > > Signed-off-by: Jonas Ådahl 
> > > ---
> > >  src/wayland-client.c | 39 +--
> > >  1 file changed, 29 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/src/wayland-client.c b/src/wayland-client.c
> > > index 8bf6124..f47e395 100644
> > > --- a/src/wayland-client.c
> > > +++ b/src/wayland-client.c
> > > @@ -1442,6 +1442,21 @@ wl_display_cancel_read(struct wl_display
> *display)
> > > pthread_mutex_unlock(>mutex);
> > >  }
> > >
> > > +static int
> > > +wl_display_poll(struct wl_display *display, short int events)
> > > +{
> > > +   int ret;
> > > +   struct pollfd pfd[2];
> >
> > why 2? why an array at all? why not just
> >
> > struct pollfd pfd;
> > pfd.fd = display->fd;
> > pfd.events = events;
> > do {
> >   poll(, 1, -1);
> > } while (blabla);
> >
> > (i understand this was in the original as well and you're simply
> > moving code around)
>
> The git history doesn't provide an explanation so I guess it is just a
> mistake. I'll change the 2 to a 1 before pushing.
>
>
> Jonas
>
> >
> > > +
> > > +   pfd[0].fd = display->fd;
> > > +   pfd[0].events = events;
> > > +   do {
> > > +   ret = poll(pfd, 1, -1);
> > > +   } while (ret == -1 && errno == EINTR);
> > > +
> > > +   return ret;
> > > +}
> > > +
> > >  /** Dispatch events in an event queue
> > >   *
> > >   * \param display The display context object
> > > @@ -1485,27 +1500,31 @@ WL_EXPORT int
> > >  wl_display_dispatch_queue(struct wl_display *display,
> > >   struct wl_event_queue *queue)
> > >  {
> > > -   struct pollfd pfd[2];
> > > int ret;
> > >
> > > if (wl_display_prepare_read_queue(display, queue) == -1)
> > > return wl_display_dispatch_queue_pending(display,
> queue);
> > >
> > > +   while (true) {
> > > +   ret = wl_display_flush(display);
> > > +   if (ret == -1 && errno == EAGAIN) {
> > > +   if (wl_display_poll(display, POLLOUT) == -1) {
> > > +   wl_display_cancel_read(display);
> > > +   return -1;
> > > +   }
> > > +   } else {
> > > +   break;
> > > +   }
> > > +   }
> > > +
> > > /* Don't stop if flushing hits an EPIPE; continue so we can
> read any
> > >  * protocol error that may have triggered it. */
> > > -   ret = wl_display_flush(display);
> > > -   if (ret < 0 && errno != EAGAIN && errno != EPIPE) {
> > > +   if (ret < 0 && errno != EPIPE) {
> > > wl_display_cancel_read(display);
> > > return -1;
> > > }
> > >
> > > -   pfd[0].fd = display->fd;
> > > -   pfd[0].events = POLLIN;
> > > -   do {
> > > -   ret = poll(pfd, 1, -1);
> > > -   } while (ret == -1 && errno == EINTR);
> > > -
> > > -   if (ret == -1) {
> > > +   if (wl_display_poll(display, POLLIN) == -1) {
> > > wl_display_cancel_read(display);
> > > return -1;
> > > }
> > > --
> > > 2.4.3
> > >
> > > ___
> > > wayland-devel mailing list
> > > wayland-devel@lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols 0/3] xdg_surface base interface and xdg_tooltip

[Bill Spitzak]

Okay it makes sense.

I think the term "toplevel" is rather confusing, since the word "level" is
often used when talking about window stacking. Perhaps "normal" or
"default"?

Other thing is that the argument called "parent" to the set-role methods
has got to be renamed. Perhaps to "surface"?

I'm not clear at all what a "tooltip" does that is different from a normal
surface. Can you clarify this?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols 3/3] xdg-shell: Introduce xdg_tooltip

[Bill Spitzak]

On Tue, Jan 12, 2016 at 12:16 AM, Jonas Ådahl  wrote:

> An xdg_tooltip is a new window type used to implement tooltip like
> surfaces. See the interface documentation for details.
>
> +
> +  
> +   This creates an xdg_tooltip for the given xdg_surface and gives the
> +   associated wl_surface the xdg_tooltip role. >>>A wl_surface can
> only have
> +   one xdg_tooltip role. If the wl_surface is given the xdg_tooltip
> role
> +   while it already has an active xdg_tooltip role, or if it has been
> given
> +   any other role before, an error is raised.<<<
>

I believe all the text between >>> and <<< is redundant, it has already
been established that you can set the role of a surface exactly once.


> +   See the documentation of xdg_tooltip for more details about what an
> +   xdg_tooltip is and how it is used.
> +  
> +  
> +  
>

This seems to combine creation of the surface and assignment of a role, at
least that is my best guess. No matter what this does this documentation
seems misleading.

If in fact this is assigning the "tooltip role" to an existing surface,
then the "parent" argument name is really misleading. That surface *is* the
tooltip.

If this is creating a new surface with the "tooltip role" then the text
"assign the xdg_tooltip surface role" is misleading. It is also rather
mysterious how you do things like set the buffer.

>
> +  
> +
> +  Unmap the tooltip surface and destroy the object.
> +
>

Why isn't the wl_surface destroy request used? Or if you do not have access
to surface methods, how do you do basic things like set the buffer?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v3 weston 2/2] Support axis source, axis discrete, frame and axis stop events

[Bill Spitzak]

On Mon, Jan 11, 2016 at 4:07 PM, Jonas Ådahl  wrote:

>
> > > > + widget_pointer_frame_handler_t pointer_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;
> > >
> > > Should we really make the toytoolkit API this low level? I guess it's
> > > easier this way, so I won't complain further, but it'd be good to have
> > > our toy toolkit try to construct the higher level events the protocol
> > > try to communicate.
> >
> > I think the question is: how much we want the toytoolkit to stay a
> > toy? Composing those events is doable, but how many toytoolkit users will
> > really care about them?
>
> Probably none. It's just a matter of a "toytoolkit should represent how
> the protocol should be interpreted" kind of philosophy. But I understand
> that doing all that extra work just for that reason isn't all that
> reasonable.
>

Another option is to *not* support this in toytoolkit.

Making callbacks like this that don't wait for the frame event is very
misleading, and people are going to copy it (if you think they are going to
read the documentation rather than copy code from toytoolkit, I have a
bridge for sale you may like). I think it would be better to just not
support this at all. Then somebody looking for "how do I get pen tilt from
the tablet" would be forced to read the documentation.

I am not very clear on how this could be done, but it would be nice if
there was a way to do direct-wayland inside toytoolkit. With no support
from toytoolkit, a client should be able to get tablet events. I think all
this requires is the ability to get the wl_surface or xdg_surface proxy
from the toytoolkit window, but maybe I am missing something here...
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland v2] server: don't send an error to NULL display_resource

[Bill Spitzak]

I like this minimal fix better than the previous one that fixed the bug
twice.

I think it would be clearer to just state that "wl_resource_post_error will
crash if display_resource is null".


On Mon, Jan 11, 2016 at 9:33 AM, Derek Foreman 
wrote:

> On 11/01/16 04:45 AM, Marek Chalupa wrote:
> > if display_resource = wl_resource_create() fails in bind_display(),
> > we call wl_client_post_no_memory() which is wrong, since this function
> > uses display_resource (which is NULL at this point).
> > said simply: don't send an error to resource that you've just failed to
> create)
> >
> > https://bugs.freedesktop.org/show_bug.cgi?id=91356
> >
> > Reported-by: Ashim 
> > Signed-off-by: Marek Chalupa 
>
> Reviewed-by: Derek Foreman 
>
> Looks good to me - instead of trying to dereference the pointer in
> wl_resource_post_error() and crashing, now we'll clean up and kill the
> client connection in wl_client_create(), as we should.
>
> Thanks,
> Derek
>
> > ---
> >  src/wayland-server.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/wayland-server.c b/src/wayland-server.c
> > index 9e26b18..017a975 100644
> > --- a/src/wayland-server.c
> > +++ b/src/wayland-server.c
> > @@ -778,7 +778,8 @@ bind_display(struct wl_client *client, struct
> wl_display *display)
> >   client->display_resource =
> >   wl_resource_create(client, _display_interface, 1, 1);
> >   if (client->display_resource == NULL) {
> > - wl_client_post_no_memory(client);
> > + /* DON'T send no-memory error to client - it has no
> > +  * resource to which it could post the event */
> >   return -1;
> >   }
> >
> >
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v3 weston 2/2] Support axis source, axis discrete, frame and axis stop events

[Bill Spitzak]

On Sun, Jan 10, 2016 at 11:59 PM, Jonas Ådahl  wrote:

>
> > + widget_pointer_frame_handler_t pointer_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;
>
> Should we really make the toytoolkit API this low level? I guess it's
> easier this way, so I won't complain further, but it'd be good to have
> our toy toolkit try to construct the higher level events the protocol
> try to communicate.
>

Considering that toytoolkit is doing the xkb stuff, I think it really
should reconsolidate wayland events back into more useful structures.

This is also going to be important if future versions change how this
information is sent. The toytoolkit really should be a source of sample
code as to how to map the various versions to the output data, so that
everybody does not come up with different solutions and make the clients
behave differently from each other.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 2/5] data-device: Implement DnD actions

[Bill Spitzak]

Can you please explain in detail the difference between the actions being
"COPY + MOVE" and being "COPY + MOVE + ASK". I do not at all understand the
purpose of "ASK". It might also help to specify what should happen if ASK
is combined with less than 2 other actions.

On Mon, Jan 11, 2016 at 12:30 AM, Jonas Ådahl  wrote:

> On Thu, Dec 24, 2015 at 02:00:38AM +0100, Carlos Garnacho wrote:
> > The policy in weston in order to determine the chosen DnD action is
> > deliberately simple, and is probably the minimals that any compositor
> > should be doing here.
> >
> > Besides honoring the set_actions requests on both wl_data_source and
> > wl_data_offer, weston now will emit the newly added "action" events
> > notifying both source and dest of the chosen action.
> >
> > The "dnd" client has been updated too (although minimally), so it
> > notifies the compositor of a "move" action on both sides.
> >
>
> Mostly looks good; but I have some questions/comments related to how
> 'ask' is implemented.
>
> > Changes since v5:
> >   - Use enum types and values for not-a-bitfield stored values.
> > handle errors when finding unexpected dnd_actions values.
> >
> > Changes since v4:
> >   - Added compositor-side version checks. Spaces vs tabs fixes.
> > Fixed resource versioning. Initialized new weston_data_source/offer
> > fields.
> >
> > Changes since v3:
> >   - Put data_source.action to use in the dnd client, now updates
> > the dnd surface like data_source.target events do.
> >
> > Changes since v2:
> >   - Split from DnD progress notification changes.
> >
> > Changes since v1:
> >   - Updated to v2 of DnD actions protocol changes, implement
> > wl_data_offer.source_actions.
> >   - Fixed coding style issues.
> >
> > Signed-off-by: Carlos Garnacho 
> > Reviewed-by: Michael Catanzaro 
> > ---
> >  clients/dnd.c |  32 ++---
> >  clients/window.c  |  25 +++
> >  src/compositor.h  |   4 ++
> >  src/data-device.c | 131
> --
> >  4 files changed, 183 insertions(+), 9 deletions(-)
> >
> > diff --git a/clients/dnd.c b/clients/dnd.c
> > index 48111d9..ddf3fcc 100644
> > --- a/clients/dnd.c
> > +++ b/clients/dnd.c
> > @@ -72,6 +72,7 @@ struct dnd_drag {
> >   struct item *item;
> >   int x_offset, y_offset;
> >   int width, height;
> > + uint32_t dnd_action;
> >   const char *mime_type;
> >
> >   struct wl_surface *drag_surface;
> > @@ -266,16 +267,13 @@ dnd_get_item(struct dnd *dnd, int32_t x, int32_t y)
> >  }
> >
> >  static void
> > -data_source_target(void *data,
> > -struct wl_data_source *source, const char *mime_type)
> > +dnd_drag_update_surface(struct dnd_drag *dnd_drag)
> >  {
> > - struct dnd_drag *dnd_drag = data;
> >   struct dnd *dnd = dnd_drag->dnd;
> >   cairo_surface_t *surface;
> >   struct wl_buffer *buffer;
> >
> > - dnd_drag->mime_type = mime_type;
> > - if (mime_type)
> > + if (dnd_drag->mime_type && dnd_drag->dnd_action)
> >   surface = dnd_drag->opaque;
> >   else
> >   surface = dnd_drag->translucent;
> > @@ -288,6 +286,16 @@ data_source_target(void *data,
> >  }
> >
> >  static void
> > +data_source_target(void *data,
> > +struct wl_data_source *source, const char *mime_type)
> > +{
> > + struct dnd_drag *dnd_drag = data;
> > +
> > + dnd_drag->mime_type = mime_type;
> > + dnd_drag_update_surface(dnd_drag);
> > +}
> > +
> > +static void
> >  data_source_send(void *data, struct wl_data_source *source,
> >const char *mime_type, int32_t fd)
> >  {
> > @@ -360,12 +368,22 @@ data_source_drag_finished(void *data, struct
> wl_data_source *source)
> >   dnd_drag_destroy(dnd_drag);
> >  }
> >
> > +static void
> > +data_source_action(void *data, struct wl_data_source *source, uint32_t
> dnd_action)
> > +{
> > + struct dnd_drag *dnd_drag = data;
> > +
> > + dnd_drag->dnd_action = dnd_action;
> > + dnd_drag_update_surface(dnd_drag);
> > +}
> > +
> >  static const struct wl_data_source_listener data_source_listener = {
> >   data_source_target,
> >   data_source_send,
> >   data_source_cancelled,
> >   data_source_drop_performed,
> >   data_source_drag_finished,
> > + data_source_action,
> >  };
> >
> >  static cairo_surface_t *
> > @@ -428,6 +446,8 @@ create_drag_source(struct dnd *dnd,
> >   dnd_drag->item = item;
> >   dnd_drag->x_offset = x - item->x;
> >   dnd_drag->y_offset = y - item->y;
> > + dnd_drag->dnd_action =
> WL_DATA_DEVICE_MANAGER_DND_ACTION_MOVE;
> > + dnd_drag->mime_type = NULL;
> >
> >   for (i = 0; i < ARRAY_LENGTH(dnd->items); i++) {
> >   if (item == dnd->items[i]){
> > @@ -461,6 +481,8 @@ create_drag_source(struct dnd *dnd,
> >
>  window_get_wl_surface(dnd->window),
> > 

Re: libinput: Disable tap-and-drag

[Bill Spitzak]

The timeout can be avoided by sending tap+drag as
press/release/(wait)/press/drag. I don't have it here to test but I
remember hearing this is what some (all?) mac implementations do.

This requires libinput to also decide whether a click is a "double click"
or not, the fact that our software was doing it's own timeout rather than
use the system api is why I heard about this. Moving double click decision
into libinput certainly seems consistent with what is being done here, and
would avoid a big annoyance where different clients have different rules.
The fact that this "mouse gesture" is interpreted by clients on X is just
historical because X predates the double-click idea.

Searching on the web shows that recent versions of OS/X turned off
tap-and-drag, since all the discussion was from people asking how to turn
it back on. This indicates two things: first that somebody at Apple decided
that it was not desirable to a big enough set of users to change the
default, second that there is a non-zero set of users that *do* like it.




On Fri, Jan 8, 2016 at 9:14 AM, Cyril B.  wrote:

> Peter Hutterer wrote:
>
>> thanks for doing this work. tbh, I'm not a big fan of having this as a
>> configuration option. IMO if you are using tapping as an interaction
>> method
>> on the touchpad, having tap-and-drag available is the natural extension
>> and
>> I don't see why we should disable it.
>>
>
> I have the same issue as Caibin: I simply cannot use tap-to-click as it
> is, as it triggers unwanted drags all the time. I even wonder how other
> people do not have the same problem: do they systematically (consciously or
> not) wait before moving the cursor after tapping?
>
> However, I'd like to point out that both Windows and OSX have tap-and-drag
> disabled by default. That means that many users are probably used to that
> behaviour, and may find it frustrating not being able to turn off
> tap-and-drag.
>
> Regarding decreasing the timeout, in my case I doubt it would work as my
> tap + move combination is done very quickly, as fast as a double-tap
> actually. I'm willing to try it though, but I'm not sure what constant
> should be modified in the code.
>
> Caibin: thanks for the work, I'll test your branch very soon.
>
> --
> Cyril B.
>
> ___
> 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: [RFC wayland-protocols V3] Add Primary Selection Protocol Version 1

[Bill Spitzak]

On Wed, Jan 6, 2016 at 7:42 PM, Jonas Ådahl  wrote:

>
> Does this mean that the offer always comes on keyboard focus? Or pointer
> focus? Or touch focus? Or does it come a user interaction of some kind?
>

I think the last one is the intention here. The offer will come just before
an event that the compositor consideres a possible "paste event". The
original proposal was for this to be limited to middle mouse down, but it
sounds like it will be on all button and key down events. I now think the
idea is good, it prevents a client from passively watching the contents of
the selection, and may mean it is safe to select passwords and other
sensitive information. I also will contradict what I said before, it seems
good to not tie this to focus, so that simply moving the mouse does not
give clients the ability to peek at the selection.

And after that it may retrieve the primary selection at any point?


Yes, until the selection is changed. At that point it will get a destroyed
event on the offer, but it won't get another offer until the next "paste
event".

Could
> it not be done as request that is a response to an input event carrying
> a serial, where the serial can be used to match the request to the
> triggering user interaction. Or would that break some expectations of
> the primary selection use case (i.e. retrieve not from a user
> interaction)?
>

I think that would make it impossible to emulate the X11 interface. Also it
adds round trips.

X11 just has a "selection was changed" event, and the ability to read the
selection. I think this can be mapped from this api without giving the X11
clients any more ability to peek at the selection, by having the
destruction of the offer act as though the selection was changed to an
empty string, and the new offer act as though the selection was changed yet
again. So a middle-mouse click will give an X11 client a selection changed
event followed immediately by the mouse click.

Something I do realize is necessary: the client making the selection needs
an indication that another client has made a selection. This is so it can
redraw highlighting to show the fact that it no longer has the selection
(I'm not saying this is required, but it is a behavior that should be
possible). Right now this sends destruct events to the clients that got the
offer, but I don't think anything is sent to the source client. I think
this needs to be another event on the primary_selection_device.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC v2] Add Primary Selection Protocol Version 1

[Bill Spitzak]

On Tue, Jan 5, 2016 at 7:47 AM, Michal Suchanek  wrote:

>
> > Maybe it should only send the newid if the selection has changed. The
> client
> > can keep the old object around until it is destroyed, even if it gets
> many
> > clicks.
> >
> > ie. when the selection changes, any old offers get the destroyed event.
> But
> > clients do not get the new offer until they get another middle click. If
> the
> > user clicks many times only one offer proxy is created.
> >
> > The overhead may not be so minimal in creating/destroying local objects
> in
> > some languages such as Python, so it does seem nice to avoid this. A
> bigger
> > concern is that if more events are decided to be "pasteable" by the
> > compostior, it will have to send the offer even more times (imagine if
> it is
> > decided that any keystroke can paste). This rule means it only has to
> send
> > it before the first such event.
>
> Actually, this sounds reasonable.
>
> When there is a selection set and an application receives any input
> event it will also receive a paste offer. It can then act on that
> offer any time until a new selection is set. It does need  any new
> offer until new selection is set.
>
> When concerned about pasting into the wrong application the user can
> unmap/minimize/whatever the application window so it cannot receive
> input events.
>

Actually with this design, a user can be certain that no other app can see
the selected text unless they actually click the middle mouse in that app
after making the selection. Even with the more extreme versions I think
will eventually appear, the app probably will not see the selection unless
they type a key or click in it. This may make it safe to select passwords
and other sensitive data.


> There is only slight problem with paste buffer managers and download
> managers which try to watch for paste buffer changes in the background
> without receiving any input. This can be probably amended by setting
> different paste policies (filters for events that allow access to the
> paste buffer) for different applications.
>

Yea it would prevent that. Maybe those could require special privledges,
and they will get the event with the offer on all changes.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC v2] Add Primary Selection Protocol Version 1

[Bill Spitzak]

On 01/04/2016 08:33 PM, Peter Hutterer wrote:


Also it seems like you will send this on *every* middle click. Some clients
require clicking the middle button a lot without pasting (it is very common
to use it as a pan control in 2D/3D).



in the normal use-case you will get a lot more focus changes than middle
clicks.


Not if middle-click is used for panning. That's why I mentioned it.

You are correct though that it is probably irrelevant. Though I am a bit
concerned that this event includes an object with a new id, and all the
necessary work on both the compositor and client to track it.


one of the big benefits that input related stuff has is that you don't need
to care too much about resources. yes, this protocol involves creating and
destroying objects on every middle click. Compared to the textures you just
had to load to display the web browser, this is peanuts. Crushed into very
small pieces :)


Maybe it should only send the newid if the selection has changed. The 
client can keep the old object around until it is destroyed, even if it 
gets many clicks.


ie. when the selection changes, any old offers get the destroyed event. 
But clients do not get the new offer until they get another middle 
click. If the user clicks many times only one offer proxy is created.


The overhead may not be so minimal in creating/destroying local objects 
in some languages such as Python, so it does seem nice to avoid this. A 
bigger concern is that if more events are decided to be "pasteable" by 
the compostior, it will have to send the offer even more times (imagine 
if it is decided that any keystroke can paste). This rule means it only 
has to send it before the first such event.




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

Re: [RFC v2] Add Primary Selection Protocol Version 1

[Bill Spitzak]

On 01/03/2016 10:28 PM, Peter Hutterer wrote:


I really do not like this key assignment being something the compositor is
in charge of. A client may have a very good reason to use middle-click for
something else, yet still want the ability to paste from the selection.


this is still possible with the current proposal.


I think you are talking about the client optionally using the middle 
click for paste or for something else, perhaps depending on where they 
click. That is certainly important.


As far as I can tell this is purposely preventing clients from using a 
keystroke or shift+click or any other action to trigger a paste from the 
selection. That seems wrong to me. Also, despite the comment, it is not 
"identical to that of primary selection pasting in X". X lets the client 
grab the selection buffer at any moment, nothing in the X protocol ties 
it to the middle mouse button.



Also it seems like you will send this on *every* middle click. Some clients
require clicking the middle button a lot without pasting (it is very common
to use it as a pan control in 2D/3D).



in the normal use-case you will get a lot more focus changes than middle
clicks.


Not if middle-click is used for panning. That's why I mentioned it.

You are correct though that it is probably irrelevant. Though I am a bit 
concerned that this event includes an object with a new id, and all the 
necessary work on both the compositor and client to track it.


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

Re: [RFC v2] Add Primary Selection Protocol Version 1

[Bill Spitzak]

On 01/03/2016 09:05 PM, Peter Hutterer wrote:

On Fri, Dec 18, 2015 at 12:03:46PM -0500, Lyude wrote:

+This event is sent whenever the client receives a middle click, and 
will
+be received by the client before the actual middle click event. While
+the compositor is free to bind this event to another input event (such
+as a keyboard shortcut), the client should always treat pastes from the
+primary selection as middle clicks. This is to ensure the behavior is
+identical to that of primary selection pasting in X.


Not a big fan of this, the intent is good but the wording needs improvement.
Unless you somehow pair the event with a middle click, a client cannot know
if the middle click triggered the paste or a keyboard shortcut, followed by
a middle click. I would argue for wording that requires this event to be in
the same wl_{pointer|touch|keyboard}.frame as the triggering event.

Let's assume an application that binds middle click to full-screen, for
argument's sake:
"treat pastes from the primary selection as middle clicks."
This would mean that if you receive a selection_offer event the client must
full-screen the application because the event is to be treated like a
middle click :)

Suggested rewording:
"This event is typically sent whenever the user executes a middle click
though the compositor may bind this event to other user input sequences. If
applicable, the selection_offer event is sent in the same wl_pointer.frame,
wl_touch.frame or wl_keyboard.frame as the triggering event.


I really do not like this key assignment being something the compositor 
is in charge of. A client may have a very good reason to use 
middle-click for something else, yet still want the ability to paste 
from the selection.


Also it seems like you will send this on *every* middle click. Some 
clients require clicking the middle button a lot without pasting (it is 
very common to use it as a pan control in 2D/3D).


It seems like it would be much better to send this event when to 
surfaces with various foci (keyboard, mouse, etc) when the selection 
changes, and also when a surface gets a focus and the selection has 
changed since it last had focus.



I'm missing something or I'm misunderstanding how this is supposed to work.
When I highlight something, the source adds the mimetypes available. A middle
click triggers the selection_offer event and the "offer" events on that
object. the client calls "receive" which converts to the "send" event in the
other client and data is exchanged over the fd.

Two problems:
* the source client has no way of finalising the list of mimetypes. What
   happens if a mimetype is added after the selection_offer event was sent to
   the receiving client?
* what happens if the source client goes away between selection_offer and
   the receiving client's receive? does the protocol guarantee an empty fd*?
   I think you need a cancel event on the selection_offer object.


These problems apply to (and have been solved by?) the DnD offer objects 
already. Copy that exactly. If there is a bug it needs to be fixed in 
both of them.


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

Re: [PATCH wayland-protocols v2 2/2] Introduce pointer locking and confinement protocol

[Bill Spitzak]

On 01/03/2016 08:21 PM, Peter Hutterer wrote:

On Fri, Jan 01, 2016 at 04:54:14PM +, Daniel Stone wrote:


I almost wonder if we couldn't make peoples' lives easier by merging
locking and confinement into a single interface, adding a bool for
whether or not to allow pointer movement (confine) or not (lock). Or
perhaps, rather than a bool, we could add an allow-null
wp_relative_pointer argument instead: gives you lock if non-null, or
confine if null.


you get a much less expressive API, less checking, etc. for a fairly minimal
benefit. Furthermore, any extension to *either/or* the lock/confine
interface would need to handle the appropriate NULL cases for the other
interface. Right now we can easily add a locking-specific request without
messing up the logic of the confinement, and vice versa.


You have a confinement protocol where the client updates a region to 
move the cursor.


You have the lock protocol where the client updates an x/y and it moves 
the cursor (though you call it the "hint" and it does not move the 
cursor until after the lock is destroyed, but since this is useless 
unless the client hides the cursor, the behavior would be identical if 
it moved the cursor immediately).


An x/y position is a degenerate region.

Therefore the two are the same, provided you let the lock version 
actually move the cursor, rather than it being a "hint". Which would be 
incredibly useful, too!



Also, for symmetry with wp_relative_pointer, should this take a
wl_pointer instead of wl_seat?


you'd be restricting locking and confinement to a pointer device, with a
wl_seat you can confine and lock devices that are not wl_pointer devices,
e.g. a wl_tablet tool in relative mode.


I'm pretty certain that would provide a wl_pointer. Absolute mode maybe 
I could understand, but not relative.


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

Re: [PATCH wayland-protocols v2 2/2] Introduce pointer locking and confinement protocol

[Bill Spitzak]

On 01/01/2016 08:54 AM, Daniel Stone wrote:


I almost wonder if we couldn't make peoples' lives easier by merging
locking and confinement into a single interface, adding a bool for
whether or not to allow pointer movement (confine) or not (lock). Or
perhaps, rather than a bool, we could add an allow-null
wp_relative_pointer argument instead: gives you lock if non-null, or
confine if null.


Yes please merge these two almost-identical apis into a single one. Base 
it on the confinement version. This already allows the client to update 
the confinement region as often as wanted. A zero-sized region can force 
the cursor to be at a particular point, which is what the pointer lock 
does (with my oft-requested enhancement that the normal cursor-setting 
code can be reused to set the cursor image).


If you want to duplicate the almost-useless current pointer-lock, the 
client can just hide the cursor, and make a fake one using a new 
surface. Setting the region also sets the "hint" as he calls it.



Also, for symmetry with wp_relative_pointer, should this take a
wl_pointer instead of wl_seat?


Seems like a good idea


+  If the compositor decides to unlock the pointer the unlocked event is
+  sent. The wp_locked_pointer object is at this point defunct and should be
+  destroyed.


Egads. :( This is a bit hostile - what's the harm in allowing latent
objects to remain?


I think he is just trying to say that the object is now useless. The 
client does not have to destroy it, but it probably should.


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

Re: [PATCH wayland v2 4/8] client: Use read preparation API in wl_display_dispatch_queue()

[Bill Spitzak]

I was going to propose the same thing, though I was uncertain if it 
really was equivalent. IMHO this looks correct as it is almost identical 
to my patch (mine lacked the changes for EPIPE and had a nested if so 
there was only one call to dispatch_queue).


It would also help to fix the documentation to say that this function is 
identical to this other sequence.


On 12/28/2015 06:10 PM, Jonas Ådahl wrote:

Instead of doing things that do the equivalent of using
wl_display_prepare_read() and friends, just use the public API. The
only semantical difference is that we will now unlock and lock the mutex
more times compared to before.

Signed-off-by: Jonas Ådahl 
---
  src/wayland-client.c | 45 ++---
  1 file changed, 10 insertions(+), 35 deletions(-)

diff --git a/src/wayland-client.c b/src/wayland-client.c
index 035825c..8bf6124 100644
--- a/src/wayland-client.c
+++ b/src/wayland-client.c
@@ -1488,30 +1488,17 @@ wl_display_dispatch_queue(struct wl_display *display,
struct pollfd pfd[2];
int ret;

-   pthread_mutex_lock(>mutex);
-
-   ret = dispatch_queue(display, queue);
-   if (ret == -1)
-   goto err_unlock;
-   if (ret > 0) {
-   pthread_mutex_unlock(>mutex);
-   return ret;
-   }
+   if (wl_display_prepare_read_queue(display, queue) == -1)
+   return wl_display_dispatch_queue_pending(display, queue);

-   /* We ignore EPIPE here, so that we try to read events before
-* returning an error.  When the compositor sends an error it
-* will close the socket, and if we bail out here we don't get
-* a chance to process the error. */
-   ret = wl_connection_flush(display->connection);
+   /* Don't stop if flushing hits an EPIPE; continue so we can read any
+* protocol error that may have triggered it. */
+   ret = wl_display_flush(display);
if (ret < 0 && errno != EAGAIN && errno != EPIPE) {
-   display_fatal_error(display, errno);
-   goto err_unlock;
+   wl_display_cancel_read(display);
+   return -1;
}

-   display->reader_count++;
-
-   pthread_mutex_unlock(>mutex);
-
pfd[0].fd = display->fd;
pfd[0].events = POLLIN;
do {
@@ -1523,22 +1510,10 @@ wl_display_dispatch_queue(struct wl_display *display,
return -1;
}

-   pthread_mutex_lock(>mutex);
-
-   if (read_events(display) == -1)
-   goto err_unlock;
-
-   ret = dispatch_queue(display, queue);
-   if (ret == -1)
-   goto err_unlock;
-
-   pthread_mutex_unlock(>mutex);
-
-   return ret;
+   if (wl_display_read_events(display) == -1)
+   return -1;

- err_unlock:
-   pthread_mutex_unlock(>mutex);
-   return -1;
+   return wl_display_dispatch_queue_pending(display, queue);
  }

  /** Dispatch pending events in an event queue



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

Re: [PATCH wayland v2 4/8] client: Use read preparation API in wl_display_dispatch_queue()

[Bill Spitzak]

On 12/28/2015 06:10 PM, Jonas Ådahl wrote:


+   ret = wl_display_flush(display);
if (ret < 0 && errno != EAGAIN && errno != EPIPE) {


With your patch 5/8 EAGAIN will never happen, so you might want to 
remove it here.


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

Re: [PATCH wayland 2/2] protocol: Add DnD actions

[Bill Spitzak]

What does "ask" mean?

I would think "ask" is implied by the fact that more than one action is
provided. Maybe an explanation as to what the drop target should do with
these combinations and how they differ from each other (just write what the
drop target should do for each):

 MOVE
 MOVE+ASK
 MOVE+COPY
 MOVE+COPY+ASK
 0 (ie no action)
 ASK

For an example of what I am looking for, here is my best guess that
actually makes ask mean anything:

 MOVE
do a move without any user interaction
 MOVE+ASK
do a move, but ui allowing choice of overlapping drop targets is allowed
 MOVE+COPY
must choose move or copy without user interaction
 MOVE+COPY+ASK
must choose move or copy but can use user interaction
 0 (ie no action)
error
 ASK
error
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput] tablet: invert tilt axes when left-handed is enabled

[Bill Spitzak]

On Mon, Dec 21, 2015 at 1:24 PM, Peter Hutterer <peter.hutte...@who-t.net>
wrote:

> On Mon, Dec 21, 2015 at 10:12:24AM -0800, Bill Spitzak wrote:
> > I find it hard to believe this is what client programs will want.  A
> > painting program wants the axis of an elongated brush to be perpendicular
> > to the tilt will work correctly only if *both* axes are flipped (as your
> > code appears to be doing). But it will get "which edge is nearer"
> backward
> > if it wants to draw something asymmetric in the direction the pen is
> > tilted. And it also seems to make little sense to flip the vertical tilt
> > for a left-handed user.
> >
> > Or are you perhaps undoing some flip that the tablet is doing internally?
>
> a tablet in left-handed mode is effectively rotated by 180 degrees to bring
> the set of buttons towards the side of the nondominant hand. this inverts x
> and y, if we don't also invert tilt the client program will think that the
> pen is tilted in the opposite direction.
>
> symmetrical tablets don't have a left-handed mode.
>
> That makes sense. I assume the condition that triggers this is exactly the
same as the one that triggers the x and y axis to be inverted, right?

You might also need to check whether z-axis rotation is correct (ie is the
zero in the right direction).
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC v2] Add Primary Selection Protocol Version 1

[Bill Spitzak]

On Fri, Dec 18, 2015 at 9:03 AM, Lyude  wrote:

> Signed-off-by: Lyude 
> ---
> Changes
> * Add new interfaces to replace reuse of wl_data_(source|offer)
> * Get rid of the selection changed event since we now have our own version
>   of wl_data_(source|offer), and clients can just assume destroyed events
>   indicate that their data in the primary clipboard has been replaced.
> * Get rid of summary on arguments, I noticed most of the official wayland
>   protocol doesn't actually use these, and they were mostly redundant
>   anyway.
> * s/selection_set/set_selection/
> * Add destructor requests for all interfaces
>

I do not like the fact that a program has to create both a
wl_primary_selection_offer and a wl_data_offer on any selection (yes it can
defer the second one until the user starts a drag, but it still would be
nice to reuse the same one for both). Still not a huge problem, like in
many other cases the two proxies can be stuffed into the same higher-level
api object.

Some assurance that the abilities of both will be kept identical would
help, however. I don't want some data transfers to be impossible depending
on whether the user does dnd or middle-click paste.


> +
> +  
> +Singleton global object that manages the
> zwp_primary_selection_device_v1
> +objects for each wl_seat.
> +  
> +   interface="zwp_primary_selection_device_v1"/>
> +  
> +
>

Also, looking at what happened to wl_pointer, it appears the design of
Wayland is to not have any "singletons" except the globally-advertised
objects. I'm not sure if this has any visible effects on your api because
there is no actual state stored on the object, and you must already support
creating more than one, but it might make sense to get rid of the words
"Singleton global".

+  
> +
> +  
> +Set the current contents of the primary selection buffer. This
> clears
> +anything which was previously held in the primary selection
> buffer.
> +
> +This request can only be used while the window is focused.
> +  
> +   interface="zwp_primary_selection_source_v1"/>
> +
>

Please don't require the "window is focused". The rules used by the
compositor to accept/reject these offers should be defined by the
compositor (a possible rule is that the window either got a mouse click or
a keystroke from the seat). Clicking in a window should never be required
to cause focus/activate/raise by the low-level api, that is instead part of
the desktop and client definition.

+
> +  
> +Sent when the client has permission to read from the primary
> selection
> +buffer.
> +
> +This event is sent whenever the client receives a middle click,
> and will
> +be received by the client before the actual middle click event.
> While
> +the compositor is free to bind this event to another input event
> (such
> +as a keyboard shortcut), the client should always treat pastes
> from the
> +primary selection as middle clicks. This is to ensure the
> behavior is
> +identical to that of primary selection pasting in X.
> +
> +It is up to the client to decide whether or not it is appropriate
> to
> +read from the primary buffer and paste it's contents.
> +  
> +   interface="zwp_primary_selection_offer_v1"/>
> +
>

I think it would be better to send this to the client when it gets any
focus from the seat, and also if the selection is changed while it has
focus. Then the client is able to free to use any method to do the paste
(though of course using the middle mouse is encouraged). Also means there
is not redundant events if the user clicks the middle mouse many times (a
lot of programs use the middle-mouse drag as a pan operation).

+
> +  
> +Request for the current primary selection contents from the
> client.
> +Send the specified mime type over the passed file descriptor, then
> +close it.
> +  
> +  
> +  
> +
>

May want to point out that this can happen more than once (ie the middle
mouse button is clicked more than once per set_selection).

+
> +  
> +This primary selection source has been replaced by another primary
> +selection source. The client should clean up and destroy this
> primary
> +selection source.
> +  
> +
>

I would guess this event is also sent if the compositor refuses the
set_selection request?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 5/5] dnd: Turn into a full blown example

[Bill Spitzak]

On Mon, Dec 21, 2015 at 5:33 PM, Carlos Garnacho  wrote:

> In order to keep things simple, weston-dnd made a few choices that
> turn out to be unrealistic, a few tweaks have been done to make it
> less of a playground demo:
>
> - It now caters for copy/move operations, instead of just move,
>   which still remains the default nonetheless.
> - As "move" operations are no longer assumed, the item isn't removed
>   on start_drag, instead it is made translucent until the drag
>   operation finishes (and we know whether the item is to be
>   removed after transfer or left as is)
>

A much better demo would be to alter the opacity depending on the selected
action: if it is move then the source vanishes, if it is copy it remains
opaque, and if it is not known it is the translucent value.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: weston flip a null frame first before start launcher

[Bill Spitzak]

On Thu, Dec 17, 2015 at 3:05 AM, Pekka Paalanen  wrote:

> On Thu, 17 Dec 2015 18:27:48 +0800
> zou lan  wrote:
>
> > Hi pekka & others
> >
> > I find weston flip a null frame before start the launcher
> > weston-desktop-shell. So there is always a black surface flash before the
> > launcher. That doesn't have the relationship with the animation mode.
> > I think it's caused by the code weston_output_init which call
> > the weston_output_damage.
> >
> > weston_output_damage will paint nothing if the animation mode is noe and
> > flip one frame.
> >
> > Does this frame is normal or my implementions have problems?  Thank you.
> > I try it on weston version 1.8 and 1.9.
> >
> > weston.ini
> > [shell]
> > animation=none
> > startup-animation=none
> > client=/usr/lib/weston/weston-desktop-shell
>
> Hi Nancy,
>
> I think this commit explains some aspects of it:
>
> http://cgit.freedesktop.org/wayland/weston/commit/?id=23ed5f2526e97d11df35cd8d9a9c7b95b635e225
> Looks like 1.7.93 was the first release to include that patch.
>
> What you see is how Weston is written, AFAIU. Nothing wrong on your
> part.
>
> Hmm, yeah, I suppose we could delay the very first repaint until after
> the shell client signals ready, or at least until something causes a
> real need for repaint.
>
> In fact the x11-backend shows the same issue, it flips to one frame of
> garbage before showing the desktop.
>

I think the demo compositor must be fixed to not have any such issues.
Mostly so that you can prove that it is possible and that there is not an
insurmountable bug in Wayland, and to provide instruction in how to do it.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput] tablet: invert tilt axes when left-handed is enabled

[Bill Spitzak]

I find it hard to believe this is what client programs will want. A
painting program wants the axis of an elongated brush to be perpendicular
to the tilt will work correctly only if *both* axes are flipped (as your
code appears to be doing). But it will get "which edge is nearer" backward
if it wants to draw something asymmetric in the direction the pen is
tilted. And it also seems to make little sense to flip the vertical tilt
for a left-handed user.

Or are you perhaps undoing some flip that the tablet is doing internally?

On Sun, Dec 20, 2015 at 5:46 PM, Peter Hutterer 
wrote:

> Signed-off-by: Peter Hutterer 
> ---
>  src/evdev-tablet.c |  4 
>  test/tablet.c  | 38 ++
>  2 files changed, 42 insertions(+)
>
> diff --git a/src/evdev-tablet.c b/src/evdev-tablet.c
> index bf61411..50891e3 100644
> --- a/src/evdev-tablet.c
> +++ b/src/evdev-tablet.c
> @@ -365,6 +365,8 @@ tablet_handle_tilt(struct tablet_dispatch *tablet,
> if (bit_is_set(tablet->changed_axes, a)) {
> absinfo = libevdev_get_abs_info(device->evdev, ABS_TILT_X);
> tablet->axes[a] = normalize_tilt(absinfo);
> +   if (device->left_handed.enabled)
> +   tablet->axes[a] *= -1;
> }
> tilt.x = tablet->axes[a];
>
> @@ -372,6 +374,8 @@ tablet_handle_tilt(struct tablet_dispatch *tablet,
> if (bit_is_set(tablet->changed_axes, a)) {
> absinfo = libevdev_get_abs_info(device->evdev, ABS_TILT_Y);
> tablet->axes[a] = normalize_tilt(absinfo);
> +   if (device->left_handed.enabled)
> +   tablet->axes[a] *= -1;
> }
> tilt.y = tablet->axes[a];
>
> diff --git a/test/tablet.c b/test/tablet.c
> index a55b60a..87af814 100644
> --- a/test/tablet.c
> +++ b/test/tablet.c
> @@ -1018,6 +1018,43 @@ START_TEST(no_left_handed)
>  }
>  END_TEST
>
> +START_TEST(left_handed_tilt)
> +{
> +#if HAVE_LIBWACOM
> +   struct litest_device *dev = litest_current_device();
> +   struct libinput *li = dev->libinput;
> +   struct libinput_event *event;
> +   struct libinput_event_tablet_tool *tev;
> +   enum libinput_config_status status;
> +   struct axis_replacement axes[] = {
> +   { ABS_DISTANCE, 10 },
> +   { ABS_TILT_X, 90 },
> +   { ABS_TILT_Y, 10 },
> +   { -1, -1 }
> +   };
> +   double tx, ty;
> +
> +   status =
> libinput_device_config_left_handed_set(dev->libinput_device, 1);
> +   ck_assert_int_eq(status, LIBINPUT_CONFIG_STATUS_SUCCESS);
> +
> +   litest_drain_events(li);
> +
> +   litest_tablet_proximity_in(dev, 10, 10, axes);
> +   libinput_dispatch(li);
> +   event = libinput_get_event(li);
> +   tev = litest_is_tablet_event(event,
> +LIBINPUT_EVENT_TABLET_TOOL_PROXIMITY);
> +   tx = libinput_event_tablet_tool_get_tilt_x(tev);
> +   ty = libinput_event_tablet_tool_get_tilt_y(tev);
> +
> +   ck_assert_double_lt(tx, 0);
> +   ck_assert_double_gt(ty, 0);
> +
> +   libinput_event_destroy(event);
> +#endif
> +}
> +END_TEST
> +
>  START_TEST(motion_event_state)
>  {
> struct litest_device *dev = litest_current_device();
> @@ -2852,6 +2889,7 @@ litest_setup_tests(void)
> litest_add("tablet:tilt", tilt_x, LITEST_TABLET|LITEST_TILT,
> LITEST_ANY);
> litest_add("tablet:tilt", tilt_y, LITEST_TABLET|LITEST_TILT,
> LITEST_ANY);
> litest_add_for_device("tablet:left_handed", left_handed,
> LITEST_WACOM_INTUOS);
> +   litest_add_for_device("tablet:left_handed", left_handed_tilt,
> LITEST_WACOM_INTUOS);
> litest_add_for_device("tablet:left_handed", no_left_handed,
> LITEST_WACOM_CINTIQ);
> litest_add("tablet:normalization", normalization, LITEST_TABLET,
> LITEST_ANY);
> litest_add("tablet:pad", pad_buttons_ignored, LITEST_TABLET,
> LITEST_ANY);
> --
> 2.5.0
>
> ___
> 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: [RFC wayland-protocols 1/1] Add Primary Selection Protocol Version 1

[Bill Spitzak]

On Mon, Dec 14, 2015 at 9:13 AM, Pekka Paalanen <ppaala...@gmail.com> wrote:

> On Mon, 14 Dec 2015 10:39:05 -0500
> Lyude <cp...@redhat.com> wrote:
>
> > On Sat, 2015-12-12 at 11:29 -0800, Bill Spitzak wrote:
> > > I don't think you need the word "primary" in there. It can be called
> the
> > > selection. The other thing this is confused with is called the
> "clipboard".
> > >
> > > Glad to see you reusing the dnd protocol. X selection and
> middle-button paste
> > > is really a form of DnD, but with the advantage that the user can
> rearrage and
> > > open and close windows between when they start and finish the drag.
> > Alright I'm a bit confused here since I'm getting conflicting opinions
> on this.
> > Should we be reusing the dnd protocol or not? Giulio seems to think we
> shouldn't
> > be reusing the data offer objects here, but I would have thought that
> makes the
> > most sense here seeing as the functionality of a
> wp_primary_(offer|source) would
> > be pretty much identical to the wl_data_(offer|source) objects.
>
> Giulio is right.
>
> You must not break the versioning (hierarchy) of protocol objects.
> See:
> http://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Versioning
>
> Having two different global interfaces that (or their child
> interfaces, i.e. the interfaces of objects that can be created from
> these) can create objects with the same interface will not allow
> that interface to be extended, because the interface version becomes
> ambiguous.
>
> Examples of interfaces that are already impossible to extend are
> wl_buffer and wl_callback. For wl_buffer there is a good reason to
> break the rule and take the hit of being stuck at version 1
> forever, but I think it was more of an accident than intentional
> design originally.
>

He is not creating the DnD objects with the new api, just reusing them.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland v3] protocol: add support for cross-interface enum attributes

[Bill Spitzak]

I believe this is correct and worth using.

The only difference with mine is that the protocol-to-docbook.xsl puts the
enum arg handling into it's own top-level clause, rather than as an if
statement. This I think makes it more consistent with the other argument
special-cases (one for object ids, and another for new ids). I'm not sure
if this is really important, and also I think I could submit it as an extra
patch after this.


On Mon, Dec 14, 2015 at 4:48 AM, Auke Booij  wrote:

> Bill, any chance you could review this? Or would you prefer it if this
> were based on your patch (which I do still support)?
>
> On 5 December 2015 at 13:39, Auke Booij  wrote:
> > The enum attribute, for which scanner support was introduced in
> > 1771299, can be used to link message arguments to s. However,
> > some arguments refer to s in a different .
> >
> > This adds scanner support for referring to an  in a different
> >  using dot notation. It also sets the attributes in this
> > style in the wayland XML protocol (wl_shm_pool::create_buffer::format
> > to wl_shm::format, and wl_surface::set_buffer_transform::transform to
> > wl_output::transform), and updates the documentation XSL so that this
> > new style is supported.
> >
> > Changes since v2:
> >  - add object:: prefix for all enumerations in the documentation
> >  - fix whitespace in scanner.c
> >  - minor code fixup to return early and avoid casts in scanner.c
> >
> > Changes since v1:
> >  - several implementation bugs fixed
> >
> > Signed-off-by: Auke Booij 
> > ---
> >  doc/publican/protocol-to-docbook.xsl | 19 +--
> >  protocol/wayland.xml |  4 +--
> >  src/scanner.c| 63
> +++-
> >  3 files changed, 65 insertions(+), 21 deletions(-)
> >
> > diff --git a/doc/publican/protocol-to-docbook.xsl
> b/doc/publican/protocol-to-docbook.xsl
> > index fad207a..7e892c3 100644
> > --- a/doc/publican/protocol-to-docbook.xsl
> > +++ b/doc/publican/protocol-to-docbook.xsl
> > @@ -103,9 +103,22 @@
> >  
> >  
> >
> > -
> > -  
> > -
> > +
> > +  
> > +
> > +  
> > +  ::
> > +  
> > +
> > +  
> > +  
> > +
> > +  
> > +  ::
> > +  
> > +
> > +  
> > +
> >  
> >
> >
> > diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> > index f9e6d76..0873553 100644
> > --- a/protocol/wayland.xml
> > +++ b/protocol/wayland.xml
> > @@ -229,7 +229,7 @@
> >
> >
> >
> > -  
> > +  
> >  
> >
> >  
> > @@ -1292,7 +1292,7 @@
> > wl_output.transform enum the invalid_transform protocol error
> > is raised.
> >
> > -  
> > +  
> >  
> >
> >  
> > diff --git a/src/scanner.c b/src/scanner.c
> > index 406519f..85aeea7 100644
> > --- a/src/scanner.c
> > +++ b/src/scanner.c
> > @@ -747,8 +747,8 @@ start_element(void *data, const char *element_name,
> const char **atts)
> > enumeration->bitfield = true;
> > else
> > fail(>loc,
> > - "invalid value (%s) for bitfield attribute
> (only true/false are accepted)",
> > - bitfield);
> > +"invalid value (%s) for bitfield attribute
> (only true/false are accepted)",
> > +bitfield);
> >
> > wl_list_insert(ctx->interface->enumeration_list.prev,
> >>link);
> > @@ -785,32 +785,62 @@ start_element(void *data, const char
> *element_name, const char **atts)
> > }
> >  }
> >
> > +static struct enumeration *
> > +find_enumeration(struct protocol *protocol, struct interface
> *interface, char *enum_attribute)
> > +{
> > +   struct interface *i;
> > +   struct enumeration *e;
> > +   char *enum_name;
> > +   uint idx = 0, j;
> > +
> > +   for (j = 0; j + 1 < strlen(enum_attribute); j++) {
> > +   if (enum_attribute[j] == '.') {
> > +   idx = j;
> > +   }
> > +   }
> > +
> > +   if (idx > 0) {
> > +   enum_name = enum_attribute + idx + 1;
> > +
> > +   wl_list_for_each(i, >interface_list, link)
> > +   if (strncmp(i->name, enum_attribute, idx) == 0)
> > +   wl_list_for_each(e,
> >enumeration_list, link)
> > +   if(strcmp(e->name, enum_name) ==
> 0)
> > +   return e;
> > +   } else if (interface) {
> > +   enum_name = enum_attribute;
> > +
> > +   wl_list_for_each(e, 

Re: Inconsistency with scaler extension?

[Bill Spitzak]

I agree that the problems the poster is having is due to not sending damage
requests, but I am not really certain the description of the requirement to
send damage is correct.

I am pretty certain the plan for buffer_damage is to indicate the area that
would have to be uploaded to the graphics card to update the texture map.
The fact that if there is no change to the buffer->screen transform this
also can be turned into a minimum screen area that has to be recomposited
is a nice side-effect. If the transform *does* change, it would still be
nice if the buffer_damage represented this texture upload area (in the
unlikely scenario that the client reuses part of the old image for the new
transform). Therefore potentially the buffer damage may be smaller than the
area that needs to be recomposited on-screen.

It sounds like you are saying that on any transform change, the client must
also send wl_surface.damage requests. But this then gets a little
ambiguous. The actual on-screen area damaged is the union of both the old
and new area of the surface. Yet all clients are only sending the new area
of the surface. So either all clients are broken, or the compositor is
detecting that the transform changed and using that to create more damage
than the client requested.

I think perhaps the correct documentation is this:

wl_surface.buffer_damage:

Indicates what pixels in this buffer are different from the pixels in the
previous buffer attached to the surface. The most direct use of this
information is to limit the area that needs to be uploaded to a GPU texture
to only the changed rectangle. However if no wl_surface.damage request is
sent this area is transformed to screen space and used for that as well.

wl_surface.damage:

Indicates the area on-screen that must be redrawn to show the result of the
commit. If this request is not sent, the area of wl_surface.buffer_damage
is instead transformed to the screen and used. This will only work
correctly if the transform does not change.

If the transform or buffer size changes, the compositor will always
re-composite the on-screen area that was occupied by the old version of the
surface but is *not* occupied by the new version. But it may limit
re-compositing of the new area to only the area of the wl_surface.damage
request. This will allow a client that happens to know that an area has not
actually changed to indicate it does not need re-compositing (an actual
example would be a client changing the buffer scale but drawing the same
image at the new scale).

Most clients should send a wl_buffer.damage for the entire new area of the
surface on any transformation change to make sure the screen is updated
correctly. A client could equivalently send a buffer_damage request for the
entire area of the new buffer.

Note that a lot of compositors are going to update the screen on some or
all transformation changes even without the wl_surface.damage request.
Clients should not rely on this.


On Mon, Dec 14, 2015 at 5:16 AM, Pekka Paalanen  wrote:

> On Mon, 14 Dec 2015 13:00:06 +
> Daniel Stone  wrote:
>
> > On 14 December 2015 at 12:49, Daniel Stone  wrote:
> > > On 14 December 2015 at 11:40, Pekka Paalanen 
> wrote:
> > >> On Tue, 08 Dec 2015 14:48:01 +0100
> > >> Matthias Treydte  wrote:
> > >>> Either way, using the scaler API causes either too much drawing when
> > >>> used without setting the damage region (variant (b) above then should
> > >>> change nothing on screen at all, right?) -- or it causes insufficient
> > >>> drawing for variants (a) and (c) above.
> > >>
> > >> We easily err on too much repainting, as it is safe. The damage region
> > >> handling is one of the most complicated pieces of Weston, and
> > >> optimizing it is hard. It also has some known inefficiencies, but
> yours
> > >> is a new observation, IIRC.
> > >
> > > Is it actually new, or is it just yet another occurrence of
> > > https://phabricator.freedesktop.org/T17 ... ?
> >
> > By which I obviously mean https://phabricator.freedesktop.org/T18
>
> I think it's a different issue. But yes, pointing out T18 was in my
> mind, just lazy to look it up. :-)
>
> T18 is about window management causing unnecessary GL texture uploads,
> while here we are looking at excessive repaints. So T18 is about
> weston_surface_damage doing the wrong thing, while the issue here would
> be akin to calling weston_surface_damage at inappropriate times in the
> first place.
>
> Because of T18, moving a window might sometimes "fix" a missing damage
> from the client.
>
>
> Thanks,
> pq
>
> ___
> 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

Re: [PATCH v2 wayland-protocols] Add the tablet protocol

[Bill Spitzak]

On Tue, Dec 8, 2015 at 2:00 PM, Peter Hutterer <peter.hutte...@who-t.net>
wrote:

> On Tue, Dec 08, 2015 at 11:58:20AM -0800, Bill Spitzak wrote:
> > What is the plan for using a tablet in "relative" mode? This is pretty
> > common if the tablet is smaller than the screen, as many modern ones are.
>
> I would love to hear where you get this information from, because the one
> thing we're suffering from is not knowing how our users use the tablet.
> Relative mode is common (and default) in the wacom driver for the lens/puck
> tool but few users have that one. Relative mode for the stylus is
> available,
> but we have little to no data on who's using it.
>

I am using a Wacom Inutos 6x8 tablet. This is a professional and expensive
device (I got it from the bankruptcy auction for Rhythm & Hues, every
artist used these things except for a very small number that had the much
larger 16x16 (?) ones).

My screens are a 4x3 and a 16x9 screen arranged next to each other. Mapping
the tablet area to the entire display results in a horizontal magnification
between physical stylus movement and on-screen movement of about 6 and
vertical scale of about 2. This is too large for me to use on sketching or
3D modelling unless the model is zoomed in so much that I lose any context.
In addition motion of the stylus is distorted by 2.33 times more
horizontally than vertically, which I find very disconcerting. Mapping to
only one screen reduces both of these problems, but not enough imho, and
makes it impossible to use the stylus on one of the screens.

I am also using this on an IMac which has a screen that is closer to 4/3 so
there is no distortion, but I still found the scale much too large to use
on photoshop work.

For these reasons I use the tablet in relative mode for all the tools.

I find it hard to believe that my hardware setup is uncommon. It was used
this way at R, and Linux and Windows and Mac all have the ability to set
it.

Linux support is quite broken and refuses to produce a square aspect ratio
of the motion unless you send xsetwacom commands. Previous versions had
weird bugs where the commands depended on the size of the outputs, but
these seem to be fixed. Here is the cryptic commands I am using (a further
bug is that I have to run this each time after the machine sleeps):

xsetwacom --set "Wacom Intuos3 6x8 stylus" Mode Relative
xsetwacom --set "Wacom Intuos3 6x8 stylus" Area "0 0 162560 121920"
xsetwacom --set "Wacom Intuos3 6x8 eraser" Mode Relative
xsetwacom --set "Wacom Intuos3 6x8 eraser" Area "0 0 162560 121920"

I would say that Mac is not much better. It produces a square aspect but
you have no control over the scale. Windows (well the Wacom-supplied
driver) is much better with a scale control.

I personally believe that what the user wants is to limit the magnification
and distortion of motion, and would use absolute mode if possible without
violating these constraints. Therefore instead of the controls being
whether relative motion is used or not, the controls are a range of
magnification and distortion that the user accepts. This will allow the
tablet to switch automatically between modes if the area is changed (for
instance if a client is able to restrict the tablet to it's own surface).

Looking at my settings I seem to have a physical magnification very close
to 1:1 (I have to move the stylus very slow so that acceleration does not
change the dimension). I also know that a distortion of 4/3 horizontally is
outside my limits. I suspect also that if I had a third tool I would have
to add a line for it, an easy way to set all tools without knowing what
they are would be nice.

Relative mode uses acceleration just like a mouse. This does not have any
detrimental effect on using it for painting as far as I can tell.

>
> That aside, relative mode is handled by the compositor, it's not something
> exposed on the protocol. A client always gets absolute coordinates,
> regardless of the input mode.
>
> > My guess is that you plan to deliver screen/surface coordinates, and that
> > the client is unaware of the actual size of the tablet. However it is not
> > clear from this.
>
> Please suggest a rewording that makes this clearer.
>

No it is ok, a bit of thought will show that the coordinates *must* be in
surface coordinates, therefore relative motion must have been handled
already by the compositor before the client gets these events.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v2 wayland-protocols] Add the tablet protocol

[Bill Spitzak]

I should point out that a big surprise for me was discovering that 
acceleration was applied to the relative motion of the tool. I 
discovered that while trying to draw rectangles to determine the scale 
and realized that only if I moved really slowly would I get the same 
size every time.


I had been using this pretty naturally for sketching and I would have 
thought that acceleration would mess this up, but obviously it does not 
and I was not even aware it was happening.


Acceleration means some simple ideas about reusing absolute mode code 
and just moving the tablet->screen mapping rectangle on each 
proximity-in will not work, as that would have no acceleration.


I need to test the Mac and Windows drivers to see what they do, and also 
see if acceleration is necessary by turning it off. Possibly it is not 
needed.


Despite this I found that I had adjusted it so that the size on-screen 
of the slowest motion is almost exactly the same as the distance the 
stylus moves.


On 12/12/2015 12:15 PM, Bill Spitzak wrote:



On Tue, Dec 8, 2015 at 2:00 PM, Peter Hutterer <peter.hutte...@who-t.net
<mailto:peter.hutte...@who-t.net>> wrote:

On Tue, Dec 08, 2015 at 11:58:20AM -0800, Bill Spitzak wrote:
> What is the plan for using a tablet in "relative" mode? This is pretty
> common if the tablet is smaller than the screen, as many modern ones are.

I would love to hear where you get this information from, because
the one
thing we're suffering from is not knowing how our users use the tablet.
Relative mode is common (and default) in the wacom driver for the
lens/puck
tool but few users have that one. Relative mode for the stylus is
available,
but we have little to no data on who's using it.


I am using a Wacom Inutos 6x8 tablet. This is a professional and
expensive device (I got it from the bankruptcy auction for Rhythm &
Hues, every artist used these things except for a very small number that
had the much larger 16x16 (?) ones).

My screens are a 4x3 and a 16x9 screen arranged next to each other.
Mapping the tablet area to the entire display results in a horizontal
magnification between physical stylus movement and on-screen movement of
about 6 and vertical scale of about 2. This is too large for me to use
on sketching or 3D modelling unless the model is zoomed in so much that
I lose any context. In addition motion of the stylus is distorted by
2.33 times more horizontally than vertically, which I find very
disconcerting. Mapping to only one screen reduces both of these
problems, but not enough imho, and makes it impossible to use the stylus
on one of the screens.

I am also using this on an IMac which has a screen that is closer to 4/3
so there is no distortion, but I still found the scale much too large to
use on photoshop work.

For these reasons I use the tablet in relative mode for all the tools.

I find it hard to believe that my hardware setup is uncommon. It was
used this way at R, and Linux and Windows and Mac all have the ability
to set it.

Linux support is quite broken and refuses to produce a square aspect
ratio of the motion unless you send xsetwacom commands. Previous
versions had weird bugs where the commands depended on the size of the
outputs, but these seem to be fixed. Here is the cryptic commands I am
using (a further bug is that I have to run this each time after the
machine sleeps):

xsetwacom --set "Wacom Intuos3 6x8 stylus" Mode Relative
xsetwacom --set "Wacom Intuos3 6x8 stylus" Area "0 0 162560 121920"
xsetwacom --set "Wacom Intuos3 6x8 eraser" Mode Relative
xsetwacom --set "Wacom Intuos3 6x8 eraser" Area "0 0 162560 121920"

I would say that Mac is not much better. It produces a square aspect but
you have no control over the scale. Windows (well the Wacom-supplied
driver) is much better with a scale control.

I personally believe that what the user wants is to limit the
magnification and distortion of motion, and would use absolute mode if
possible without violating these constraints. Therefore instead of the
controls being whether relative motion is used or not, the controls are
a range of magnification and distortion that the user accepts. This will
allow the tablet to switch automatically between modes if the area is
changed (for instance if a client is able to restrict the tablet to it's
own surface).

Looking at my settings I seem to have a physical magnification very
close to 1:1 (I have to move the stylus very slow so that acceleration
does not change the dimension). I also know that a distortion of 4/3
horizontally is outside my limits. I suspect also that if I had a third
tool I would have to add a line for it, an easy way to set all tools
without knowing what they are would be nice.

Relative mode uses acceleration just like a mouse. This does not have
any detrimental effect on using it for painting as far as I can tell.

Re: [PATCH v2 wayland-protocols] Add the tablet protocol

[Bill Spitzak]

What is the plan for using a tablet in "relative" mode? This is pretty
common if the tablet is smaller than the screen, as many modern ones are.
My guess is that you plan to deliver screen/surface coordinates, and that
the client is unaware of the actual size of the tablet. However it is not
clear from this.



On Mon, Dec 7, 2015 at 9:31 PM, Peter Hutterer 
wrote:

> fixing up the weston patches for this showed a couple of typos:
>
> On Tue, Dec 08, 2015 at 12:50:01PM +1000, Peter Hutterer wrote:
> > +
>
> the protocol name should just be "tablet", i.e. tablet_unstable_v1 in this
> case.
>
> > +  
>
> this should be ...seat_v1
>
> > +  
>
> this should be v1
>
> These are all fixed locally now.
>
> Cheers,
>Peter
>
> ___
> 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 v7 wayland] protocol: add wl_pointer.frame, axis_source, axis_stop, and axis_discrete

[Bill Spitzak]

On Mon, Dec 7, 2015 at 5:11 PM, Peter Hutterer 
wrote:

>
> +
> +  
> +   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.
>

With the addition of the axis_discrete events it seems like this no longer
is for distinguishing smooth coordinate space from discrete steps. I think
this description wants to be reworded to remove that. Also clarify what a
trackball with smooth motion should produce.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 2/2] compositor: Damage the whole surface if the viewport changes

[Bill Spitzak]

If there was a buffer damage request, this should not damage the entire
buffer, since supposedly the client sent the correct damage rectangle. I
think it would be a good idea to enforce this so that clients changing the
transform don't send incorrect damage regions (in particular *no* damage
region) and still cause correct output.

If you are trying to figure out the area of the outputs to recomposite, the
actual area is the union of the old and new surface regions. Looks like you
are setting it to the entire output.


On Wed, Dec 2, 2015 at 12:56 PM, Derek Foreman 
wrote:

> Surface damage has a curious relationship with buffer damage.  If we
> change our buffer orientation, the whole buffer contents will likely
> change.  The application is really only supposed to tell us what parts
> of the surface changed, which could still just be a subset.
>
> Since the gl renderer uses the damage rectangles for texture uploads, it
> won't upload the entire buffer contents after an orientation change.
>
> To deal with this we just damage the entire surface any time the buffer
> viewport changes.
>
> This fixes weston_simple_damage --rotating-transform when using the gl
> renderer.
>
> Signed-off-by: Derek Foreman 
> ---
>  src/compositor.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/src/compositor.c b/src/compositor.c
> index 33d500e..5a2f3aa 100644
> --- a/src/compositor.c
> +++ b/src/compositor.c
> @@ -2761,6 +2761,10 @@ weston_surface_commit_state(struct weston_surface
> *surface,
> surface->configure(surface, state->sx, state->sy);
> }
>
> +   if (state->buffer_viewport.changed)
> +   pixman_region32_union_rect(>damage,
> >damage,
> +  0, 0, INT32_MAX, INT32_MAX);
> +
> state->sx = 0;
> state->sy = 0;
> state->newly_attached = 0;
> --
> 2.6.2
>
> ___
> 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 libinput 6/8] tablet: support tool-specific pressure offsets

[Bill Spitzak]

On Sun, Dec 6, 2015 at 8:22 PM, Peter Hutterer 
wrote:

>
> if you touch the surface so light that it flickers between 0 and nonzero
> pressure, then the up/down storm is representative of the user's action.
> That is not the case when you have a magic threshold, because you can
> trigger the up/down storm even while holding the stylus down on the tablet.
>
>
I think he means there to be a different (higher) threshold for down than
up.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] [RFC] desktop-shell: change the alpha of black view in fullscreen mode

[Bill Spitzak]

On 12/04/2015 12:14 AM, Pekka Paalanen wrote:

On Thu, 3 Dec 2015 14:18:54 -0800
Bryce Harrington  wrote:


On Thu, Dec 03, 2015 at 10:33:27PM +0900, Hyungwon Hwang wrote:

This patch changes the alpha value of black view in fullscreen mode,
when the applications opacity changes.

Signed-off-by: Hyungwon Hwang 
---
This patch is incomplete, and just a proof of concept. But I want to
make this patch as the starting point of discussion related the opacity
in fullscreen mode [1]. I tested it with weston-fullscreen.


Thanks for sending this as an RFC, as a follow up to the earlier
discussion with pq.  I notice some of the points he had raised in that
discussion (e.g. avoiding alpha for letterbox edges, etc.) aren't
being addressed.  In technical terms this patch doesn't look bad but you
might include a discussion of how the remaining problems would be
handled?


FWIW, I do think that changing the opacity of the black surface like
this is a totally wrong approach to any problem.

Either the opaque black borders exist or they do not. They are realized
by either a single black surface behind the window like currently, or
several black surfaces around the window. When the black borders must
not be drawn, the black surface(s) must be destroyed (and re-created
on-demand).


If the intention is to make an otherwise-opaque window uniformly 
transparent, this is not going to work right.


Say you wish to make the window 50% transparent. If the background color 
of a pixel is B and the window color is A, the desired result is 
B/2+A/2. However if you composite 50% opaque black over the background, 
you get B/2, and then if you composite the window over that with 50% you 
get B/4+A/2.


You could instead do an additive composite of the window over the black 
(ie for alpha a, instead of doing B(1-a)+Aa, do B+Aa. However you have 
to special-case that in the composite stack.


My feeling is that making the black be a "surface" is a mistake, it 
should instead be an aspect of the compositing. When the compositor 
composites in a full-screen surface, it also draws up to 4 black 
rectangles to fill the area between the surface and the edge of the 
screen. Instead of a black surface in the stack, there is a flag on the 
surface indicating this is wanted.



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

Re: [PATCH v3 wayland] protocol: specify behavior of get_pointer when capabilities change

[Bill Spitzak]

Again I don't understand why you think it is important to include all this
confusing text.

If I am not mistaken, *some* compositors less than version 5 do *NOT* act
in the old way.

Therefore no client can rely on this behaviour even if the compositor is
less than verison 5. And people writing compositors I think should be
encouraged to write the newest version api. So this text is irrelevant for
everybody.

I really would just delete all this text. You want to require clients to
monitor the capability events and destroy/create the wl_pointer in
response, so just say that. Stop giving them ways to get around what you
want.

I'm not sure if it is possible, but you might want to change creation of
wl_pointer before the capability is received into an error. I would suspect
a lot of clients create the wl_seat and then immediately create the
wl_pointer (and wl_keyboard, etc) without waiting for anything. This is
technically wrong, and probably a good indicator of a client that will also
fail to destroy/recreate the wl_pointer correctly.


On Sun, Dec 6, 2015 at 11:29 PM, Jonas Ådahl  wrote:

> On Mon, Dec 07, 2015 at 03:43:35PM +1000, Peter Hutterer wrote:
> > Also applies to touch/keyboard
> >
> > Signed-off-by: Peter Hutterer 
>
> Looks good to me now, so consider this Reviewed-by: Jonas Ådahl
> 
>
>
> Jonas
>
> > ---
> > Changes to v1:
> > - reword the paragraph detailing the pre v5 behaviour
> >
> >  protocol/wayland.xml | 33 ++---
> >  1 file changed, 30 insertions(+), 3 deletions(-)
> >
> > diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> > index 7ca5049..df8ed19 100644
> > --- a/protocol/wayland.xml
> > +++ b/protocol/wayland.xml
> > @@ -1396,6 +1396,27 @@
> >   This is emitted whenever a seat gains or loses the pointer,
> >   keyboard or touch capabilities.  The argument is a capability
> >   enum containing the complete set of capabilities this seat has.
> > +
> > + When the pointer capability is added, a client may create a
> > + wl_pointer object using the wl_seat.get_pointer request. This
> object
> > + will receive pointer events until the capability is removed in the
> > + future.
> > +
> > + When the pointer capability is removed, a client should destroy the
> > + wl_pointer objects associated with the seat where the capability
> was
> > + removed, using the wl_pointer.release request. No further pointer
> > + events will be received on these objects.
> > +
> > + In some compositors, if a seat regains the pointer capability and a
> > + client has a previously obtained wl_pointer object of version 4 or
> > + less, that object may start sending pointer events again. This
> > + behavior is considered a misinterpretation of the intended behavior
> > + and must not be relied upon by the client. wl_pointer objects of
> > + version 5 or later must not send events if created before the most
> > + recent event notifying the client of an added pointer capability.
> > +
> > + The above behavior also applies to wl_keyboard and wl_touch with
> the
> > + keyboard and touch capabilities, respectively.
> >
> >
> >  
> > @@ -1406,7 +1427,9 @@
> >   for this seat.
> >
> >   This request only takes effect if the seat has the pointer
> > - capability.
> > + capability, or has had the pointer capability in the past.
> > + It is a protocol violation to issue this request on a seat that has
> > + never had the pointer capability.
> >
> >
> >  
> > @@ -1417,7 +1440,9 @@
> >   for this seat.
> >
> >   This request only takes effect if the seat has the keyboard
> > - capability.
> > + capability, or has had the keyboard capability in the past.
> > + It is a protocol violation to issue this request on a seat that has
> > + never had the keyboard capability.
> >
> >
> >  
> > @@ -1428,7 +1453,9 @@
> >   for this seat.
> >
> >   This request only takes effect if the seat has the touch
> > - capability.
> > + capability, or has had the touch capability in the past.
> > + It is a protocol violation to issue this request on a seat that has
> > + never had the touch capability.
> >
> >
> >  
> > --
> > 2.5.0
> >
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] server: don't send an error to NULL display_resource

[Bill Spitzak]

On Mon, Dec 7, 2015 at 12:42 AM, Marek Chalupa  wrote:

>
> diff --git a/src/wayland-server.c b/src/wayland-server.c
> index 1364d5d..b372aa9 100644
> --- a/src/wayland-server.c
> +++ b/src/wayland-server.c
> @@ -511,6 +511,14 @@ wl_client_get_object(struct wl_client *client,
> uint32_t id)
>  WL_EXPORT void
>  wl_client_post_no_memory(struct wl_client *client)
>  {
> +   /* display_resource is destroyed first upon client's destruction
> +* If some resource destructor calls wl_client_post_no_memory()
> +* (why it would do it? you never know...), we would pass NULL
> +* here as a resource to the wl_resource_post_error
> +* and we don't want that */
> +   if (!client->display_resource)
> +   return;
> +
> wl_resource_post_error(client->display_resource,
>WL_DISPLAY_ERROR_NO_MEMORY, "no memory");
>  }
> @@ -779,7 +787,8 @@ bind_display(struct wl_client *client, struct
> wl_display *display)
> client->display_resource =
> wl_resource_create(client, _display_interface, 1, 1);
> if (client->display_resource == NULL) {
> -   wl_client_post_no_memory(client);
> +   /* Don't send error to client -
> +* what resource we would use anyway? */
> return -1;
> }
>

Seems like you put two fixes in this, one of them is redundant. My guess is
that you want the second change and not the first, but I'm not really
certain about it.

Also it is inconsistent about using !x v.s. x==NULL.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] [RFC] desktop-shell: change the alpha of black view in fullscreen mode

[Bill Spitzak]

On Mon, Dec 7, 2015 at 12:17 AM, Pekka Paalanen  wrote:

>
> FYI, I do not like the user-controlled window opacity feature. It
> currently cannot work right with sub-surfaces, and the black surface
> case is equivalent to a sub-surface. We would need an intermediate
> composite of the compound window to be able to apply window opacity
> properly as a second step. I feel that implementing that costs too much
> in work, runtime, and maintenance at the moment.
>

In fact it fails even in this case with the black background. A 50% opaque
window composited atop a 50% opaque black is not the same result as just a
50% opaque window.

In fact he will get a much closer simulation of the desired result if the
black surface was removed when the surface is made transparent. Pixels
inside the surface will be correct, and if it happens to fill the screen
then all pixels will be correct.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v2 wayland] protocol: specify behavior of get_pointer when capabilities change

[Bill Spitzak]

This seems more complex than is needed.

My impression is that there are a non-zero set of version<5 compositors
that implement the new behaviour. Therefore a client that relies on the
incorrect behavior is broken even if it requests a version < 5, as it will
fail with some compositors. I think you should completely remove any text
about "it may act this way" as it is just confusing.

I also think that any such text will encourage *some* compositor to work
the old way, irregardless of what version number is claims. This will then
lead to some clients relying on the old behaviour. If these clients are at
all popular it will pretty much force all compositors to implement the old
behavior, making all this text irrelevant.

On Thu, Dec 3, 2015 at 5:01 PM, Jonas Ådahl  wrote:

> On Fri, Dec 04, 2015 at 10:34:34AM +1000, Peter Hutterer wrote:
> > Also applies to touch/keyboard
> >
> > Signed-off-by: Peter Hutterer 
> > ---
> > Changes to v1:
> > - make it clear that from the next version onwards sending events to an
> >   earlier wl_pointer object is a no-no.
> >
> >  protocol/wayland.xml | 36 +---
> >  1 file changed, 33 insertions(+), 3 deletions(-)
> >
> > diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> > index 7ca5049..471c1fe 100644
> > --- a/protocol/wayland.xml
> > +++ b/protocol/wayland.xml
> > @@ -1396,6 +1396,30 @@
> >   This is emitted whenever a seat gains or loses the pointer,
> >   keyboard or touch capabilities.  The argument is a capability
> >   enum containing the complete set of capabilities this seat has.
> > +
> > + When the pointer capability is added, a client may create a
> > + wl_pointer object using the wl_seat.get_pointer request. This
> object
> > + will receive pointer events until the capability is removed in the
> > + future.
> > +
> > + When the pointer capability is removed, a client should destroy the
> > + wl_pointer objects associated with the seat where the capability
> was
> > + removed, using the wl_pointer.release request. No further pointer
> > + events will be received on these objects.
> > +
> > + If a seat regains the pointer capability and a client has a pointer
> > + object obtained previously, that object may start sending pointer
> > + events. This behavior was implemented in some compositors
> supporting
> > + version 5 or less of the wl_seat interface and is considered a
>
> 5 -> 4
>
> > + misinterpretation of the intended behavior.
>
> tricycleshed: This newline will be ignored when displayed as HTML, so I
> don't think it that good to rely on such formatting.
>
> > + This behavior must not be relied upon by the client. A compositor
> > + implementing version 6 or later of the wl_seat or wl_pointer
>
> 6 -> 5
>
> > + interface must not send events to a wl_pointer object created
> > + before the most recent event notifying the client of an added
> > + pointer capability.
>
>
> This to me reads like we are now aiming to break those clients, as if
> they happen to connect to a newer compositor supporting version >= 5
> of wl_seat will not continue supporting the old behaviour. Was that the
> conclusion drawn?
>
> If so is the case, the text sounds correct to me, but I think it could be
> made to sound more obvious that the behaviour is not supported any more.
>
> In some compositors only supporting version 4 or less of the
> wl_seat, if a seat regains the pointer capability and a client
> has a pointer object obtained previously, that object may start
> sending pointer events. This behaviour is considered a
> misinterpretation and must not be relied upon by the client. A
> compositor implementing version 5 or later of the wl_seat or
> wl_pointer interface must not send events to a wl_pointer object
> created before the most recent event notifying the client of an
> added pointer capability.
>
> That way its more up front that its old unsupported behaviour.
>
>
> Jonas
>
> > +
> > + The above behavior also applies to wl_keyboard and wl_touch with
> the
> > + keyboard and touch capabilities, respectively.
> >
> >
> >  
> > @@ -1406,7 +1430,9 @@
> >   for this seat.
> >
> >   This request only takes effect if the seat has the pointer
> > - capability.
> > + capability, or has had the pointer capability in the past.
> > + It is a protocol violation to issue this request on a seat that has
> > + never had the pointer capability.
> >
> >
> >  
> > @@ -1417,7 +1443,9 @@
> >   for this seat.
> >
> >   This request only takes effect if the seat has the keyboard
> > - capability.
> > + capability, or has had the keyboard capability in the past.
> > + It is a protocol violation to issue this request on a seat that has
> > + never had the 

Re: [PATCH v2 wayland] protocol: add support for cross-interface enum attributes

[Bill Spitzak]

On Wed, Dec 2, 2015 at 7:19 AM, Nils Chr. Brause 
wrote:

> On Wed, Dec 2, 2015 at 11:48 AM, Auke Booij  wrote:
> > I'd be happy to rebase against that, but since that hasn't been merged
> > yet, I thought I'd take the current tree as a a basis.
> >
> > If you think having the interface:: prefix everywhere makes sense, I
> > can change that if you want.
>
> I think that would be very nice for consistency. :)
>

It was an accident in how I wrote it, but it seems at least one person (and
possibly two as there was another comment but I'm not sure who from) like
it that way.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v2 wayland] protocol: add support for cross-interface enum attributes

[Bill Spitzak]

Looks correct to me.

I had a slightly different patch in patchwork which changes
protocol-to-docbook. It puts the enumeration into it's own statement,
rather than a nested if statement, and it adds the object:: prefix to the
documentation for all enumerations, not just the cross-object ones.

On Sun, Nov 29, 2015 at 5:54 AM, Auke Booij  wrote:

> The enum attribute, for which scanner support was introduced in
> 1771299, can be used to link message arguments to s. However,
> some arguments refer to s in a different .
>
> This adds scanner support for referring to an  in a different
>  using dot notation. It also sets the attributes in this
> style in the wayland XML protocol (wl_shm_pool::create_buffer::format
> to wl_shm::format, and wl_surface::set_buffer_transform::transform to
> wl_output::transform), and updates the documentation XSL so that this
> new style is supported.
>
> Changes since v1:
>  - several implementation bugs fixed
>
> Signed-off-by: Auke Booij 
> ---
>  doc/publican/protocol-to-docbook.xsl | 17 +--
>  protocol/wayland.xml |  4 +--
>  src/scanner.c| 59
> +++-
>  3 files changed, 61 insertions(+), 19 deletions(-)
>
> diff --git a/doc/publican/protocol-to-docbook.xsl
> b/doc/publican/protocol-to-docbook.xsl
> index fad207a..1fa066d 100644
> --- a/doc/publican/protocol-to-docbook.xsl
> +++ b/doc/publican/protocol-to-docbook.xsl
> @@ -103,9 +103,20 @@
>  
>  
>
> -
> -  
> -
> +
> +  
> +
> +  
> +  ::
> +  
> +
> +  
> +  
> +
> +  
> +
> +  
> +
>  
>
>
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index f9e6d76..0873553 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -229,7 +229,7 @@
>
>
>
> -  
> +  
>  
>
>  
> @@ -1292,7 +1292,7 @@
> wl_output.transform enum the invalid_transform protocol error
> is raised.
>
> -  
> +  
>  
>
>  
> diff --git a/src/scanner.c b/src/scanner.c
> index 406519f..e69bd2a 100644
> --- a/src/scanner.c
> +++ b/src/scanner.c
> @@ -785,32 +785,62 @@ start_element(void *data, const char *element_name,
> const char **atts)
> }
>  }
>
> +static struct enumeration *
> +find_enumeration(struct protocol *protocol, struct interface *interface,
> char *enum_attribute)
> +{
> +   struct interface *i;
> +   struct enumeration *e, *f = NULL;
> +   char *enum_name;
> +   int idx = 0, j;
> +
> +for (j = 0; j + 1 < (int)strlen(enum_attribute); j++) {
> +   if (enum_attribute[j] == '.') {
> +   idx = j;
> +   }
> +   }
> +
> +   if (idx > 0) {
> +   enum_name = enum_attribute + idx + 1;
> +
> +   wl_list_for_each(i, >interface_list, link)
> +   if (strncmp(i->name, enum_attribute, idx) == 0)
> +   wl_list_for_each(e, >enumeration_list,
> link)
> +   if(strcmp(e->name, enum_name) == 0)
> +   f = e;
> +   } else if (interface) {
> +   enum_name = enum_attribute;
> +
> +   wl_list_for_each(e, >enumeration_list, link)
> +   if(strcmp(e->name, enum_name) == 0)
> +   f = e;
> +   }
> +
> +   return f;
> +}
> +
>  static void
> -verify_arguments(struct parse_context *ctx, struct wl_list *messages,
> struct wl_list *enumerations)
> +verify_arguments(struct parse_context *ctx, struct interface *interface,
> struct wl_list *messages, struct wl_list *enumerations)
>  {
> struct message *m;
> wl_list_for_each(m, messages, link) {
> struct arg *a;
> wl_list_for_each(a, >arg_list, link) {
> -   struct enumeration *e, *f;
> +   struct enumeration *e;
>
> if (!a->enumeration_name)
> continue;
>
> -   f = NULL;
> -   wl_list_for_each(e, enumerations, link) {
> -   if(strcmp(e->name, a->enumeration_name) ==
> 0)
> -   f = e;
> -   }
>
> -   if (f == NULL)
> +   e = find_enumeration(ctx->protocol, interface,
> a->enumeration_name);
> +
> +   if (e == NULL)
> fail(>loc,
>  "could not find enumeration %s",
>  a->enumeration_name);
>
>  

Re: [PATCH wayland] protocol: specify behavior of get_pointer when capabilities change

[Bill Spitzak]

On Mon, Nov 30, 2015 at 3:32 PM, Peter Hutterer 
wrote:

> On Mon, Nov 30, 2015 at 09:46:36PM +, Daniel Stone wrote:
>
> > > +   If a seat regains the pointer capability and a client has a
> pointer
> > > +   object obtained previously, that object may start sending
> pointer
> > > +   events. This behavior is implementation-dependent and must not
> be
> > > +   relied upon.
> >
> > Urgh, I don't really like having this there as a bit of a get-out
> > clause. Can we just strengthen the 'client should destroy the
> > wl_pointer objects' to a 'must'? Especially since this paragraph
> > contradicts the immediately previous one ('No further pointer events
> > will be received on these objects'). Maybe we could fold bits of this
> > paragraph in to replace that problematic sentence, but couple with a
> > recommendation that compositors should not send events to stale
> > objects - and bump that to a must for compositors advertising whatever
> > our next version of wl_seat ends up being.
>
> if the per-version behaviour works correctly we can add this, otherwise we
> still have to keep this paragraph in, otherwise we're retroactively
> disallowing current working implementations. The same goes for the
> should/must, we already have implementations doing this.
>

I don't think you want this text. An existing implementation that sends
pointer events after the loss/gain is broken. People wrote lots of other
bugs into existing implementations, that does not mean all descriptions
have to allow any existing bug.

A more practical reason for being more insistent is that if a popular
compositor does this, it is quite likely to be relied on by some clients
(due to the fact that it is much easier to write a client that relies on
this), quickly leading to this being a required behaviour of all
compositors. Explicitly saying that is wrong may encourage the compositors
to not do this, though of course it does not guarantee it.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput 6/8] tablet: support tool-specific pressure offsets

[Bill Spitzak]

On Tue, Dec 1, 2015 at 5:46 PM, Peter Hutterer 
wrote:

>
> +   switch (tool->type) {
> +   case LIBINPUT_TABLET_TOOL_TYPE_PEN:
> +   strtype = "PEN";
> +   break;
> +   case LIBINPUT_TABLET_TOOL_TYPE_BRUSH:
> +   strtype = "BRUSH";
> +   break;
> +   case LIBINPUT_TABLET_TOOL_TYPE_AIRBRUSH:
> +   strtype = "AIRBRUSH";
> +   break;
> +   case LIBINPUT_TABLET_TOOL_TYPE_PENCIL:
> +   strtype = "PENCIL";
> +   break;
> +   case LIBINPUT_TABLET_TOOL_TYPE_ERASER:
> +   strtype = "RUBBER";
> +   break;
>
> Is there a good reason for this inconsistency in the strings? Ie why isn't
the last strtype "ERASER".
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput] tablet: handle custom proximity handling

[Bill Spitzak]

On Wed, Dec 2, 2015 at 3:57 PM, Peter Hutterer 
wrote:

> For the puck/lens cursor tool we need to artificially reduce proximity
> detection. These tools are usually used in a relative mode (i.e. like a
> mouse)
> and thus require lifting and resetting the tool multiple times to move
> across
> the screen. The tablets' distance detection goes too far, requiring the
> user
> to lift the device several cm on every move. This is uncomfortable.
>
> Introduce an artificial distance threshold for the devices with the default
> value taken from the X.Org wacom driver. If a tool is in proximity but
> outside
> of this range, fake proximity events accordingly.
>
>
You will want something like this for pens and all other tools, as it is
possible to use them in a relative mode (very common if the tablet is
smaller than the screen). I think rather than typing this to the type of
tool, you need to tie it to whether relative motion is being used or not.
Not sure where in libinput or wayland that would be, though.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] Refine compositor grabs behavior

[Bill Spitzak]

On Sun, Nov 22, 2015 at 4:19 PM, Peter Hutterer 
wrote:

>
> p1.leave, p2.leave, \
>   p1.enter, p2.enter,\
>   p1.frame *FOCUS TRANSITIONED*, p2.frame *FOCUS TRANSITIONED*
>
> we have the same issue where two surfaces are focused simultaneously though
> at least in this case it's detectable. I don't know how much of an issue
> this is in the real world, Carlos may have more feedback here.
>

If there are two pointers, then having both surfaces focused simultaneously
is possible anyway, so I don't see how this is a problem.

I am assuming a client will just wait for the frame events and not do
anything until that happens. The fact that it got enter/leave events does
nothing visible to code outside the very low levels so the interleaving is
not a problem. An extremely simplified example of the style of code I
expect clients to use:

  struct ToolkitWindow;
  void (*focusIsNowHere)(ToolkitWindow*, seat); // callback from the toolkit

  toolkit_event_handler() {
static ToolkitWindow* currentFocus[2];
static ToolkitWindow* requestedFocus[2]; // This array in particular
cannot be seen by outside code!
...
case wl_pointer.enter:
   requestedFocus[seat] = findWindow(surface);
   break;
case wl_pointer.exit:
   requestedFocus[seat] = NULL;
   break;
case wl_pointer.frame:
   if (requestedFocus[seat] != currentFocus[seat]) {
   currentFocus[seat] = requesetedFocus[seat];
   focusIsNowHere(requestedFocus[seat], seat);
   }
   break;
   ...

I find it hard to imagine any client being implemented differently than
this so I really don't see the problem.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC] Screensaver/blanking inhibition

[Bill Spitzak]

On Tue, Nov 24, 2015 at 10:46 AM, Bryce Harrington 
wrote:

>
> > Besides preventing blanking of only the correct output, this could also
> > allow the compositor to show popup notifications when the compositor
> knows
> > they will not interfere with the surface.
>
> Not sure what you mean here - mind elaborating?
>

There was discussion that the inhibitor would also stop popup
notifications. If such an inhibitor is attached to a surface, then it is
possible that the compositor could still show a popup notification, if it
figures out that it can make it appear without interfering with that
surface. For instance if the surface is not full-screen then the popup
could be placed in the unoccupied area.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC] Screensaver/blanking inhibition

[Bill Spitzak]

I now agree that tying the inhibit to a surface is exactly the right thing
to do.

Besides preventing blanking of only the correct output, this could also
allow the compositor to show popup notifications when the compositor knows
they will not interfere with the surface.

I also think there is no need for the "all outputs inhibit". That is just
an artifact of how current systems work. I know for a fact that I am
annoyed that watching a movie on the tv screen disables the screen saver
and thus leaves the desktop monitor on (and projecting a glow against a
wall behind the tv) and I physically have to turn that monitor off to fix
this. I would guess that disabling the screen saver only on the monitors
being used is the desired behavior by everybody, and thus should be the
supported. The only reason to blank all of them is technical impossibility
of blanking only one of them.

So it should only inhibit disabling the outputs the attached surface is
viewed on.

Also my concern about requiring a visible output is I think not a problem
for any real application I think.


On Fri, Nov 20, 2015 at 6:10 AM, Michal Suchanek <hramr...@gmail.com> wrote:

> On 20 November 2015 at 14:43, Pekka Paalanen <ppaala...@gmail.com> wrote:
> > On Fri, 20 Nov 2015 14:10:47 +0100
> > Michal Suchanek <hramr...@gmail.com> wrote:
> >
> >> On 20 November 2015 at 12:48, Pekka Paalanen <ppaala...@gmail.com>
> wrote:
> >> > On Fri, 20 Nov 2015 12:18:29 +0100
> >> > Michal Suchanek <hramr...@gmail.com> wrote:
> >> >
> >> >> On 20 November 2015 at 11:39, Pekka Paalanen <ppaala...@gmail.com>
> wrote:
> >> >> > On Thu, 19 Nov 2015 22:46:06 +0100
> >> >> > Michal Suchanek <hramr...@gmail.com> wrote:
> >> >> >
> >> >> >> On 19 November 2015 at 20:12, Daniel Stone <dan...@fooishbar.org>
> wrote:
> >> >> >> > Hi,
> >> >> >> >
> >> >> >> > On 19 November 2015 at 19:05, Bill Spitzak <spit...@gmail.com>
> wrote:
> >> >> >> >> I feel like there is no need to tie it to a surface. In
> Wayland the client
> >> >> >> >> is always notified of any changes to it's state, so it can
> update the
> >> >> >> >> screensaver object to match. (destruction of the screensaver
> object would of
> >> >> >> >> course remove the inhibit).
> >> >> >> >>
> >> >> >> >> The surface may be necessary to indicate if only one output is
> to have the
> >> >> >> >> screensaver inhibited, but I think wayland clients are aware
> of which output
> >> >> >> >> their surfaces are on so instead the output could be indicated
> directly.
> >> >> >> >
> >> >> >> > By default it should be tied to a surface.
> >> >> >>
> >> >> >> That sounds quite reasonable. The compositor can point to a
> particular
> >> >> >> surface that inhibits screen blanking, the surface can be removed
> >> >> >> one-sidedly by the compositor, the compositor may choose to cease
> the
> >> >> >> blank-inhibit function when the surface is obscured/unmapped/..
> >> >> >>
> >> >> >> >
> >> >> >> >>>>>>>> In X11, various getter functions are provided for the
> application to
> >> >> >> >>>>>>>> poll inhibition status.  For Wayland, instead of
> getters, the current
> >> >> >> >>>>>>>> state is just be pushed to the client when the inhibitor
> global is
> >> >> >> >>>>>>>> bound, and then updates pushed if/when the status
> changes.
> >> >> >> >>>>>>>>
> >> >> >> >>>>>>>
> >> >> >> >>>>>>> This makes sense, and follows "standard" wayland practice
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> I don't see any reason for a client to know about any other
> clients
> >> >> >> >> inhibiting the screensaver, and this might be a security leak
> too.
> >> >> >> >
> >> >> >> > Yes, seems a bit pointless.
> >> >> >> >
> >> >> >> >>>>>>>> A corresponding unin

Re: [PATCH v3 wayland 1/2] protocol: Add wl_surface.damage_buffer

[Bill Spitzak]

You are correct that it is equally valid to convert buffer_damage
coordinates to surface coordinates and store the union of those.

More importantly, I think you are correct that the "new" transform should
be used. Ideally the last transform the client sent (even though it is not
committed yet). I made a mistake of thinking you had to use the old
transform to go from surface to buffer coordinates, that was wrong. This
also means that the compositor only has to track the current transformation
and only has to keep one copy of it that is replaced when it gets the
request, so it is probably the simplest.

I figure clients will send damage rectangles produced by their drawing
toolkit as damage requests, which are necessarily in buffer coordinates. If
the client is correctly implemented and using wl_surface.damage, it will
transform this from buffer coordinates to surface coordinates.

My belief is that most clients are written on the assumption that the
compositor immediately transforms these back, and therefore have to use any
transform they already have and cannot use a transform that was not sent
yet. So it probably uses whatever transform it just sent. Although allowing
the final composite to be performed on only a region is really nice, I
suspect the main advantage of buffer damage is to reduce the size of the
rectangle copied from the buffer to gpu texture memory, which is why I
always figured buffer coordinates are more useful for compositors and why
clients would assume compositors would immediately translate back.


On Fri, Nov 20, 2015 at 6:37 PM, Derek Foreman <der...@osg.samsung.com>
wrote:

> On 20/11/15 07:39 PM, Bill Spitzak wrote:
> > I am pretty certain you can just convert wl_surface.damage coordinates
> > *to* buffer coordinates, using the transform the old buffer was attached
> > with, and thus merge all the wl_surface.damage and
> > wl_surface.damage_buffer into a single region in buffer space.
>
> Yep, that should be fine.  We have all the code to do that already since
> we previously stored damage in surface co-ords exclusively and gl
> texture uploads needed buffer co-ordinates.
>
> We need the co-ordinates in both spaces regardless - surface as a step
> to screen space co-ordinates for that damage, and buffer for texture
> damage.
>
> I chose to convert buffer space co-ordinates to screen space since all
> the existing code used screen space.  I just dumped it all into the
> accumulated surface space region after the buffer to surface matrix was
> set up.
>
> > If the transformation does not change, you can back-transform this
> > region into the changed region in screen space.
> >
> > You seem to be worried about what happens if the transformation is
> > different between the old and new buffers. But in that case the
> > on-screen changed area is the union of the entire old buffer with it's
> > old transform and the new buffer with it's new transform. The damage
> > region is ignored when figuring out the screen-space damage so it does
> > not matter what it was set to.
>
> Well, I'm somewhat concerned about loss of precision due to the double
> transform - but I think the matrices we're working with should be ok for
> that.
>
> I'm also annoyed that wasted math gets done (buffer to surface and back
> again), but I think avoiding that wasted transform is probably far more
> code complexity than is worthwhile to eliminate what's not very much math.
>
> I'm actually not bothered by the transform being changed - I think we
> just have to specify that all damage is posted in the "new co-ordinates"
> that the rest of the commit sets up, then we don't have to worry.
>
> We do have an existing bug - either in simple-damage or weston - where
> changing transformations results in bad damage.  weston-simple-damage
> --rotating-transform shows this. This has been around before
> damage_buffer existed, so I haven't bothered to dig into it yet.
>
> Now that I think of it, I think the client's posting bad damage - it's
> posting the remove for the old bouncing-green-ball and the arrival of
> the new frame of bouncing-green-ball as if they were in the same
> co-ordinate space.
>
> > If a client actually sends the "correct" wl_surface.damage for a
> > transform change, it will be a region that translates to cover the
> > entire old buffer. This may be excessive but is harmless.
>
> Nod.  I guess some of our trivial test apps (simple-damage has a fixed
> white border) could preserve some buffer content over certain transform
> changes, but in the real world I can't imagine anyone trying to do this.
>
> > I suppose rotating a perfectly square buffer which is filled with a
> > solid color could, under the old system, turn into no da

Re: [PATCH] Refine compositor grabs behavior

[Bill Spitzak]

On Thu, Nov 19, 2015 at 7:47 PM, Peter Hutterer 
wrote:

>
> we had a bit of a discussion on IRC here, this is the attempt of a summary:
> A wl_touch.enter/leave event pair makes sense for some use-cases and can
> fix
> the xdg_popup case. The idea here is that if you move between two surfaces
> *of the same client* you send a wl_touch.leave(old_surface) followed by a
> wl_touch.enter(new_surface), with a wl_touch.update all within the same
> frame. Both enter/leave carry the touch ID and are thus per touchpoint.
>
> If a client is capable of handling the new enter/leave events, this is a
> way
> to tell them that a touch has moved away and that surface doesn't have it
> anymore, and for the new surface that a touch has appeared but wasn't set
> down in that spot (so it won't trigger in-client gestures like tapping).
> In X term, a wl_touch.enter/leave is similar to NotifyGrab.
>

You know I have been trying to point out that the equivalent bug exists on
wl_pointer enter/leave events for a couple years now, but all I get is
hostility (witness recent emails). If you do manage to fix this problem,
perhaps you could look into getting it fixed there, too?

Using a frame is a method of fixing it, but I think sending the enter event
first, or not sending the exit at all, would also work.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v3 wayland 1/2] protocol: Add wl_surface.damage_buffer

[Bill Spitzak]

I am pretty certain you can just convert wl_surface.damage coordinates *to*
buffer coordinates, using the transform the old buffer was attached with,
and thus merge all the wl_surface.damage and wl_surface.damage_buffer into
a single region in buffer space.

If the transformation does not change, you can back-transform this region
into the changed region in screen space.

You seem to be worried about what happens if the transformation is
different between the old and new buffers. But in that case the on-screen
changed area is the union of the entire old buffer with it's old transform
and the new buffer with it's new transform. The damage region is ignored
when figuring out the screen-space damage so it does not matter what it was
set to.

If a client actually sends the "correct" wl_surface.damage for a transform
change, it will be a region that translates to cover the entire old buffer.
This may be excessive but is harmless.

I suppose rotating a perfectly square buffer which is filled with a solid
color could, under the old system, turn into no damage, while the new one
will not know (unless it compares the buffers) and damage an unchanged
area. However this seems really trivial. Any client that actually tries to
do this correctly with wl_surface.damage will send a region that
necessarily translates to something that includes all the damage to the
buffer.

On Fri, Nov 20, 2015 at 1:49 PM, Derek Foreman 
wrote:

> wl_surface.damage uses surface local co-ordinates.
>
> Buffer scale and buffer transforms came along, and EGL surfaces
> have no understanding of them.
>
> Theoretically, clients pass damage rectangles - in Y-inverted surface
> co-ordinates) to EGLSwapBuffersWithDamage, and the EGL implementation
> passed them on to wayland.  However, for this to work the EGL
> implementation must be able to flip those rectangles into the space
> the compositor is expecting, but it's unable to do so because it
> doesn't know the height of the transformed buffer.
>
> So, currently, EGLSwapBuffersWithDamage is unusable and EGLSwapBuffers
> has to pass (0,0) - (INT32_MAX, INT32_MAX) damage to function.
>
> wl_surface.damage_buffer allows damage to be registered on a surface
> in buffer co-ordinates, avoiding this problem.
>
> Credit where it's due, these ideas are not entirely my own:
> Over a year ago the idea of changing damage co-ordinates to buffer
> co-ordinates was suggested (by Jason Ekstrand), and it was at least
> partially rejected and abandoned.  At the time it was also suggested
> (by Pekka Paalanen) that adding a new wl_surface.damage_buffer request
> was another option.
>
> This will eventually resolve:
> https://bugs.freedesktop.org/show_bug.cgi?id=78190
> by making the problem irrelevant.
>
> Signed-off-by: Derek Foreman 
> ---
>
> New change: Explain that damages can't be combined until commit
>
> Also, copy the new wl_surface.damage text that doesn't require attach
> to be before damage
>
> (enough text is new that I haven't carried over any RBs)
>
>  protocol/wayland.xml | 48 ++--
>  1 file changed, 46 insertions(+), 2 deletions(-)
>
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index 525e092..4d75f39 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -176,7 +176,7 @@
>  
>
>
> -  
> +  
>  
>A compositor.  This object is a singleton global.  The
>compositor is in charge of combining the contents of multiple
> @@ -986,7 +986,7 @@
>  
>
>
> -  
> +  
>  
>A surface is a rectangular area that is displayed on the screen.
>It has a location, size and pixel contents.
> @@ -1109,6 +1109,10 @@
> wl_surface.commit assigns pending damage as the current damage,
> and clears pending damage. The server will clear the current
> damage as it repaints the surface.
> +
> +   Alternatively, damage can be posted with wl_surface.damage_buffer
> +   which uses buffer co-ordinates instead of surface co-ordinates,
> +   and is probably the preferred and intuitive way of doing this.
>
>
>
> @@ -1325,6 +1329,46 @@
>
>
>  
> +
> +
> +
> +  
> +   This request is used to describe the regions where the pending
> +   buffer is different from the current surface contents, and where
> +   the surface therefore needs to be repainted. The compositor
> +   ignores the parts of the damage that fall outside of the surface.
> +
> +   Damage is double-buffered state, see wl_surface.commit.
> +
> +   The damage rectangle is specified in buffer coordinates.
> +
> +   The initial value for pending damage is empty: no damage.
> +   wl_surface.damage_buffer adds pending damage: the new pending
> +   damage is the union of old pending damage and the given rectangle.
> +
> +   wl_surface.commit assigns pending damage as the current damage,

Re: [PATCH wayland] protocol: Remove incorrect statement that attach must precede damage

[Bill Spitzak]

On Thu, Nov 19, 2015 at 3:08 AM, Daniel Stone <dan...@fooishbar.org> wrote:

> Hi,
>
> On 18 November 2015 at 18:30, Bill Spitzak <spit...@gmail.com> wrote:
> > On Wed, Nov 18, 2015 at 7:44 AM, Derek Foreman <der...@osg.samsung.com>
> > wrote:
> >> The documentation for wl_surface.commit makes it clear that the
> >> application of damage follows attach during the commit, so it
> >> doesn't matter what order the app sends the requests.
> >>
> >> Many existing apps post damage before attaching a buffer already,
> >> and it's really quite reasonable to do so.
> >
> > Especially because they probably think of the old buffer as being the one
> > that is "damaged", while the new buffer does not have any damage.
>
> No, it does. The old buffer has not changed. The new buffer is the one
> with the changed areas, and changed areas are the literal definition
> of damaged.
>

Actually neither buffer has changed. The damage is saying that only the
pixels in the rectangle are different between the old and new buffer.

I was just saying that I can certainly think of people as saying "the old
buffer is bad in this area, therefore I must send this message now to
indicate it is bad. If I change the buffer first then this message is
saying the new buffer is bad in this area, when in fact the new buffer is
perfect". This is all incorrect but is likely the logic that caused almost
all clients to send the damage request first.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC] Screensaver/blanking inhibition

[Bill Spitzak]

On Thu, Nov 19, 2015 at 2:38 AM, Christopher Michael <
cpmich...@osg.samsung.com> wrote:

So, after issuing the inhibit request for a surface, the screensaver
>> (and screenblanking) will be blocked until the surface is destroyed,
>> disabled, or otherwise loses visibility or becomes occluded.
>>
>
Will it be possible to inhibit the screensaver without putting anything
visible on the screen? I can imagine some programs doing this.

I feel like there is no need to tie it to a surface. In Wayland the client
is always notified of any changes to it's state, so it can update the
screensaver object to match. (destruction of the screensaver object would
of course remove the inhibit).

The surface may be necessary to indicate if only one output is to have the
screensaver inhibited, but I think wayland clients are aware of which
output their surfaces are on so instead the output could be indicated
directly.

In X11, various getter functions are provided for the application to
>> poll inhibition status.  For Wayland, instead of getters, the current
>> state is just be pushed to the client when the inhibitor global is
>> bound, and then updates pushed if/when the status changes.
>>
>>
> This makes sense, and follows "standard" wayland practice
>

I don't see any reason for a client to know about any other clients
inhibiting the screensaver, and this might be a security leak too.


> A corresponding uninhibit API will be added as well.  For example, a
>> movie player may wish to inhibit while a video is playing but
>> uninhibit
>> when it is paused.
>>
>
The screensaver object should have several requests. One of them turns the
inhibit on/off.

Yes I think it makes sense to add this to its own extension. A
>>> "wp_inhibiter" in a inhibiter XML file that inhibit things.
>>>
>>
Please don't use any name that does not have the word "screensaver" in it,
because that is the word programmers are going to look for. My suggestion
is "wpz_screensaver_v1" (or whatever the rules for experimental protocols
are). I suspect this api will quickly get enhanced with other api (such as
events when the screensaver turns on/off), so I would not use the word
"inhibit" at all.


> Makes sense ("potentially" could inhibit other things depending on scope
>> and how it grows)
>>
>
Absolutely it should by default inhibit any kind of notifier or any other
changes to the display not triggered by the user (it also should NOT
inhibit changes that the user triggers, such as hitting a shortcut key that
creates a popup).

Among these changes that must be inhibited are "things that have not been
invented yet but may appear in a future desktop". Therefore a per-thing api
to inhibit them is not going to work and this must inhibit them all.

The api can be enhanced in the future if you want finer control over what
is inhibited.

Not so sure about the scope though. If its not about surfaces on outputs
>>> or input devices or focus or display protocol things it should just be a
>>> D-Bus protocol.
>>>
>>
No please don't! It has to inhibit everything by default that you would
think that a program trying to disable the screensaver is also trying to
disable. It does not matter where or how they are implemented.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 10/11] simple-damage: Offset drawing co-ordinates not buffer start

[Bill Spitzak]

It is not clear if this is changing anything other than the printf
statement, but it makes sense as that is not printing anything about where
the origin was moved.

I think however the program was broken before. This fix has nothing to do
with the transition to buffer damage and is required to print the
coordinates that would be passed to the older wl_surface.damage.


On Thu, Nov 19, 2015 at 9:28 AM, Derek Foreman <der...@osg.samsung.com>
wrote:

> On 18/11/15 07:31 PM, Bill Spitzak wrote:
> > You sure this has to change?
>
> If I'm posting damage in buffer co-ordinates, I need to know what buffer
> co-ordinates to use.
>
> Currently, the code moves the *data pointer and does its drawing as if
> everything is still at 0,0.
>
> ie) if we set a buffer viewport with a top left corner of 20, 20, we
> move the pointer, all the drawing ops are done with 0,0 as origin.
>
> So we draw the bouncy ball at 75, 75 in the buffer by using a draw call
> at 55, 55.  Now I've got those 55, 55 co-ordinates to pass to the
> damage_buffer function.  I get a box of damage that isn't in the right
> place.
>
>
> So, I don't technically need to change any of the drawing operations,
> and I can still move the pointer to do the offset - but I still need to
> track the "real" co-ordinates of what I just drew.
>
> I could write a smaller patch that just tracked those co-ordinates to
> use for damage posting, but I think it ends up being simpler code to
> read if stop moving the buffer pointer entirely so damage and draw use
> the same co-ordinates.
>
> (There's actually a bug fix hidden in here - the debug prints were wrong
> when viewports were in use because they showed the 0,0 referenced
> co-ordinates)
>
> For the following patch, the important bit is that off_x and off_y are
> now transformed.
>
> Thanks,
> Derek
>
> > On Wed, Nov 18, 2015 at 2:32 PM, Derek Foreman <der...@osg.samsung.com
> > <mailto:der...@osg.samsung.com>> wrote:
> >
> > We've been setting up the viewport by moving the start pointer of the
> > draw buffer, but later when we want to post damage in buffer
> > co-ordinates
> > we'll need to keep track of the x,y offsets anyway.
> >
> > Signed-off-by: Derek Foreman <der...@osg.samsung.com
> > <mailto:der...@osg.samsung.com>>
> > ---
> >  clients/simple-damage.c | 58
> > +
> >  1 file changed, 34 insertions(+), 24 deletions(-)
> >
> > diff --git a/clients/simple-damage.c b/clients/simple-damage.c
> > index 13e220a..0551b9d 100644
> > --- a/clients/simple-damage.c
> > +++ b/clients/simple-damage.c
> > @@ -454,8 +454,8 @@ redraw(void *data, struct wl_callback *callback,
> > uint32_t time)
> >  {
> > struct window *window = data;
> > struct buffer *buffer;
> > -   int off_x, off_y, bwidth, bheight, bborder, bpitch, bradius;
> > -   uint32_t *buffer_data;
> > +   int off_x = 0, off_y = 0;
> > +   int bwidth, bheight, bborder, bpitch, bradius;
> > float bx, by;
> >
> > buffer = window_next_buffer(window);
> > @@ -494,8 +494,8 @@ redraw(void *data, struct wl_callback *callback,
> > uint32_t time)
> > bborder = window->border * window->scale;
> > bradius = window->ball.radius * window->scale;
> >
> > -   buffer_data = buffer->shm_data;
> > if (window->viewport) {
> > +   int tx, ty;
> > /* Fill the whole thing with red to detect viewport
> > errors */
> > paint_box(buffer->shm_data, bpitch, 0, 0, bwidth,
> > bheight,
> >   0x);
> > @@ -508,35 +508,41 @@ redraw(void *data, struct wl_callback
> > *callback, uint32_t time)
> > bheight /= 2;
> >
> > /* Offset the drawing region */
> > -   off_x = (window->width / 3) * window->scale;
> > -   off_y = (window->height / 5) * window->scale;
> > +   tx = (window->width / 3) * window->scale;
> > +   ty = (window->height / 5) * window->scale;
> > switch (window->transform) {
> > default:
> > case WL_OUTPUT_TRANSFORM_NORMAL:
> > -   buffer_data += off_y * bpitc

Re: [PATCH 3/5] socket-test: Fix indentation to follow project code style policy

[Bill Spitzak]

On Thu, Nov 19, 2015 at 1:36 AM, Bryce Harrington 
wrote:

> From: Bryce Harrington 
>
> Signed-off-by: Bryce Harrington 
> ---
>  tests/socket-test.c | 174
> ++--
>  1 file changed, 87 insertions(+), 87 deletions(-)
>
> diff --git a/tests/socket-test.c b/tests/socket-test.c
> index c53f972..f6db6cf 100644
> --- a/tests/socket-test.c
> +++ b/tests/socket-test.c
> @@ -46,129 +46,129 @@ static const struct sockaddr_un example_sockaddr_un;
>  static const char *
>  require_xdg_runtime_dir(void)
>  {
> -   char *val = getenv("XDG_RUNTIME_DIR");
> -   if (!val)
> -   assert(0 && "set $XDG_RUNTIME_DIR to run this test");
> +   char *val = getenv("XDG_RUNTIME_DIR");
> +   if (!val)
> +   assert(0 && "set $XDG_RUNTIME_DIR to run
> this test");
>

How about:

 assert(val && "set $XDG_RUNTIME_DIR to run this test")

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

Re: [RFC] Screensaver/blanking inhibition

[Bill Spitzak]

On Thu, Nov 19, 2015 at 11:12 AM, Daniel Stone <dan...@fooishbar.org> wrote:

> Hi,
>
> On 19 November 2015 at 19:05, Bill Spitzak <spit...@gmail.com> wrote:
> > I feel like there is no need to tie it to a surface. In Wayland the
> client
> > is always notified of any changes to it's state, so it can update the
> > screensaver object to match. (destruction of the screensaver object
> would of
> > course remove the inhibit).
> >
> > The surface may be necessary to indicate if only one output is to have
> the
> > screensaver inhibited, but I think wayland clients are aware of which
> output
> > their surfaces are on so instead the output could be indicated directly.
>
> By default it should be tied to a surface.
>

Yes I believe that will work, but will it be possible to inhibit the
screensaver without putting anything visible on the screen?

Probably not a big deal, actually. The only application I can really think
of for this is to force presentation of some other application that does
not use the inhibit api, and such a tool may still map some kind of
(normally invisible) overlay for popup controls, so the inhibit could be
tied to that.



>
> >>>>>>> In X11, various getter functions are provided for the application
> to
> >>>>>>> poll inhibition status.  For Wayland, instead of getters, the
> current
> >>>>>>> state is just be pushed to the client when the inhibitor global is
> >>>>>>> bound, and then updates pushed if/when the status changes.
> >>>>>>>
> >>>>>>
> >>>>>> This makes sense, and follows "standard" wayland practice
> >
> >
> > I don't see any reason for a client to know about any other clients
> > inhibiting the screensaver, and this might be a security leak too.
>
> Yes, seems a bit pointless.
>
> >>>>>>> A corresponding uninhibit API will be added as well.  For example,
> a
> >>>>>>> movie player may wish to inhibit while a video is playing but
> >>>>>>> uninhibit
> >>>>>>> when it is paused.
>
> Just make the inhibit request return a new object, which upon destroy,
> removes the inhibition. That way you don't even have duplicate
> codepaths for client exiting uncleanly vs. client removed inhibition.
>
> > The screensaver object should have several requests. One of them turns
> the
> > inhibit on/off.
>
> The screensaver object and the inhibition object are not the same thing.
>
> >>>> Yes I think it makes sense to add this to its own extension. A
> >>>> "wp_inhibiter" in a inhibiter XML file that inhibit things.
> >
> >
> > Please don't use any name that does not have the word "screensaver" in
> it,
> > because that is the word programmers are going to look for. My
> suggestion is
> > "wpz_screensaver_v1" (or whatever the rules for experimental protocols
> are).
> > I suspect this api will quickly get enhanced with other api (such as
> events
> > when the screensaver turns on/off), so I would not use the word
> "inhibit" at
> > all.
>
> It's not a screensaver API, it's a screensaver/blanking inhibition
> API. Everyone else already uses 'inhibit'.
>

Ok I think I see where you are going. I would still have the word
"screensaver" in the name, ie "screensaver_inhibit". Though of course it is
going to inhibit other things, but I'm afraid the fact that people
searching for this api are going to look for the word "screensaver" about
100 times more often than they look for the word "inhibit" means it had
better be in the name. Thus zwp_screensaver_inhibit_v1 is probably the name.

> Absolutely it should by default inhibit any kind of notifier or any other
> > changes to the display not triggered by the user (it also should NOT
> inhibit
> > changes that the user triggers, such as hitting a shortcut key that
> creates
> > a popup).
> >
> > Among these changes that must be inhibited are "things that have not been
> > invented yet but may appear in a future desktop". Therefore a per-thing
> api
> > to inhibit them is not going to work and this must inhibit them all.
> >
> > The api can be enhanced in the future if you want finer control over
> what is
> > inhibited.
>
> No. People want to receive notifications whilst they watch movies.
> Presentation is something else altogether.
>

I may have been too specific about what is disabled. Let me try to be more
careful:

There are two set

Re: [PATCH 2/5] wayland-server: Add code docs for new display socket API's

[Bill Spitzak]

I don't see any reason for the  wl_display_add_socket_fd_auto and
wl_display_add_socket_auto functions, as they are the same as passing NULL
for the name to wl_display_add_socket_fd, right?

Also (on the patch) it looks like if there is an error it destroys the
wl_socket object, could this do the wrong thing if the fd was supplied from
outside?

On Thu, Nov 19, 2015 at 1:36 AM, Bryce Harrington 
wrote:

> Signed-off-by: Bryce Harrington 
> ---
>  src/wayland-server.c | 67
> +---
>  1 file changed, 53 insertions(+), 14 deletions(-)
>
> diff --git a/src/wayland-server.c b/src/wayland-server.c
> index bac98bf..e84858d 100644
> --- a/src/wayland-server.c
> +++ b/src/wayland-server.c
> @@ -1164,6 +1164,17 @@ _wl_display_add_socket(struct wl_display *display,
> struct wl_socket *s)
> return 0;
>  }
>
> +/** Create a socket for clients with a specified file descriptor
> + * \param display Wayland display
> + * \param sock_fd The socket's file descriptor
> + * \return The socket name or NULL if failed.
> + *
> + * Adds a new socket with a specified file descriptor but an
> + * automatically determined socket name, in the form "wayland-N"
> + * where N is a display number.
> + *
> + * \memberof wl_display
> + */
>  WL_EXPORT const char *
>  wl_display_add_socket_fd_auto(struct wl_display *display, int sock_fd)
>  {
> @@ -1205,12 +1216,50 @@ wl_display_add_socket_fd_auto(struct wl_display
> *display, int sock_fd)
> return NULL;
>  }
>
> +/** Create a socket for clients using default settings
> + * \param display The Wayland display to which the socket should be added
> + * \return The name of the created socket, or NULL if failed.
> + *
> + * This helper routine establishes a socket connection for Wayland clients
> + * using an automatically socket address and file descriptor.
> + *
> + * See wl_display_add_socket_fd_auto.
> + *
> + * \memberof wl_display
> + */
>  WL_EXPORT const char *
>  wl_display_add_socket_auto(struct wl_display *display)
>  {
> return wl_display_add_socket_fd_auto(display, -1);
>  }
>
> +/** Add a socket with a defined file descriptor to the Wayland display
> for clients to connect.
> + * \param display Wayland display to which the socket should be added.
> + * \param name Name of the Unix socket.
> + * \param sock_fd File descriptor of the Unix socket.
> + * \return 0 if success. -1 if failed.
> + *
> + * This adds a Unix socket to Wayland display which can be used by
> clients to
> + * connect to Wayland display.
> + *
> + * If NULL is passed as name, then it would look for WAYLAND_DISPLAY env
> + * variable for the socket name. If WAYLAND_DISPLAY is not set, then
> default
> + * wayland-0 is used.
> + *
> + * If -1 is passed for sock_id, a new local socket will be created.  A
> link to
> + * this socket will be made available in display->socket_list.
> + *
> + * This Unix socket will be created in the directory pointed to by
> environment
> + * variable XDG_RUNTIME_DIR. If XDG_RUNTIME_DIR is not set, then this
> function
> + * fails and returns -1.
> + *
> + * The length of socket path, i.e., the path set in XDG_RUNTIME_DIR and
> the
> + * socket name, must not exceed the maxium length of a Unix socket path.
> + * The function also fails if the user do not have write permission in the
> + * XDG_RUNTIME_DIR path or if the socket name is already in use.
> + *
> + * \memberof wl_display
> + */
>  WL_EXPORT int
>  wl_display_add_socket_fd(struct wl_display *display, const char *name,
> int sock_fd)
>  {
> @@ -1251,21 +1300,11 @@ wl_display_add_socket_fd(struct wl_display
> *display, const char *name, int sock_
>   * \param name Name of the Unix socket.
>   * \return 0 if success. -1 if failed.
>   *
> - * This adds a Unix socket to Wayland display which can be used by
> clients to
> - * connect to Wayland display.
> - *
> - * If NULL is passed as name, then it would look for WAYLAND_DISPLAY env
> - * variable for the socket name. If WAYLAND_DISPLAY is not set, then
> default
> - * wayland-0 is used.
> + * This adds a Unix socket to Wayland display with an automatically
> + * created file descriptor, which can be used by clients to connect to
> + * the Wayland display.
>   *
> - * The Unix socket will be created in the directory pointed to by
> environment
> - * variable XDG_RUNTIME_DIR. If XDG_RUNTIME_DIR is not set, then this
> function
> - * fails and returns -1.
> - *
> - * The length of socket path, i.e., the path set in XDG_RUNTIME_DIR and
> the
> - * socket name, must not exceed the maxium length of a Unix socket path.
> - * The function also fails if the user do not have write permission in the
> - * XDG_RUNTIME_DIR path or if the socket name is already in use.
> + * See wl_display_add_socket_fd for more details.
>   *
>   * \memberof wl_display
>   */
> --
> 1.9.1
>
> ___
> wayland-devel mailing list
> 

Re: [PATCH wayland] protocol: Remove incorrect statement that attach must precede damage

[Bill Spitzak]

On Wed, Nov 18, 2015 at 7:44 AM, Derek Foreman 
wrote:

> The documentation for wl_surface.commit makes it clear that the
> application of damage follows attach during the commit, so it
> doesn't matter what order the app sends the requests.
>
> Many existing apps post damage before attaching a buffer already,
> and it's really quite reasonable to do so.
>

Especially because they probably think of the old buffer as being the one
that is "damaged", while the new buffer does not have any damage.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel