Re: [PATCH wayland] shm, server, server-core: Move deprecated prototype
Hi, 2016-05-24 4:27 GMT+03:00 Yong Bakos : > From: Yong Bakos > > wayland-server-core.h contains the prototype of wl_shm_buffer_create, > which is marked WL_DEPRECATED. > > Move the prototype out of wayland-server-core.h and into the group of > deprecated prototypes in wayland-server.h. > Add the prototype before the implementation in wayland-shm.c. We can't do this. The deprecated things in wayland-server.h are there because they were deprecated before wayland-server-core.h was introduced, so wayland-server-core.h never had them to begin with. But if you move wl_shm_buffer_create now, code including wayland-server-core.h may break, and we guarantee backward compatibility. Cheers, Giulio > > This mimics the structure of deprecated implementations in the footer of > wayland-server.c, whose prototypes are in wayland-server.h. > > Signed-off-by: Yong Bakos > --- > src/wayland-server-core.h | 5 - > src/wayland-server.h | 5 + > src/wayland-shm.c | 5 + > 3 files changed, 10 insertions(+), 5 deletions(-) > > diff --git a/src/wayland-server-core.h b/src/wayland-server-core.h > index fa7f394..124699c 100644 > --- a/src/wayland-server-core.h > +++ b/src/wayland-server-core.h > @@ -475,11 +475,6 @@ wl_display_init_shm(struct wl_display *display); > uint32_t * > wl_display_add_shm_format(struct wl_display *display, uint32_t format); > > -struct wl_shm_buffer * > -wl_shm_buffer_create(struct wl_client *client, > -uint32_t id, int32_t width, int32_t height, > -int32_t stride, uint32_t format) WL_DEPRECATED; > - > void wl_log_set_handler_server(wl_log_func_t handler); > > #ifdef __cplusplus > diff --git a/src/wayland-server.h b/src/wayland-server.h > index 3124703..1b1a496 100644 > --- a/src/wayland-server.h > +++ b/src/wayland-server.h > @@ -90,6 +90,11 @@ void > wl_display_remove_global(struct wl_display *display, > struct wl_global *global) WL_DEPRECATED; > > +struct wl_shm_buffer * > +wl_shm_buffer_create(struct wl_client *client, > +uint32_t id, int32_t width, int32_t height, > +int32_t stride, uint32_t format) WL_DEPRECATED; > + > #endif > > #ifdef __cplusplus > diff --git a/src/wayland-shm.c b/src/wayland-shm.c > index 5efbd70..177c4a4 100644 > --- a/src/wayland-shm.c > +++ b/src/wayland-shm.c > @@ -618,6 +618,11 @@ wl_shm_buffer_end_access(struct wl_shm_buffer *buffer) > > /** \cond */ /* Deprecated functions below. */ > > +struct wl_shm_buffer * > +wl_shm_buffer_create(struct wl_client *client, > +uint32_t id, int32_t width, int32_t height, > +int32_t stride, uint32_t format) WL_DEPRECATED; > + > WL_EXPORT struct wl_shm_buffer * > wl_shm_buffer_create(struct wl_client *client, > uint32_t id, int32_t width, int32_t height, > -- > 2.7.2 > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[RFC wayland v1 1/1] private, server: Make define consistent, reorder include
From: Yong Bakos
wayland-private.h defines WL_HIDE_DEPRECATED with a token-string, which
is unnecessary. Remove the token-string from the define.
wayland-server.h includes wayland-server-protocol.h at the end of the file,
after the ifndef WL_HIDE_DEPRECATED block, but it is not necessary for the
include to follow the ifndef block. Move the include to the top of the file,
for clarity.
Place the use of extern "C" inside the ifndef WL_HIDE_DEPRECATED block, since
an empty extern "C" block would be pointless.
Signed-off-by: Yong Bakos
---
src/wayland-private.h | 2 +-
src/wayland-server.h | 9 -
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/src/wayland-private.h b/src/wayland-private.h
index 045109b..14baf28 100644
--- a/src/wayland-private.h
+++ b/src/wayland-private.h
@@ -31,7 +31,7 @@
#include
#include
-#define WL_HIDE_DEPRECATED 1
+#define WL_HIDE_DEPRECATED
#include "wayland-util.h"
diff --git a/src/wayland-server.h b/src/wayland-server.h
index 3124703..156e39d 100644
--- a/src/wayland-server.h
+++ b/src/wayland-server.h
@@ -37,13 +37,14 @@
#define WAYLAND_SERVER_H
#include "wayland-server-core.h"
+#include "wayland-server-protocol.h"
+
+#ifndef WL_HIDE_DEPRECATED
#ifdef __cplusplus
extern "C" {
#endif
-#ifndef WL_HIDE_DEPRECATED
-
struct wl_object {
const struct wl_interface *interface;
const void *implementation;
@@ -90,12 +91,10 @@ void
wl_display_remove_global(struct wl_display *display,
struct wl_global *global) WL_DEPRECATED;
-#endif
-
#ifdef __cplusplus
}
#endif
-#include "wayland-server-protocol.h"
+#endif
#endif
--
2.7.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[RFC wayland v1 0/1] private, server: Make define consistent, reorder include
From: Yong Bakos I believe I'm making sane decisions in this patch, but I'm marking it RFC and cc'ing Giulio specifically. If I'm wrong here, please do not spend a lot of time explaining why (because if this isn't sane, then I don't want to take up your time). Thank you, yong Yong Bakos (1): private, server: Make define consistent, reorder include src/wayland-private.h | 2 +- src/wayland-server.h | 9 - 2 files changed, 5 insertions(+), 6 deletions(-) -- 2.7.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [ANNOUNCE] wayland 1.10.91
On Mon, May 23, 2016 at 02:22:45PM -0700, Bryce Harrington wrote: > On Fri, May 20, 2016 at 03:35:15PM -0700, Bryce Harrington wrote: > > On Wed, May 11, 2016 at 12:11:50PM -0700, Bryce Harrington wrote: > > > On Fri, May 06, 2016 at 02:17:23PM +0300, Pekka Paalanen wrote: > > > > On Wed, 4 May 2016 11:46:23 -0700 > > > > Bryce Harrington wrote: > > > > > > > > > On Wed, May 04, 2016 at 12:55:16AM -0700, Bryce Harrington wrote: > > > > > > Here's the alpha for the upcoming 1.11 release. I'll summarize the > > > > > > major features for this release in the beta announcement, but see > > > > > > below > > > > > > for the detailed listing. > > > > > > > > > > > > The schedule going forward is: > > > > > > > > > > > > √ 1.11-alpha on May 3rd. Major features done by this point. > > > > > > It looks like someone (pq?) has marked some patches we decided to leave > > > for post-1.11 as deferred in patchwork. I've followed suit and moved > > > other patchsets there which are new APIs or that sound like feature > > > work. > > > > The patch queue has been fully processed now, except for a few items. > > > > https://patchwork.freedesktop.org/project/wayland/patches/ > > > > What wasn't landable as-is has been marked as deferred for now, and I > > will move them back to the main queue once the release is out. > > > > > 3. xwayland drag-and-drop window creation [Carlos] > > >- Looks ok to be but xwayland isn't my area > > >- Been in the queue a long time, but no reviews to date > > >- From the commit description sounds WIP-ish and that there was > > > planned some followup work, but not sure if that happened? > > > > https://patchwork.freedesktop.org/patch/74663/ > > > > I'm still unsure what to do with this drag-and-drop patch. I'm > > defaulting to defer it at this point, but it seems to fix a legitimate > > crash bug so I'm reticent to kick it down the road without at least a > > next action identified. It's a short patch, can someone take a quick > > look and give an opinion on it? > > Due to lack of response I've deferred this one. As stated in the other mail thread that brought up this patch, I think it seems better to land it now, rather than keep crashing. When I tested, it was very easy to crash weston by just dragging from an Xwayland window outside of its frame (onto the desktop shell client). Jonas > > Bryce > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland] shm, server, server-core: Move deprecated prototype
From: Yong Bakos wayland-server-core.h contains the prototype of wl_shm_buffer_create, which is marked WL_DEPRECATED. Move the prototype out of wayland-server-core.h and into the group of deprecated prototypes in wayland-server.h. Add the prototype before the implementation in wayland-shm.c. This mimics the structure of deprecated implementations in the footer of wayland-server.c, whose prototypes are in wayland-server.h. Signed-off-by: Yong Bakos --- src/wayland-server-core.h | 5 - src/wayland-server.h | 5 + src/wayland-shm.c | 5 + 3 files changed, 10 insertions(+), 5 deletions(-) diff --git a/src/wayland-server-core.h b/src/wayland-server-core.h index fa7f394..124699c 100644 --- a/src/wayland-server-core.h +++ b/src/wayland-server-core.h @@ -475,11 +475,6 @@ wl_display_init_shm(struct wl_display *display); uint32_t * wl_display_add_shm_format(struct wl_display *display, uint32_t format); -struct wl_shm_buffer * -wl_shm_buffer_create(struct wl_client *client, -uint32_t id, int32_t width, int32_t height, -int32_t stride, uint32_t format) WL_DEPRECATED; - void wl_log_set_handler_server(wl_log_func_t handler); #ifdef __cplusplus diff --git a/src/wayland-server.h b/src/wayland-server.h index 3124703..1b1a496 100644 --- a/src/wayland-server.h +++ b/src/wayland-server.h @@ -90,6 +90,11 @@ void wl_display_remove_global(struct wl_display *display, struct wl_global *global) WL_DEPRECATED; +struct wl_shm_buffer * +wl_shm_buffer_create(struct wl_client *client, +uint32_t id, int32_t width, int32_t height, +int32_t stride, uint32_t format) WL_DEPRECATED; + #endif #ifdef __cplusplus diff --git a/src/wayland-shm.c b/src/wayland-shm.c index 5efbd70..177c4a4 100644 --- a/src/wayland-shm.c +++ b/src/wayland-shm.c @@ -618,6 +618,11 @@ wl_shm_buffer_end_access(struct wl_shm_buffer *buffer) /** \cond */ /* Deprecated functions below. */ +struct wl_shm_buffer * +wl_shm_buffer_create(struct wl_client *client, +uint32_t id, int32_t width, int32_t height, +int32_t stride, uint32_t format) WL_DEPRECATED; + WL_EXPORT struct wl_shm_buffer * wl_shm_buffer_create(struct wl_client *client, uint32_t id, int32_t width, int32_t height, -- 2.7.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland] server, server-core: Minimize fwd decs, use macro, and format
From: Yong Bakos
wayland-server.h: Adjust line breaks between prototypes.
wayland-server-core.h:
Adjust line breaks between prototypes.
Adjust space between splats and identifiers.
Remove unconventional linebreak before first parameter.
Add line breaks after return types.
Remove unnecessary forward declarations, and:
- move 'struct wl_client' declaration close to the dependent typedef
- tastefully move 'wl_shm_buffer_get' to leverage the return type
Replace explicit __attribute__ with WL_PRINTF macro.
Signed-off-by: Yong Bakos
---
src/wayland-server-core.h | 51 +++
src/wayland-server.h | 2 +-
2 files changed, 30 insertions(+), 23 deletions(-)
diff --git a/src/wayland-server-core.h b/src/wayland-server-core.h
index fa7f394..408c137 100644
--- a/src/wayland-server-core.h
+++ b/src/wayland-server-core.h
@@ -42,8 +42,6 @@ enum {
WL_EVENT_ERROR= 0x08
};
-struct wl_event_loop;
-struct wl_event_source;
typedef int (*wl_event_loop_fd_func_t)(int fd, uint32_t mask, void *data);
typedef int (*wl_event_loop_timer_func_t)(void *data);
typedef int (*wl_event_loop_signal_func_t)(int signal_number, void *data);
@@ -85,7 +83,6 @@ wl_event_source_remove(struct wl_event_source *source);
void
wl_event_source_check(struct wl_event_source *source);
-
int
wl_event_loop_dispatch(struct wl_event_loop *loop, int timeout);
@@ -100,20 +97,16 @@ wl_event_loop_add_idle(struct wl_event_loop *loop,
int
wl_event_loop_get_fd(struct wl_event_loop *loop);
-struct wl_client;
-struct wl_display;
struct wl_listener;
-struct wl_resource;
-struct wl_global;
+
typedef void (*wl_notify_func_t)(struct wl_listener *listener, void *data);
void
wl_event_loop_add_destroy_listener(struct wl_event_loop *loop,
- struct wl_listener * listener);
+ struct wl_listener *listener);
struct wl_listener *
-wl_event_loop_get_destroy_listener(
- struct wl_event_loop *loop,
+wl_event_loop_get_destroy_listener(struct wl_event_loop *loop,
wl_notify_func_t notify);
struct wl_display *
@@ -143,6 +136,8 @@ wl_display_run(struct wl_display *display);
void
wl_display_flush_clients(struct wl_display *display);
+struct wl_client;
+
typedef void (*wl_global_bind_func_t)(struct wl_client *client, void *data,
uint32_t version, uint32_t id);
@@ -360,16 +355,17 @@ void
wl_resource_queue_event(struct wl_resource *resource,
uint32_t opcode, ...);
-void wl_resource_queue_event_array(struct wl_resource *resource,
- uint32_t opcode, union wl_argument *args);
+void
+wl_resource_queue_event_array(struct wl_resource *resource,
+ uint32_t opcode, union wl_argument *args);
/* msg is a printf format string, variable args are its args. */
void
wl_resource_post_error(struct wl_resource *resource,
- uint32_t code, const char *msg, ...)
- __attribute__ ((format (printf, 3, 4)));
+ uint32_t code, const char *msg, ...) WL_PRINTF(3, 4);
-void wl_resource_post_no_memory(struct wl_resource *resource);
+void
+wl_resource_post_no_memory(struct wl_resource *resource);
struct wl_display *
wl_client_get_display(struct wl_client *client);
@@ -378,11 +374,13 @@ struct wl_resource *
wl_resource_create(struct wl_client *client,
const struct wl_interface *interface,
int version, uint32_t id);
+
void
wl_resource_set_implementation(struct wl_resource *resource,
const void *implementation,
void *data,
wl_resource_destroy_func_t destroy);
+
void
wl_resource_set_dispatcher(struct wl_resource *resource,
wl_dispatcher_func_t dispatcher,
@@ -392,25 +390,35 @@ wl_resource_set_dispatcher(struct wl_resource *resource,
void
wl_resource_destroy(struct wl_resource *resource);
+
uint32_t
wl_resource_get_id(struct wl_resource *resource);
+
struct wl_list *
wl_resource_get_link(struct wl_resource *resource);
+
struct wl_resource *
wl_resource_from_link(struct wl_list *resource);
+
struct wl_resource *
wl_resource_find_for_client(struct wl_list *list, struct wl_client *client);
+
struct wl_client *
wl_resource_get_client(struct wl_resource *resource);
+
void
wl_resource_set_user_data(struct wl_resource *resource, void *data);
+
void *
wl_resource_get_user_data(struct wl_resource *resource);
+
int
wl_resource_get_version(struct wl_resource *resource);
+
void
wl_resource_set_destructor(struct wl_resource *resource,
wl_resource_destroy_func_t destroy);
+
int
wl_resource_instance_of(struct wl_resource *resource,
const struct wl_interface *interface,
@@ -418,7 +426,8 @@ wl_resourc
[PATCH wayland] client-core: Add missing line breaks
From: Yong Bakos Signed-off-by: Yong Bakos --- src/wayland-client-core.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/wayland-client-core.h b/src/wayland-client-core.h index b1d6515..dfd3e18 100644 --- a/src/wayland-client-core.h +++ b/src/wayland-client-core.h @@ -150,10 +150,12 @@ wl_proxy_marshal_constructor_versioned(struct wl_proxy *proxy, const struct wl_interface *interface, uint32_t version, ...); + struct wl_proxy * wl_proxy_marshal_array_constructor(struct wl_proxy *proxy, uint32_t opcode, union wl_argument *args, const struct wl_interface *interface); + struct wl_proxy * wl_proxy_marshal_array_constructor_versioned(struct wl_proxy *proxy, uint32_t opcode, -- 2.7.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: writing Was: [PATCH weston 1/5] gl-renderer: Rename gl_renderer_create to gl_renderer_display_create
On Wed, May 18, 2016 at 06:33:15PM -0400, Yong Bakos wrote: > Hi, > I'm partly to blame for the bikeshedding on writing, yet believe me, > I'm always asking "is this worth it?", prioritizing corrections/clarity > over mere style judgements, and am definitely sensitive to > everyone's cognitive bandwidth. My goal is high quality documentation > for Wayland, and I am open to suggestions on how to best deliver that. > > (Maybe we can chat about this over IRC rather than further hijack this > thread.) > > On May 18, 2016, at 10:31 AM, Daniel Stone wrote: > > > > Hi, > > > > On 18 May 2016 at 15:25, Derek Foreman wrote: > >> On 18/05/16 08:41 AM, Mike Blumenkrantz wrote: > >>> In fairness, we'd likely be less short on review bandwidth if the > >>> majority of that bandwidth was not in use to make/revise trivial > >>> criticisms such as whitespace usage and comment grammar which are > >>> guaranteed to be cleaned up in future patches; this leads to burnout on > >>> both the code-writing side as well as the reviewing side since everyone > >>> has become hyper attuned to the insignificant and non-functional > >>> minutiae of patches rather than focusing more on expediting the > >>> technical development of the protocol. > > I agree with the crux of Mike's point. Yet, should trivial correctness > be revised before merging or should post-merge corrections clutter the > blame history? (Rhetorical question.) > > > >> Fair points, though I'm not certain "will certainly get fixed up later" > >> is a given. Certainly indenting and basic style is a mechanical problem > >> that could be tested pre-commit hooks, and there should be no reason to > >> bike shed that on the list at all. > > Yes! > > > >> Grammar probably needs more serious consideration for protocol doc than > >> elsewhere due to its potential impact on compositor implementors - but > >> ever there probably not to the degree we're seeing lately. > >> > >> Follow up commits that do nothing but change style and grammar can make > >> "git blame" less useful (when trying to figure out who would best review > >> a piece of code - not just "agh who wrote this stupid bug") and > >> provide churn for very little benefit, imho. > > > > Yeah, I agree. I get that the bikeshedding can be annoying; I do (for > > that reason, if no other) like tagging commits as 'RFC' or similar, > > which is effectively, 'please just check out the technical concept and > > don't worry about memory leaks or spelling mistakes right now'. But > > given that it's pretty trivial to fix up, and you're likely to have to > > rebase _anyway_, I don't see the harm in doing one round of review for > > clarity. > > > > Generally, there's no need to send out a subsequent revision round > > just because someone has noted some typos - send it again if you need > > a resend anyway to get people to pick it up after a rebase, or if > > there have been notable changes, but you shouldn't be arriving at v17 > > just because you have difficulty spelling. > > Perhaps non-technical suggestions should be sent only directly to the > author, for consideration in incorporating in the event of subsequent > revisions, and we not send these to the list? This gives the author > the benefit of the information, and does not clutter the list with > non-technical reviews. No, I don't think we need special rules for such things. Just send them to the list like anything else. If you've done a spelling/grammar check then posting it publically means the next reviewer knows they don't need to comment on the same stuff and can focus on something else. In general, we don't need to bikeshed the bikeshedding. ;-) > > Similarly, 'no, I disagree' is a reasonable response to someone > > bikeshedding your exact choice of variables or naming. Review is meant > > to be a discussion, not something you just have to unilaterally > > acqiuesce to. > > > >> While we're drifting just slightly off topic here, I'm also concerned > >> about the basic usage of some of our tags: > >> > >> Reviewed-by: indicates rigorous technical review *AND* a firm > >> conviction that the feature is important and should be included. > >> > >> Acked-by: Indicates a firm conviction that the feature is important and > >> should be included, but no rigorous review has taken place. > >> > >> Signed-off-by: Indicates an assumption of responsibility for the code. > > The rigor is important. We should add this to: > https://wayland.freedesktop.org/reviewing.html. That's all fine but frankly I don't see this as a serious problem in practice. The real problem we have is more that patches aren't getting *enough* R-b's. When landing patches I do take into account who gave the R-b, and am aware that each of us has areas we're stronger in than others. I'm guessing here that pq takes this into account as well. I'd rather have excessive R-b's than none. A good technique I've seen (and tried to emulate myself) is to state what aspects of the
Re: [ANNOUNCE] wayland 1.10.91
On Fri, May 20, 2016 at 03:35:15PM -0700, Bryce Harrington wrote: > On Wed, May 11, 2016 at 12:11:50PM -0700, Bryce Harrington wrote: > > On Fri, May 06, 2016 at 02:17:23PM +0300, Pekka Paalanen wrote: > > > On Wed, 4 May 2016 11:46:23 -0700 > > > Bryce Harrington wrote: > > > > > > > On Wed, May 04, 2016 at 12:55:16AM -0700, Bryce Harrington wrote: > > > > > Here's the alpha for the upcoming 1.11 release. I'll summarize the > > > > > major features for this release in the beta announcement, but see > > > > > below > > > > > for the detailed listing. > > > > > > > > > > The schedule going forward is: > > > > > > > > > > √ 1.11-alpha on May 3rd. Major features done by this point. > > > > It looks like someone (pq?) has marked some patches we decided to leave > > for post-1.11 as deferred in patchwork. I've followed suit and moved > > other patchsets there which are new APIs or that sound like feature > > work. > > The patch queue has been fully processed now, except for a few items. > > https://patchwork.freedesktop.org/project/wayland/patches/ > > What wasn't landable as-is has been marked as deferred for now, and I > will move them back to the main queue once the release is out. > > > 3. xwayland drag-and-drop window creation [Carlos] > >- Looks ok to be but xwayland isn't my area > >- Been in the queue a long time, but no reviews to date > >- From the commit description sounds WIP-ish and that there was > > planned some followup work, but not sure if that happened? > > https://patchwork.freedesktop.org/patch/74663/ > > I'm still unsure what to do with this drag-and-drop patch. I'm > defaulting to defer it at this point, but it seems to fix a legitimate > crash bug so I'm reticent to kick it down the road without at least a > next action identified. It's a short patch, can someone take a quick > look and give an opinion on it? Due to lack of response I've deferred this one. Bryce ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston v3] configure: unify wayland-client and wayland-server requirements
On Mon, May 23, 2016 at 11:43:29AM +0300, Pekka Paalanen wrote: > From: Pekka Paalanen > > This introduces a variable common for both wayland-client and > wayland-server required version number. As most developers usually build > everything, testing server and client version requirements separately is > more poorly tested than version requirements in general. The server > requirement being greater than the client requirement will mask any > issues from forgetting to bump the client requirement appropriately. > Therefore the requirements are unified. > > This bumps wayland-client requirement to 1.10.0, on par with the > existing wayland-server requirement. > > Only the checks which explicitly defined a version are updated, > unversioned checks are left as is. > > The variable style follows that of Mesa. > > This patch is based on the similar patch by Bryce Harrington that used > m4_define instead of a variable. Since that's such a minor change, I'll just squash this to mine. Bryce > Cc: Bryce Harrington > Cc: Quentin Glidic > Signed-off-by: Pekka Paalanen > --- > configure.ac | 13 - > 1 file changed, 8 insertions(+), 5 deletions(-) > > diff --git a/configure.ac b/configure.ac > index e1300b4..e4516c1 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -11,6 +11,9 @@ AC_INIT([weston], > [weston], > [http://wayland.freedesktop.org]) > > +# External dependency versions > +WAYLAND_REQUIRED="1.10.0" > + > AC_SUBST([WESTON_VERSION_MAJOR], [weston_major_version]) > AC_SUBST([WESTON_VERSION_MINOR], [weston_minor_version]) > AC_SUBST([WESTON_VERSION_MICRO], [weston_micro_version]) > @@ -60,7 +63,7 @@ AC_CHECK_HEADERS([execinfo.h]) > > AC_CHECK_FUNCS([mkostemp strchrnul initgroups posix_fallocate]) > > -COMPOSITOR_MODULES="wayland-server >= 1.10.0 pixman-1 >= 0.25.2" > +COMPOSITOR_MODULES="wayland-server >= $WAYLAND_REQUIRED pixman-1 >= 0.25.2" > > AC_CONFIG_FILES([doc/doxygen/tools.doxygen doc/doxygen/tooldev.doxygen]) > > @@ -193,7 +196,7 @@ AM_CONDITIONAL(ENABLE_WAYLAND_COMPOSITOR, > if test x$enable_wayland_compositor = xyes -a x$enable_egl = xyes; then >AC_DEFINE([BUILD_WAYLAND_COMPOSITOR], [1], > [Build the Wayland (nested) compositor]) > - PKG_CHECK_MODULES(WAYLAND_COMPOSITOR, [wayland-client >= 1.5.91 > wayland-egl wayland-cursor]) > + PKG_CHECK_MODULES(WAYLAND_COMPOSITOR, [wayland-client >= $WAYLAND_REQUIRED > wayland-egl wayland-cursor]) > fi > > > @@ -335,7 +338,7 @@ AM_CONDITIONAL(ENABLE_VAAPI_RECORDER, test "x$have_libva" > = xyes) > > PKG_CHECK_MODULES(CAIRO, [cairo]) > > -PKG_CHECK_MODULES(TEST_CLIENT, [wayland-client >= 1.10.0]) > +PKG_CHECK_MODULES(TEST_CLIENT, [wayland-client >= $WAYLAND_REQUIRED]) > > AC_ARG_ENABLE(simple-clients, >AS_HELP_STRING([--disable-simple-clients], > @@ -389,9 +392,9 @@ AM_CONDITIONAL(BUILD_CLIENTS, test x$enable_clients = > xyes) > if test x$enable_clients = xyes; then >AC_DEFINE([BUILD_CLIENTS], [1], [Build the Wayland clients]) > > - PKG_CHECK_MODULES(CLIENT, [wayland-client >= 1.5.91 cairo >= 1.10.0 > xkbcommon wayland-cursor]) > + PKG_CHECK_MODULES(CLIENT, [wayland-client >= $WAYLAND_REQUIRED cairo >= > 1.10.0 xkbcommon wayland-cursor]) >PKG_CHECK_MODULES(SERVER, [wayland-server]) > - PKG_CHECK_MODULES(WESTON_INFO, [wayland-client >= 1.5.91]) > + PKG_CHECK_MODULES(WESTON_INFO, [wayland-client >= $WAYLAND_REQUIRED]) > ># Only check for cairo-egl if a GL or GLES renderer requested >AS_IF([test "x$cairo_modules" = "xcairo-gl" -o "x$cairo_modules" = > "xcairo-glesv2"], [ > -- > 2.7.3 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston v3] build: Define wayland prereq version
Establishes a single variable for defining the libwayland version requirements. Enforces the same version dependency between libwayland-client and libwayland-server, as per the 1.11 release discussions. This also sets wayland-client's required version to 1.10, same as for the server. Signed-off-by: Bryce Harrington --- configure.ac | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/configure.ac b/configure.ac index e1300b4..d034907 100644 --- a/configure.ac +++ b/configure.ac @@ -11,6 +11,8 @@ AC_INIT([weston], [weston], [http://wayland.freedesktop.org]) +WAYLAND_PREREQ_VERSION="1.10.0" + AC_SUBST([WESTON_VERSION_MAJOR], [weston_major_version]) AC_SUBST([WESTON_VERSION_MINOR], [weston_minor_version]) AC_SUBST([WESTON_VERSION_MICRO], [weston_micro_version]) @@ -60,7 +62,7 @@ AC_CHECK_HEADERS([execinfo.h]) AC_CHECK_FUNCS([mkostemp strchrnul initgroups posix_fallocate]) -COMPOSITOR_MODULES="wayland-server >= 1.10.0 pixman-1 >= 0.25.2" +COMPOSITOR_MODULES="wayland-server >= $WAYLAND_PREREQ_VERSION pixman-1 >= 0.25.2" AC_CONFIG_FILES([doc/doxygen/tools.doxygen doc/doxygen/tooldev.doxygen]) @@ -193,7 +195,7 @@ AM_CONDITIONAL(ENABLE_WAYLAND_COMPOSITOR, if test x$enable_wayland_compositor = xyes -a x$enable_egl = xyes; then AC_DEFINE([BUILD_WAYLAND_COMPOSITOR], [1], [Build the Wayland (nested) compositor]) - PKG_CHECK_MODULES(WAYLAND_COMPOSITOR, [wayland-client >= 1.5.91 wayland-egl wayland-cursor]) + PKG_CHECK_MODULES(WAYLAND_COMPOSITOR, [wayland-client >= $WAYLAND_PREREQ_VERSION wayland-egl wayland-cursor]) fi @@ -335,7 +337,7 @@ AM_CONDITIONAL(ENABLE_VAAPI_RECORDER, test "x$have_libva" = xyes) PKG_CHECK_MODULES(CAIRO, [cairo]) -PKG_CHECK_MODULES(TEST_CLIENT, [wayland-client >= 1.10.0]) +PKG_CHECK_MODULES(TEST_CLIENT, [wayland-client >= $WAYLAND_PREREQ_VERSION]) AC_ARG_ENABLE(simple-clients, AS_HELP_STRING([--disable-simple-clients], @@ -389,9 +391,9 @@ AM_CONDITIONAL(BUILD_CLIENTS, test x$enable_clients = xyes) if test x$enable_clients = xyes; then AC_DEFINE([BUILD_CLIENTS], [1], [Build the Wayland clients]) - PKG_CHECK_MODULES(CLIENT, [wayland-client >= 1.5.91 cairo >= 1.10.0 xkbcommon wayland-cursor]) + PKG_CHECK_MODULES(CLIENT, [wayland-client >= $WAYLAND_PREREQ_VERSION cairo >= 1.10.0 xkbcommon wayland-cursor]) PKG_CHECK_MODULES(SERVER, [wayland-server]) - PKG_CHECK_MODULES(WESTON_INFO, [wayland-client >= 1.5.91]) + PKG_CHECK_MODULES(WESTON_INFO, [wayland-client >= $WAYLAND_PREREQ_VERSION]) # Only check for cairo-egl if a GL or GLES renderer requested AS_IF([test "x$cairo_modules" = "xcairo-gl" -o "x$cairo_modules" = "xcairo-glesv2"], [ -- 1.9.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [GSoC] The coding begins
On 23.05.2016 15:56, Pekka Paalanen wrote: > Hi Armin, > Hello. > the community bonding period is over, and today is the first day of the > official coding period. How is it going? :-) > I was busy this past week, but now the things started to calm down. > We had a chat in IRC a while back, and I asked for some things: > > - a place where you will report your weekly progress (a website), which > accumulates into something of a log of the whole GSoC project > Yes, we agreed on a blog-like site. I just finished setting up a personal blog @ blogspot where I'll report my progress (weekly), as noted in "The First Post". https://armin-gsoc.blogspot.com > - some project plans, a hierarchical list of tasks and sub-tasks, which > you would update as you find new tasks and close old ones (you can > use fd.o Phabricator for this if you want!) > > In fact, I would recommend taking a look at Phabricator and use as much > of it as you can. It would be possible to create a personal project for > you (I use that at Collabora to track all my jobs) where you can put > all your Tasks. We could also do patch review there later, perhaps. > There is also a wiki, but I believe you weren't so thrilled about that > idea. ;-) > I haven't used Phabricator, and I don't think I'll need to. I can keep track of things I have to do by myself. You can always ask for progress though, and I'll report on the blog. As for the tasks, I'll once again recap on how I planned to get this done: - Setup a testing framework, where I can emulate a no-output environment and hotplug automatically. The plan was to use the weston test suite. I'll manually test no-output at startup scenario using x11 backend's --output-count=0 parameter. - Get weston to start without any outputs present (again, x11 backend and --output-count=0 come in handy here). - Once that's finished, make weston (and at least apps from the weston tree) survive when all outputs have been removed. I will be really happy if this gets solved while solving the task above, but I still have to account for it (this is where the test suite will come in handy). Once the following tasks have been finished, I'll submit a first part of my GSOC project for review to the wayland mailing list. While going through the review process, we can start discussing ideas on how to implement the second part of my proposed changes - the extended outputs. At the moment, I'm not really familiar with the topic, but I'll get to it as soon as possible. Now, while I do plan to do all of the tasks above right before midterms, it's possible that it may slip a bit further and take, lets say, until end of June. That still gives me plenty of time to work on the second part of my proposal. > Could you also reiterate your schedules, how long and much studies will > be taking time from GSoC? > Sure. I still have classes to attend to, but only for this and next week. After that, the end terms period starts, which will be happening in the same period the GSoC midterms are happening. After June 22nd, all my end terms are over, and I can work full time until end of GSoC (unless something else comes out, in which case I'll notify you of the changes). While I'm still attending classes, I won't be available at all (or will be, but for a really short amount of time) on Monday through Wednesday. I'll be mostly (but still not fully available on Thursday and Friday). And of course, I'll be always available during weekend. When the classes end (in two weeks from today), I'll be mostly available on any working day and fully available during weekend. I might not be available just the day before a really important exam, but I think that won't be a problem, as it will be 3 days at most in the 3 weeks period. > There is no need to accumulate a whole summer's worth of development in > GitHub. I recommend sending patches towards upstream as soon as you > think they are applicable. Ideally everything you do lands upstream, > but it's not mandatory, of course. Weston is a moving goal, especially > libweston going on, so unmerged patches will need rebasing from time to > time. > I set up a weston repository at github. You can access it at: https://github.com/krezovic/weston I need to commit my work somewhere, as I'm often clumsy and end up deleting my home dir or stuff like that. I'll submit patches for review often, so they don't accumulate and so they will be easier to review, in case one feature needs to depend on another. > > Thanks, > pq > That's all for now. Cheers signature.asc Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[GSoC] The coding begins
Hi Armin, the community bonding period is over, and today is the first day of the official coding period. How is it going? :-) We had a chat in IRC a while back, and I asked for some things: - a place where you will report your weekly progress (a website), which accumulates into something of a log of the whole GSoC project - some project plans, a hierarchical list of tasks and sub-tasks, which you would update as you find new tasks and close old ones (you can use fd.o Phabricator for this if you want!) In fact, I would recommend taking a look at Phabricator and use as much of it as you can. It would be possible to create a personal project for you (I use that at Collabora to track all my jobs) where you can put all your Tasks. We could also do patch review there later, perhaps. There is also a wiki, but I believe you weren't so thrilled about that idea. ;-) Could you also reiterate your schedules, how long and much studies will be taking time from GSoC? There is no need to accumulate a whole summer's worth of development in GitHub. I recommend sending patches towards upstream as soon as you think they are applicable. Ideally everything you do lands upstream, but it's not mandatory, of course. Weston is a moving goal, especially libweston going on, so unmerged patches will need rebasing from time to time. Thanks, pq pgpT_g6_n8MwF.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v2 libinput 1/2] udev: mark ALPS touchpads fw version 300 as wobbly touchpads
Hi, On 23-05-16 06:49, Peter Hutterer wrote: Includes the Dell Lattitude E5420 but since all alps touchpads with the same fw version are the same (as far as we know) hooking this off the firmware version should cover this generation. https://bugzilla.redhat.com/show_bug.cgi?id=1336084 Signed-off-by: Peter Hutterer Series looks good to me: Reviewed-by: Hans de Goede Regards, Hans --- Changes to v1: - hook onto fwversion 300 rather than the E5420 only udev/90-libinput-model-quirks.hwdb | 4 1 file changed, 4 insertions(+) diff --git a/udev/90-libinput-model-quirks.hwdb b/udev/90-libinput-model-quirks.hwdb index 147fec2..305fed0 100644 --- a/udev/90-libinput-model-quirks.hwdb +++ b/udev/90-libinput-model-quirks.hwdb @@ -26,6 +26,10 @@ libinput:name:*AlpsPS/2 ALPS DualPoint TouchPad:fwversion:800 libinput:name:*AlpsPS/2 ALPS GlidePoint:fwversion:800 LIBINPUT_ATTR_SIZE_HINT=100x55 +libinput:name:*AlpsPS/2 ALPS DualPoint TouchPad:fwversion:300 +libinput:name:*AlpsPS/2 ALPS GlidePoint:fwversion:300 + LIBINPUT_MODEL_WOBBLY_TOUCHPAD=1 + libinput:name:*AlpsPS/2 ALPS DualPoint TouchPad:fwversion:310 libinput:name:*AlpsPS/2 ALPS GlidePoint:fwversion:310 LIBINPUT_MODEL_ALPS_RUSHMORE=1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston v3] configure: unify wayland-client and wayland-server requirements
On 23/05/2016 10:43, Pekka Paalanen wrote: From: Pekka Paalanen This introduces a variable common for both wayland-client and wayland-server required version number. As most developers usually build everything, testing server and client version requirements separately is more poorly tested than version requirements in general. The server requirement being greater than the client requirement will mask any issues from forgetting to bump the client requirement appropriately. Therefore the requirements are unified. This bumps wayland-client requirement to 1.10.0, on par with the existing wayland-server requirement. Only the checks which explicitly defined a version are updated, unversioned checks are left as is. The variable style follows that of Mesa. This patch is based on the similar patch by Bryce Harrington that used m4_define instead of a variable. Cc: Bryce Harrington Cc: Quentin Glidic Signed-off-by: Pekka Paalanen --- configure.ac | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) Reviewed-by: Quentin Glidic Tested-by: Quentin Glidic Cheers, -- Quentin “Sardem FF7” Glidic ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] clients: Add a weston-autorotater client and rotater protocol
On Sat, 21 May 2016 03:43:04 +0100 Emmanuel Gil Peyrot wrote: > This client uses libiio to retrieve accelerometer values from the iio > subsystem on Linux (and maybe some other kernels), and automatically > rotate the output whenever orientation changed. > > I tested it with a mma8453 accelerometer, but everything needed should > be available in the configuration to make it work with any other iio > device. > > Signed-off-by: Emmanuel Gil Peyrot > --- > Makefile.am | 24 +++ > clients/autorotater.c | 472 > > configure.ac| 15 ++ > desktop-shell/shell.c | 1 + > protocol/weston-rotater.xml | 26 +++ > src/compositor.h| 3 + > src/rotater.c | 150 ++ > 7 files changed, 691 insertions(+) > create mode 100644 clients/autorotater.c > create mode 100644 protocol/weston-rotater.xml > create mode 100644 src/rotater.c Hi Emmanuel, why is there a new client for this? Could it not be a plugin? Is IIO potentially so slow and blocking we cannot use it in the server process? Why the polling approach, cannot IIO deliver events? Should there be a way to set which outputs get rotated by a specific IIO device, rather than assuming there is just one device rotating all outputs at once? Any reason why this is limited to desktop-shell rather than being a shell-agnostic feature? Thanks, pq > > diff --git a/Makefile.am b/Makefile.am > index 00b74e5..b1e0ade 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -122,6 +122,8 @@ endif > nodist_weston_SOURCES = \ > protocol/weston-screenshooter-protocol.c\ > protocol/weston-screenshooter-server-protocol.h \ > + protocol/weston-rotater-protocol.c \ > + protocol/weston-rotater-server-protocol.h \ > protocol/text-cursor-position-protocol.c\ > protocol/text-cursor-position-server-protocol.h \ > protocol/text-input-unstable-v1-protocol.c \ > @@ -611,6 +613,28 @@ nodist_weston_screenshooter_SOURCES = > \ > weston_screenshooter_LDADD = $(CLIENT_LIBS) libshared.la > weston_screenshooter_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS) > > +if BUILD_AUTOROTATER > +libexec_PROGRAMS += weston-autorotater > + > +weston_autorotater_SOURCES = \ > + clients/autorotater.c > +nodist_weston_autorotater_SOURCES = \ > + protocol/weston-rotater-protocol.c \ > + protocol/weston-rotater-client-protocol.h > +weston_autorotater_LDADD = $(CLIENT_LIBS) $(LIBIIO_LIBS) libshared.la > +weston_autorotater_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS) $(LIBIIO_CFLAGS) > + > +weston_SOURCES +=\ > + src/rotater.c > + > +BUILT_SOURCES += \ > + protocol/weston-rotater-protocol.c \ > + protocol/weston-rotater-client-protocol.h > + > +EXTRA_DIST +=\ > + protocol/weston-rotater.xml > +endif > + > weston_terminal_SOURCES =\ > clients/terminal.c \ > shared/helpers.h > diff --git a/clients/autorotater.c b/clients/autorotater.c > new file mode 100644 > index 000..0547f83 > --- /dev/null > +++ b/clients/autorotater.c > @@ -0,0 +1,472 @@ > +/* > + * Copyright © 2016 Collabora, Ltd. > + * > + * 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. > + */ > + > +#include "config.h" > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include "weston-rotater-client-protocol.h" > +#include "shared/config-parser.h" > +#include "shared/helpers.h" > +#include "shared/xalloc.h" > + > +#inclu
[PATCH weston v3] configure: unify wayland-client and wayland-server requirements
From: Pekka Paalanen This introduces a variable common for both wayland-client and wayland-server required version number. As most developers usually build everything, testing server and client version requirements separately is more poorly tested than version requirements in general. The server requirement being greater than the client requirement will mask any issues from forgetting to bump the client requirement appropriately. Therefore the requirements are unified. This bumps wayland-client requirement to 1.10.0, on par with the existing wayland-server requirement. Only the checks which explicitly defined a version are updated, unversioned checks are left as is. The variable style follows that of Mesa. This patch is based on the similar patch by Bryce Harrington that used m4_define instead of a variable. Cc: Bryce Harrington Cc: Quentin Glidic Signed-off-by: Pekka Paalanen --- configure.ac | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/configure.ac b/configure.ac index e1300b4..e4516c1 100644 --- a/configure.ac +++ b/configure.ac @@ -11,6 +11,9 @@ AC_INIT([weston], [weston], [http://wayland.freedesktop.org]) +# External dependency versions +WAYLAND_REQUIRED="1.10.0" + AC_SUBST([WESTON_VERSION_MAJOR], [weston_major_version]) AC_SUBST([WESTON_VERSION_MINOR], [weston_minor_version]) AC_SUBST([WESTON_VERSION_MICRO], [weston_micro_version]) @@ -60,7 +63,7 @@ AC_CHECK_HEADERS([execinfo.h]) AC_CHECK_FUNCS([mkostemp strchrnul initgroups posix_fallocate]) -COMPOSITOR_MODULES="wayland-server >= 1.10.0 pixman-1 >= 0.25.2" +COMPOSITOR_MODULES="wayland-server >= $WAYLAND_REQUIRED pixman-1 >= 0.25.2" AC_CONFIG_FILES([doc/doxygen/tools.doxygen doc/doxygen/tooldev.doxygen]) @@ -193,7 +196,7 @@ AM_CONDITIONAL(ENABLE_WAYLAND_COMPOSITOR, if test x$enable_wayland_compositor = xyes -a x$enable_egl = xyes; then AC_DEFINE([BUILD_WAYLAND_COMPOSITOR], [1], [Build the Wayland (nested) compositor]) - PKG_CHECK_MODULES(WAYLAND_COMPOSITOR, [wayland-client >= 1.5.91 wayland-egl wayland-cursor]) + PKG_CHECK_MODULES(WAYLAND_COMPOSITOR, [wayland-client >= $WAYLAND_REQUIRED wayland-egl wayland-cursor]) fi @@ -335,7 +338,7 @@ AM_CONDITIONAL(ENABLE_VAAPI_RECORDER, test "x$have_libva" = xyes) PKG_CHECK_MODULES(CAIRO, [cairo]) -PKG_CHECK_MODULES(TEST_CLIENT, [wayland-client >= 1.10.0]) +PKG_CHECK_MODULES(TEST_CLIENT, [wayland-client >= $WAYLAND_REQUIRED]) AC_ARG_ENABLE(simple-clients, AS_HELP_STRING([--disable-simple-clients], @@ -389,9 +392,9 @@ AM_CONDITIONAL(BUILD_CLIENTS, test x$enable_clients = xyes) if test x$enable_clients = xyes; then AC_DEFINE([BUILD_CLIENTS], [1], [Build the Wayland clients]) - PKG_CHECK_MODULES(CLIENT, [wayland-client >= 1.5.91 cairo >= 1.10.0 xkbcommon wayland-cursor]) + PKG_CHECK_MODULES(CLIENT, [wayland-client >= $WAYLAND_REQUIRED cairo >= 1.10.0 xkbcommon wayland-cursor]) PKG_CHECK_MODULES(SERVER, [wayland-server]) - PKG_CHECK_MODULES(WESTON_INFO, [wayland-client >= 1.5.91]) + PKG_CHECK_MODULES(WESTON_INFO, [wayland-client >= $WAYLAND_REQUIRED]) # Only check for cairo-egl if a GL or GLES renderer requested AS_IF([test "x$cairo_modules" = "xcairo-gl" -o "x$cairo_modules" = "xcairo-glesv2"], [ -- 2.7.3 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [systemd-devel] [ANNOUNCE] systemd v230
On Mon, May 23, 2016 at 11:12:05AM +0900, Michel Dänzer wrote: > On 22.05.2016 18:02, Alexander E. Patrakov wrote: > > 22.05.2016 13:33, Alexander E. Patrakov пишет: > >> 22.05.2016 03:51, Zbigniew Jędrzejewski-Szmek пишет: > >>> Hi, > >>> > >>> systemd v230 has been tagged. Enjoy! > >>> > >>> CHANGES WITH 230: > >> > >> > >> > >>> * Framebuffer devices (/dev/fb*) and 3D printers and scanners > >>> (devices tagged with ID_MAKER_TOOL) are now tagged with > >>> "uaccess" and are available to logged in users. > >> > >> Has this been discussed with Wayland developers? Framebuffer device > >> access can possibly be abused to take screenshots and draw on top of the > >> compositor in a Wayland-based environment. Impossibility for arbitrary > >> applications to take screenshots was one of the design goals of Wayland, > >> and this change breaks it. > >> > >> So, unless one of Wayland developers confirms that they are OK with it, > >> please revert it and ask for a CVE. > >> > > > > Sorry, I have to take this back. Attempting to grab video from /dev/fb0 > > here on Intel hardware, both under X and Weston, shows only an image > > from the first virtual console - i.e. not the actual session. Still, I > > would like someone else to confirm that this behaviour is not > > Intel-specific and cannot be circumvented by, say, ioctls on /dev/fb0. > > The scenario you describe isn't possible if the Wayland compositor > directly uses the KMS API of /dev/dri/card*, but it may be possible if > the Wayland compositor uses the fbdev API of /dev/fb* instead (e.g. if > weston uses its fbdev backend). Yeah, if both weston and your screen grabber uses native fbdev API you can now screenshot your desktop. And since fbdev has no concept of "current owner of the display hw" like the drm master, I think this is not fixable. At least not just in userspace. Also even with native KMS compositors fbdev still doesn't have the concept of ownership, which is why it doesn't bother clearing it's buffer before KMS takes over. I agree that this should be reverted or at least hidden better. Also, can we just burn down fbdev please ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
