Re: Proposed 1.9 release schedule
On Thu, Aug 13, 2015 at 12:16:11PM +0300, Pekka Paalanen wrote: > Hi all, > > this looks fine to me personally. I'll point out some specific feature > cut-off points below, in case anyone wants to scream. > > > On Wed, 12 Aug 2015 15:42:53 -0700 > Bryce Harrington wrote: > > > We're coming up to our next scheduled release. I've got a few scattered > > events and holidays but looking at my calendar, these dates look > > feasible and fit the timeframe we wanted: > > > > * 8/14 (Friday) - 1.8.91 (1.9 alpha) > > The end of big new features. I think this will cut: > - any changes or additions to protocols installed from Wayland > - introducing the proxy wrapper in libwayland-client > - require WAYLAND_DISPLAY, and the other env variable additions and > changes in Wayland > - building of libweston.so > > > > > * 9/01 (Tuesday) - 1.8.92 (1.9 beta) > > + Feature freeze > > Cuts: > - pointer lock, if patching only Weston > - Weston atomic > - Weston dmabuf > > > > > * 9/15 (Tuesday) - 1.8.93 (1.9 rc1) > > + Final freeze > > > > * rc2 only if necessary > > > > * 9/22 (Tuesday) - 1.9.0 (1.9 release) > > + Re-open trunk for 1.10 development > > To clarify, "cut" means the essential patches need to have landed, or > they need to wait for 1.10 developement to open. > > Would you agree on the categorization between big and minor features, > that is, alpha vs. beta? Yes, works for me. So alpha is sort of a "Feature Frost". > > Notably, I'd like to shift from doing releases on Fridays to mid-week, > > but that's mostly just for my own convenience. If anyone prefers > > strongly that I stick with Friday releases let me know. > > > > I'm also shifting to calling the releases alpha/beta/rc instead of > > alpha/rc1/rc2, since we don't typically consider that second one to be > > an actual candidate for releasing. Again, I'm guessing no one but me > > cares, but if anyone wants to stick with the old approach let me know. > > Yeah, that's cool. > > Referring to > http://lists.freedesktop.org/archives/wayland-devel/2014-May/014955.html : > > - alpha: all big features landed, only minor, >contained features after this > > - beta: only bug fixes after this > > - rc: only critical bug fixes after this > > Seems like a good idea to keep on using, right? Yes, it seems to have worked well so far. So, same process really, just tweaks to the naming. Bryce > Thanks, > pq > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iQIVAwUBVcxgYyNf5bQRqqqnAQgePA//W2KS0niaBaNI/Q5cAqHKre6b4tXQ0hwb > sjJCcedLrxMyqqRMOz2VurY3ZslqPBqr1x+GUW9XDaE7EU7rYIP0qxxJ8kK6NCmr > t02p2r3tQH+Hw4GBmpIhXV4n5KDrc1YSqOzTh7xZoGREeTesegh3If8OzYtgjACG > 3Xkwu+CqPziM0uIhWfnhmXsTRrLacxi8Axz/ijzdjpVbHsWTzhz7MKxGBoY/1qgd > XSNWvIVtI4Mgk7mrwQuVrxfiSfKRJpgwycvvRvo2iP8dfF84rtrTNCTnfsPjmXO8 > o+i1Z8TC4eS7dmY/xiblbcERLDCVTRUR9n5Dn/y7yjYgsZoy0q1qqlbttdZKs7Zm > vHEn1IehYTVXvpGToMmcwt0jV6hKxNS81RrMqqdonZQJSJrUMuMFGVSIPJ1e/kEZ > rPgOuRBxtoxhSJzsBt2ECG7Db+fDTajnxtz3Jb6iL5yjy7s5304rn3WEkWASVW0B > mqnX3khaRg/Qx3gvbS4SOfGJlt5Jwa0xcBrLbAxv0aXOX0ZYzIFz+e7SjlGTS3t0 > cr8KELST9ZPjw/+9M44s04ueDA/owgvW9aBClNipLxf3Lnv14eG1X1RtDQUmYFUX > 0lnyfVdUZ1AtIgVdGurNgOexGjFd3tQu6WxMCZ2zNdQZTd/tWZAhnzQ+LYVNfpDc > YUp8+gm+Ino= > =bXEj > -END PGP SIGNATURE- ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Patchwork upgrade?
On Fri, Aug 07, 2015 at 04:40:11PM -0700, Bryce Harrington wrote: > > Damien, would you have time to update Patchwork in the next week or two? > > > > Also, it would be awesome to have Cairo included in patchwork, for > > patches going back maybe 2-3 years. > > > > Bryce > > Hello Damien, just checking in again to see if you're available for > handling the above requests? Sorry, just back from holidays. I expect I'd have some time in the near future to look at the FDO patchwork, with a bigger scope than just updating to latest upstream. No ETA though (hopefully in the next few weeks). -- Damien ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston v2] ivi-shell: bugfix, an ivi_surface is not removed from list of ivi_layer when the ivi_surface is removed from the compositor.
On Fri, 7 Aug 2015 09:47:02 +0900
Nobuhiko Tanibata wrote:
> The api, ivi_layout_layer_remove_surface, shall remove a ivi_surface
> from　a list of ivi_layer. In previous code, there is no trigger to
> refresh order of list, removing the ivi_surface, in commit_layer_list.
>
> To fix this bug, set a mask; IVI_NOTIFICATION_REMOVE in order to trigger
> refresh list of surface in commit_layer_list.
>
> In commit_layer_list, this patch also removes duplicated code in two
> conditions for IVI_NOTIFICATION_ADD/REMOVE.
>
> Signed-off-by: Nobuhiko Tanibata
> ---
> v2 changes:
> - fix 8 spaces to tab.
> - clean up duplicate code in commit_layer_list.
> - improve commit message.
>
> ivi-shell/ivi-layout.c | 28 +---
> 1 file changed, 9 insertions(+), 19 deletions(-)
>
> diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
> index 2974bb7..1b45003 100644
> --- a/ivi-shell/ivi-layout.c
> +++ b/ivi-shell/ivi-layout.c
> @@ -812,25 +812,7 @@ commit_layer_list(struct ivi_layout *layout)
> if (!(ivilayer->event_mask &
> (IVI_NOTIFICATION_ADD | IVI_NOTIFICATION_REMOVE)) ) {
> continue;
Hi Tanibata-san,
using 'continue', there is no need to have an else-branch. This would
save one level of indent in the remaining code.
> - }
> -
> - if (ivilayer->event_mask & IVI_NOTIFICATION_REMOVE) {
> - wl_list_for_each_safe(ivisurf, next,
> - &ivilayer->order.surface_list, order.link) {
> - remove_ordersurface_from_layer(ivisurf);
> -
> - if (!wl_list_empty(&ivisurf->order.link)) {
> - wl_list_remove(&ivisurf->order.link);
> - }
> -
> - wl_list_init(&ivisurf->order.link);
> - ivisurf->event_mask |= IVI_NOTIFICATION_REMOVE;
You are removing this setting of the flag IVI_NOTIFICATION_REMOVE, but
in the code that remains I do not see that happening anymore in
commit_layer_list().
However, I see it being set by ivi_layout_layer_remove_surface(). At
which time should the flag be set? Should the ADD flag not work the
same way?
Would it be essential to flag ivi-surfaces that get removed from
ivilayer->order.surface_list with IVI_NOTIFICATION_REMOVE, and surfaces
that are added to flag with IVI_NOTIFICATION_ADD, and all remaining
surfaces even if they are reordered not be flagged at all?
Or is it intended that all surfaces that are originally in the
ivilayer->order.surface_list are flagged as REMOVE, and all surfaces in
the pending list are flagged as ADD? That would imply that surfaces
that were and still remain in the order list are flagged as both REMOVE
and ADD.
> - }
> -
> - wl_list_init(&ivilayer->order.surface_list);
> - }
> -
> - if (ivilayer->event_mask & IVI_NOTIFICATION_ADD) {
> + } else {
> wl_list_for_each_safe(ivisurf, next,
> &ivilayer->order.surface_list,
> order.link) {
> remove_ordersurface_from_layer(ivisurf);
> @@ -843,6 +825,13 @@ commit_layer_list(struct ivi_layout *layout)
> }
>
> wl_list_init(&ivilayer->order.surface_list);
> +
> + /**
> + * Following ivilayer->pending.surface_list must be
> maintained by
> + * a function who will set these masks. Order of
> surfaces in a
> + * layer is restructured here. if there is no surface in
> + * surface_list, the following code is skipped.
> + */
> wl_list_for_each(ivisurf,
> &ivilayer->pending.surface_list,
>pending.link) {
> if(!wl_list_empty(&ivisurf->order.link)){
> @@ -2565,6 +2554,7 @@ ivi_layout_layer_remove_surface(struct ivi_layout_layer
> *ivilayer,
> }
>
> remsurf->event_mask |= IVI_NOTIFICATION_REMOVE;
> + ivilayer->event_mask |= IVI_NOTIFICATION_REMOVE;
> }
>
> static int32_t
All the flagging issues aside, I see what this patch does.
Previously removing a ivi-surface didn't work at all. With this patch,
whether ivi-surfaces are added or removed from the ivi-layer, the code
will always completely reconstruct the ivilayer->order.surface_list
from the pending list. In that sense:
Reviewed-by: Pekka Paalanen
Do you want me to push this patch as is?
Thanks,
pq
pgp3VYI0xPmki.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] Require WAYLAND_DISPLAY to be set instead of using wayland-0 as the default
On Wed, 12 Aug 2015 19:34:31 -0700
Dima Ryazanov wrote:
Hi Dima.
Reviewed-by: Ryo Munakata
Thanks.
> Although defaulting to wayland-0 seems convenient, it has an undesirable
> side effect: clients may unintentionally connect to the wrong compositor.
> Generally, it's safer to fail instead. Here's a real example:
>
> In Fedora 22, Gtk+ prefers Wayland over X11, though the default session is
> still
> a normal X11 Gnome session. When you launch a Gtk+ app, it will try Wayland,
> fail, then try X11, and succesfully start up. That works fine.
>
> Now suppose you launch Weston while running the Gnome session. Suddenly, all
> of the Gtk+ apps launched from Gnome will show up inside Weston instead.
> That's unexpected. There's also no good way to prevent that from happening
> (other than perhaps setting WAYLAND_DISPLAY to an invalid value when launching
> an app).
>
> Not using wayland-0 as the default will solve that problem: an app launched
> from the X11 Gnome session will use the X11 backend regardless of whether
> there's a wayland compositor running at the same time.
>
> Everything else should work as before. The compositor already sets
> the WAYLAND_DISPLAY when starting the session, so the lack of the default
> value
> should not make a difference to the user.
>
> Signed-off-by: Dima Ryazanov
> Acked-by: Pekka Paalanen
> Acked-by: Giulio Camuffo
> Acked-by: Daniel Stone
> Acked-by: Jasper St. Pierre
> ---
> doc/man/wl_display_connect.xml| 5 ++---
> doc/publican/sources/Protocol.xml | 8
> src/wayland-client.c | 10 ++
> src/wayland-server.c | 6 +++---
> 4 files changed, 15 insertions(+), 14 deletions(-)
>
> diff --git a/doc/man/wl_display_connect.xml b/doc/man/wl_display_connect.xml
> index 7e6e05c..ded3cbd 100644
> --- a/doc/man/wl_display_connect.xml
> +++ b/doc/man/wl_display_connect.xml
> @@ -57,9 +57,8 @@
>that was previously opened by a Wayland server. The server socket
> must
>be placed in XDG_RUNTIME_DIR for this function to
>find it. The name argument specifies the name of
> - the socket or NULL to use the default (which
> is
> - "wayland-0"). The environment variable
> - WAYLAND_DISPLAY replaces the default value. If
> + the socket or NULL to use the default
> + (which is the value of WAYLAND_DISPLAY). If
>WAYLAND_SOCKET is set, this function behaves like
>wl_display_connect_to_fd with the
> file-descriptor
>number taken from the environment variable.
> diff --git a/doc/publican/sources/Protocol.xml
> b/doc/publican/sources/Protocol.xml
> index 477063b..9464953 100644
> --- a/doc/publican/sources/Protocol.xml
> +++ b/doc/publican/sources/Protocol.xml
> @@ -60,10 +60,10 @@
> Wire Format
>
>The protocol is sent over a UNIX domain stream socket, where the
> endpoint
> - usually is named wayland-0
> - (although it can be changed via WAYLAND_DISPLAY
> - in the environment). The protocol is message-based. A
> - message sent by a client to the server is called request. A message
> + name is determined by the WAYLAND_DISPLAY
> + environment variable. Its value will usually be
> + wayland-0. The protocol is
> message-based.
> + A message sent by a client to the server is called request. A message
>from the server to a client is called event. Every message is
>structured as 32-bit words, values are represented in the host's
>byte-order.
> diff --git a/src/wayland-client.c b/src/wayland-client.c
> index 09c594a..ffbca4b 100644
> --- a/src/wayland-client.c
> +++ b/src/wayland-client.c
> @@ -764,8 +764,11 @@ connect_to_socket(const char *name)
>
> if (name == NULL)
> name = getenv("WAYLAND_DISPLAY");
> - if (name == NULL)
> - name = "wayland-0";
> + if (name == NULL) {
> + wl_log("error: WAYLAND_DISPLAY not set in the environment.\n");
> + errno = ENOENT;
> + return -1;
> + }
>
> fd = wl_os_socket_cloexec(PF_LOCAL, SOCK_STREAM, 0);
> if (fd < 0)
> @@ -869,8 +872,7 @@ wl_display_connect_to_fd(int fd)
> * \return A \ref wl_display object or \c NULL on failure
> *
> * Connect to the Wayland display named \c name. If \c name is \c NULL,
> - * its value will be replaced with the WAYLAND_DISPLAY environment
> - * variable if it is set, otherwise display "wayland-0" will be used.
> + * its value will be replaced with the WAYLAND_DISPLAY environment variable.
> *
> * \memberof wl_display
> */
> diff --git a/src/wayland-server.c b/src/wayland-server.c
> index 0f04f66..1ea53f9 100644
> --- a/src/wayland-server.c
> +++ b/src/wayland-server.c
> @@ -1209,8 +1209,8 @@ wl_display_add_socket_auto(struct wl_display *display)
> * connect to Wayland display.
> *
> * If NULL is passed as name, then it would look for WAYLAND_DISPLAY env
[PATCH weston 3/3] wayland: port the wayland backend to the new api
From: Giulio Camuffo
---
Makefile.am | 3 +
src/compositor-wayland.c | 220 ---
src/compositor-wayland.h | 58 +
src/main.c | 198 +-
4 files changed, 296 insertions(+), 183 deletions(-)
create mode 100644 src/compositor-wayland.h
diff --git a/Makefile.am b/Makefile.am
index 2f21930..d05bf88 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -73,6 +73,7 @@ weston_SOURCES = \
src/compositor.c\
src/compositor.h\
src/compositor-drm.h\
+ src/compositor-wayland.h\
src/input.c \
src/data-device.c \
src/screenshooter.c \
@@ -190,6 +191,7 @@ westoninclude_HEADERS = \
src/version.h \
src/compositor.h\
src/compositor-drm.h\
+ src/compositor-wayland.h\
src/timeline-object.h \
shared/matrix.h \
shared/config-parser.h \
@@ -283,6 +285,7 @@ wayland_backend_la_CFLAGS = \
$(AM_CFLAGS)
wayland_backend_la_SOURCES = \
src/compositor-wayland.c\
+ src/compositor-wayland.h\
shared/helpers.h
nodist_wayland_backend_la_SOURCES =\
protocol/fullscreen-shell-protocol.c\
diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
index 9788714..1f04e65 100644
--- a/src/compositor-wayland.c
+++ b/src/compositor-wayland.c
@@ -40,6 +40,7 @@
#include
#include "compositor.h"
+#include "compositor-wayland.h"
#include "gl-renderer.h"
#include "pixman-renderer.h"
#include "shared/helpers.h"
@@ -49,8 +50,6 @@
#include "fullscreen-shell-client-protocol.h"
#include "presentation_timing-server-protocol.h"
-#define WINDOW_TITLE "Weston Compositor"
-
struct wayland_backend {
struct weston_backend base;
struct weston_compositor *compositor;
@@ -71,6 +70,7 @@ struct wayland_backend {
int use_pixman;
int sprawl_across_outputs;
+ char *window_title;
struct theme *theme;
cairo_device_t *frame_device;
@@ -752,21 +752,15 @@ wayland_output_set_windowed(struct wayland_output *output)
{
struct wayland_backend *b =
(struct wayland_backend *)output->base.compositor->backend;
- int tlen;
char *title;
if (output->frame)
return 0;
if (output->name) {
- tlen = strlen(output->name) + strlen(WINDOW_TITLE " - ");
- title = malloc(tlen + 1);
- if (!title)
- return -1;
-
- snprintf(title, tlen + 1, WINDOW_TITLE " - %s", output->name);
+ title = strdup(output->name);
} else {
- title = strdup(WINDOW_TITLE);
+ title = strdup(b->window_title);
}
if (!b->theme) {
@@ -1083,65 +1077,6 @@ err_name:
}
static struct wayland_output *
-wayland_output_create_for_config(struct wayland_backend *b,
-struct weston_config_section *config_section,
-int option_width, int option_height,
-int option_scale, int32_t x, int32_t y)
-{
- struct wayland_output *output;
- char *mode, *t, *name, *str;
- int width, height, scale;
- uint32_t transform;
- unsigned int slen;
-
- weston_config_section_get_string(config_section, "name", &name, NULL);
- if (name) {
- slen = strlen(name);
- slen += strlen(WINDOW_TITLE " - ");
- str = malloc(slen + 1);
- if (str)
- snprintf(str, slen + 1, WINDOW_TITLE " - %s", name);
- free(name);
- name = str;
- }
- if (!name)
- name = strdup(WINDOW_TITLE);
-
- weston_config_section_get_string(config_section,
-"mode", &mode, "1024x600");
- if (sscanf(mode, "%dx%d", &width, &height) != 2) {
- weston_log("Invalid mode \"%s\" for output %s\n",
- mode, name);
- width = 1024;
- height = 640;
- }
- free(mode);
-
- if (option_width)
- width = option_width;
- if (option_height)
- height = option_height;
-
- weston_config_section_get_int(config_section, "scale", &scale, 1);
-
- if (option_scale)
- scale = option_scale;
-
- weston_config_section_
[PATCH weston 2/3] drm: port the drm backend to the new init api
From: Giulio Camuffo
---
Makefile.am | 3 +
src/compositor-drm.c | 234 ---
src/compositor-drm.h | 89
src/main.c | 127 +++-
4 files changed, 292 insertions(+), 161 deletions(-)
create mode 100644 src/compositor-drm.h
diff --git a/Makefile.am b/Makefile.am
index 76ab546..2f21930 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -72,6 +72,7 @@ weston_SOURCES = \
src/log.c \
src/compositor.c\
src/compositor.h\
+ src/compositor-drm.h\
src/input.c \
src/data-device.c \
src/screenshooter.c \
@@ -188,6 +189,7 @@ westonincludedir = $(includedir)/weston
westoninclude_HEADERS =\
src/version.h \
src/compositor.h\
+ src/compositor-drm.h\
src/timeline-object.h \
shared/matrix.h \
shared/config-parser.h \
@@ -251,6 +253,7 @@ drm_backend_la_CFLAGS = \
$(AM_CFLAGS)
drm_backend_la_SOURCES = \
src/compositor-drm.c\
+ src/compositor-drm.h\
$(INPUT_BACKEND_SOURCES)\
shared/helpers.h\
shared/timespec-util.h \
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index ce95d05..4c298fe 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -50,6 +50,7 @@
#include "shared/timespec-util.h"
#include "libbacklight.h"
#include "compositor.h"
+#include "compositor-drm.h"
#include "gl-renderer.h"
#include "pixman-renderer.h"
#include "libinput-seat.h"
@@ -73,17 +74,6 @@
#define GBM_BO_USE_CURSOR GBM_BO_USE_CURSOR_64X64
#endif
-static int option_current_mode = 0;
-
-enum output_config {
- OUTPUT_CONFIG_INVALID = 0,
- OUTPUT_CONFIG_OFF,
- OUTPUT_CONFIG_PREFERRED,
- OUTPUT_CONFIG_CURRENT,
- OUTPUT_CONFIG_MODE,
- OUTPUT_CONFIG_MODELINE
-};
-
struct drm_backend {
struct weston_backend base;
struct weston_compositor *compositor;
@@ -106,6 +96,7 @@ struct drm_backend {
uint32_t connector_allocator;
struct wl_listener session_listener;
uint32_t format;
+ bool option_current_mode;
/* we need these parameters in order to not fail drmModeAddFB2()
* due to out of bounds dimensions, and then mistakenly set
@@ -129,6 +120,10 @@ struct drm_backend {
int32_t cursor_width;
int32_t cursor_height;
+
+ void (*configure_output)(struct weston_compositor *compositor,
+const char *name,
+struct weston_drm_backend_output_config
*config);
};
struct drm_mode {
@@ -219,13 +214,6 @@ struct drm_sprite {
uint32_t formats[];
};
-struct drm_parameters {
- int connector;
- int tty;
- int use_pixman;
- const char *seat_id;
-};
-
static struct gl_renderer_interface *gl_renderer;
static const char default_seat[] = "seat0";
@@ -2026,47 +2014,26 @@ find_and_parse_output_edid(struct drm_backend *b,
-static int
-parse_modeline(const char *s, drmModeModeInfo *mode)
-{
- char hsync[16];
- char vsync[16];
- float fclock;
-
- mode->type = DRM_MODE_TYPE_USERDEF;
- mode->hskew = 0;
- mode->vscan = 0;
- mode->vrefresh = 0;
- mode->flags = 0;
-
- if (sscanf(s, "%f %hd %hd %hd %hd %hd %hd %hd %hd %15s %15s",
- &fclock,
- &mode->hdisplay,
- &mode->hsync_start,
- &mode->hsync_end,
- &mode->htotal,
- &mode->vdisplay,
- &mode->vsync_start,
- &mode->vsync_end,
- &mode->vtotal, hsync, vsync) != 11)
- return -1;
-
- mode->clock = fclock * 1000;
- if (strcmp(hsync, "+hsync") == 0)
- mode->flags |= DRM_MODE_FLAG_PHSYNC;
- else if (strcmp(hsync, "-hsync") == 0)
- mode->flags |= DRM_MODE_FLAG_NHSYNC;
- else
- return -1;
+static void
+parse_modeline(struct weston_drm_backend_modeline *modeline,
+ drmModeModeInfo *drm_mode)
+{
+ drm_mode->type = DRM_MODE_TYPE_USERDEF;
+ drm_mode->hskew = 0;
+ drm_mode->vscan = 0;
+ drm_mode->vrefresh = 0;
+ drm_mode->flags = modeline->flags;
+ drm_mode->clock = modeline->clock;
- if (strcmp(vsync, "+vsync") == 0)
- mode->flags |= DRM_M
Re: [PATCH weston 0/3] start making backends not weston specific
I don't know what's going on, git send-email failed after sending the 1/3 and it won't send the other two*. Anyway they are here: https://github.com/giucam/weston/commits/libweston-split *: Send this email? ([y]es|[n]o|[q]uit|[a]ll): a [Net::SMTP::SSL] Connection closed at /usr/lib/git-core/git-send-email line 1351. fatal: 'send-email' appears to be a git command, but we were not able to execute it. Maybe git-send-email is broken? 2015-08-13 12:30 GMT+02:00 Giulio Camuffo : > The first patch by Pekka adds some functions to ease a smooth migration > from the old way of initializing the backends to a new one which is > libweston friendly. > The other two patches make the drm and wayland backends use that new way. > The other backends will follow if we're ok with the direction this is going. > > Giulio Camuffo (2): > drm: port the drm backend to the new init api > wayland: port the wayland backend to the new api > > Pekka Paalanen (1): > compositor: prep for migration to new config system > > Makefile.am | 6 + > src/compositor-drm.c | 233 +-- > src/compositor-drm.h | 89 +++ > src/compositor-fbdev.c| 3 +- > src/compositor-headless.c | 3 +- > src/compositor-rdp.c | 3 +- > src/compositor-rpi.c | 3 +- > src/compositor-wayland.c | 219 +- > src/compositor-wayland.h | 58 +++ > src/compositor-x11.c | 3 +- > src/compositor.h | 21 ++- > src/main.c| 392 > -- > 12 files changed, 675 insertions(+), 358 deletions(-) > create mode 100644 src/compositor-drm.h > create mode 100644 src/compositor-wayland.h > > -- > 2.5.0 > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 0/3] start making backends not weston specific
The first patch by Pekka adds some functions to ease a smooth migration from the old way of initializing the backends to a new one which is libweston friendly. The other two patches make the drm and wayland backends use that new way. The other backends will follow if we're ok with the direction this is going. Giulio Camuffo (2): drm: port the drm backend to the new init api wayland: port the wayland backend to the new api Pekka Paalanen (1): compositor: prep for migration to new config system Makefile.am | 6 + src/compositor-drm.c | 233 +-- src/compositor-drm.h | 89 +++ src/compositor-fbdev.c| 3 +- src/compositor-headless.c | 3 +- src/compositor-rdp.c | 3 +- src/compositor-rpi.c | 3 +- src/compositor-wayland.c | 219 +- src/compositor-wayland.h | 58 +++ src/compositor-x11.c | 3 +- src/compositor.h | 21 ++- src/main.c| 392 -- 12 files changed, 675 insertions(+), 358 deletions(-) create mode 100644 src/compositor-drm.h create mode 100644 src/compositor-wayland.h -- 2.5.0 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston 1/3] compositor: prep for migration to new config system
From: Pekka Paalanen
Add new configuration argument to the backend_init() function, which
will replace the current argc, argv, and config arguments.
Next, each backend is converted individually, after which the unused
arguments will be removed.
Also add the skeleton to main.c for picking the right configuration path
by the backend.
Fix an error path that forgot to destroy weston_compositor.
Signed-off-by: Pekka Paalanen
---
src/compositor-drm.c | 3 +-
src/compositor-fbdev.c| 3 +-
src/compositor-headless.c | 3 +-
src/compositor-rdp.c | 3 +-
src/compositor-rpi.c | 3 +-
src/compositor-wayland.c | 3 +-
src/compositor-x11.c | 3 +-
src/compositor.h | 21 --
src/main.c| 71 ---
9 files changed, 93 insertions(+), 20 deletions(-)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 585169e..ce95d05 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -3182,7 +3182,8 @@ err_base:
WL_EXPORT int
backend_init(struct weston_compositor *compositor, int *argc, char *argv[],
-struct weston_config *config)
+struct weston_config *config,
+struct weston_backend_config *config_base)
{
struct drm_backend *b;
struct drm_parameters param = { 0, };
diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c
index 051a381..1431621 100644
--- a/src/compositor-fbdev.c
+++ b/src/compositor-fbdev.c
@@ -903,7 +903,8 @@ out_compositor:
WL_EXPORT int
backend_init(struct weston_compositor *compositor, int *argc, char *argv[],
-struct weston_config *config)
+struct weston_config *config,
+struct weston_backend_config *config_base)
{
struct fbdev_backend *b;
/* TODO: Ideally, available frame buffers should be enumerated using
diff --git a/src/compositor-headless.c b/src/compositor-headless.c
index dba21a6..ba0d8d7 100644
--- a/src/compositor-headless.c
+++ b/src/compositor-headless.c
@@ -260,7 +260,8 @@ err_free:
WL_EXPORT int
backend_init(struct weston_compositor *compositor,
int *argc, char *argv[],
-struct weston_config *config)
+struct weston_config *config,
+struct weston_backend_config *config_base)
{
int width = 1024, height = 640;
char *display_name = NULL;
diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c
index c221eb9..36c22d8 100644
--- a/src/compositor-rdp.c
+++ b/src/compositor-rdp.c
@@ -1269,7 +1269,8 @@ err_free_strings:
WL_EXPORT int
backend_init(struct weston_compositor *compositor, int *argc, char *argv[],
-struct weston_config *wconfig)
+struct weston_config *wconfig,
+struct weston_backend_config *config_base)
{
struct rdp_backend *b;
struct rdp_backend_config config;
diff --git a/src/compositor-rpi.c b/src/compositor-rpi.c
index 602cbee..f4b33ee 100644
--- a/src/compositor-rpi.c
+++ b/src/compositor-rpi.c
@@ -551,7 +551,8 @@ out_compositor:
WL_EXPORT int
backend_init(struct weston_compositor *compositor,
int *argc, char *argv[],
-struct weston_config *config)
+struct weston_config *config,
+struct weston_backend_config *config_base)
{
const char *transform = "normal";
struct rpi_backend *b;
diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
index f6c84d4..9788714 100644
--- a/src/compositor-wayland.c
+++ b/src/compositor-wayland.c
@@ -2049,7 +2049,8 @@ wayland_backend_destroy(struct wayland_backend *b)
WL_EXPORT int
backend_init(struct weston_compositor *compositor, int *argc, char *argv[],
-struct weston_config *config)
+struct weston_config *config,
+struct weston_backend_config *config_base)
{
struct wayland_backend *b;
struct wayland_output *output;
diff --git a/src/compositor-x11.c b/src/compositor-x11.c
index 73ba783..d18595d 100644
--- a/src/compositor-x11.c
+++ b/src/compositor-x11.c
@@ -1681,7 +1681,8 @@ err_free:
WL_EXPORT int
backend_init(struct weston_compositor *compositor, int *argc, char *argv[],
-struct weston_config *config)
+struct weston_config *config,
+struct weston_backend_config *config_base)
{
struct x11_backend *b;
int fullscreen = 0;
diff --git a/src/compositor.h b/src/compositor.h
index d1ca9ab..acf9016 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -607,9 +607,23 @@ enum weston_capability {
WESTON_CAP_VIEW_CLIP_MASK = 0x0010,
};
+struct weston_backend_output_config {
+ uint32_t transform;
+ int32_t width;
+ int32_t height;
+ int scale;
+};
+
struct weston_backend {
- void (*destroy)(struct weston_compositor *ec);
- void (*restore)(struct weston_compositor *ec);
+ void (*destroy)(struct weston_compositor *compositor);
+ void (*rest
Re: Proposed 1.9 release schedule
Hi all, this looks fine to me personally. I'll point out some specific feature cut-off points below, in case anyone wants to scream. On Wed, 12 Aug 2015 15:42:53 -0700 Bryce Harrington wrote: > We're coming up to our next scheduled release. I've got a few scattered > events and holidays but looking at my calendar, these dates look > feasible and fit the timeframe we wanted: > > * 8/14 (Friday) - 1.8.91 (1.9 alpha) The end of big new features. I think this will cut: - any changes or additions to protocols installed from Wayland - introducing the proxy wrapper in libwayland-client - require WAYLAND_DISPLAY, and the other env variable additions and changes in Wayland - building of libweston.so > > * 9/01 (Tuesday) - 1.8.92 (1.9 beta) > + Feature freeze Cuts: - pointer lock, if patching only Weston - Weston atomic - Weston dmabuf > > * 9/15 (Tuesday) - 1.8.93 (1.9 rc1) > + Final freeze > > * rc2 only if necessary > > * 9/22 (Tuesday) - 1.9.0 (1.9 release) > + Re-open trunk for 1.10 development To clarify, "cut" means the essential patches need to have landed, or they need to wait for 1.10 developement to open. Would you agree on the categorization between big and minor features, that is, alpha vs. beta? > > Notably, I'd like to shift from doing releases on Fridays to mid-week, > but that's mostly just for my own convenience. If anyone prefers > strongly that I stick with Friday releases let me know. > > I'm also shifting to calling the releases alpha/beta/rc instead of > alpha/rc1/rc2, since we don't typically consider that second one to be > an actual candidate for releasing. Again, I'm guessing no one but me > cares, but if anyone wants to stick with the old approach let me know. Yeah, that's cool. Referring to http://lists.freedesktop.org/archives/wayland-devel/2014-May/014955.html : - alpha: all big features landed, only minor, contained features after this - beta: only bug fixes after this - rc: only critical bug fixes after this Seems like a good idea to keep on using, right? Thanks, pq pgpl7a4mm2dYE.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
