Re: [PATCH libinput] Add libinput_device_touch_get_touch_count()

On Fri, Mar 02, 2018 at 06:16:34PM +1000, Peter Hutterer wrote: > This makes it possible for callers to detect whether a touch device is > single or multitouch (or even check for things like dual-touch vs real > multi-touch) and adjust the interface accordingly. > > Note that this is for touch

Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol

On Wed, Mar 14, 2018 at 06:41:53AM -0400, Simon Ser wrote: > On March 14, 2018 10:22 AM, Peter Hutterer wrote: > > sorry about the delay, but better late than too late ;) > > No problem, thanks for your review! > > > On Sun, Mar 11, 2018 at 05:53:42PM -0400, Simon Ser

[PATCH libinput] touchpad: ignore any semi-mt movement in the same frame as a finger release

Semi-MT devices provide a bounding box of the fingers, and internally we don't treat them as real MT device. Depending which finger currently provides ABS_X/Y we may get a large jump when the other finger is released. Basic sequence is finger 1 down, finger 2 down, finger 1 up. On the last

Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol

How about: If the client chooses not to use server-side decorations, it may be responsible for its own window management operations. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org

Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol

>> If server and client do not negotiate the use of a server-side >> decoration using this protocol, clients continue to self-decorate as >> they see fit." > > The wording here is weird, and I want to avoid the word decorate. What > the client does is not necessarily decorate. The reason why

Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol

On 2018-03-19 4:42 AM, Eike Hein wrote: > How about: > > > +1 > And as description: > > "This interface allows a server to announce support for server-side > decorations and optionally express a preference for using them. > > A client can use this protocol to request being decorated by a >

Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol

How about: And as description: "This interface allows a server to announce support for server-side decorations and optionally express a preference for using them. A client can use this protocol to request being decorated by a supporting server. If server and client do not negotiate the use

Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol

To summarize the state of affairs here, the purpose of this protocol is to communicate: - The compositor's preference to use SSD or leave the client to its own devices - The choice of the client to have SSD displayed We can completely remove CSD from the question because the term is barely

Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol

On March 16, 2018 1:22 PM, Pekka Paalanen wrote: > > > I'm missing a comment that describes what happens if the xdg_toplevel is > > > destroyed. There is some object dependency here that needs to be stated. > > > Do > > > we need an event here? Or are we assuming that

[PATCH] xwm: Send configure event when moving

Send a synthetic configure notify event to the reparented window to update the position in Xwayland. This fixes menu positioning in clients like VLC after moving the window. --- xwayland/window-manager.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git

[PATCH] xwm: Fix wrong input offset for certain clients

Some windows might get a create_notify event without the override redirect flag set and then get a confiure_notify event before map_request is received. This means that when weston_wm_window_get_child_position is called in response to configure_notify, the wrong offsets are computed resulting in

[PATCH] xwm: Handle changing override redirect flag

Xwayland windows might be created with a different override redirect flag than is given on map or configure notify. This causes confusion about whether a window should be treated as override redirect or not. Here we handle the changing override redirect flag in relevant notify handlers so windows

Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol

Hi Eike, On 18 March 2018 at 16:35, Eike Hein wrote: > On 03/18/2018 03:55 PM, Markus Ongyerth wrote: >>> a) Change the definition of "decoration" to "window controls as deemed >>> appropriate by the compositor, for example ...". This leaves what's in a >>> server-side deco and

Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol

Hi, On 18 March 2018 at 16:22, Eike Hein wrote: > On 03/18/2018 10:45 PM, Daniel Stone wrote: >> That strikes me as a problem. So what can we do to bridge the gap >> between these projects? > > FWIW, I agree this is a problem. KDE's Wayland contributor base is > slowly growing,

Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol

On 03/18/2018 03:55 PM, Markus Ongyerth wrote: >> a) Change the definition of "decoration" to "window controls as deemed >> appropriate by the compositor, for example ...". This leaves what's in a >> server-side deco and what's in a client-side deco up to servers and >> clients, respectively, and

Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol

On 03/18/2018 10:45 PM, Daniel Stone wrote: > That strikes me as a problem. So what can we do to bridge the gap > between these projects? FWIW, I agree this is a problem. KDE's Wayland contributor base is slowly growing, though - we have more people working on Wayland stuff than we had

Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol

Sorry, I messed up my quoting, cutting down the mail =.= I wanted to keep the part that ended in: > Yes, but I think this reinforces my point. If an IVI, phone or > set-top-box compositor suddenly started sticking decorations on the > surfaces it found, it wouldn't be useful. Saying 'but the

Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol

On 2018/3月/18 01:45, Daniel Stone wrote: > Hi Drew, > > On 15 March 2018 at 16:53, Drew DeVault wrote: > >> > In fact, I have done so. Before we started working on this protocol, > >> > Sway did exactly this. We have provided users the means of overriding > >> > the approach to

Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol

On 2018-03-18 1:45 PM, Daniel Stone wrote: > I don't think prolonging the argument is helpful. Just a fairly clear > statement that in the absence of this extension and unless told > otherwise, clients which can decorate themselves, should decorate > themselves, would work for me. I don't want to

Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol

Hi Drew, On 15 March 2018 at 16:53, Drew DeVault wrote: >> Denying facts and being disingenuous doesn't help anyone, and it's >> tiring. Tiring enough that I came into this thread with the intention >> of giving this protocol a couple of suggestions and a push towards >> getting

Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol

On 2018/3月/18 10:50, Eike Hein wrote: > > > On 03/16/2018 12:43 AM, Daniel Stone wrote:> No, it really has. GTK+ has > always - well, until you got the patches > > for this protocol merged a month or two ago - decorated its own > > windows under Wayland. Same with Qt. Same with EFL. These are