Re: T480s Trackpoint drifts

[Peter Hutterer]

On Thu, Mar 22, 2018 at 01:50:31PM +0800, Kai Hendry wrote:
> On Thu, 22 Mar 2018, at 12:15 PM, Peter Hutterer wrote:
> > right, sorry if that wasn't clear but changing the acceleration profile
> > won't change the drift you're seeing. Completely separate bug. What it does
> > change is the speed which you labeled as "a bit too fast" in the first
> > email.
> 
> Oh, so what can I do at this point to disable my drifting trackpoint but
> still have the buttons working?

there's nothing ready-made. the solution would be to figure out the kernel
knobs and whatever else is there to fix the HW problem that we have here.
And/or hack up some custom version of libinput that ignores motion events
from that device. But something off-the-shelf - nothing, sorry.

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

Re: T480s Trackpoint drifts

[Kai Hendry]

On Thu, 22 Mar 2018, at 12:15 PM, Peter Hutterer wrote:
> right, sorry if that wasn't clear but changing the acceleration profile
> won't change the drift you're seeing. Completely separate bug. What it does
> change is the speed which you labeled as "a bit too fast" in the first
> email.

Oh, so what can I do at this point to disable my drifting trackpoint but still 
have the buttons working?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH v3] xwm: Choose icon closest to target size

[Scott Moreau]

Xwayland clients can offer multiple icon sizes in no particular order.
Previously xwm was selecting the first one unconditionally. This patch
selects the icon that matches the size closest to the target size. The
target size is hard coded to 16 since there is only one theme and the
data used to create the theme is hard coded.
---

Changed in v2:

- Fix typo setting width to height

Changed in v3:

- Move checks for malformed input into data handling function

 xwayland/window-manager.c | 74 ++-
 1 file changed, 67 insertions(+), 7 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index c307e19..30c4b1c 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1352,6 +1352,70 @@ weston_wm_window_schedule_repaint(struct 
weston_wm_window *window)
   weston_wm_window_do_repaint, window);
 }
 
+static uint32_t *
+get_icon_size_from_data(int target_width, int target_height,
+   uint32_t *width, uint32_t 
*height,
+   uint32_t length, uint32_t *data)
+{
+   uint32_t *d = data, **img = NULL, *ret = NULL, w, h;
+   int num_sizes = 0, *sizes = NULL, a1, a2, a3;
+
+   *width = *height = 0;
+
+   while (d - data < length / 4) {
+   w = *d++;
+   h = *d++;
+
+   /* Some checks against malformed input. */
+   if (w == 0 || h == 0 || length < 2 + w * h) {
+   free(sizes);
+   free(img);
+   return NULL;
+   }
+
+   sizes = realloc(sizes, 2 * (num_sizes + 1) * sizeof(uint32_t));
+   if (!sizes) {
+   free(img);
+   return NULL;
+   }
+
+   img = realloc(img, (num_sizes + 1) * sizeof(uint32_t *));
+   if (!img) {
+   free(sizes);
+   return NULL;
+   }
+
+   sizes[(num_sizes * 2) + 0] = w;
+   sizes[(num_sizes * 2) + 1] = h;
+   img[num_sizes] = d;
+
+   num_sizes++;
+   d += w * h;
+   }
+
+   /* Choose closest match by comparing icon dimension areas */
+   a1 = target_width * target_height;
+
+   while (num_sizes--) {
+   w = sizes[(num_sizes * 2) + 0];
+   h = sizes[(num_sizes * 2) + 1];
+
+   a2 = w * h;
+   a3 = *width * *height;
+
+   if (a2 != a3 && abs(a2 - a1) < abs(a3 - a1)) {
+   *width = w;
+   *height = h;
+   ret = img[num_sizes];
+   }
+   }
+
+   free(sizes);
+   free(img);
+
+   return ret;
+}
+
 static void
 weston_wm_handle_icon(struct weston_wm *wm, struct weston_wm_window *window)
 {
@@ -1361,9 +1425,6 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
uint32_t *data, width, height;
cairo_surface_t *new_surface;
 
-   /* TODO: icons don’t have any specified order, we should pick the
-* closest one to the target dimension instead of the first one. */
-
cookie = xcb_get_property(wm->conn, 0, window->id,
  wm->atom.net_wm_icon, XCB_ATOM_ANY, 0,
  UINT32_MAX);
@@ -1375,11 +1436,10 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
return;
 
data = xcb_get_property_value(reply);
-   width = *data++;
-   height = *data++;
 
-   /* Some checks against malformed input. */
-   if (width == 0 || height == 0 || length < 2 + width * height)
+   data = get_icon_size_from_data(16, 16, , , length, data);
+
+   if (!data)
return;
 
new_surface =
-- 
2.7.4

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

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

[Peter Hutterer]

On Mon, Mar 19, 2018 at 04:59:15AM +0900, Eike Hein wrote:
> 
> >> 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 clients
> > would need to decorate themselves at all is to give the user some visual
> > cues for their true purpose: window management. We should just say this.
> > I prefer my previous wording:
> >
> >> If the client chooses not to use server-side decorations, it is
> >> responsible for its own window management operations.
> Up-front: I could live with that one if need be.
> 
> ... but I think it's sort of inviting some trouble again. "Window
> management operations" gets us - albeit in a much less specific way,
> which is a big improvement - back into the territory of defining
> "decoration". The use of "responsible" also creates an expectation that
> a client will cater to window management in some way, which some clients
> have shown a preference for not doing. I think my version captures
> reality in a better way without holding anyone to new requirements that
> didn't exist before today.
>
> The spirit of my para was two communicate two things:
> 
> * This is an optional additional negotiation that takes place between
> server and client that allows them to agree on the client being
> server-decorated.
> 
> That means servers who don't care are unaffected and clients which don't
> care are unaffected, which is what we want because we can't universally
> agree on any specific case, but we can agree that Wayland should let us
> all build the systems we envision. What it does allow is for components
> that do agree to work together, which is a big step in the right direction.
> 
> * If this negotiation does not take place or does not have this result
> (server does not implement at all, preferred mode is client-side, client
> doesn't request server-side), clients are left to do whatever.
> 
> The wording of my second clause also implies - but does not enforce,
> since it has no mechanism to do this anyway - that if client and server
> agree on server-side decoration, a client should probably not decorate,
> which I think is good to have in there in spirit.

so, random thought: instead of talking about decorations or not (which isn't
what we really care about) talk about window management and who does it.
So you now name it xdg-toplevel-window-management and the two options you
get are
* self-managed: the client is expected to control window operations such as
  move, resize, minimize and maximize and closing windows. The exact
  approach is client-dependent, usually clients provided a window decoration
  bar with GUI elements to perform some of these tasks.
  Clients are not required to provide any or all above operations on all
  windows, they may provide window management operations not listed in
  the above enumeration, or they may not provide any graphical elements for
  these tasks.
* imposed: window operations such as move, resize, ... are imposed on the
  client by the compositor. The client should avoid rendering GUI elements
  for these operations, these should be provided by the compositor instead.

I think this covers the current case well enough (self-managed) and is
explicit enough about the SSD case and the expectations. Some wording
improvements may be needed.

Just as an extra note: the term "imposed" is chosen explicitly - once a
compositor says it's going to decorate the window, the client loses all
information about which operations are available to the user. In some
clients this may result in a detrimental user experience (e.g. if a maximise
button isn't there that the client really really expects). But such is life
under an imposing rule ;)

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

[PATCH v2] xwm: Choose icon closest to target size

[Scott Moreau]

Xwayland clients can offer multiple icon sizes in no particular order.
Previously xwm was selecting the first one unconditionally. This patch
selects the icon that matches the size closest to the target size. The
target size is hard coded to 16 since there is only one theme and the
data used to create the theme is hard coded.
---

Changed in v2:

- Fix typo setting width to height

 xwayland/window-manager.c | 66 ++-
 1 file changed, 60 insertions(+), 6 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index c307e19..327b4b9 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1352,6 +1352,63 @@ weston_wm_window_schedule_repaint(struct 
weston_wm_window *window)
   weston_wm_window_do_repaint, window);
 }
 
+static uint32_t *
+get_icon_size_from_data(int target_width, int target_height,
+   uint32_t *width, uint32_t 
*height,
+   uint32_t length, uint32_t *data)
+{
+   uint32_t *d = data, **img = NULL, *ret = NULL, w, h;
+   int num_sizes = 0, *sizes = NULL, a1, a2, a3;
+
+   *width = *height = 0;
+
+   while (d - data < length / 4) {
+   w = *d++;
+   h = *d++;
+
+   sizes = realloc(sizes, 2 * (num_sizes + 1) * sizeof(uint32_t));
+   if (!sizes) {
+   free(img);
+   return NULL;
+   }
+
+   img = realloc(img, (num_sizes + 1) * sizeof(uint32_t *));
+   if (!img) {
+   free(sizes);
+   return NULL;
+   }
+
+   sizes[(num_sizes * 2) + 0] = w;
+   sizes[(num_sizes * 2) + 1] = h;
+   img[num_sizes] = d;
+
+   num_sizes++;
+   d += w * h;
+   }
+
+   /* Choose closest match by comparing icon dimension areas */
+   a1 = target_width * target_height;
+
+   while (num_sizes--) {
+   w = sizes[(num_sizes * 2) + 0];
+   h = sizes[(num_sizes * 2) + 1];
+
+   a2 = w * h;
+   a3 = *width * *height;
+
+   if (a2 != a3 && abs(a2 - a1) < abs(a3 - a1)) {
+   *width = w;
+   *height = h;
+   ret = img[num_sizes];
+   }
+   }
+
+   free(sizes);
+   free(img);
+
+   return ret;
+}
+
 static void
 weston_wm_handle_icon(struct weston_wm *wm, struct weston_wm_window *window)
 {
@@ -1361,9 +1418,6 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
uint32_t *data, width, height;
cairo_surface_t *new_surface;
 
-   /* TODO: icons don’t have any specified order, we should pick the
-* closest one to the target dimension instead of the first one. */
-
cookie = xcb_get_property(wm->conn, 0, window->id,
  wm->atom.net_wm_icon, XCB_ATOM_ANY, 0,
  UINT32_MAX);
@@ -1375,11 +1429,11 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
return;
 
data = xcb_get_property_value(reply);
-   width = *data++;
-   height = *data++;
+
+   data = get_icon_size_from_data(16, 16, , , length, data);
 
/* Some checks against malformed input. */
-   if (width == 0 || height == 0 || length < 2 + width * height)
+   if (!data || width == 0 || height == 0 || length < 2 + width * height)
return;
 
new_surface =
-- 
2.7.4

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

Re: T480s Trackpoint drifts

[Peter Hutterer]

On Thu, Mar 22, 2018 at 12:04:12PM +0800, Kai Hendry wrote:
> On Thu, 22 Mar 2018, at 11:49 AM, Peter Hutterer wrote:
> > see the libinput documentation, it's a normalised value from -1.0 (slowest) 
> > to
> > 1.0 (fastest) with 0 being the usually-default midpoint.
> 
>  [hendry@t480s ~]$ xinput --set-prop 11 'libinput Accel Speed' -1
> 
> Has no impact to my drift problem. Not sure what else I can set. 

right, sorry if that wasn't clear but changing the acceleration profile
won't change the drift you're seeing. Completely separate bug. What it does
change is the speed which you labeled as "a bit too fast" in the first
email.

> "libinput Accel Speed Default" doesn't work.

the defaults are read-only property because that's all they are, defaults.

Cheers,
   Peter

> 
> [hendry@t480s ~]$ xinput --set-prop 11 'libinput Accel Default' -1
> property 'libinput Accel Default' doesn't exist, you need to specify its type 
> and format
> [hendry@t480s ~]$ xinput --list-props 11
> Device 'ETPS/2 Elantech TrackPoint':
> Device Enabled (140):   1
> Coordinate Transformation Matrix (142): 1.00, 0.00, 0.00, 
> 0.00, 1.00, 0.00, 0.00, 0.00, 1.00
> libinput Natural Scrolling Enabled (275):   0
> libinput Natural Scrolling Enabled Default (276):   0
> libinput Left Handed Enabled (277): 0
> libinput Left Handed Enabled Default (278): 0
> libinput Accel Speed (279): -1.00
> libinput Accel Speed Default (280): 0.00
> libinput Accel Profiles Available (281):1, 1
> libinput Accel Profile Enabled (282):   1, 0
> libinput Accel Profile Enabled Default (283):   1, 0
> libinput Scroll Methods Available (284):0, 0, 1
> libinput Scroll Method Enabled (285):   0, 0, 1
> libinput Scroll Method Enabled Default (286):   0, 0, 1
> libinput Button Scrolling Button (287): 2
> libinput Button Scrolling Button Default (288): 2
> libinput Middle Emulation Enabled (289):0
> libinput Middle Emulation Enabled Default (290):0
> libinput Send Events Modes Available (260): 1, 0
> libinput Send Events Mode Enabled (261):0, 0
> libinput Send Events Mode Enabled Default (262):0, 0
> Device Node (263):  "/dev/input/event7"
> Device Product ID (264):2, 14
> libinput Drag Lock Buttons (291):   
> libinput Horizontal Scroll Enabled (292):   1
> [hendry@t480s ~]$ xinput --set-prop 11 'libinput Accel Speed Default' -1
> X Error of failed request:  BadAccess (attempt to access private resource 
> denied)
>   Major opcode of failed request:  131 (XInputExtension)
>   Minor opcode of failed request:  57 ()
>   Serial number of failed request:  20
>   Current serial number in output stream:  21
> [hendry@t480s ~]$ sudo xinput --set-prop 11 'libinput Accel Speed Default' -1
> X Error of failed request:  BadAccess (attempt to access private resource 
> denied)
>   Major opcode of failed request:  131 (XInputExtension)
>   Minor opcode of failed request:  57 ()
>   Serial number of failed request:  20
>   Current serial number in output stream:  21
> [hendry@t480s ~]$
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: T480s Trackpoint drifts

[Kai Hendry]

On Thu, 22 Mar 2018, at 11:49 AM, Peter Hutterer wrote:
> see the libinput documentation, it's a normalised value from -1.0 (slowest) to
> 1.0 (fastest) with 0 being the usually-default midpoint.

 [hendry@t480s ~]$ xinput --set-prop 11 'libinput Accel Speed' -1

Has no impact to my drift problem. Not sure what else I can set.  "libinput 
Accel Speed Default" doesn't work.

[hendry@t480s ~]$ xinput --set-prop 11 'libinput Accel Default' -1
property 'libinput Accel Default' doesn't exist, you need to specify its type 
and format
[hendry@t480s ~]$ xinput --list-props 11
Device 'ETPS/2 Elantech TrackPoint':
Device Enabled (140):   1
Coordinate Transformation Matrix (142): 1.00, 0.00, 0.00, 
0.00, 1.00, 0.00, 0.00, 0.00, 1.00
libinput Natural Scrolling Enabled (275):   0
libinput Natural Scrolling Enabled Default (276):   0
libinput Left Handed Enabled (277): 0
libinput Left Handed Enabled Default (278): 0
libinput Accel Speed (279): -1.00
libinput Accel Speed Default (280): 0.00
libinput Accel Profiles Available (281):1, 1
libinput Accel Profile Enabled (282):   1, 0
libinput Accel Profile Enabled Default (283):   1, 0
libinput Scroll Methods Available (284):0, 0, 1
libinput Scroll Method Enabled (285):   0, 0, 1
libinput Scroll Method Enabled Default (286):   0, 0, 1
libinput Button Scrolling Button (287): 2
libinput Button Scrolling Button Default (288): 2
libinput Middle Emulation Enabled (289):0
libinput Middle Emulation Enabled Default (290):0
libinput Send Events Modes Available (260): 1, 0
libinput Send Events Mode Enabled (261):0, 0
libinput Send Events Mode Enabled Default (262):0, 0
Device Node (263):  "/dev/input/event7"
Device Product ID (264):2, 14
libinput Drag Lock Buttons (291):   
libinput Horizontal Scroll Enabled (292):   1
[hendry@t480s ~]$ xinput --set-prop 11 'libinput Accel Speed Default' -1
X Error of failed request:  BadAccess (attempt to access private resource 
denied)
  Major opcode of failed request:  131 (XInputExtension)
  Minor opcode of failed request:  57 ()
  Serial number of failed request:  20
  Current serial number in output stream:  21
[hendry@t480s ~]$ sudo xinput --set-prop 11 'libinput Accel Speed Default' -1
X Error of failed request:  BadAccess (attempt to access private resource 
denied)
  Major opcode of failed request:  131 (XInputExtension)
  Minor opcode of failed request:  57 ()
  Serial number of failed request:  20
  Current serial number in output stream:  21
[hendry@t480s ~]$
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: T480s Trackpoint drifts

[Peter Hutterer]

On Thu, Mar 22, 2018 at 11:36:55AM +0800, Kai Hendry wrote:
> Well I never installed gnome/kde to begin with.
> 
> On Thu, 22 Mar 2018, at 11:24 AM, Peter Hutterer wrote:
> > don't get me wrong but - if you're capable of removing gnome/kde for
> > whatever reasons, you're capable of figuring out xinput. there are plenty of
> > guides on google, some of which are even accurate.
> 
> The thing that puzzles me here is:
> 
> [hendry@t480s ~]$ xinput --list-props 11
> Device 'ETPS/2 Elantech TrackPoint':
> Device Enabled (140):   1
> Coordinate Transformation Matrix (142): 1.00, 0.00, 0.00, 
> 0.00, 1.00, 0.00, 0.00, 0.00, 1.00
> libinput Natural Scrolling Enabled (275):   0
> libinput Natural Scrolling Enabled Default (276):   0
> libinput Left Handed Enabled (277): 0
> libinput Left Handed Enabled Default (278): 0
> libinput Accel Speed (279): 0.00
> libinput Accel Speed Default (280): 0.00
> libinput Accel Profiles Available (281):1, 1
> libinput Accel Profile Enabled (282):   1, 0
> libinput Accel Profile Enabled Default (283):   1, 0
> libinput Scroll Methods Available (284):0, 0, 1
> libinput Scroll Method Enabled (285):   0, 0, 1
> libinput Scroll Method Enabled Default (286):   0, 0, 1
> libinput Button Scrolling Button (287): 2
> libinput Button Scrolling Button Default (288): 2
> libinput Middle Emulation Enabled (289):0
> libinput Middle Emulation Enabled Default (290):0
> libinput Send Events Modes Available (260): 1, 0
> libinput Send Events Mode Enabled (261):0, 0
> libinput Send Events Mode Enabled Default (262):0, 0
> Device Node (263):  "/dev/input/event7"
> Device Product ID (264):2, 14
> libinput Drag Lock Buttons (291):   
> libinput Horizontal Scroll Enabled (292):   1
> [hendry@t480s ~]$ uname -a
> Linux t480s 4.15.9-1-ARCH #1 SMP PREEMPT Sun Mar 11 17:54:33 UTC 2018 x86_64 
> GNU/Linux
> 
> For example IIUC the  Accel Speed is already zero. So what on earth do I 
> change it to?

see the libinput documentation, it's a normalised value from -1.0 (slowest) to
1.0 (fastest) with 0 being the usually-default midpoint.

Cheers,
   Peter

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

Re: T480s Trackpoint drifts

[Kai Hendry]

Well I never installed gnome/kde to begin with.

On Thu, 22 Mar 2018, at 11:24 AM, Peter Hutterer wrote:
> don't get me wrong but - if you're capable of removing gnome/kde for
> whatever reasons, you're capable of figuring out xinput. there are plenty of
> guides on google, some of which are even accurate.

The thing that puzzles me here is:

[hendry@t480s ~]$ xinput --list-props 11
Device 'ETPS/2 Elantech TrackPoint':
Device Enabled (140):   1
Coordinate Transformation Matrix (142): 1.00, 0.00, 0.00, 
0.00, 1.00, 0.00, 0.00, 0.00, 1.00
libinput Natural Scrolling Enabled (275):   0
libinput Natural Scrolling Enabled Default (276):   0
libinput Left Handed Enabled (277): 0
libinput Left Handed Enabled Default (278): 0
libinput Accel Speed (279): 0.00
libinput Accel Speed Default (280): 0.00
libinput Accel Profiles Available (281):1, 1
libinput Accel Profile Enabled (282):   1, 0
libinput Accel Profile Enabled Default (283):   1, 0
libinput Scroll Methods Available (284):0, 0, 1
libinput Scroll Method Enabled (285):   0, 0, 1
libinput Scroll Method Enabled Default (286):   0, 0, 1
libinput Button Scrolling Button (287): 2
libinput Button Scrolling Button Default (288): 2
libinput Middle Emulation Enabled (289):0
libinput Middle Emulation Enabled Default (290):0
libinput Send Events Modes Available (260): 1, 0
libinput Send Events Mode Enabled (261):0, 0
libinput Send Events Mode Enabled Default (262):0, 0
Device Node (263):  "/dev/input/event7"
Device Product ID (264):2, 14
libinput Drag Lock Buttons (291):   
libinput Horizontal Scroll Enabled (292):   1
[hendry@t480s ~]$ uname -a
Linux t480s 4.15.9-1-ARCH #1 SMP PREEMPT Sun Mar 11 17:54:33 UTC 2018 x86_64 
GNU/Linux

For example IIUC the  Accel Speed is already zero. So what on earth do I change 
it to?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: T480s Trackpoint drifts

[Peter Hutterer]

On Thu, Mar 22, 2018 at 09:46:59AM +0800, Kai Hendry wrote:
> Thank you Peter for the pointers!
> 
> On Wed, 21 Mar 2018, at 12:25 PM, Peter Hutterer wrote:
> > yeah, that's a built-in trackpoint feature that we don't have control over.
> 
> drat
> 
> > pieces with google. drift_time is probably the key here, maybe resetafter or
> > resync_time. At some point I had a pdf somewhere that described some of
> > these but, ...
> 
> https://s.natalian.org/2018-03-22/Elantech-TrackPoint.txt
> 
> Well, I'm doing random stuff like `[root@t480s device]# echo 5 >
> resync_time` since I have no idea what I am doing and It's not helping..

ah, crap, I just realised: I'm not sure that device is really working yet,
you'll likely need the latest kernels. Lenovo decided to mess with us again,
so the whole *80 series is a bit of a mess. I don't even know if that
trackpoint exposes the various hooks, and if so, if they work or do
anything.

> > > How do I do that? xinput?
> > use the gnome control center to change the pointer speed. or yeah, the
> > libinput Accel Speed property, set it to -1 and you'll have tar galore.
> 
> https://s.natalian.org/2018-03-22/xinput.png
> Sorry, I'm not a Gnome user. I one of those suckless linux users (lusers)
> who try to remove every gnome or kde app on their machine. Is there no cli
> tool I can effectively jam my trackpoint with?

don't get me wrong but - if you're capable of removing gnome/kde for
whatever reasons, you're capable of figuring out xinput. there are plenty of
guides on google, some of which are even accurate.

> > https://wayland.freedesktop.org/libinput/doc/latest/trackpoints.html matters
> > too
> 
> It doesn't seem to account for the Y access. In my case here:
> https://s.natalian.org/2018-03-21/libinput.txt X axis is probably 25? and
> y is .. er.. 13? So how would LIBINPUT_ATTR_TRACKPOINT_RANGE look?

start with 25 and see how you go.

Cheers,
   Peter

> 
> That hwdb configuration syntax looks a bit daunting.
> 
> Kind regards,
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 1/2] xwm: Choose icon closest to target size

[Scott Moreau]

Xwayland clients can offer multiple icon sizes in no particular order.
Previously xwm was selecting the first one unconditionally. This patch
selects the icon that matches the size closest to the target size. The
target size is hard coded to 16 since there is only one theme and the
data used to create the theme is hard coded.
---
 xwayland/window-manager.c | 66 ++-
 1 file changed, 60 insertions(+), 6 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index c307e19..8b7d2f6 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1352,6 +1352,63 @@ weston_wm_window_schedule_repaint(struct 
weston_wm_window *window)
   weston_wm_window_do_repaint, window);
 }
 
+static uint32_t *
+get_icon_size_from_data(int target_width, int target_height,
+   uint32_t *width, uint32_t 
*height,
+   uint32_t length, uint32_t *data)
+{
+   uint32_t *d = data, **img = NULL, *ret = NULL, w, h;
+   int num_sizes = 0, *sizes = NULL, a1, a2, a3;
+
+   *width = *height = 0;
+
+   while (d - data < length / 4) {
+   w = *d++;
+   h = *d++;
+
+   sizes = realloc(sizes, 2 * (num_sizes + 1) * sizeof(uint32_t));
+   if (!sizes) {
+   free(img);
+   return NULL;
+   }
+
+   img = realloc(img, (num_sizes + 1) * sizeof(uint32_t *));
+   if (!img) {
+   free(sizes);
+   return NULL;
+   }
+
+   sizes[(num_sizes * 2) + 0] = w;
+   sizes[(num_sizes * 2) + 1] = h;
+   img[num_sizes] = d;
+
+   num_sizes++;
+   d += w * h;
+   }
+
+   /* Choose closest match by comparing icon dimension areas */
+   a1 = target_width * target_height;
+
+   while (num_sizes--) {
+   w = sizes[(num_sizes * 2) + 0];
+   h = sizes[(num_sizes * 2) + 1];
+
+   a2 = w * h;
+   a3 = *width * *height;
+
+   if (a2 != a3 && abs(a2 - a1) < abs(a3 - a1)) {
+   *width = w;
+   *height = w;
+   ret = img[num_sizes];
+   }
+   }
+
+   free(sizes);
+   free(img);
+
+   return ret;
+}
+
 static void
 weston_wm_handle_icon(struct weston_wm *wm, struct weston_wm_window *window)
 {
@@ -1361,9 +1418,6 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
uint32_t *data, width, height;
cairo_surface_t *new_surface;
 
-   /* TODO: icons don’t have any specified order, we should pick the
-* closest one to the target dimension instead of the first one. */
-
cookie = xcb_get_property(wm->conn, 0, window->id,
  wm->atom.net_wm_icon, XCB_ATOM_ANY, 0,
  UINT32_MAX);
@@ -1375,11 +1429,11 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
return;
 
data = xcb_get_property_value(reply);
-   width = *data++;
-   height = *data++;
+
+   data = get_icon_size_from_data(16, 16, , , length, data);
 
/* Some checks against malformed input. */
-   if (width == 0 || height == 0 || length < 2 + width * height)
+   if (!data || width == 0 || height == 0 || length < 2 + width * height)
return;
 
new_surface =
-- 
2.7.4

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

[PATCH 2/2] xwm: Scale icon if size is not the target size

[Scott Moreau]

This scales the icon cairo surface for the titlebar if it isn't the
right size.

shared/cairo-util: Add surface resizing function to be used for this
case and other potential cases.
---
 shared/cairo-util.c   | 61 +++
 shared/cairo-util.h   |  4 
 xwayland/window-manager.c |  9 ++-
 3 files changed, 73 insertions(+), 1 deletion(-)

diff --git a/shared/cairo-util.c b/shared/cairo-util.c
index d71e0ed..b91b5bc 100644
--- a/shared/cairo-util.c
+++ b/shared/cairo-util.c
@@ -142,6 +142,67 @@ blur_surface(cairo_surface_t *surface, int margin)
return 0;
 }
 
+static cairo_surface_t *
+scale_surface(cairo_surface_t *source, cairo_filter_t filter,
+   double width, double 
height)
+{
+   cairo_surface_t *dest;
+   cairo_t *cr;
+   int old_width, old_height;
+
+   old_width = cairo_image_surface_get_width(source);
+   old_height = cairo_image_surface_get_height(source);
+
+   dest = cairo_surface_create_similar(source, CAIRO_CONTENT_COLOR_ALPHA,
+   width, height);
+   cr = cairo_create (dest);
+
+   cairo_scale (cr, width / old_width, height / old_height);
+   cairo_set_source_surface (cr, source, 0, 0);
+
+   cairo_pattern_set_extend (cairo_get_source(cr), CAIRO_EXTEND_REFLECT);
+
+   cairo_set_operator (cr, CAIRO_OPERATOR_SOURCE);
+
+   cairo_paint (cr);
+
+   cairo_destroy (cr);
+
+   cairo_surface_destroy(source);
+
+   return dest;
+}
+
+cairo_surface_t *
+cairo_resize_surface(cairo_surface_t *source, cairo_filter_t filter,
+   int width, int height)
+{
+   if (!filter)
+   filter = CAIRO_FILTER_BEST;
+
+   while((cairo_image_surface_get_width(source) / 2.0f) > width)
+   source = scale_surface(source, filter,
+   cairo_image_surface_get_width(source) / 2.0f,
+   cairo_image_surface_get_height(source));
+
+   while((cairo_image_surface_get_height(source) / 2.0f) > height)
+   source = scale_surface(source, filter,
+   cairo_image_surface_get_width(source),
+   cairo_image_surface_get_height(source) / 2.0f);
+
+   while((cairo_image_surface_get_width(source) * 2.0f) < width)
+   source = scale_surface(source, filter,
+   cairo_image_surface_get_width(source) * 2.0f,
+   cairo_image_surface_get_height(source));
+
+   while((cairo_image_surface_get_height(source) * 2.0f) < height)
+   source = scale_surface(source, filter,
+   cairo_image_surface_get_width(source),
+   cairo_image_surface_get_height(source) * 2.0f);
+
+   return scale_surface(source, filter, width, height);
+}
+
 void
 render_shadow(cairo_t *cr, cairo_surface_t *surface,
  int x, int y, int width, int height, int margin, int top_margin)
diff --git a/shared/cairo-util.h b/shared/cairo-util.h
index 6fd11f6..3bd2b0c 100644
--- a/shared/cairo-util.h
+++ b/shared/cairo-util.h
@@ -49,6 +49,10 @@ rounded_rect(cairo_t *cr, int x0, int y0, int x1, int y1, 
int radius);
 cairo_surface_t *
 load_cairo_surface(const char *filename);
 
+cairo_surface_t *
+cairo_resize_surface(cairo_surface_t *source, cairo_filter_t filter,
+   int width, int height);
+
 struct theme {
cairo_surface_t *active_frame;
cairo_surface_t *inactive_frame;
diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 8b7d2f6..741fa1e 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -1409,6 +1409,7 @@ get_icon_size_from_data(int target_width, int 
target_height,
return ret;
 }
 
+#define ICON_SIZE 16
 static void
 weston_wm_handle_icon(struct weston_wm *wm, struct weston_wm_window *window)
 {
@@ -1430,7 +1431,8 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
 
data = xcb_get_property_value(reply);
 
-   data = get_icon_size_from_data(16, 16, , , length, data);
+   data = get_icon_size_from_data(ICON_SIZE, ICON_SIZE,
+   , 
, length, data);
 
/* Some checks against malformed input. */
if (!data || width == 0 || height == 0 || length < 2 + width * height)
@@ -1447,11 +1449,16 @@ weston_wm_handle_icon(struct weston_wm *wm, struct 
weston_wm_window *window)
return;
}
 
+   if (width != ICON_SIZE || height != ICON_SIZE)
+   new_surface =
+   cairo_resize_surface(new_surface, 0, ICON_SIZE, 
ICON_SIZE);
+
if (window->frame)
frame_set_icon(window->frame, new_surface);
  

Re: T480s Trackpoint drifts

[Kai Hendry]

Thank you Peter for the pointers!

On Wed, 21 Mar 2018, at 12:25 PM, Peter Hutterer wrote:
> yeah, that's a built-in trackpoint feature that we don't have control over.

drat

> pieces with google. drift_time is probably the key here, maybe resetafter or
> resync_time. At some point I had a pdf somewhere that described some of
> these but, ...

https://s.natalian.org/2018-03-22/Elantech-TrackPoint.txt

Well, I'm doing random stuff like `[root@t480s device]# echo 5 > resync_time` 
since I have no idea what I am doing and It's not helping..

> > How do I do that? xinput?
> use the gnome control center to change the pointer speed. or yeah, the
> libinput Accel Speed property, set it to -1 and you'll have tar galore.

https://s.natalian.org/2018-03-22/xinput.png
Sorry, I'm not a Gnome user. I one of those suckless linux users (lusers) who 
try to remove every gnome or kde app on their machine. Is there no cli tool I 
can effectively jam my trackpoint with?

> https://wayland.freedesktop.org/libinput/doc/latest/trackpoints.html matters
> too

It doesn't seem to account for the Y access. In my case here: 
https://s.natalian.org/2018-03-21/libinput.txt X axis is probably 25? and y is 
.. er.. 13? So how would LIBINPUT_ATTR_TRACKPOINT_RANGE look?

That hwdb configuration syntax looks a bit daunting.

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

2018 Election voting OPEN

[Rob Clark]

To all X.Org Foundation Members:

The X.Org Foundation's annual election is now open and will remain
open until 23:59 UTC on 5 April 2018.

Four of the eight director seats are open during this election, with
the four nominees receiving the highest vote totals serving as
directors for two year terms.

There were six candidates nominated. For a complete list of the
candidates and their personal statements, please see the following:

  https://www.x.org/wiki/BoardOfDirectors/Elections/2018/

Here are some instructions on how to cast your vote:

Login to the membership system at: https://members.x.org/

If you do not remember your password, you can click on the "lost
password" button and enter your user name. An e-mail will be sent to
you with your password. If you have problems with the membership
system, please e-mail members...@x.org.

When you login you will see a row of buttons that will allow you to
update your info, list the members, list the open ballots and logout.
Below this you will see a list of open ballots, for which you can cast
votes. At the bottom of this page you will see another row of buttons
with the current privacy policy, the provisional By-laws, the
provisional Membership Agreement and instructions on how to contact
the admin.

Note that if you click on the "Ballots" button at any time, you will
see a list of the open ballots.

To cast your vote in a ballot, click on the "Cast" button to the right
of the ballot you wish to vote on. This will bring up another page
with the list of the candidates, and a question of whether or not to
approve the new By-laws.

For the election: There is a pull-down selection box next to each
candidate. For your top choice, select "1". For your second choice,
select "2" and so forth. You should think of the numbers that you are
selecting as the ranking of your preferences.

Note that you are NOT required to select your preferences for all four
positions. You can leave more than one blank. The only restriction is
that you cannot duplicate any of your choices (i.e., you can only
select one "1", one "2" and so forth).

After you have completed your ballot, click the "Vote" button. Note
that once you click this button, your votes will be cast and you will
not be able to make further changes, so please make sure you are
satisfied with your votes before clicking the "Vote" button.

After you click the "Vote" button, the system will verify that you
have completed a valid ballot. If your ballot is invalid (e.g., you
duplicated a selection), it will return you to the previous voting
page. If your ballot is valid, your votes will be recorded and the
system will show you a notice that your votes were cast.

Note that the election will close at 23:59 UTC on 5 April 2018. At
that time, the election committee will count the votes and present the
results to the current board for validation. After the current board
validates the results, the election committee will present the results
to the Members.

Rob Clark,
on behalf of the X.Org elections committee
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[prefix=PATCH weston] gl-renderer.c: Pass visual ID for choosing egl configs for pbuffer

[Madhurkiran Harikrishnan]

The original implementation always chose first egl config for pbuffer
surface type, however the returned configs are implementation specific
and egl config may not always match between ctx and surface. Hence,
pass the visual_id to find the correct egl config.

Signed-off-by: Madhurkiran Harikrishnan 
---
 libweston/gl-renderer.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c
index b67c8e2..c387367 100644
--- a/libweston/gl-renderer.c
+++ b/libweston/gl-renderer.c
@@ -3145,7 +3145,7 @@ output_handle_destroy(struct wl_listener *listener, void 
*data)
 }

 static int
-gl_renderer_create_pbuffer_surface(struct gl_renderer *gr) {
+gl_renderer_create_pbuffer_surface(struct gl_renderer *gr, const EGLint 
*visual_id, int n_ids) {
EGLConfig pbuffer_config;

static const EGLint pbuffer_config_attribs[] = {
@@ -3164,11 +3164,19 @@ gl_renderer_create_pbuffer_surface(struct gl_renderer 
*gr) {
EGL_NONE
};

-   if (egl_choose_config(gr, pbuffer_config_attribs, NULL, 0, 
_config) < 0) {
+   if (egl_choose_config(gr, pbuffer_config_attribs, visual_id, n_ids, 
_config) < 0) {
weston_log("failed to choose EGL config for PbufferSurface\n");
return -1;
}

+   if (pbuffer_config != gr->egl_config &&
+   !gr->has_configless_context) {
+   weston_log("attempted to use a different EGL config for an "
+  "output but EGL_KHR_no_config_context or "
+  "EGL_MESA_configless_context is not supported\n");
+   return -1;
+   }
+
gr->dummy_surface = eglCreatePbufferSurface(gr->egl_display,
pbuffer_config,
pbuffer_attribs);
@@ -3277,7 +3285,7 @@ gl_renderer_display_create(struct weston_compositor *ec, 
EGLenum platform,
weston_log("EGL_KHR_surfaceless_context unavailable. "
   "Trying PbufferSurface\n");

-   if (gl_renderer_create_pbuffer_surface(gr) < 0)
+   if (gl_renderer_create_pbuffer_surface(gr, visual_id, n_ids) < 
0)
goto fail_with_error;
}

--
2.7.4

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston 0/2 v4] DRM lease support

[Marius Vlad]

Patch series that adds support for DRM leases.

DRM leases is a method developed by Keith Packard to allow other application 
manage the output of a display/VR, while a DRM master is already owning
the outputs resources. A more thorough explanation and terminology can
be found at [1]. libdrm [2] and kernel [3] have already gained support.

Protocol support can be found at [4].

Initially this was a single patch but decided to split into series to
accommodate a demo client as well.

Changes since v3:
- rename lease with leasable to avoid confusion (Philipp Zabel)
- added client protocol headers / protocol to BUILD_SOURCES otherwise the
client example can't be built due to missing client headers

Changes since v2:
- rebased as drm_output_disable() has been changed due to atomic changes
- deferring the lease when the output can't be disabled due to a pending 
flip
- client blocks until it receives a 'created'/'failed' event when
deferring the lease.
- fix a potential NULL pointer if failing to get an encoder in the client
- provide correct link to protocol
- use lessee_id instead of lease_id as per libdrm/kernel terminology

Changes since v1:
- accommodate changes due to protocol changes
- use enable/disabled for the output instead of destroy/update_outputs (Daniel 
Stone)
- split into a series, added a client example
- forcing a repaint when giving the lease and not doing a modeset if the output
has been leased avoids blank switching between the lesor and lessee

[1] https://keithp.com/blogs/DRM-lease/
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.15-rc9=62884cd386b876638720ef88374b31a84ca7ee5f
[3] 
https://cgit.freedesktop.org/mesa/drm/commit/?id=c4171535389d72e9135c9615cecd07b346fd6d7e
[4] 
https://lists.freedesktop.org/archives/wayland-devel/2018-February/036947.html


Marius Vlad (2):
  compositor-drm: Add support for DRM lease
  clients/simple-egl-lease: A demo client for DRM leases

 Makefile.am|  15 +
 clients/simple-egl-lease.c | 887 +
 clients/simple-egl-lease.h |  99 +
 compositor/main.c  |  11 +
 configure.ac   |  21 ++
 libweston/compositor-drm.c | 272 ++
 libweston/compositor.c |   1 +
 libweston/compositor.h |   2 +
 8 files changed, 1308 insertions(+)
 create mode 100644 clients/simple-egl-lease.c
 create mode 100644 clients/simple-egl-lease.h

-- 
2.9.3

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

[PATCH weston 1/2 v4] compositor-drm: Add support for DRM lease

[Marius Vlad]

Signed-off-by: Marius Vlad 
---
 Makefile.am|   4 +
 compositor/main.c  |  11 ++
 configure.ac   |   4 +
 libweston/compositor-drm.c | 272 +
 libweston/compositor.c |   1 +
 libweston/compositor.h |   2 +
 6 files changed, 294 insertions(+)

diff --git a/Makefile.am b/Makefile.am
index 69ca6cb..9c53a6b 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -163,6 +163,8 @@ nodist_libweston_@LIBWESTON_MAJOR@_la_SOURCES = 
\
protocol/viewporter-server-protocol.h   \
protocol/linux-dmabuf-unstable-v1-protocol.c\
protocol/linux-dmabuf-unstable-v1-server-protocol.h \
+   protocol/drm-lease-unstable-v1-protocol.c   \
+   protocol/drm-lease-unstable-v1-server-protocol.h\
protocol/relative-pointer-unstable-v1-protocol.c\
protocol/relative-pointer-unstable-v1-server-protocol.h \
protocol/pointer-constraints-unstable-v1-protocol.c \
@@ -888,6 +890,8 @@ BUILT_SOURCES +=\
protocol/ivi-application-client-protocol.h  \
protocol/linux-dmabuf-unstable-v1-protocol.c\
protocol/linux-dmabuf-unstable-v1-client-protocol.h \
+   protocol/drm-lease-unstable-v1-protocol.c   \
+   protocol/drm-lease-unstable-v1-client-protocol.h\
protocol/input-timestamps-unstable-v1-protocol.c\
protocol/input-timestamps-unstable-v1-client-protocol.h
 
diff --git a/compositor/main.c b/compositor/main.c
index 1e82788..5ea15fc 100644
--- a/compositor/main.c
+++ b/compositor/main.c
@@ -1093,6 +1093,17 @@ drm_backend_output_configure(struct wl_listener 
*listener, void *data)
api->set_seat(output, seat);
free(seat);
 
+   char *lease;
+   weston_config_section_get_string(section, "lease", , "off");
+   if (!strncmp(lease, "on", 2)) {
+   output->leasable = true;
+#ifdef DEBUG
+   weston_log("Enabling lease on output %s\n", output->name);
+#endif
+   }
+   free(lease);
+
+
weston_output_enable(output);
 }
 
diff --git a/configure.ac b/configure.ac
index 1609ace..738f4a4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -212,6 +212,10 @@ if test x$enable_drm_compositor = xyes; then
   PKG_CHECK_MODULES(DRM_COMPOSITOR_GBM, [gbm >= 10.2],
[AC_DEFINE([HAVE_GBM_FD_IMPORT], 1, [gbm supports dmabuf 
import])],
[AC_MSG_WARN([gbm does not support dmabuf import, will omit 
that capability])])
+  PKG_CHECK_MODULES(DRM_LEASE, [libdrm >= 2.4.89],
+   [AC_DEFINE([HAVE_DRM_LEASE], 1, [libdrm support lease 
capability])],
+   [AC_MSG_WARN([libdrm doesn't have leases support, will omit 
that capability])])
+
 fi
 
 
diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
index 81ca67d..dc2d37f 100644
--- a/libweston/compositor-drm.c
+++ b/libweston/compositor-drm.c
@@ -62,6 +62,7 @@
 #include "presentation-time-server-protocol.h"
 #include "linux-dmabuf.h"
 #include "linux-dmabuf-unstable-v1-server-protocol.h"
+#include "drm-lease-unstable-v1-server-protocol.h"
 
 #ifndef DRM_CAP_TIMESTAMP_MONOTONIC
 #define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
@@ -269,6 +270,21 @@ struct drm_backend {
uint32_t pageflip_timeout;
 
bool shutting_down;
+   struct wl_list leases;
+};
+
+struct lease {
+   int leased_fd;
+   uint32_t lessee_id;
+
+   int nobjects;
+   int tnobjects;
+   uint32_t *objects;
+
+   struct drm_output *leased_output;
+   struct wl_resource *lease_resource;
+   struct drm_backend *drm_backend;
+   struct wl_list link;
 };
 
 struct drm_mode {
@@ -422,6 +438,7 @@ struct drm_output {
int destroy_pending;
int disable_pending;
int dpms_off_pending;
+   int lease_pending;
 
struct drm_fb *gbm_cursor_fb[2];
struct drm_plane *cursor_plane;
@@ -449,6 +466,8 @@ struct drm_output {
struct wl_listener recorder_frame_listener;
 
struct wl_event_source *pageflip_timer;
+
+   struct lease *lease;
 };
 
 static struct gl_renderer_interface *gl_renderer;
@@ -1383,6 +1402,36 @@ drm_pending_state_get_output(struct drm_pending_state 
*pending_state,
 
 static int drm_pending_state_apply_sync(struct drm_pending_state *state);
 
+#ifdef HAVE_DRM_LEASE
+static void
+drm_lease_clear_objects(struct lease *lease)
+{
+   memset(lease->objects, 0, sizeof(uint32_t) * lease->tnobjects);
+   lease->tnobjects = 0;
+}
+
+static void
+drm_output_send_lease(struct drm_output *output)
+{
+   struct lease *lease = output->lease;
+   struct wl_resource *resource = lease->lease_resource;
+   int drm_fd = lease->drm_backend->drm.fd;
+
+   lease->leased_fd = drmModeCreateLease(drm_fd, 

[PATCH weston 2/2 v4] clients/simple-egl-lease: A demo client for DRM leases

[Marius Vlad]

Heavily inspired by kmscube and simple-egl. Uses legacy page-flipping and
triangle shaders from simple-egl.

Signed-off-by: Marius Vlad 
---
 Makefile.am|  11 +
 clients/simple-egl-lease.c | 887 +
 clients/simple-egl-lease.h |  99 +
 configure.ac   |  17 +
 4 files changed, 1014 insertions(+)
 create mode 100644 clients/simple-egl-lease.c
 create mode 100644 clients/simple-egl-lease.h

diff --git a/Makefile.am b/Makefile.am
index 9c53a6b..d099b12 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -649,6 +649,17 @@ weston_simple_dmabuf_v4l_CFLAGS = $(AM_CFLAGS) 
$(SIMPLE_DMABUF_V4L_CLIENT_CFLAGS
 weston_simple_dmabuf_v4l_LDADD = $(SIMPLE_DMABUF_V4L_CLIENT_LIBS) libshared.la
 endif
 
+if BUILD_SIMPLE_EGL_LEASE_CLIENTS
+demo_clients += weston-simple-egl-lease
+weston_simple_egl_lease_SOURCES = clients/simple-egl-lease.c
+nodist_weston_simple_egl_lease_SOURCES = 
protocol/drm-lease-unstable-v1-protocol.c \
+   protocol/drm-lease-unstable-v1-client-protocol.h
+weston_simple_egl_lease_CFLAGS = $(AM_CFLAGS) 
$(SIMPLE_EGL_LEASE_CLIENT_CFLAGS) \
+$(LIBDRM_CFLAGS)
+weston_simple_egl_lease_LDADD = $(SIMPLE_EGL_LEASE_CLIENT_LIBS) $(LIBDRM_LIBS) 
\
+   $(GBM_LIBS) -lm
+endif
+
 noinst_LTLIBRARIES += libtoytoolkit.la
 
 libtoytoolkit_la_SOURCES = \
diff --git a/clients/simple-egl-lease.c b/clients/simple-egl-lease.c
new file mode 100644
index 000..8922e57
--- /dev/null
+++ b/clients/simple-egl-lease.c
@@ -0,0 +1,887 @@
+/*
+ * Copyright 2018 NXP
+ *
+ * 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.
+ *
+ * Adapted from kmscube and simple-egl. No atomic support atm.
+ *
+ */
+
+#include "config.h"
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+
+#include "drm-lease-unstable-v1-client-protocol.h"
+
+#include 
+#include 
+
+#include 
+#include 
+
+#include "simple-egl-lease.h"
+
+static volatile uint8_t sig_recv = 0;
+
+static const GLfloat verts[3][2] = {
+   { -0.5, -0.5 },
+   {  0.5, -0.5 },
+   {  0,0.5 }
+};
+
+static const GLfloat colors[3][3] = {
+   { 1, 0, 0 },
+   { 0, 1, 0 },
+   { 0, 0, 1 }
+};
+
+GLfloat rotation[4][4] = {
+   { 1, 0, 0, 0 },
+   { 0, 1, 0, 0 },
+   { 0, 0, 1, 0 },
+   { 0, 0, 0, 1 }
+};
+
+static const char *vertex_shader_source =
+   "uniform mat4 rotation;\n"
+   "attribute vec4 pos;\n"
+   "attribute vec4 color;\n"
+   "varying vec4 v_color;\n"
+   "void main() {\n"
+   "  gl_Position = rotation * pos;\n"
+   "  v_color = color;\n"
+   "}\n";
+
+static const char *fragment_shader_source =
+   "precision mediump float;\n"
+   "varying vec4 v_color;\n"
+   "void main() {\n"
+   "  gl_FragColor = v_color;\n"
+   "}\n";
+
+static struct gbm *
+init_gbm(int drm_fd, int w, int h)
+{
+   struct gbm *gbm = calloc(1, sizeof(*gbm));
+
+   gbm->dev = gbm_create_device(drm_fd);
+
+   gbm->surface = gbm_surface_create(gbm->dev, w, h, GBM_FORMAT_XRGB,
+ GBM_BO_USE_SCANOUT | 
GBM_BO_USE_RENDERING);
+   if (!gbm->surface) {
+   printf("failed to create gbm surface\n");
+   return NULL;
+   }
+
+   gbm->width = w;
+   gbm->height = h;
+
+   return gbm;
+}
+
+static int
+init_egl(struct egl *egl, const struct gbm *gbm)
+{
+   EGLint major, minor, n;
+
+   static const EGLint context_attribs[] = {
+   EGL_CONTEXT_CLIENT_VERSION, 2,
+   EGL_NONE
+   };
+
+   static const EGLint config_attribs[] = {
+   EGL_SURFACE_TYPE, EGL_WINDOW_BIT,
+   

Re: No output on display with Weston using fbdev backend

[Pekka Paalanen]

On Wed, 21 Mar 2018 19:45:36 +0530
nsola...@codeaurora.org wrote:

> On 2018-03-21 19:42, nsola...@codeaurora.org wrote:
> > On 2018-03-21 14:52, Pekka Paalanen wrote:  
> >> On Wed, 21 Mar 2018 14:40:13 +0530
> >> nsola...@codeaurora.org wrote:
> >>   
> >>> Hi Wayland Team,
> >>> 
> >>> 
> >>> I am using weston 1.9.0-r0 version and compiled weston for fbdev
> >>> backend.
> >>> 
> >>> But I do not see any output on display. Basically I do not see call
> >>> reaching to "ioctl(fd, FBIOPUT_VSCREENINFO, )" in function
> >>> fbdev_set_screen_info().
> >>> 
> >>> 
> >>> So, if I add a call "ioctl(fd,  FBIOPUT_VSCREENINFO, )" in
> >>> function fbdev_output_repaint_pixman(), I can see output on display.
> >>> 
> >>> Should I add FBIOPUT_VSCREENINFO ioctl in function
> >>> fbdev_output_repaint_pixman() ?
> >>> Can you please help me regarding this?  
> >> 
> >> Hi,
> >> 
> >> it is unlikely to find help with such an old Weston, even more so with
> >> the fbdev backend which at least I would like to just delete already.
> >> 
> >> But the fbdev backend is still in Weston, so I'd recommend trying a
> >> more recent version. You can also check git to see if there are code
> >> changes in the fbdev-backend.
> >> 
> >> I don't think FBIOPUT_VSCREENINFO at every repaint is good in any 
> >> case.
> >> 
> >> You might be interested in reviewing this patch or the whole series:
> >> https://patchwork.freedesktop.org/patch/200333/
> >> 
> >> What I've occasionally tested the fbdev-backend, I've never needed a
> >> call to FBIOPUT_VSCREENINFO, so your use case must be somehow
> >> different. Explaining exactly how and in what kind of a system and
> >> environment you are running Weston could help. E.g. is it a secondary
> >> fbdev device, or using UDL driver.
> >> 
> >> 
> >> Thanks,
> >> pq  
> > 
> > Hi,
> > 
> > In our FB driver FBIOPUT_VSCREENINFO internally calls a commit() call,
> > which actually displays content on panel.
> > So, it is needed it seems. I am not sure how drawing in mmap() ed
> > memory by opening /dev/fb0 can display content on panel without a
> > commit() call as weston is currently doing.

Hi,

it works because the mmapped memory is already continuously and
repeatedly being scanned out. There is no per-frame "commit" in fbdev
ABI. The ABI implies that any change to the mmapped memory will be
immediately visible on screen, if you write to the on-screen memory
area. This is just how fbdev works.

There are some cases where the ioctl is needed to wake up the fbdev
device, but it is not needed on every frame.

If your fbdev driver needs an ioctl each frame, then your fbdev driver
is broken. I would recommend to *not* fix your fbdev driver, but write
a DRM driver instead. Then you can use Weston's DRM-backend which is
actually developed and maintained.

> One more query is when (on what events) function fbdev_output_reenable() 
> should be called?
> I am not seeing session_notify() fnction call .

There is a
->session_listener.notify = session_notify;
assignment, which will get that function called on VT switch.

Mind, fbdev-backend's VT switching is probably broken - it was some
years ago when I last tried it.


Thanks,
pq


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

[prefix=PATCH weston] gl-renderer.c: Pass visual ID for choosing egl configs for pbuffer

[Madhurkiran Harikrishnan]

The original implementation always chose first egl config for pbuffer
surface type, however the returned configs are implementation specific
and egl config may not always match between ctx and surface. Hence,
pass the visual_id to find the correct egl config.

Signed-off-by: Madhurkiran Harikrishnan 
---
 libweston/gl-renderer.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c
index b67c8e2..c387367 100644
--- a/libweston/gl-renderer.c
+++ b/libweston/gl-renderer.c
@@ -3145,7 +3145,7 @@ output_handle_destroy(struct wl_listener *listener, void 
*data)
 }

 static int
-gl_renderer_create_pbuffer_surface(struct gl_renderer *gr) {
+gl_renderer_create_pbuffer_surface(struct gl_renderer *gr, const EGLint 
*visual_id, int n_ids) {
EGLConfig pbuffer_config;

static const EGLint pbuffer_config_attribs[] = {
@@ -3164,11 +3164,19 @@ gl_renderer_create_pbuffer_surface(struct gl_renderer 
*gr) {
EGL_NONE
};

-   if (egl_choose_config(gr, pbuffer_config_attribs, NULL, 0, 
_config) < 0) {
+   if (egl_choose_config(gr, pbuffer_config_attribs, visual_id, n_ids, 
_config) < 0) {
weston_log("failed to choose EGL config for PbufferSurface\n");
return -1;
}

+   if (pbuffer_config != gr->egl_config &&
+   !gr->has_configless_context) {
+   weston_log("attempted to use a different EGL config for an "
+  "output but EGL_KHR_no_config_context or "
+  "EGL_MESA_configless_context is not supported\n");
+   return -1;
+   }
+
gr->dummy_surface = eglCreatePbufferSurface(gr->egl_display,
pbuffer_config,
pbuffer_attribs);
@@ -3277,7 +3285,7 @@ gl_renderer_display_create(struct weston_compositor *ec, 
EGLenum platform,
weston_log("EGL_KHR_surfaceless_context unavailable. "
   "Trying PbufferSurface\n");

-   if (gl_renderer_create_pbuffer_surface(gr) < 0)
+   if (gl_renderer_create_pbuffer_surface(gr, visual_id, n_ids) < 
0)
goto fail_with_error;
}

--
2.7.4

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: No output on display with Weston using fbdev backend

[nsolanki]

On 2018-03-21 19:42, nsola...@codeaurora.org wrote:

On 2018-03-21 14:52, Pekka Paalanen wrote:

On Wed, 21 Mar 2018 14:40:13 +0530
nsola...@codeaurora.org wrote:


Hi Wayland Team,


I am using weston 1.9.0-r0 version and compiled weston for fbdev
backend.

But I do not see any output on display. Basically I do not see call
reaching to "ioctl(fd, FBIOPUT_VSCREENINFO, )" in function
fbdev_set_screen_info().


So, if I add a call "ioctl(fd,  FBIOPUT_VSCREENINFO, )" in
function fbdev_output_repaint_pixman(), I can see output on display.

Should I add FBIOPUT_VSCREENINFO ioctl in function
fbdev_output_repaint_pixman() ?
Can you please help me regarding this?


Hi,

it is unlikely to find help with such an old Weston, even more so with
the fbdev backend which at least I would like to just delete already.

But the fbdev backend is still in Weston, so I'd recommend trying a
more recent version. You can also check git to see if there are code
changes in the fbdev-backend.

I don't think FBIOPUT_VSCREENINFO at every repaint is good in any 
case.


You might be interested in reviewing this patch or the whole series:
https://patchwork.freedesktop.org/patch/200333/

What I've occasionally tested the fbdev-backend, I've never needed a
call to FBIOPUT_VSCREENINFO, so your use case must be somehow
different. Explaining exactly how and in what kind of a system and
environment you are running Weston could help. E.g. is it a secondary
fbdev device, or using UDL driver.


Thanks,
pq


Hi,

In our FB driver FBIOPUT_VSCREENINFO internally calls a commit() call,
which actually displays content on panel.
So, it is needed it seems. I am not sure how drawing in mmap() ed
memory by opening /dev/fb0 can display content on panel without a
commit() call as weston is currently doing.


Thanks
Namit



One more query is when (on what events) function fbdev_output_reenable() 
should be called?

I am not seeing session_notify() fnction call .
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: No output on display with Weston using fbdev backend

[nsolanki]

On 2018-03-21 14:52, Pekka Paalanen wrote:

On Wed, 21 Mar 2018 14:40:13 +0530
nsola...@codeaurora.org wrote:


Hi Wayland Team,


I am using weston 1.9.0-r0 version and compiled weston for fbdev
backend.

But I do not see any output on display. Basically I do not see call
reaching to "ioctl(fd, FBIOPUT_VSCREENINFO, )" in function
fbdev_set_screen_info().


So, if I add a call "ioctl(fd,  FBIOPUT_VSCREENINFO, )" in
function fbdev_output_repaint_pixman(), I can see output on display.

Should I add FBIOPUT_VSCREENINFO ioctl in function
fbdev_output_repaint_pixman() ?
Can you please help me regarding this?


Hi,

it is unlikely to find help with such an old Weston, even more so with
the fbdev backend which at least I would like to just delete already.

But the fbdev backend is still in Weston, so I'd recommend trying a
more recent version. You can also check git to see if there are code
changes in the fbdev-backend.

I don't think FBIOPUT_VSCREENINFO at every repaint is good in any case.

You might be interested in reviewing this patch or the whole series:
https://patchwork.freedesktop.org/patch/200333/

What I've occasionally tested the fbdev-backend, I've never needed a
call to FBIOPUT_VSCREENINFO, so your use case must be somehow
different. Explaining exactly how and in what kind of a system and
environment you are running Weston could help. E.g. is it a secondary
fbdev device, or using UDL driver.


Thanks,
pq


Hi,

In our FB driver FBIOPUT_VSCREENINFO internally calls a commit() call, 
which actually displays content on panel.
So, it is needed it seems. I am not sure how drawing in mmap() ed memory 
by opening /dev/fb0 can display content on panel without a commit() call 
as weston is currently doing.



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

Re: [PATCH wayland] wayland-egl: Ignore underscored symbols in ABI check

[Emil Velikov]

On 21 March 2018 at 09:28, Daniel Stone  wrote:
> Hi,
>
> On 21 March 2018 at 08:27, Pekka Paalanen  wrote:
>> On Tue, 20 Mar 2018 11:46:32 +, Daniel Stone  
>> wrote:
>>> inconvenience of maintaining a list of every linker's implementation
>>> detail on every platform, outweighs the risk of an exported
>>> underscore-prefixed symbol slipping through review.
>>
>> how about we make it a coding style rule to not have any symbols
>> starting with an underscore?
>>
>> I don't recall any already being in the code for either Wayland or
>> Weston, but I didn't check. They certainly are not public ABI as the
>> ABI check script would have listed such.
>
> Sure, works for me.
>
Indeed very good suggestion.

>> Aren't symbols (functions, variables) starting with an underscore
>> reserved in C so should not be used anyway?
>
> My recollection is that double-underscore and underscore-uppercase is
> forbidden for use apart from the implementation / standard library,
> and anything else underscore (underscore-number or
> underscore-lowercase) can only be used for static symbols. But I'm
> sure Simon will be along shortly to correct the record. :)
>
The spec does not explicitly state "static symbols" although you're
spot on overall.

-Emil

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

Re: [PATCH wayland] wayland-egl: Ignore underscored symbols in ABI check

[Daniel Stone]

Hi,

On 21 March 2018 at 08:27, Pekka Paalanen  wrote:
> On Tue, 20 Mar 2018 11:46:32 +, Daniel Stone  wrote:
>> inconvenience of maintaining a list of every linker's implementation
>> detail on every platform, outweighs the risk of an exported
>> underscore-prefixed symbol slipping through review.
>
> how about we make it a coding style rule to not have any symbols
> starting with an underscore?
>
> I don't recall any already being in the code for either Wayland or
> Weston, but I didn't check. They certainly are not public ABI as the
> ABI check script would have listed such.

Sure, works for me.

> Aren't symbols (functions, variables) starting with an underscore
> reserved in C so should not be used anyway?

My recollection is that double-underscore and underscore-uppercase is
forbidden for use apart from the implementation / standard library,
and anything else underscore (underscore-number or
underscore-lowercase) can only be used for static symbols. But I'm
sure Simon will be along shortly to correct the record. :)

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

Re: No output on display with Weston using fbdev backend

[Pekka Paalanen]

On Wed, 21 Mar 2018 14:40:13 +0530
nsola...@codeaurora.org wrote:

> Hi Wayland Team,
> 
> 
> I am using weston 1.9.0-r0 version and compiled weston for fbdev 
> backend.
> 
> But I do not see any output on display. Basically I do not see call 
> reaching to "ioctl(fd, FBIOPUT_VSCREENINFO, )" in function 
> fbdev_set_screen_info().
> 
> 
> So, if I add a call "ioctl(fd,  FBIOPUT_VSCREENINFO, )" in 
> function fbdev_output_repaint_pixman(), I can see output on display.
> 
> Should I add FBIOPUT_VSCREENINFO ioctl in function 
> fbdev_output_repaint_pixman() ?
> Can you please help me regarding this?

Hi,

it is unlikely to find help with such an old Weston, even more so with
the fbdev backend which at least I would like to just delete already.

But the fbdev backend is still in Weston, so I'd recommend trying a
more recent version. You can also check git to see if there are code
changes in the fbdev-backend.

I don't think FBIOPUT_VSCREENINFO at every repaint is good in any case.

You might be interested in reviewing this patch or the whole series:
https://patchwork.freedesktop.org/patch/200333/

What I've occasionally tested the fbdev-backend, I've never needed a
call to FBIOPUT_VSCREENINFO, so your use case must be somehow
different. Explaining exactly how and in what kind of a system and
environment you are running Weston could help. E.g. is it a secondary
fbdev device, or using UDL driver.


Thanks,
pq


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

No output on display with Weston using fbdev backend

[nsolanki]

Hi Wayland Team,


I am using weston 1.9.0-r0 version and compiled weston for fbdev 
backend.


But I do not see any output on display. Basically I do not see call 
reaching to "ioctl(fd, FBIOPUT_VSCREENINFO, )" in function 
fbdev_set_screen_info().



So, if I add a call "ioctl(fd,  FBIOPUT_VSCREENINFO, )" in 
function fbdev_output_repaint_pixman(), I can see output on display.


Should I add FBIOPUT_VSCREENINFO ioctl in function 
fbdev_output_repaint_pixman() ?

Can you please help me regarding this?


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

Re: [PATCH wayland] wayland-egl: Ignore underscored symbols in ABI check

[Pekka Paalanen]

On Tue, 20 Mar 2018 11:46:32 +
Daniel Stone  wrote:

> inconvenience of maintaining a list of every linker's implementation
> detail on every platform, outweighs the risk of an exported
> underscore-prefixed symbol slipping through review.

Hi,

how about we make it a coding style rule to not have any symbols
starting with an underscore?

I don't recall any already being in the code for either Wayland or
Weston, but I didn't check. They certainly are not public ABI as the
ABI check script would have listed such.

Aren't symbols (functions, variables) starting with an underscore
reserved in C so should not be used anyway?


Thanks,
pq


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