Re: [PATCH v14 19/41] compositor-drm: Extract buffer->plane co-ord translation

[Daniel Stone]

Hi Pekka,
Thanks for the explanation; I'm not sure why it's requiring so much
mental contortion on my end. :\

On 26 February 2018 at 08:30, Pekka Paalanen  wrote:
> On Fri, 23 Feb 2018 17:25:49 + Daniel Stone  wrote:
>> Hm ... I am feeling particularly dense today, but I can't get my head
>> around this. Why/how would we need to translate the dest region?
>
> The function currently works like this:
>
> 1. Starting from the view parameters, compute the destination rectangle
>in the framebuffer.
>
> 2. Starting from the view parameters, compute the source rectangle in
>the buffer.
>
> 3. Source rectangle is clamped to the accessible buffer area.
>
> If step 3 changes the source rectangle position in the buffer area, and
> we do not take that into account in the destination rectangle, it will
> look like as if the image has been shifted slightly. E.g. if computed
> src_x was -1, and it gets clamped to 0, then the whole resulting image
> will get shifted by one source pixel.
>
> One possible solution would be to compute the source rectangle first,
> clamp it, and then starting from the source rectangle compute the
> destination rectangle. Whether the destination rectangle ends up any
> different depends on the actual values in the transformation.
>
> I think one could also take this further to take advantage of the
> fractional source coordinates of KMS, by first computing the
> destination coordinates from the view parameters, then computing the
> source coordinates from the destination coordinates (which may produce
> fractional values), clamp, and then re-compute the destination
> coordinates from the final source coordinates.

I think that sounds like the best approach. I wonder if, for now,
we're best off just punting back to the renderer and refusing to
promote the surface, if we generate OOB co-ordinates.

> However, as I gave my R-b already, I don't think this is important
> enough to work on right now. Testing it would require carefully
> constructing special test cases. We also seem to still lack an
> automatable way to test this, so it would be a manual test. And it
> seems like it would be easy to break this by accident.
>
> It would be a lot of work for what seems to be a "rounding effect"
> leading to the clamps even changing anything.
>
> Also, this patch is just extracting code into a new function, not
> intending to fix it, so it's fine.

Thanks for this. I think we'd very definitely need a test with a few
cases on either side of the line to both illustrate what's supposed to
happen, and make sure it doesn't break. Unfortunately it doesn't seem
at all easy to plumb it through, so would likely be a lot of annoying
mechanical work. On the other hand, it would at least provide a good
example for making more parts unit-testable, so would be great if
someone felt like stepping up to do it.

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

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

[Mike Blumenkrantz]

Hi,

I agree with your point regarding a SSD-capable compositor not always
wanting them, and certainly I can see the usefulness for cases such as what
you've cited. However, in the example you provided, it's easy enough for an
application to determine what desktop it's running in and then determine
whether to use SSD--if the compositor implements and advertises this
protocol then it's ultimately a client decision whether to use it.

My issue is in the inconsistency of the protocol that has been proposed
here. This is a protocol for enabling SSD; there should be no need for
anything related to CSD, and I don't think there is a need for clients to
have any form of protocol request to toggle between CSD and SSD.

Based on your assertion that borderless mode would be achieved in this
protocol in the CSD mode, I would raise the counterpoint that in this case
the client should just destroy the zxdg_toplevel_decoration_v1 object
which, according to the destroy request, would revert to the surface using
CSD anyway, furthering my assessment that there is indeed no need for any
mention of CSD in the protocol requests.

This change allows for everything except the destroy request to be removed
from zxdg_toplevel_decoration_v1, greatly simplifying the protocol as well
as implementations of it. The case of the compositor "ignoring" the request
to create SSD also becomes moot as well, since all that would mean is the
compositor has chosen to use a borderless state at this time (e.g., tiling
layout) which is irrelevant to the client anyway.

This aside, there's some other items of note here, such as the lack of
precision related to when the change in decoration management state takes
effect: most likely it should be applied on the next surface commit? I
think this should be specified in the zxdg_toplevel_decoration_v1 interface
description. Also, I would think that destroying the
zxdg_toplevel_decoration_manager_v1
object while any zxdg_toplevel_decoration_v1 objects exist should be a
client error, but this is similarly not specified anywhere.

Regards,
Mike

On Thu, Mar 1, 2018 at 1:18 PM Simon Ser  wrote:

> Hi Mike,
>
> I don't think a compositor supporting the protocol means that it always
> wants SSDs. For instance, I can imagine a DE like GNOME supporting it:
> - Allowing clients that prefer SSDs to use SSDs, so that toolkits like
> GLFW or winit and apps like mpv don't have to draw decorations that'll look
> alien and don't respect the user's preferences
> - But still preferring CSDs, so that GTK+ apps can use them
>
> Also, the CSD mode allows the client to do not draw decorations at all.
>
> Regards,
>
> On March 1, 2018 7:01 PM, Mike Blumenkrantz <
> michael.blumenkra...@gmail.com> wrote:
> > Hi,
> >
> > This patch is certainly an improvement upon the previous protocol draft
> which I reviewed, but it still does not address the most significant issue
> that I pointed out, which is that it both is too complex and lacks
> features. Why is there any "mode" when this is a protocol for enabling
> server-side decorations? By using the protocol in a server or client, you
> are enabling server-side decoration; why would there be any mention of
> client-side at all? If the compositor, for whatever reason, decides to do a
> runtime disable of SSD then it can simply destroy the global.
> >
> > Please see again my mail on this topic from the previous thread:
> https://lists.freedesktop.org/archives/wayland-devel/2018-January/036495.html
> >
> > Regards,
> >
> > Mike
> >
> > On Sun, Feb 18, 2018 at 3:01 PM Simon Ser  wrote:
> >
> > > This adds a new protocol to negotiate server- and client-side
> rendering of
> > >
> > > window decorations for xdg-toplevels.
> > >
> > > \-\-\-
> > >
> > > This is inspired by a protocol from KDE\[0\] which has been
> implemented in KDE
> > >
> > > and Sway and was submitted for consideration in 2017\[1\]. This patch
> provides an
> > >
> > > updated protocol with those concerns taken into account.
> > >
> > > This was iterated on privately between representatives of Sway and
> wlroots
> > >
> > > (Simon Ser and Drew DeVault), KDE (David Edmundson), and Mir (Alan
> Griffiths).
> > >
> > > A proof-of-concept of a client and server implementation is available
> at \[2\].
> > >
> > > \[0\]
> https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml
> > >
> > > \[1\]
> https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html
> > >
> > > \[2\] https://github.com/swaywm/wlroots/pull/638
> > >
> > >  Makefile.am|   1 +
> > >
> > >  unstable/xdg-toplevel-decoration/README|   4 +
> > >
> > >  .../xdg-toplevel-decoration-unstable-v1.xml| 127
> +
> > >
> > >  3 files changed, 132 insertions(+)
> > >
> > >  create mode 100644 unstable/xdg-toplevel-decoration/README
> > >
> > >  create mode 100644
> 

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

[Simon Ser]

This adds a new protocol to negotiate server- and client-side rendering of
window decorations for xdg-toplevels. This allows compositors that want
to draw decorations themselves to send their preference to clients, and
clients that prefer server-side decorations to request them.

This is inspired by a protocol from KDE [1] which has been implemented in
KDE and Sway and was submitted for consideration in 2017 [2]. This patch
provides an updated protocol with those concerns taken into account.

Signed-off-by: Simon Ser 
Reviewed-by: Drew DeVault 
Reviewed-by: David Edmundson 
Reviewed-by: Alan Griffiths 
Reviewed-by: Tony Crisci 

[1] 
https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml
[2] 
https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html
---

This was iterated on privately between representatives of Sway and wlroots
(Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson),
and Mir (Alan Griffiths).

A proof-of-concept of a client and server implementation is available at [1].

Changes from v1 to v2: moved the enum above in the protocol, added
Signed-off-by and Reviewed-by tags, updated the commit message.

[1] https://github.com/swaywm/wlroots/pull/638

 Makefile.am|   1 +
 unstable/xdg-toplevel-decoration/README|   4 +
 .../xdg-toplevel-decoration-unstable-v1.xml| 127 +
 3 files changed, 132 insertions(+)
 create mode 100644 unstable/xdg-toplevel-decoration/README
 create mode 100644 
unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index 4b9a901..07744e9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -17,6 +17,7 @@ unstable_protocols =  
\

unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \
unstable/xdg-output/xdg-output-unstable-v1.xml  
\
unstable/input-timestamps/input-timestamps-unstable-v1.xml  \
+   
unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
\
$(NULL)
 
 stable_protocols = 
\
diff --git a/unstable/xdg-toplevel-decoration/README 
b/unstable/xdg-toplevel-decoration/README
new file mode 100644
index 000..e927110
--- /dev/null
+++ b/unstable/xdg-toplevel-decoration/README
@@ -0,0 +1,4 @@
+xdg_toplevel_decoration protocol
+
+Maintainers:
+Simon Ser 
diff --git 
a/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml 
b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
new file mode 100644
index 000..acc1ed2
--- /dev/null
+++ b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
@@ -0,0 +1,127 @@
+
+
+  
+Copyright © 2018 Simon Ser
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+to deal in the Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, distribute, sublicense,
+and/or sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice (including the next
+paragraph) shall be included in all copies or substantial portions of the
+Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.
+  
+
+  
+
+  This interface permits choosing between client-side and server-side
+  window decorations for a toplevel surface.
+
+  A window decoration is a user interface component used to move, resize 
and
+  change a window's state. It can be managed either by the client (part of
+  the surface) or by the server.
+
+  By advertizing this interface the server anounces support for server-side
+  window decorations.
+
+  Warning! The protocol described in this file is experimental and
+  backward incompatible changes may be made. Backward compatible changes
+  may be added together with the corresponding interface version bump.
+  Backward incompatible changes are done by bumping the version number in
+  the protocol and interface 

Re: Is it possible to emit event at client side?

[Pekka Paalanen]

On Fri, 02 Mar 2018 14:51:54 +
Sichem Zhou  wrote:

> Hi PQ,
> 
> Thanks for your answer. It would be nice have it though.

Sorry, not going to happen.


Thanks,
pq
 
> Le ven. 2 mars 2018 09 h 41, Pekka Paalanen  a écrit :
> 
> > On Fri, 02 Mar 2018 14:27:23 +
> > Sichem Zhou  wrote:
> >  
> > > Hi all,
> > >
> > > I have a question regarding the Wayland client side API. I see there is  
> > API  
> > > to create a `wl_ event_queue` but it seems you can only assign `wl_proxy`
> > > and send command to server.
> > >
> > > Is anyway that I can create a event queue and keep it to myself, it's use
> > > case lies in multi threading application where one thread trigger a event
> > > and other thread process it. If I can use this queue myself. later on I  
> > can  
> > > just add an event in the queue and in main thread I just use
> > > `wl_display_dispatch` to process the event.  
> >
> > Hi,
> >
> > wl_event_queue is meant exclusively for processing events received from a
> > Wayland server. It's not for generic use.
> >
> >
> > Thanks,
> > pq
> >  



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

Re: [PATCH] gl-renderer: Create a high priority context

[Chris Wilson]

Quoting Emil Velikov (2018-03-02 14:52:28)
> Hi Chris,
> 
> On 1 March 2018 at 08:28, Chris Wilson  wrote:
> > EGL_IMG_context_priority allows the client to request that their
> > rendering be considered high priority. For ourselves, this is important
> > as we are interactive and any delay in our rendering causes input-output
> 
> > +   if (gr->has_context_priority) {
> > +   EGLint value = EGL_CONTEXT_PRIORITY_MEDIUM_IMG;
> > +
> > +   eglQueryContext(gr->egl_display, gr->egl_context,
> > +   EGL_CONTEXT_PRIORITY_LEVEL_IMG, );
> > +
> > +   if (value != EGL_CONTEXT_PRIORITY_HIGH_IMG) {
> > +   weston_log("Failed to obtain a high priority 
> > context.\n");
> > +   /* Not an error, continue on as normal */
> > +   }
> While this (and EGL spec) says "not an error" the i965 driver will
> error out as the ioctl fails.

The high priority attribute is filtered out from the allowed set of EGL
attributes, so the request for a high priority context is silently
converted back to normal. You don't get as far as hitting the ioctl.

diff --git a/src/egl/main/eglcontext.c b/src/egl/main/eglcontext.c
index 1b03160439..8c64f9ab82 100644
--- a/src/egl/main/eglcontext.c
+++ b/src/egl/main/eglcontext.c
@@ -332,6 +332,60 @@ _eglParseContextAttribList(_EGLContext *ctx, _EGLDisplay 
*dpy,
  ctx->NoError = !!val;
  break;
 
+  case EGL_CONTEXT_PRIORITY_LEVEL_IMG:
+ /* The  EGL_IMG_context_priority spec says:
+  *
+  * "EGL_CONTEXT_PRIORITY_LEVEL_IMG determines the priority level of
+  * the context to be created. This attribute is a hint, as an
+  * implementation may not support multiple contexts at some
+  * priority levels and system policy may limit access to high
+  * priority contexts to appropriate system privilege level. The
+  * default value for EGL_CONTEXT_PRIORITY_LEVEL_IMG is
+  * EGL_CONTEXT_PRIORITY_MEDIUM_IMG."
+  */
+ {
+int bit;
+
+switch (val) {
+case EGL_CONTEXT_PRIORITY_HIGH_IMG:
+   bit = __EGL_CONTEXT_PRIORITY_HIGH_BIT;
+   break;
+case EGL_CONTEXT_PRIORITY_MEDIUM_IMG:
+   bit = __EGL_CONTEXT_PRIORITY_MEDIUM_BIT;
+   break;
+case EGL_CONTEXT_PRIORITY_LOW_IMG:
+   bit = __EGL_CONTEXT_PRIORITY_LOW_BIT;
+   break;
+default:
+   bit = -1;
+   break;
+}
+
+if (bit < 0) {
+   err = EGL_BAD_ATTRIBUTE;
+   break;
+}
+
+/* "This extension allows an EGLContext to be created with a
+ * priority hint. It is possible that an implementation will not
+ * honour the hint, especially if there are constraints on the
+ * number of high priority contexts available in the system, or
+ * system policy limits access to high priority contexts to
+ * appropriate system privilege level. A query is provided to find
+ * the real priority level assigned to the context after creation."
+ *
+ * We currently assume that the driver applies the priority hint
+ * and filters out any it cannot handle during the screen setup,
+ * e.g. dri2_setup_screen(). As such we can mask any change that
+ * the driver would fail, and ctx->ContextPriority matches the
+ * hint applied to the driver/hardware backend.
+ */
+if (dpy->Extensions.IMG_context_priority & (1 << bit))
+   ctx->ContextPriority = val;
+
+break;
+ }
+
   default:
  err = EGL_BAD_ATTRIBUTE;
  break;

and dpy->Extensions.IMG_context_priority should not have HIGH_BIT set.
-Chris
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] gl-renderer: Create a high priority context

[Emil Velikov]

Hi Chris,

On 1 March 2018 at 08:28, Chris Wilson  wrote:
> EGL_IMG_context_priority allows the client to request that their
> rendering be considered high priority. For ourselves, this is important
> as we are interactive and any delay in our rendering causes input-output

> +   if (gr->has_context_priority) {
> +   EGLint value = EGL_CONTEXT_PRIORITY_MEDIUM_IMG;
> +
> +   eglQueryContext(gr->egl_display, gr->egl_context,
> +   EGL_CONTEXT_PRIORITY_LEVEL_IMG, );
> +
> +   if (value != EGL_CONTEXT_PRIORITY_HIGH_IMG) {
> +   weston_log("Failed to obtain a high priority 
> context.\n");
> +   /* Not an error, continue on as normal */
> +   }
While this (and EGL spec) says "not an error" the i965 driver will
error out as the ioctl fails.
Say, for some reason the kernel module/HW cannot do a high-priority one ATM.

Should that be changed/fixed?

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

Re: Is it possible to emit event at client side?

[Sichem Zhou]

Hi PQ,

Thanks for your answer. It would be nice have it though.

Regards,
X


Le ven. 2 mars 2018 09 h 41, Pekka Paalanen  a écrit :

> On Fri, 02 Mar 2018 14:27:23 +
> Sichem Zhou  wrote:
>
> > Hi all,
> >
> > I have a question regarding the Wayland client side API. I see there is
> API
> > to create a `wl_ event_queue` but it seems you can only assign `wl_proxy`
> > and send command to server.
> >
> > Is anyway that I can create a event queue and keep it to myself, it's use
> > case lies in multi threading application where one thread trigger a event
> > and other thread process it. If I can use this queue myself. later on I
> can
> > just add an event in the queue and in main thread I just use
> > `wl_display_dispatch` to process the event.
>
> Hi,
>
> wl_event_queue is meant exclusively for processing events received from a
> Wayland server. It's not for generic use.
>
>
> Thanks,
> pq
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Is it possible to emit event at client side?

[Pekka Paalanen]

On Fri, 02 Mar 2018 14:27:23 +
Sichem Zhou  wrote:

> Hi all,
> 
> I have a question regarding the Wayland client side API. I see there is API
> to create a `wl_ event_queue` but it seems you can only assign `wl_proxy`
> and send command to server.
> 
> Is anyway that I can create a event queue and keep it to myself, it's use
> case lies in multi threading application where one thread trigger a event
> and other thread process it. If I can use this queue myself. later on I can
> just add an event in the queue and in main thread I just use
> `wl_display_dispatch` to process the event.

Hi,

wl_event_queue is meant exclusively for processing events received from a
Wayland server. It's not for generic use.


Thanks,
pq


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

Is it possible to emit event at client side?

[Sichem Zhou]

Hi all,

I have a question regarding the Wayland client side API. I see there is API
to create a `wl_ event_queue` but it seems you can only assign `wl_proxy`
and send command to server.

Is anyway that I can create a event queue and keep it to myself, it's use
case lies in multi threading application where one thread trigger a event
and other thread process it. If I can use this queue myself. later on I can
just add an event in the queue and in main thread I just use
`wl_display_dispatch` to process the event.

Thank you very much,
Xichen
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Sharing wl display/surface with another process.

[Pekka Paalanen]

On Fri, 02 Mar 2018 15:12:40 +0200
Maksim Sisov  wrote:

> Hi,
> 
> I have a question about a proper client side of implementation of
> wayland with egl.
> 
> The idea is that we have wayland ui related stuff on ui process
> (creating wayland window, managing mouse/keyboard inputs and etc), and
> have egl related stuff created and rendering on another gpu process.
> 
> That gpu process creates an egl window, but it has to use an wl_surface
> handle, which is available on the ui process side.
> 
> What would be the best way to achieve that? Can I just pass the handle
> to another process or is there a better way how to achieve that? And how
> I can share the wl_display across the process? Or should I better have
> another wayland connection established?
> 
> What is the best approach in this kind of cases?

Hi,

you simply cannot share a wl_display or a wl_surface with another
process.

The usual way to make such architecture work is to have the GPU process
send rendered buffers to the UI process which relays them to the
Wayland server. You can use a completely custom protocol for sharing
those buffers between the GPU and UI processes, or you can make the UI
process to be a Wayland mini-server.

The Wayland mini-server approach is nice because it will leverage the
same infrastructure that Wayland normally uses as well. I call it
mini-server, because the portion of Wayland protocols you have to
implement is very bare-bones, nothing even close to what normal Wayland
desktop applications would require. You can also have custom private
Wayland extensions for your specific needs for IPC, so you can run
everything through Wayland IPC if you want.

Another benefit of having the GPU process go through the UI process to
the display server is that the UI process will always know exactly what
is on the screen, which helps to avoid synchronization issues like
sub-window resizing glitches or window content not matching the window
state.

As an alternative approach, there is
https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/xdg-foreign
but you need to consider which Wayland servers actually support it. The
mini-server approach does not need any special support from the (host)
Wayland server. The mini-server approach is usable even if your UI
process needs to run on X11, I believe.


Thanks,
pq


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

Sharing wl display/surface with another process.

[Maksim Sisov]

Hi,

I have a question about a proper client side of implementation of
wayland with egl.

The idea is that we have wayland ui related stuff on ui process
(creating wayland window, managing mouse/keyboard inputs and etc), and
have egl related stuff created and rendering on another gpu process.

That gpu process creates an egl window, but it has to use an wl_surface
handle, which is available on the ui process side.

What would be the best way to achieve that? Can I just pass the handle
to another process or is there a better way how to achieve that? And how
I can share the wl_display across the process? Or should I better have
another wayland connection established?

What is the best approach in this kind of cases?

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

[PATCH libinput] Add libinput_device_touch_get_touch_count()

[Peter Hutterer]

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 devices only, not touchpads that are just pointer
devices.

https://bugs.freedesktop.org/show_bug.cgi?id=104867

Signed-off-by: Peter Hutterer 
---
 src/evdev.c   | 22 ++
 src/evdev.h   |  3 +++
 src/libinput.c|  6 ++
 src/libinput.h| 14 ++
 src/libinput.sym  |  4 
 test/test-touch.c | 23 +++
 6 files changed, 72 insertions(+)

diff --git a/src/evdev.c b/src/evdev.c
index 257824aa..629d4e2f 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -2224,6 +2224,28 @@ evdev_device_has_key(struct evdev_device *device, 
uint32_t code)
return libevdev_has_event_code(device->evdev, EV_KEY, code);
 }
 
+int
+evdev_device_get_touch_count(struct evdev_device *device)
+{
+   int ntouches;
+
+   if (!(device->seat_caps & EVDEV_DEVICE_TOUCH))
+   return -1;
+
+   ntouches = libevdev_get_num_slots(device->evdev);
+   if (ntouches == -1) {
+   /* mtdev device have multitouch but we don't know
+* how many. Otherwise, any touch device with num_slots of
+* -1 is a single-touch device */
+   if (device->mtdev)
+   ntouches = 0;
+   else
+   ntouches = 1;
+   }
+
+   return ntouches;
+}
+
 int
 evdev_device_has_switch(struct evdev_device *device,
enum libinput_switch sw)
diff --git a/src/evdev.h b/src/evdev.h
index 162adecb..e732e693 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -459,6 +459,9 @@ evdev_device_has_button(struct evdev_device *device, 
uint32_t code);
 int
 evdev_device_has_key(struct evdev_device *device, uint32_t code);
 
+int
+evdev_device_get_touch_count(struct evdev_device *device);
+
 int
 evdev_device_has_switch(struct evdev_device *device,
enum libinput_switch sw);
diff --git a/src/libinput.c b/src/libinput.c
index 8fb0ba92..5e675dd9 100644
--- a/src/libinput.c
+++ b/src/libinput.c
@@ -2941,6 +2941,12 @@ libinput_device_keyboard_has_key(struct libinput_device 
*device, uint32_t code)
return evdev_device_has_key((struct evdev_device *)device, code);
 }
 
+LIBINPUT_EXPORT int
+libinput_device_touch_get_touch_count(struct libinput_device *device)
+{
+   return evdev_device_get_touch_count((struct evdev_device *)device);
+}
+
 LIBINPUT_EXPORT int
 libinput_device_switch_has_switch(struct libinput_device *device,
  enum libinput_switch sw)
diff --git a/src/libinput.h b/src/libinput.h
index 759bce91..d9f74d2f 100644
--- a/src/libinput.h
+++ b/src/libinput.h
@@ -3713,6 +3713,20 @@ int
 libinput_device_keyboard_has_key(struct libinput_device *device,
 uint32_t code);
 
+/**
+ * @ingroup device
+ *
+ * Check how many touches a @ref LIBINPUT_DEVICE_CAP_TOUCH device supports
+ * simultaneously.
+ *
+ * @param device A current input device
+ *
+ * @return The number of simultaneous touches or 0 if unknown, -1
+ * on error.
+ */
+int
+libinput_device_touch_get_touch_count(struct libinput_device *device);
+
 /**
  * @ingroup device
  *
diff --git a/src/libinput.sym b/src/libinput.sym
index bb283407..aa2794e9 100644
--- a/src/libinput.sym
+++ b/src/libinput.sym
@@ -293,3 +293,7 @@ LIBINPUT_1.7 {
 LIBINPUT_1.9 {
libinput_device_switch_has_switch;
 } LIBINPUT_1.7;
+
+LIBINPUT_1.11 {
+   libinput_device_touch_get_touch_count;
+} LIBINPUT_1.9;
diff --git a/test/test-touch.c b/test/test-touch.c
index b3a6d0a0..a14bcf4b 100644
--- a/test/test-touch.c
+++ b/test/test-touch.c
@@ -945,6 +945,26 @@ START_TEST(touch_release_on_unplug)
 }
 END_TEST
 
+START_TEST(touch_count_st)
+{
+   struct litest_device *dev = litest_current_device();
+   struct libinput_device *device = dev->libinput_device;
+
+   ck_assert_int_eq(libinput_device_touch_get_touch_count(device), 1);
+}
+END_TEST
+
+START_TEST(touch_count_mt)
+{
+   struct litest_device *dev = litest_current_device();
+   struct libinput_device *device = dev->libinput_device;
+   struct libevdev *evdev = dev->evdev;
+
+   ck_assert_int_eq(libinput_device_touch_get_touch_count(device),
+libevdev_get_num_slots(evdev));
+}
+END_TEST
+
 void
 litest_setup_tests_touch(void)
 {
@@ -980,4 +1000,7 @@ litest_setup_tests_touch(void)
litest_add_for_device("touch:fuzz", touch_fuzz, 
LITEST_MULTITOUCH_FUZZ_SCREEN);
 
litest_add_no_device("touch:release", touch_release_on_unplug);
+
+   litest_add("touch:count", touch_count_st, LITEST_SINGLE_TOUCH, 
LITEST_TOUCHPAD);
+   litest_add("touch:count", touch_count_mt, LITEST_TOUCH, 
LITEST_SINGLE_TOUCH);
 }
-- 
2.14.3

___
wayland-devel