Re: 2018 Election voting OPEN

[Rob Clark]

To all X.Org Foundation Members:

Due to some technical difficulties, the earlier election notification
messages to memb...@x.org list did not go through (but also did not
trigger bounce/moderator notification).  We cross referenced the
members list to the subscriber lists for xorg-devel, xorg, mesa-dev,
and wayland-devel lists and concluded that there are a small
percentage of x.org foundation members who were not also subscribed to
one of the lists CC'd on the original notification about election
period.

For this reason, to ensure that all x.org foundation members have an
opportunity to vote, we are extending the voting period by one week.
The voting period will now remain open until 23:59 UTC on 12 April
2018.

Rob Clark,
on behalf of the X.Org elections committee

On Wed, Mar 21, 2018 at 8:40 PM, Rob Clark  wrote:
> 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

[ANNOUNCE] weston 3.0.93

[Derek Foreman]

This is the RC1 for the weston 4.0 release.

We've unfortunately had to revert some XWayland changes.  The icon code
still has some cosmetic issues that we don't have time to deal with
before release, so it has been temporarily removed.  Similarly, a fix
for XWayland input region calculations has also been removed until the
next release when there's more time to review the fixes.

If all goes well we're looking at an April 9th release date.

Derek Foreman (4):
  xwm: Fix two more icon related memory leaks
  Revert "xwm: do not include shadow in input region"
  Partially revert "xwm: Add icon support to the frame" and friends
  configure.ac: bump to version 3.0.93 for the RC1 release

Emre Ucan (6):
  compositor-drm: remove dead assigment in drm_fb_create_dumb
  hmi-controller: remove dead assignments in add_launchers
  input: fix use-after-free issue at pointer_cancel
  gl-renderer: set num_images after import_simple_dmabuf
  compositor: initialize ret in repaint_timer_handler
  ivi-shell: remove dead assignments in layer transition

Pekka Paalanen (1):
  Revert "xwm: Fix memory leak"

Scott Moreau (2):
  xwm: Fix memory leak
  xwm: Fix memory leak

git tag: 3.0.93

https://wayland.freedesktop.org/releases/weston-3.0.93.tar.xz
MD5:  a06fe44302b752be856b493b18594ac5  weston-3.0.93.tar.xz
SHA1: 97bd993f79f160c6a135c949a9dfb5453ce4332d  weston-3.0.93.tar.xz
SHA256: 8d2fd050d6b0cf990223788293f58781c1c1e08929cc679711eeaab717caf01d
 weston-3.0.93.tar.xz
SHA512:
cd40291517194d3f6eb0dd3f3d8d70c0c1da577eec5a30d787ac83484306e1fef7077521cd05b3b64a91ad702a1743286c5b33ebb55896e38bfc747e4a487c5d
 weston-3.0.93.tar.xz
PGP:  https://wayland.freedesktop.org/releases/weston-3.0.93.tar.xz.sig




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

[ANNOUNCE] wayland 1.14.93

[Derek Foreman]

This is the RC1 for the wayland 1.15 release.

If all goes well, the next release will be on Monday April 9th.

This release fixes make check under platforms (such as ARM) where our
ABI check test was broken.


Daniel Stone (1):
  wayland-egl: Ignore underscored symbols in ABI check

Derek Foreman (1):
  configure.ac: bump to version 1.14.93 for the RC1 release

Emil Velikov (1):
  .gitignore: add wayland-egl-abi-check

git tag: 1.14.93

https://wayland.freedesktop.org/releases/wayland-1.14.93.tar.xz
MD5:  57dc5715bbe3bf53043ef55b29a789e3  wayland-1.14.93.tar.xz
SHA1: 159f27e6f1a4e459903afebee42a2c0c9b6bf27f  wayland-1.14.93.tar.xz
SHA256: 62f649725a5ab73b528cd3a9283670942375c2486844ec21475d8a4031299d7f
 wayland-1.14.93.tar.xz
SHA512:
6d617b2025505e599c25c8a42062e7f78fe5bcbab58a96fcbc6afb54cf4b92e44a3f5a096c8d55e58539530f98a549f1cd20615c378cc591d50abdefa56b7656
 wayland-1.14.93.tar.xz
PGP:  https://wayland.freedesktop.org/releases/wayland-1.14.93.tar.xz.sig




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

Re: 2018 Election voting OPEN

[Rob Clark]

On Wed, Mar 21, 2018 at 8:40 PM, Rob Clark  wrote:
> 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.

Reminder that the elections are open until midnight on Thurs, so if
you have not already voted, please do.

> 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

Re: [PATCH v2 weston] Partially revert "xwm: Add icon support to the frame" and friends

[Quentin Glidic]

On 3/30/18 6:56 PM, Derek Foreman wrote:

This (partially) reverts commit bef761796c2ada6344d227142af4a0f40b9760dd.
This (partially) reverts commit 4d1cd36c9ea041688f92cd8981e43b5fe3b52409.
This (partially) reverts commit 44fc1be913ab2faad0414f50e51d58310302d065.
This (partially) reverts commit 6b58ea8c43ac81e519bd418efbf24687a5d731b8.

The new xwm icon code has proven to be leaky and incomplete, and while
we have patches under consideration to fix the rest of its known problems
they still require changes and review cycles.  Currently the known
leaks have been squashed, but it still picks wrong sized icons and
does no scaling, which can lead to very strange rendering.  At window
close time the wrong sized icon appears above the window during fade out.

This patch reverts the mostly solid bits and keeps the unfinished
bits behind in favor of a simpler revert than removing the whole
thing.

Signed-off-by: Derek Foreman  > ---

Changes from v1:

Only reverts the changes in window-manager.c (and updates frame_create call
to pass NULL for icon surface.


Yeah, looks safer to me:
Reviewed-by: Quentin Glidic 

I’m sure Scott will submit a complete feature soon, this way we can 
focus the review on the real bits. :-)


Thanks,




  xwayland/window-manager.c | 88 ++-
  1 file changed, 2 insertions(+), 86 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index 62087941..06370b70 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -138,8 +138,6 @@ struct weston_wm_window {
xcb_window_t frame_id;
struct frame *frame;
cairo_surface_t *cairo_surface;
-   int icon;
-   cairo_surface_t *icon_surface; /* A temporary slot, to be passed to 
frame on creation */
uint32_t surface_id;
struct weston_surface *surface;
struct weston_desktop_xwayland_surface *shsurf;
@@ -475,7 +473,6 @@ weston_wm_window_read_properties(struct weston_wm_window 
*window)
{ wm->atom.net_wm_state,   TYPE_NET_WM_STATE,  NULL 
},
{ wm->atom.net_wm_window_type, XCB_ATOM_ATOM,  
F(type) },
{ wm->atom.net_wm_name,XCB_ATOM_STRING,
F(name) },
-   { wm->atom.net_wm_icon,XCB_ATOM_CARDINAL,  
F(icon) },
{ wm->atom.net_wm_pid, XCB_ATOM_CARDINAL,  
F(pid) },
{ wm->atom.motif_wm_hints, TYPE_MOTIF_WM_HINTS,NULL 
},
{ wm->atom.wm_client_machine,  XCB_ATOM_WM_CLIENT_MACHINE, 
F(machine) },
@@ -976,10 +973,8 @@ weston_wm_window_create_frame(struct weston_wm_window 
*window)
buttons |= FRAME_BUTTON_MAXIMIZE;
  
  	window->frame = frame_create(window->wm->theme,

-window->width, window->height,
-buttons, window->name,
-window->icon_surface);
-   window->icon_surface = NULL;
+window->width, window->height,
+buttons, window->name, NULL);
frame_resize_inside(window->frame, window->width, window->height);
  
  	weston_wm_window_get_frame_size(window, , );

@@ -1318,70 +1313,6 @@ weston_wm_window_schedule_repaint(struct 
weston_wm_window *window)
   weston_wm_window_do_repaint, window);
  }
  
-static void

-handle_icon_surface_destroy(void *data)
-{
-   free(data);
-}
-
-static void
-weston_wm_handle_icon(struct weston_wm *wm, struct weston_wm_window *window)
-{
-   xcb_get_property_reply_t *reply;
-   xcb_get_property_cookie_t cookie;
-   uint32_t length;
-   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);
-   reply = xcb_get_property_reply(wm->conn, cookie, NULL);
-   length = xcb_get_property_value_length(reply);
-
-   /* This is in 32-bit words, not in bytes. */
-   if (length < 2) {
-   free(reply);
-   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) {
-   free(reply);
-   return;
-   }
-
-   new_surface =
-   cairo_image_surface_create_for_data((unsigned char *)data,
-   CAIRO_FORMAT_ARGB32,
-   

Re: [PATCH wayland 2/2] .gitignore: add wayland-egl-abi-check

[Derek Foreman]

On 2018-03-20 06:10 AM, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Instruct git go ignore the file, in case we've done an in-tree build.
> 
> Cc: Derek Foreman 
> Signed-off-by: Emil Velikov 
Reviewed-by: Derek Foreman 

And pushed.

Thanks,
Derek

> ---
> I've opted for the shortest fix - add an entry instead of renaming
> files, updating build rules, etc.
> 
> If people really want to we can opt for that route.
> ---
>  .gitignore | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/.gitignore b/.gitignore
> index 8da9861..eadea12 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -43,5 +43,6 @@ Makefile
>  Makefile.in
>  exec-fd-leak-checker
>  fixed-benchmark
> +/wayland-egl-abi-check
>  /wayland-scanner
>  protocol/*.[ch]
> 

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

Re: [PATCH weston 00/25] A new touchscreen calibrator

[Matt Hoosier]

Do you happen to know of a good readymade program that fakes the presence
of a touch input device with uinput? I'd love to test this series, but
current Weston is far ahead of what my embedded devices will do; so I'm in
the position of mostly relying on the desktop for testing.

On Fri, Mar 23, 2018, 09:38 Matt Hoosier  wrote:

> On Fri, Mar 23, 2018 at 9:30 AM, Pekka Paalanen 
> wrote:
> > On Fri, 23 Mar 2018 08:46:46 -0500
> > Matt Hoosier  wrote:
> >
> >> I am very much in favor of the overall approach on this patch series.
> >> I've experienced every single one of the problems described in this
> >> summary, and my company currently resorts to maintaining a hacky
> >> out-of-tree calibration tool to paper over these problems.
> >
> > Hi Matt,
> >
> > that is very heartwarming to hear. Is your tool specifically for Weston
> > too?
>
> Yes and no. It's not phrased as a patch against the Weston source
> code, but it uses heuristics for determining which output the raw
> /dev/input/* events should be correlated against, and those heuristics
> probably would fail if some different compositor happened to be
> running.
>
> >
> > I would be very happy if this proposal fits your needs, and certainly
> > interested in hearing where it falls short.
> >
> >
> > Thanks,
> > pq
> >
> >> On Fri, Mar 23, 2018 at 7:00 AM, Pekka Paalanen 
> wrote:
> >> > From: Pekka Paalanen 
> >> >
> >> > Hi all,
> >> >
> >> > the existing touchscreen calibrator in Weston has several problems.
> This
> >> > proposal intends to solve them all by introducing a new protocol
> >> > extension for touchscreen calibration and a new calibrator tool.
> >> >
> >> > The benefits of the new tool, which the old tool lacks, are:
> >> >
> >> > - You can unambiguously pick a physical touch device to calibrate.
> >> >
> >> > - You can be sure your touch events come only from that particular
> >> >   device, and that you cannot miss touch events even if the current
> >> >   calibration is horribly wrong.
> >> >
> >> > - You can be sure the calibration window (pattern) is shown on the
> right
> >> >   output with the right coordinates.
> >> >
> >> > - You can unambiguously calibrate even multiple touchscreens that are
> >> >   all cloned (showing the same image).
> >> >
> >> > - You get a libinput style calibation matrix instead of the
> >> >   WL_CALIBRATION format which depends on output resolution.
> >> >
> >> > - You can load a new calibration into the compositor without playing
> >> >   tricks with udev or restarting the compositor.
> >> >
> >> > There is more discussion about the topic at:
> >> > https://phabricator.freedesktop.org/T7868
> >> >
> >> > This patch series depends on the clone mode series:
> >> > https://patchwork.freedesktop.org/series/32898/
> >> >
> >> > There is a full branch available at:
> >> > https://gitlab.collabora.com/pq/weston/commits/touchcalib-1
> >
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

XDC 2018: Call for Papers

[Samuel Iglesias Gonsálvez]

Hello,

I have the pleasure to announce that the X.org Developer Conference 2018
will be held in A Coruña, Spain from September 26th to September 28th.
The venue is located at the Computer Science faculty of the University
of Coruña.

This year, we have created a new website for the event:

https://xdc2018.x.org

And a Twitter account for announcing updates, please follow us!

https://twitter.com/xdc2018

However, we are going to keep updating the good old wiki too:

https://www.x.org/wiki/Events/XDC2018

As usual, we are open to talks across the layers of the graphics stack,
from the kernel to desktop environments / graphical applications and
about how to make things better for the developers who build them. Other
topics such as Virtual Reality are also welcome. If you're not sure if
something might fit, mail us or add it to the ideas list found in the
program page at:

https://www.x.org/wiki/Events/XDC2018/Program/

The Call for Papers information is here: https://xdc2018.x.org/#cfp.
Remember, the deadline for submissions is Wednesday 25th July 2018 17:00
UTC. Don't forget to send your proposals to bo...@foundation.x.org!

The conference is free of charge and open to the general public. If you
plan on coming, please add yourself to the attendees list:

https://www.x.org/wiki/Events/XDC2018/Attendees/

We'll use this list of attendees to make badges and plan for the
catering, so if you are attending please add your name as early as
possible.

I am looking forward to seeing you there. If you have any
inquiries/questions, please send an email to xdc2...@gpul.org, adding on
CC the X.org board (bo...@foundation.x.org).

Best regards,

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

Re: [wayland-protocols] text-input: Add v3 of the text-input protocol

[Dorota Czaplejewicz]

On Sun, 11 Mar 2018 20:30:14 +0100
Carlos Garnacho  wrote:

> This new protocol description is a vast simplification over v2, highlights
> are:
> - All pre-edit text styling is gone, the protocol doesn't seem the place
>   to convey UI state. Clients are in better knowledge of how to make the
>   pre-edit string distinguishable from regular text.
> - No input panel (OSK) state nor covered rectangle events. This leaks
>   assumptions about the coordinate space of windows, and clients aren't
>   fully capable of handling all possible situations (eg. if the OSK fully
>   covers the surface). At the very least it could be split into a generic
>   protocol of its own, this version of the protocol simply doesn't get
>   into this business, compositors are still free to handle situations where
>   the keyboard focus rectangle is covered by the input panel.
> - Less state is to be kept on compositors. Clients must now reissue all
>   applying IM state whenever the surface gains focus (or internal focus
>   changes), instead of state requests being independent from focus.
> - No set_preferred_language request for clients, modern desktops have
>   generally moved towards session-wide IM settings, it seems hard to
>   conciliate this piece of information flowing in both directions.
> - There is no event to send keysyms. The handling ought to be by all means
>   identical to wl_keyboard's, compositors might just use that interface.
> 
> Signed-off-by: Carlos Garnacho 
> ---
> 
> Hey,
> 
> Belatedly, here's my proposed v3 of the text-input protocol, a rename of
> what is implemented on gnome-shell/gtk+. It basically is a
> (over?)simplification compared to v2, the main difference besides the
> punted functionality is the simplified messaging flow, state is considered
> reset after enter/leave, or on .disable requests from the client, all
> new state must be submitted afterwards.
> 
> Some of the removed things are maybe debatable (eg. the keysym event,
> or language preference request/signal, although I don't see that working
> out of the box widely, highly toolkit specific at best). For stuff like
> the old input_panel_state request to do client-side UI magic to keep
> keyboard focus visible I'm personally more opinionated though :).
> 
> Comments?
> 
> Cheers,
>   Carlos

...

> +  Focus moving throughout surfaces will result in the emission of
> +  zwp_text_input_v3.enter and zwp_text_input_v3.leave events. The focused
> +  surface must perform zwp_text_input_v3.enable and
> +  zwp_text_input_v3.disable requests as the keyboard focus moves across
> +  editable and non-editable elements of the UI. Those two requests are 
> not
> +  expected to be paired with each other, the compositor must be able to
> +  handle consecutive series of the same request.
What does it mean if there are several consecutive "enable" events? Should the 
compositor treat the second and next as an implicit "disable" events? Or should 
the input method stay open, which makes some sense if the input method presents 
a popup?

...

> +
> +  
> +   Notification that this seat's text-input focus is on a certain 
> surface.
> +
> +   When the seat has the keyboard capability the text-input focus follows
> +   the keyboard focus.
> +  
> +  
> +  
> +
> +
> +
> +  
> +   Notification that this seat's text-input focus is no longer on
> +   a certain surface. The client should reset any preedit string 
> previously
> +   set.
> +
> +   The leave notification is sent before the enter notification
> +   for the new focus.
I read this to mean that there can be only one surface in the "entered" state 
at a time. What is the purpose of serial number in the enter and leave events 
if there's only one surface to keep track of?

Cheers,
Dorota


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