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
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
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
/* 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.
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
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
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:
> > >
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
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
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
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 =
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
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
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
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
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
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
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,
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
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 <
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"
>
>
>> > > > > +# 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
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 =
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>
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
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?
ured 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
> >
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
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.
> >
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 t
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
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
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>> wr
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
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
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
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>
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.
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
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
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
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
> > o
> + 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
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
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
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
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
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
>
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
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,
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
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
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
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
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
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
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
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
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)
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
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
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
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
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 brus
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
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
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
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
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
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,
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
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
ize 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, 201
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
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
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
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
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
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
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,
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
>
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
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
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
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
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 =
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
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
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
00
> >> >> > Michal Suchanek <hramr...@gmail.com> wrote:
> >> >> >
> >> >> >> On 19 November 2015 at 20:12, Daniel Stone <dan...@fooishbar.org>
> wrote:
> >> >> >> > Hi,
> >> >>
uld 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 c
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
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,
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:
> >&g
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
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
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
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 notif
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
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
1 - 100 of 1326 matches
Mail list logo