date:20170519

[PATCH libinput] touchpad: fix clickfinger behavior with a thumb being present

2017-05-19 Thread Friedrich Schöller

With a thumb on the touchpad, a two-finger click was always treated as
a middle-click. This patch takes the thumb into account and treats the
click as a right-click, if the touchpad supports tracking of at least
three fingers.
---
 src/evdev-mt-touchpad-buttons.c | 90 +
 1 file changed, 65 insertions(+), 25 deletions(-)

diff --git a/src/evdev-mt-touchpad-buttons.c b/src/evdev-mt-touchpad-buttons.c
index 895cf0e..30c2948 100644
--- a/src/evdev-mt-touchpad-buttons.c
+++ b/src/evdev-mt-touchpad-buttons.c
@@ -978,54 +978,94 @@ out:
return within_distance;
 }
 
+static inline bool
+tp_clickfinger_within_distance_3(struct tp_dispatch *tp,
+struct tp_touch *t1,
+struct tp_touch *t2,
+struct tp_touch *t3)
+{
+   if (!t1 || !t2 || !t3)
+   return false;
+
+   double d12 =
+   (t1->point.x - t2->point.x) * (t1->point.x - t2->point.x) +
+   (t1->point.y - t2->point.y) * (t1->point.y - t2->point.y);
+   double d23 =
+   (t2->point.x - t3->point.x) * (t2->point.x - t3->point.x) +
+   (t2->point.y - t3->point.y) * (t2->point.y - t3->point.y);
+   double d31 =
+   (t3->point.x - t1->point.x) * (t3->point.x - t1->point.x) +
+   (t3->point.y - t1->point.y) * (t3->point.y - t1->point.y);
+
+   if (d12 > d23 && d12 > d31) {
+   return tp_clickfinger_within_distance(tp, t2, t3) &&
+  tp_clickfinger_within_distance(tp, t3, t1);
+   }
+
+   if (d23 > d31 && d23 > d12) {
+   return tp_clickfinger_within_distance(tp, t3, t1) &&
+  tp_clickfinger_within_distance(tp, t1, t2);
+   }
+
+   return tp_clickfinger_within_distance(tp, t1, t2) &&
+  tp_clickfinger_within_distance(tp, t2, t3);
+}
+
 static uint32_t
 tp_clickfinger_set_button(struct tp_dispatch *tp)
 {
-   uint32_t button;
+   bool thumb_detected = false;
unsigned int nfingers = tp->nfingers_down;
struct tp_touch *t;
struct tp_touch *first = NULL,
-   *second = NULL;
+   *second = NULL,
+   *third = NULL;
 
-   if (nfingers != 2)
-   goto out;
+   if (nfingers < 2)
+   return BTN_LEFT;
+   if (nfingers > 3)
+   return BTN_MIDDLE;
+
+   /* Thumb detection is unreliable if the number of fingers on the
+* touchpad is greater than the number of touches that can be
+* tracked. */
+   if (nfingers == 3 && tp->num_slots < 3)
+   return BTN_MIDDLE;
 
-   /* two fingers down on the touchpad. Check for distance
-* between the fingers. */
tp_for_each_touch(tp, t) {
if (t->state != TOUCH_BEGIN && t->state != TOUCH_UPDATE)
continue;
 
-   if (t->thumb.state == THUMB_STATE_YES)
+   if (t->thumb.state == THUMB_STATE_YES) {
+   thumb_detected = true;
continue;
+   }
 
if (!first)
first = t;
else if (!second)
second = t;
+   else if (!third)
+   third = t;
}
 
-   if (!first || !second) {
-   nfingers = 1;
-   goto out;
-   }
+   if (nfingers == 2) {
+   if (thumb_detected)
+   return BTN_LEFT;
 
-   if (tp_clickfinger_within_distance(tp, first, second))
-   nfingers = 2;
-   else
-   nfingers = 1;
+   if (tp_clickfinger_within_distance(tp, first, second))
+   return BTN_RIGHT;
+   else
+   return BTN_LEFT;
+   } else {
+   if (thumb_detected)
+   return BTN_RIGHT;
 
-out:
-   switch (nfingers) {
-   case 0:
-   case 1: button = BTN_LEFT; break;
-   case 2: button = BTN_RIGHT; break;
-   default:
-   button = BTN_MIDDLE; break;
-   break;
+   if (tp_clickfinger_within_distance_3(tp, first, second, third))
+   return BTN_MIDDLE;
+   else
+   return BTN_RIGHT;
}
-
-   return button;
 }
 
 static int
-- 
2.9.4

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

Re: [PATCH libinput] touchpad: fix clickfinger behavior with a thumb being present

2017-05-19 Thread Friedrich Schöller


Hi Peter,

Thanks for the comments.

On 18.05.2017 03:17, Peter Hutterer wrote:

Hi Friedrich,

On Tue, May 16, 2017 at 10:44:22PM +0200, Friedrich Schöller wrote:

With a thumb on the touchpad, a two-finger click was incorrectly
treated as a middle-click. This patch takes the thumb into account and
treats the click as a right-click.


fwiw, this was intentional behaviour, introduced in 316f30d2f28b62 with the
comment:
   It's reasonable to expect a thumb (or the other hand's index finger) to click
   a button while a finger is down for movement. It's less reasonable to expect
   this when two fingers are interacting with the touchpad, or when two fingers
   click the touchpad (even on a large touchpad that's an awkward position).


This is interesting to hear. I personally never found this to be an awkward 
position.



The problem is that while a index down + thumb is always [1] a one-finger
click, it's not as well defined for two fingers down. But that doesn't
matter, I'm happy to change that behaviour if we can detect the position
correctly. The patch works, but it'll need a change please:
on a touchpad with num_slots 2 the third finger position is based on the
finger position of the first two fingers (see tp_position_fake_touches() or
so).

with the patch applied, *when* the thumb is put down now matters:
if the thumb is the first or second finger, a two-finger + thumb
click is BTN_RIGHT, if the thumb is the third finger, a two-finger + thumb
click is BTN_MIDDLE. That's inconsistent, so we need an extra for num_slots
so this behaviour only gets enabled for devices that can reliably track 3 
fingers.


Ah yes, I did not notice before, but you are right. Now I did a bit more testing 
and found that in order to get consistent behavior, we needed to check if all 
three fingers are within a certain distance. It seems to work quite well now. 
Let me know what you think. The patch follows.


Best,

Friedrich



Thanks

Cheers,
Peter

[1] fsvo 'always'


---
  src/evdev-mt-touchpad-buttons.c | 44 ++---
  1 file changed, 19 insertions(+), 25 deletions(-)

diff --git a/src/evdev-mt-touchpad-buttons.c b/src/evdev-mt-touchpad-buttons.c
index 895cf0e..ffb6a58 100644
--- a/src/evdev-mt-touchpad-buttons.c
+++ b/src/evdev-mt-touchpad-buttons.c
@@ -981,23 +981,24 @@ out:
  static uint32_t
  tp_clickfinger_set_button(struct tp_dispatch *tp)
  {
-   uint32_t button;
+   bool thumb_detected = false;
unsigned int nfingers = tp->nfingers_down;
struct tp_touch *t;
struct tp_touch *first = NULL,
*second = NULL;
  
-	if (nfingers != 2)

-   goto out;
+   if (nfingers < 2)
+   return BTN_LEFT;
  
-	/* two fingers down on the touchpad. Check for distance

-* between the fingers. */
tp_for_each_touch(tp, t) {
if (t->state != TOUCH_BEGIN && t->state != TOUCH_UPDATE)
continue;
  
-		if (t->thumb.state == THUMB_STATE_YES)

+   if (t->thumb.state == THUMB_STATE_YES) {
+   thumb_detected = true;
+   nfingers--;
continue;
+   }
  
  		if (!first)

first = t;
@@ -1005,27 +1006,20 @@ tp_clickfinger_set_button(struct tp_dispatch *tp)
second = t;
}
  
-	if (!first || !second) {

-   nfingers = 1;
-   goto out;
-   }
+   if (nfingers < 2)
+   return BTN_LEFT;
+   else if (nfingers > 2)
+   return BTN_MIDDLE;
  
-	if (tp_clickfinger_within_distance(tp, first, second))

-   nfingers = 2;
+   /* Two fingers (not counting thumbs) are on the touchpad. If no
+* additional thumb was detected, we check the distance between the
+* touches. Some touchpads can not report more than two finger positions
+* so we do not check the distance if an additional thumb was detected.
+*/
+   if (thumb_detected || tp_clickfinger_within_distance(tp, first, second))
+   return BTN_RIGHT;
else
-   nfingers = 1;
-
-out:
-   switch (nfingers) {
-   case 0:
-   case 1: button = BTN_LEFT; break;
-   case 2: button = BTN_RIGHT; break;
-   default:
-   button = BTN_MIDDLE; break;
-   break;
-   }
-
-   return button;
+   return BTN_LEFT;
  }
  
  static int

--
2.9.4

___
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


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org

[PATCH weston 1/2 v2] clients: Allow simple-egl to use wl_surface_damage_buffer

2017-05-19 Thread Derek Foreman

wl_surface_damage_buffer landed ages ago, but in order for GL to
use it the client must bind a wl_compositor version >= 4 (the
version where damage_buffer was introduced).

This patch updates the bind version and allows
eglSwapBuffersWithDamage to actually use the provided damage
rectangles instead of performing full surface damage.

This log is much longer than the patch.

Signed-off-by: Derek Foreman 
---
 clients/simple-egl.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/clients/simple-egl.c b/clients/simple-egl.c
index c4f72a44..dad0f09b 100644
--- a/clients/simple-egl.c
+++ b/clients/simple-egl.c
@@ -797,7 +797,8 @@ registry_handle_global(void *data, struct wl_registry 
*registry,
if (strcmp(interface, "wl_compositor") == 0) {
d->compositor =
wl_registry_bind(registry, name,
-_compositor_interface, 1);
+_compositor_interface,
+MIN(version, 4));
} else if (strcmp(interface, "zxdg_shell_v6") == 0) {
d->shell = wl_registry_bind(registry, name,
_shell_v6_interface, 1);
-- 
2.11.0

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

[PATCH weston 2/2 v2] libweston: Allow compositor-wayland to use wl_surface_damage_buffer

2017-05-19 Thread Derek Foreman

wl_surface_damage_buffer landed ages ago, but in order for GL to
use it the client must bind a wl_compositor version >= 4 (the
version where damage_buffer was introduced).

This patch updates the bind version and allows
eglSwapBuffersWithDamage to actually use the provided damage
rectangles instead of performing full surface damage.

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

diff --git a/libweston/compositor-wayland.c b/libweston/compositor-wayland.c
index 14f2c8db..77a73689 100644
--- a/libweston/compositor-wayland.c
+++ b/libweston/compositor-wayland.c
@@ -2319,7 +2319,8 @@ registry_handle_global(void *data, struct wl_registry 
*registry, uint32_t name,
if (strcmp(interface, "wl_compositor") == 0) {
b->parent.compositor =
wl_registry_bind(registry, name,
-_compositor_interface, 1);
+_compositor_interface,
+MIN(version, 4));
} else if (strcmp(interface, "zxdg_shell_v6") == 0) {
b->parent.xdg_shell =
wl_registry_bind(registry, name,
-- 
2.11.0

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

Re: [PATCH weston 1/2] clients: Allow simple-egl to use wl_surface_damage_buffer

2017-05-19 Thread Derek Foreman


Oops, will repost these with a proper version test.

On 19/05/17 10:43 AM, Derek Foreman wrote:

wl_surface_damage_buffer landed ages ago, but in order for GL to
use it the client must bind a wl_compositor version >= 4 (the
version where damage_buffer was introduced).

This patch updates the bind version and allows
eglSwapBuffersWithDamage to actually use the provided damage
rectangles instead of performing full surface damage.

This log is much longer than the patch.

Signed-off-by: Derek Foreman 
---
 clients/simple-egl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/clients/simple-egl.c b/clients/simple-egl.c
index c4f72a44..b7dbaa40 100644
--- a/clients/simple-egl.c
+++ b/clients/simple-egl.c
@@ -797,7 +797,7 @@ registry_handle_global(void *data, struct wl_registry 
*registry,
if (strcmp(interface, "wl_compositor") == 0) {
d->compositor =
wl_registry_bind(registry, name,
-_compositor_interface, 1);
+_compositor_interface, 4);
} else if (strcmp(interface, "zxdg_shell_v6") == 0) {
d->shell = wl_registry_bind(registry, name,
_shell_v6_interface, 1);



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

[PATCH weston 2/2] libweston: Allow compositor-wayland to use wl_surface_damage_buffer

2017-05-19 Thread Derek Foreman

wl_surface_damage_buffer landed ages ago, but in order for GL to
use it the client must bind a wl_compositor version >= 4 (the
version where damage_buffer was introduced).

This patch updates the bind version and allows
eglSwapBuffersWithDamage to actually use the provided damage
rectangles instead of performing full surface damage.

Signed-off-by: Derek Foreman 
---
 libweston/compositor-wayland.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libweston/compositor-wayland.c b/libweston/compositor-wayland.c
index 14f2c8db..7fc07e42 100644
--- a/libweston/compositor-wayland.c
+++ b/libweston/compositor-wayland.c
@@ -2319,7 +2319,7 @@ registry_handle_global(void *data, struct wl_registry 
*registry, uint32_t name,
if (strcmp(interface, "wl_compositor") == 0) {
b->parent.compositor =
wl_registry_bind(registry, name,
-_compositor_interface, 1);
+_compositor_interface, 4);
} else if (strcmp(interface, "zxdg_shell_v6") == 0) {
b->parent.xdg_shell =
wl_registry_bind(registry, name,
-- 
2.11.0

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

[PATCH weston 1/2] clients: Allow simple-egl to use wl_surface_damage_buffer

2017-05-19 Thread Derek Foreman

wl_surface_damage_buffer landed ages ago, but in order for GL to
use it the client must bind a wl_compositor version >= 4 (the
version where damage_buffer was introduced).

This patch updates the bind version and allows
eglSwapBuffersWithDamage to actually use the provided damage
rectangles instead of performing full surface damage.

This log is much longer than the patch.

Signed-off-by: Derek Foreman 
---
 clients/simple-egl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/clients/simple-egl.c b/clients/simple-egl.c
index c4f72a44..b7dbaa40 100644
--- a/clients/simple-egl.c
+++ b/clients/simple-egl.c
@@ -797,7 +797,7 @@ registry_handle_global(void *data, struct wl_registry 
*registry,
if (strcmp(interface, "wl_compositor") == 0) {
d->compositor =
wl_registry_bind(registry, name,
-_compositor_interface, 1);
+_compositor_interface, 4);
} else if (strcmp(interface, "zxdg_shell_v6") == 0) {
d->shell = wl_registry_bind(registry, name,
_shell_v6_interface, 1);
-- 
2.11.0

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

Re: Return values in Wayland XML specification

2017-05-19 Thread Quentin Glidic


On 5/19/17 4:57 PM, adlo wrote:

Do any compositors support this protocol?


Any compositor based on libweston and capable of loading weston plugins 
(and later libweston plugins), using Weston Wall[1].
The implementation is limited (no workspaces support) but that is 
something fixable in the future (I have a few ideas on how to solve that 
while still sharing most of the code).


It was drafted to start porting rofi. For now, no other switcher 
developer commented on it, so all I can do is use it because it works 
for rofi and have rofi users happy with it.



Cheers,


--

Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Return values in Wayland XML specification

2017-05-19 Thread adlo

Do any compositors support this protocol?

Regards

adlo

> On 15 May 2017, at 14:27, Quentin Glidic  
> wrote:
> 
> On 5/15/17 3:13 PM, adlo wrote:
>>> On 15 May 2017, at 10:52, Quentin Glidic
>>>  wrote:
>>> If you are writing/porting a window switcher, please consider using
>>> Wayland Wall window-switcher protocol[1]. If you are not, please
>>> don’t, as this protocol is very specific to switchers (it has
>>> "switch_to" and "close" requests). If you need for more than this
>>> protocol offers, or something doesn’t fit your software, just fill
>>> an issue and we will discuss the possible designs.
>> Does your protocol have window thumbnails and damage events for these
>> thumbnails? How does your protocol compare to KDE's
>> org_kde_plasma_windowmanagement?
> 
> KDE protocol seems to be designed for window managers, not window
> switchers. My protocol does allow to display thumbnails, but everything
> is on the compositor side, the client just ask it to display them at a
> specific position of its own surface.
> 
> I believe KDE’s protocol is too complex for simple compositors to use it 
> easily.
> 
> Cheers,
> 
> -- 
> 
> Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: wl_output ambiguity, xdg_shell fullscreen refresh rate

2017-05-19 Thread Philipp Kerling

Am Dienstag, den 16.05.2017, 12:28 +0300 schrieb Pekka Paalanen:
> On Mon, 15 May 2017 17:31:57 +0200
> Philipp Kerling  wrote:
> 2017-05-15 (月) の 11:18 +0300 に Pekka Paalanen さんは書きました:
> > > On Sun, 14 May 2017 14:43:44 +0200
> > > Philipp Kerling  wrote:  
> > > > To start off:
> > > >  * Kodi should offer the user the opportunity to select inside
> > > > the
> > > >application on which monitor he/she wants to have Kodi
> > > > displayed
> > > > on
> > > >when in full-screen mode. Now I see that I can do this with
> > > > either
> > > >wl_shell_surface::set_fullscreen and
> > > > zxdg_toplevel::set_fullscreen,
> > > >which expect a wl_output to display the window on. But I am
> > > > not
> > > > sure
> > > >how I should match the wl_output instance I get from Wayland
> > > > with
> > > >the monitor that the user selected. As far as I can see, I
> > > > can
> > > > only
> > > >identify the monitor by way of "make" and "model". This
> > > > seems
> > > >reasonable enough at first glance, but I think that in
> > > > multi-
> > > > monitor 
> > > >configurations it is not so uncommon to buy the same monitor
> > > > model
> > > >multiple times - I personally have done this. Naturally, the
> > > > "make"
> > > >and "model" of both monitors are identical, so I cannot
> > > > discern
> > > >which is which by looking at the wl_output metadata. Am I
> > > > missing
> > > >something here?  
> > > 
> > > That is all true, you are not missing anything.
> > > 
> > > It is a missing piece of protocol - I believe no-one has had both
> > > the
> > > need and the time to work on getting anything better yet.
> > >   
> > > > Why isn't e.g. the connector the output is connected
> > > >to exported?  
> > > 
> > > Because connector names are specific to DRM while Wayland (core
> > > protocol at least) is not.  
> > 
> > I'm not sure I agree. See further below.
> > 
> > > Also, would you not want to identify the
> > > monitor rather than which connector it happens to be plugged
> > > in?   
> > 
> > I think that it's not quite decided yet what we want the user
> > experience to be on the Kodi side, i.e. do we want to bind output
> > to
> > the physical monitor (however it is identified) or the GPU
> > connector?
> > You can probably find use cases for both, so it's not an easy
> > decision
> > to make. With X11 it was limited to the latter, so my first
> > approach
> > was to mimic that. Ideally, both would be possible with Wayland and
> > the
> > application can decide what is best for its specific use case. I
> > realize that this might be too much to ask for all at once, so I'll
> > talk to my mentor to decide which case we want to focus on for
> > Kodi.
> > There are also two different points involved in this discussion:
> >I. How the *user* identifies which output/monitor the fullscreen
> >   display should be on (e.g. with make+model+connector name, or
> > by
> >   compositor-specific numbering).
> >   II. How *Kodi* or any other application then stores this, re-
> > identifies
> >   this output/monitor and maps it to a wl_output on application
> > start
> >   and hotplug. Possiblities include saving information
> > pertaining to
> >   the output, the connector, the physical device, or any
> > combination.
> 
> Hi,
> 
> very much agreed.
> 
> > > Would
> > > a user even know which connector name matches to which monitor?  
> > 
> > Yes, I also thought about this. Tech-savvy users might actually be
> > able
> > to identify the connector name, but you are absolutely right that
> > usually users should not be expected to. In fact, having make and
> > model
> > available actually is an improvement in that regard (on X11, Kodi
> > *only* displays connector since that is what's available via
> > RANDR).
> > So: How do you suggest to identify a particular monitor then? As I
> > said, make and model are not sufficient - but serial number will
> > not
> > help the user in identification. If there are multiple monitors of
> > the
> > same model, I do not think that they (i.e. the physical devices)
> > can be
> > reasonably discerned in a way that is transparent to the user.
> > That's
> > why I suggested the connector name.
> 
> One idea coming to mind is that in the DE's (compositor's) display
> configuration dialog, the user would be allowed to identify monitors
> by
> visual clues, and would be given the opportunity to give the monitors
> (or connectors!) custom names. An application could then show all the
> information plus the custom names so that the user can pick the one
> he
> wants.
What do you think makes more sense here - having the compositor provide
this information such as the custom names to the application which can
then display a selection box to the user (with the option to ask the
compositor to briefly display said information on all screens as
overlay), or having the compositor provide the

Re: [PATCH wayland-protocols v4] linux-dmabuf: add immediate dmabuf import path

2017-05-19 Thread Daniel Stone

Hey Varad,

On 12 May 2017 at 06:16, Varad Gautam  wrote:
> On Fri, Feb 10, 2017 at 1:28 PM, Varad Gautam  wrote:
>> provide a mechanism that allows clients to import the added dmabufs
>> and immediately use the newly created wl_buffers without waiting on
>> an event. this is useful to clients that are sure of their import
>> request succeeding, and wish to avoid the wl_buffer communication
>> roundtrip.
>>
>> bump zwp_linux_dmabuf_v1, zwp_linux_buffer_params_v1 interface
>> versions.
>>
>> v2: specify using incorrectly imported dmabufs as undefined behavior
>> instead of sending success/failure events. (pq, daniels)
>> v3: preserve the optional protocol error added in v2 and explicitly
>> state the outcome of import success or failure (pq)
>> v4: clarify create_immed failure cases and error codes (pq)
>>
>> Signed-off-by: Varad Gautam 
>> Reviewed-by: Pekka Paalanen 
>> ---
>
> Could we get this merged into wayland-protocols, if there are no
> objections on the v4?

Er yeah, it's definitely been long enough. Pushed now, thanks!

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

[PATCH libinput] touchpad: fix clickfinger behavior with a thumb being present

Re: [PATCH libinput] touchpad: fix clickfinger behavior with a thumb being present

[PATCH weston 1/2 v2] clients: Allow simple-egl to use wl_surface_damage_buffer

[PATCH weston 2/2 v2] libweston: Allow compositor-wayland to use wl_surface_damage_buffer

Re: [PATCH weston 1/2] clients: Allow simple-egl to use wl_surface_damage_buffer

[PATCH weston 2/2] libweston: Allow compositor-wayland to use wl_surface_damage_buffer

[PATCH weston 1/2] clients: Allow simple-egl to use wl_surface_damage_buffer

Re: Return values in Wayland XML specification

Re: Return values in Wayland XML specification

Re: wl_output ambiguity, xdg_shell fullscreen refresh rate

Re: [PATCH wayland-protocols v4] linux-dmabuf: add immediate dmabuf import path

11 matches

Site Navigation

Mail list logo

Footer information