XDC2013 - Call for Proposals
# Call For Proposals **2013 X.Org Developers Conference (XDC 2013)** **23-25 September 2013** **Portland, Oregon USA** The [2013 X.Org Developers Conference] (http://www.x.org/wiki/Events/XDC2013) is the annual technical meeting for [X Window System](http://x.org) and [Free Desktop](http://freedesktop.org) developers. The attendees will gather to discuss outstanding technical issues related to X and to plan the direction of the X Window System and its software ecosystem. The event is free of charge and open to the general public. The XDC 2013 Technical Program Committee (TPC) is requesting proposals for papers and presentations at XDC 2013. While any serious proposal will be gratefully considered, topics of interest to X.org and FreeDesktop.org developers are encouraged. There are three particular types of proposal the TPC is seeking: 1. Technical talk abstracts: 250-1000 words describing a presentation to be made at XDC 2013. This can be anything: a work-in-progress talk, a proposal for change, analysis of trends, etc. 2. Informal white papers: 1000+ words on something of interest or relevance to X.org developers, FreeDesktop.org developers or the X community at large. These papers will appear in the online conference proceedings of XDC 2013, and are unrefereed (beyond basic checks for legitimacy and relevance). Papers can be refereed if requested in advance. 3. Technical research papers: 2500+ words in a format and style suitable for refereed technical publication. Papers that are judged acceptable by the TPC and its referees will be published in the printed conference proceedings of XDC 2013, available on a print-on-demand basis online. XDC 2013 technical presenters will be chosen from the authors of any of these submissions (as well as other presenters invited by the TPC). Normally, there is time for everyone who wants to present to do so, but one can never tell. As much as possible, presenters will be selected from those who submit before the deadline. We also may be able to offer financial assistance for travel for presenters who could not otherwise afford to attend and who submit before the deadline. Please do submit your proposal in a timely fashion. **Proposals due:** Thursday 1 August 2013 17:00 UTC *Accepted formats: PDF and ASCII text. **Notification of acceptance:** Thursday 8 August 2013 **E-mail:** bo...@foundation.x.org -- keith.pack...@intel.com pgpTeM1G3fTXj.pgp Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
XDC2013 - Announcement
Now that we have everything in place we can finally make it official and announce it: XDC2013 will take place from September 23th to September 25th in Portland, Oregon at the University Place Hotel and Conference Center Ian Romanick, Bart Massey, and I will be orgainzing this event. The initial wiki page for this event has been put in place at: http://wiki.x.org/wiki/Events/XDC2013 This page will get updated regularly. Also we will keep you up-to-date on the X.Org events mailing list http://lists.x.org/mailman/listinfo/events so if you plan to come and are not subscribed there already, please consider doing so! For registration please add yourself to the attendees page http://wiki.x.org/wiki/Events/XDC2013/Attendees. If you would like to give a talk during the event, please add it to the program page http://wiki.x.org/wiki/Events/XDC2013/Program. We are looking forward to seeing you in Portland. So if you are corporate please talk to your managers about funding your trip. If you aren't but you have something to present, please contact the XOrg Foundation Board of Directors at bo...@foundation.x.org for travel funding. We have negotiated a special conference rate at the conference hotel. Please check the Wiki page for more information. -- keith.pack...@intel.com pgp2K9eReoe6m.pgp Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] weston: Filter keys by id bit
Martin Minarik wrote: The way to verify this: 1. press A on keyboard 1 2. press A on keyboard 2 3. release A on keyboard 1 4. release A on keyboard 2 The actual sequence: [2134420.1337] -> wl_keyboard at 39.key(2316, 899782584, 30, 1) [2134421.1337] -> wl_keyboard at 39.key(2316, 899782584, 30, 1) [2134422.1337] -> wl_keyboard at 39.key(2316, 899782584, 30, 0) [2134423.1337] -> wl_keyboard at 39.key(2316, 899782584, 30, 0) The correct sequence - after applying this patch: [2134420.1337] -> wl_keyboard at 39.key(2316, 899782584, 30, 1) [2134423.1337] -> wl_keyboard at 39.key(2316, 899782584, 30, 0) Sorry I completely cannot figure out any reason the client can't do this filtering. And I suspect there are clients who would want to see the multiple events. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
sardemff7+wayl...@sardemff7.net wrote: This is a requirement so that non-trivial clients can be written that are not forced to blink the transient windows to change their parenting. Do you have a use case for this scenario ? There are probably some I cannot see, but maybe could we solve them another way. A "toolbox" that must remain all of the N document windows, no matter which is raised. I propose that rather than the client having to send a directed acyclic graph to describe this situation, it only has to send a tree but it can edit it . Before the client raises any document window it reparents the toolbox to the new top-most window. Same question, do you have a use case for a popup surface that you would reparent? For our current use case (menus, do we have another one?) this is unlikely (afaict, I am not a toolkit guy). The exact same situation, because a client needs to be able to turn a "popup" into a "transient", for instance if the user can pin the menu. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH RFC] Allow configuration of output positions
Hi,
Can someone pls have a look at this patch?
I implemented configuration options for relativ output positioning in
weston.ini. Currently the implementation is private to the drm compositor,
but i think this can be generalized for all output drivers.
ATM it can only be configured in weston.ini, a dynamic way like xrandr
would be nice (now idea how to).
Next i want to introduce a concept of primary output, to center the
mouse on the right monitor on start, draw the launcher only there and
other stuff.
I'm new to wayland/weston, so i'm not sure if this is even the right
approach ...
only tested with 2 monitors, sadly i don't have more :)
>From 4ee86a0b78a1c0d217cf5c973af0f3d50bd15c68 Mon Sep 17 00:00:00 2001
From: Florian Scandella
Date: Thu, 13 Jun 2013 21:23:51 +0200
Subject: [PATCH] [drm] Add support for output layout configuration
Output configuration is specified by the "output" entries:
above=
below=
left-of=
right-of=
where name references another output configuration.
---
src/compositor-drm.c | 189 +++
1 file changed, 189 insertions(+)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 76d0810..0823f54 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -187,6 +187,16 @@ struct drm_sprite {
uint32_t formats[];
};
+struct drm_output_layout {
+ struct drm_output *output;
+ int visited;
+ int vx, vy;
+ struct drm_output_layout *left;
+ struct drm_output_layout *right;
+ struct drm_output_layout *top;
+ struct drm_output_layout *bottom;
+};
+
static const char default_seat[] = "seat0";
static void
@@ -2031,6 +2041,182 @@ destroy_sprites(struct drm_compositor *compositor)
}
static int
+drm_output_layout_init (struct drm_compositor *ec, struct drm_output_layout **map, int *n)
+{
+ struct drm_output *output;
+ int i = 0;
+
+ *n = wl_list_length(&ec->base.output_list);
+ *map = malloc((*n) * sizeof **map);
+
+ if (*map == NULL)
+ return -1;
+
+ memset(*map, 0, (*n) * sizeof **map);
+
+ wl_list_for_each(output, &ec->base.output_list, base.link) {
+ (*map)[i].output = output;
+ ++i;
+ }
+
+ return 0;
+}
+
+static int
+drm_output_layout_find_index_by_name (struct drm_output_layout const *map, int n, char const *name)
+{
+ int j;
+ for (j=0; j < n; ++j) {
+ if (strcmp(name, map[j].output->base.name) == 0) {
+ return j;
+ }
+ }
+ return -1;
+}
+
+static void
+drm_output_layout_calculate_positions (struct drm_output_layout *current, int *minx, int *miny)
+{
+ current->visited = 1;
+
+ if (current->vx < *minx)
+ *minx = current->vx;
+ if (current->vy < *miny)
+ *miny = current->vy;
+
+ if (current->left && !current->left->visited) {
+ current->left->vx = current->vx - current->left->output->base.width;
+ current->left->vy = current->vy;
+ drm_output_layout_calculate_positions(current->left, minx, miny);
+ }
+ if (current->right && !current->right->visited) {
+ current->right->vx = current->vx + current->output->base.width;
+ current->right->vy = current->vy;
+ drm_output_layout_calculate_positions(current->right, minx, miny);
+ }
+ if (current->bottom && !current->bottom->visited) {
+ current->bottom->vx = current->vx;
+ current->bottom->vy = current->vy + current->output->base.height;
+ drm_output_layout_calculate_positions(current->bottom, minx, miny);
+ }
+ if (current->top && !current->top->visited) {
+ current->top->vx = current->vx;
+ current->top->vy = current->vy - current->top->output->base.height;
+ drm_output_layout_calculate_positions(current->top, minx, miny);
+ }
+}
+
+
+static void
+drm_output_layout_put_left_of (struct drm_output_layout *map, int left_idx, int right_idx)
+{
+ map[left_idx].right = &map[right_idx];
+ map[right_idx].left = &map[left_idx];
+}
+
+
+static void
+drm_output_layout_put_above (struct drm_output_layout *map, int bottom_idx, int top_idx)
+{
+ map[bottom_idx].top = &map[top_idx];
+ map[top_idx].bottom = &map[bottom_idx];
+}
+
+/* merge defined und undefined output configurations */
+static void
+drm_output_layout_prepare (struct drm_output_layout *map, int n)
+{
+ struct drm_output_layout *last_undefined = NULL;
+ struct drm_output_layout *last_defined = NULL;
+
+ int i;
+ for (i = 0; iright = &map[i];
+map[i].left = last_undefined;
+ }
+ last_undefined = &map[i];
+ }
+ }
+
+ if (last_undefined && last_defined) {
+
+ while(last_undefined->left)
+ last_undefined = last_undefined->left;
+
+ while (last_defined->right)
+ last_defined = last_defined->right;
+
+ last_defined->right = last_undefined;
+ last_undefined->left = last_defined;
+ }
+}
+
+
+static int
+arrange_outputs(struct drm_compositor *ec)
+{
+ struct drm_output_layout *map;
+ int n_outputs, idx, minx = 0, miny = 0;
+
+ if (drm_output_layout_init(ec, &map, &n_outputs))
+ return -1;
+
+
+ for(idx=0; idx < n_outputs; ++idx) {
+ struct weston_config_section *current_section = weston_config_get_section(ec->base.config, "output", "name", map[idx].output->base.name);
+ char *option;
+
+
[PATCH] weston: Filter keys by id bit
Since evdev keys are unreliable, they might randomly get dropped, such
as, on SYN_DROPPED. Even SYN_DROPPED is sometimes not delivered.
Clients, compositor are not able to recover from duplicate press/release.
Multiple wl_keyboard attached devices are not distinguished properly.
This fixes this bug, thereby making the compositor and clients useable
even under critical system conditions such as, but not limited to, high
system load, device malfunction. This improves reliability.
This fixes the compositor, so that it delivers the correct events, when attached
multiple keyboards to the same seat. This is tested under the evdev backend,
perhaps it works under multiseat X.
The way to verify this:
1. press A on keyboard 1
2. press A on keyboard 2
3. release A on keyboard 1
4. release A on keyboard 2
The actual sequence:
[2134420.1337] -> wl_keyboard at 39.key(2316, 899782584, 30, 1)
[2134421.1337] -> wl_keyboard at 39.key(2316, 899782584, 30, 1)
[2134422.1337] -> wl_keyboard at 39.key(2316, 899782584, 30, 0)
[2134423.1337] -> wl_keyboard at 39.key(2316, 899782584, 30, 0)
The correct sequence - after applying this patch:
[2134420.1337] -> wl_keyboard at 39.key(2316, 899782584, 30, 1)
[2134423.1337] -> wl_keyboard at 39.key(2316, 899782584, 30, 0)
The reason is, because the wl_keyboard device must from the client's
perspective act like single input device, as discussed.
Every seat device is assigned a different id_bit. Up to 64 devices
can be recognized per seat this way. The notify_key() will
use this bit to recognize from which device the event originated.
This is necessary because it filters keys double press double release,
improving reliability. In case multiple
This adds a second stack where keys are filtered, each time
a press or release occurs, the originating device is marked.
An event is propagated further only if the key is held or released
on 1 or 0 devices thereby giving the impression to the clients
that the wl_keyboard is 1 physical device
Disadvantages of this approach
none
---
src/compositor-wayland.c | 14 ++--
src/compositor-x11.c | 25 -
src/compositor.h |5 ++-
src/evdev.c | 57 +++---
src/evdev.h |4 +++
src/input.c | 88 +-
tests/weston-test.c |3 +-
7 files changed, 153 insertions(+), 43 deletions(-)
diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
index f3a98a8..0304937 100644
--- a/src/compositor-wayland.c
+++ b/src/compositor-wayland.c
@@ -529,11 +529,21 @@ input_handle_keyboard_enter(void *data,
struct wl_array *keys)
{
struct wayland_input *input = data;
+ struct wl_array key_states;
+ unsigned int *k_cnt;
+
+ wl_array_init(&key_states);
+ wl_array_add(&key_states, keys->size);
+ wl_array_for_each(k_cnt, &key_states) {
+ *k_cnt = 1;
+ }
/* XXX: If we get a modifier event immediately before the focus,
* we should try to keep the same serial. */
- notify_keyboard_focus_in(&input->base, keys,
+ notify_keyboard_focus_in(&input->base, keys, &key_states,
STATE_UPDATE_AUTOMATIC);
+
+ wl_array_release(&key_states);
}
static void
@@ -557,7 +567,7 @@ input_handle_key(void *data, struct wl_keyboard *keyboard,
notify_key(&input->base, time, key,
state ? WL_KEYBOARD_KEY_STATE_PRESSED :
WL_KEYBOARD_KEY_STATE_RELEASED,
- STATE_UPDATE_NONE);
+ STATE_UPDATE_NONE, 1);
}
static void
diff --git a/src/compositor-x11.c b/src/compositor-x11.c
index 5a0bcf0..09de5c3 100644
--- a/src/compositor-x11.c
+++ b/src/compositor-x11.c
@@ -65,7 +65,6 @@ struct x11_compositor {
xcb_connection_t*conn;
xcb_screen_t*screen;
xcb_cursor_t null_cursor;
- struct wl_array keys;
struct wl_event_source *xcb_source;
struct xkb_keymap *xkb_keymap;
unsigned int has_xkb;
@@ -1181,6 +1180,8 @@ static int
x11_compositor_handle_event(int fd, uint32_t mask, void *data)
{
struct x11_compositor *c = data;
+ struct wl_array keys;
+ struct wl_array key_states;
struct x11_output *output;
xcb_generic_event_t *event, *prev;
xcb_client_message_event_t *client_message;
@@ -1224,7 +1225,8 @@ x11_compositor_handle_event(int fd, uint32_t mask, void
*data)
weston_compositor_get_time(),
key_release->detail - 8,
WL_KEYBOARD_KEY_STATE_RELEASED,
- STATE_UPDATE_AUTOMATIC);
+ STATE_UPDATE_AUTOMATIC, 1);
+
free(prev)
Re: [PATCH weston 3/4] compositor-drm: Enable seat constraining when configured in weston.ini
On Tue, Jun 11, 2013 at 03:33:46PM +0300, Pekka Paalanen wrote:
> Hi Rob,
>
> I think patches 2, 3, and 4 should be all squashed, and I would like to
> know more of what is the use case here.
>
> More questions below.
>
>
> On Mon, 10 Jun 2013 15:17:30 +0100
> Rob Bradford wrote:
>
> > From: Rob Bradford
> >
> > ---
> > src/compositor-drm.c | 16
> > src/compositor.h | 2 ++
> > src/input.c | 2 ++
> > src/udev-seat.c | 3 +++
> > 4 files changed, 23 insertions(+)
> >
> > diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> > index 76d0810..7d33977 100644
> > --- a/src/compositor-drm.c
> > +++ b/src/compositor-drm.c
> > @@ -1796,6 +1796,22 @@ create_output_for_connector(struct drm_compositor
> > *ec,
> > transform = parse_transform(s, output->base.name);
> > free(s);
> >
> > + weston_config_section_get_string(section, "seat", &s, "");
> > + if (strcmp(s, "") != 0) {
> > + struct udev_seat *seat;
> > +
> > + seat = udev_seat_get_named(&ec->base, s);
> > + if (seat) {
> > + seat->base.output = &output->base;
> > + if (seat->base.pointer) {
> > + weston_pointer_output_center(seat->base.pointer,
> > +&output->base);
Hi Pekka,
Thanks for the feedback below. I'll do my best to answer everything.
> Does this mean, that every time an output is hotplugged in this seat,
> the pointer will warp?
>
> What if a seat has several outputs?
>
Excellent point. I think I could instead go with a
weston_pointer_ensure_valid_location.
This function would be based off of the code in pointer_clip_motion()
and then that function could be written in terms of this.
Thus warping would only happen if the seat was previously unconstrained
and the output that came about wanted it constrained to it.
> > + if (seat->base.output && seat->base.pointer)
> > + weston_pointer_output_center(seat->base.pointer,
> > seat->base.output);
>
> Do I understand right, that whenever any input device is hotplugged,
> like a keyboard, the pointer will warp?
Yeh I think you're right here. The function I mentioned above could
probably fix this too. But it would be nice to be cleverer about when to
call this function
> > +
> > return 0;
> > }
> >
>
> From the man page patch:
>
> +.BI "seat=" name
> +The logical seat name that that this output should be associated with. If
> this
> +is set then the seat's input will be confined to the output that has the seat
> +set on it. The expectation is that this functionality will be used in a
> +multiheaded environment with a single compositor for multiple output and
> +input configurations.
>
> So, this is an output key. It is almost as if you were trying to
> implement seats by using wl_seats. I don't think that will work. Like
> here, you try to confine the pointer, but what if a user alt+tabs? No
> constraints there. I'm confused what this is trying to achieve.
>
> Let me explain. I believe that wl_seat is misnamed. wl_seat is a set of
> foci for a set on input devices, used by one person, or by several
> people collaborating on a common desktop. Everyone has access to
> everything, using their own input devices.
>
> A seat is a physical entity, a console; an output or outputs, and the
> associated input devices. Each seat has its own user session(s), which
> is easiest to implement by running a compositor per seat. Sessions are
> separate by definition, and for security. Separating the sessions within
> a compositor is very hard.
>
> I think, that seats are configured in udev, and wl_seats will be
> configured in weston.ini or equivalent per-session configuration. A seat
> may have multiple wl_seats, if you want e.g. multi-pointer. Currently,
> we have no implementation for configuring multiple wl_seats;
> device_added() will ignore all devices that do not match the wanted
> ID_SEAT property, and only one udev_input with a wanted seat_id is
> created in a backend.
>
> Could you elaborate on what you are trying to do?
The requirement we have for this this is to be able to run a
single compositor (with it's own custom shell) that would be driving
multiple outputs using the same GPU. Clients might need to multiple
outputs or move outputs - so having multiple compositor instances would
be complicated. (Also can we have multiple compositor instances using
the same GPU - and driving different outputs?)
Each of these outputs has some input devices associated with it -
probably a touch screen and perhaps some buttons. Obviously if a
touchscreen is part of a particular physical display
In my patches that are now merged I added support to create multiple
udev_seats based on labelling the devices in udev with ENV{WL_SEAT}.
The goal of these combined patch sets is to be able to create multiple
independent logical seats with some primitive isolation: touch and
point
Re: Proposal to change subsurface extension
Hi, On 13.06.2013 16:06, John Kåre Alsaker wrote: > On Thu, Jun 13, 2013 at 2:42 PM, Pekka Paalanen wrote: >> Libwayland does not synchronize, it only protects the queues for the >> very short moment each time they are modified. It does not cause one >> application component to stall and wait for another component to wake >> up, realize there is something to do, and then do it. Libwayland also >> does not force other threads to wake up, if one thread wants to do >> something. And with the fd locking patches for libwayland-client, that >> will actually be true all the way. >> > The sort of synchronization required is exactly the same as what is needed > by libwayland-client. It needs to send some bytes to the compositor without > being interrupted by other threads. My point here holds unless > libwayland-client gets a communication channel per thread (instead of per > wl_display). [...] Just my 5c: Please, pretty please, avoid anything which looks even remotely like XLockDisplay(). This is a big hammer which makes every synchronization problem look like a nail and it will be used for too many things. (Also, it's not far from XLockDisplay() to XGrabServer() which is another thing which should be avoided as much as possible) Cheers, Uli -- Cow: He is a lawyer, too? Mooseblood: Ma'am, I was already a bloodsucking parasite. All I needed was a briefcase! ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Proposal to change subsurface extension
On Thu, Jun 13, 2013 at 2:42 PM, Pekka Paalanen wrote: > Libwayland does not synchronize, it only protects the queues for the > very short moment each time they are modified. It does not cause one > application component to stall and wait for another component to wake > up, realize there is something to do, and then do it. Libwayland also > does not force other threads to wake up, if one thread wants to do > something. And with the fd locking patches for libwayland-client, that > will actually be true all the way. > The sort of synchronization required is exactly the same as what is needed by libwayland-client. It needs to send some bytes to the compositor without being interrupted by other threads. My point here holds unless libwayland-client gets a communication channel per thread (instead of per wl_display). It is very much about performance, and also about avoiding the need for > component APIs to have a hook for "I want to update my output now" > which crosses thread boundaries. > I'd say adding a mutex (or reusing one in libwayland-client) is probably faster than doing the additional work required by the compositor in the current implementation, both being insignificant. > > If you absolutely can't tolerate any synchronization in that case > > (which we won't be able to avoid at the libwayland level anyway) a > > simpler solution is to let wl_surface.commit atomically commit itself > > and all children recursively. You then commit to two separate > > Committing children is a no-go, unless you have a mechanism to > guarantee a consistent snapshot of the child surface state. > Each thread gets it's own wl_surface and possible children. It's up to each thread to make sure their tree of surfaces is consistent. Each thread would call commit on their wl_surfaces. You'd only call commit on the top-level surface when resizing. > > wl_surfaces in the main and the component thread both of which have > > the top-level wl_surface as a parent. However to do this we need a > > way to map a surface without a buffer (or use a transparent one...) > > since the top-level wl_surface can't have content. It also won't > > Funny how no toolkit developer has brought that "problem" up yet. > I'm not quite sure which problem you refer to here. The problem of using a mapped wl_surface with no content to group up wl_surfaces belonging to separate threads as is rather unique to my solution. The problem of using a mapped wl_surface with no content and an input region of non-infinite size is a more general one, which I suspect you're referring to. I assume you have solved that by clipping the input region to the extends of the surface and children and moving the content of one of the subsurfaces into the parent. That solution won't work for my proposal since it would require synchronization when committing the parent. I instead have to pick between using a 1x1 buffer (ugh), explicit map/unmap requests (ugh) and introducing a wl_empty_buffer (meh). I prefer the wl_empty_buffer option. It also allows me to have input region to be clipped to the surface content without including children, although I don't see any reason to do that. > > allow eglSwapBuffers to work in subsurfaces (if we could even > > guarantee that it's non-blocking), but that will be rectified by the > > wl_egl_window_* additions we discussed. > > You have pretty high hopes it would go through... shall see, when you > have an implementation. > It's too nice and useful to not go through. It's very easy to implement in the current form. The question is if we want something more advanced... > > > - pq > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Proposal to change subsurface extension
On Thu, 13 Jun 2013 14:03:26 +0200 John Kåre Alsaker wrote: > On Thu, Jun 13, 2013 at 1:04 PM, Pekka Paalanen > wrote: > > > On Thu, 13 Jun 2013 12:35:36 +0200 > > John Kåre Alsaker wrote: > > > > > I propose the we should change the commit behavior to having > > > commit on the toplevel wl_surface > > > commit itself and all it's subsurfaces atomically. Commiting on > > > subsurfaces should be a no-op. > > > > When a component is running asynchronously, constantly sending new > > state to a sub-surface, how do you guarantee, that a toplevel commit > > uses a consistent set of state for the sub-surface? > > > We either introduce libwayland functions to send requests as a group > (which basically just holds the wl_display mutex) or hold a mutex > while we're playing with pending surface state. I think that is simply not feasible. > > > That is to allow eglSwapBuffers to be used in subsurfaces, should > > > you manage to get it to be non-blocking. > > > This isn't a huge loss since clients only need to atomically > > > commit all surfaces anyway. > > > > No, they don't. We want a component to be able to run independently > > in normal circumstances when it does not absolutely require > > synchronization to any other surfaces forming the window. > > > > Playing a video should not require the decorations to be committed > > for each video frame. > > > We don't need to avoid synchronization. It's simply desirable. > However you do realize that almost every call into libwayland > requires synchronization anyway? All rendering, memory management, > resizing will require synchronization. Why are you so reluctant to > introduce some insignificant synchronization given how much it > simplifies the protocol? It's not for performance since libwayland is > filled with synchronization and probably many other operations. > It's because it's too hard to use, since resizing will require much > more complex and expensive synchronization to work. Libwayland does not synchronize, it only protects the queues for the very short moment each time they are modified. It does not cause one application component to stall and wait for another component to wake up, realize there is something to do, and then do it. Libwayland also does not force other threads to wake up, if one thread wants to do something. And with the fd locking patches for libwayland-client, that will actually be true all the way. Waking up another thread for doing something on behalf of current thread is the bad thing. For resizing that cannot be avoided, but fortunately applications are resizing so briefly that it is almost never. There is no need to synchronize rendering at all. The only need for synchronization is for resize-like operations, where several surfaces need to change atomically. It is very much about performance, and also about avoiding the need for component APIs to have a hook for "I want to update my output now" which crosses thread boundaries. > If you absolutely can't tolerate any synchronization in that case > (which we won't be able to avoid at the libwayland level anyway) a > simpler solution is to let wl_surface.commit atomically commit itself > and all children recursively. You then commit to two separate Committing children is a no-go, unless you have a mechanism to guarantee a consistent snapshot of the child surface state. > wl_surfaces in the main and the component thread both of which have > the top-level wl_surface as a parent. However to do this we need a > way to map a surface without a buffer (or use a transparent one...) > since the top-level wl_surface can't have content. It also won't Funny how no toolkit developer has brought that "problem" up yet. > allow eglSwapBuffers to work in subsurfaces (if we could even > guarantee that it's non-blocking), but that will be rectified by the > wl_egl_window_* additions we discussed. You have pretty high hopes it would go through... shall see, when you have an implementation. - pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Proposal to change subsurface extension
On Thu, Jun 13, 2013 at 1:04 PM, Pekka Paalanen wrote: > On Thu, 13 Jun 2013 12:35:36 +0200 > John Kåre Alsaker wrote: > > > I propose the we should change the commit behavior to having commit > > on the toplevel wl_surface > > commit itself and all it's subsurfaces atomically. Commiting on > > subsurfaces should be a no-op. > > When a component is running asynchronously, constantly sending new > state to a sub-surface, how do you guarantee, that a toplevel commit > uses a consistent set of state for the sub-surface? > We either introduce libwayland functions to send requests as a group (which basically just holds the wl_display mutex) or hold a mutex while we're playing with pending surface state. > > That is to allow eglSwapBuffers to be used in subsurfaces, should you > > manage to get it to be non-blocking. > > This isn't a huge loss since clients only need to atomically commit > > all surfaces anyway. > > No, they don't. We want a component to be able to run independently in > normal circumstances when it does not absolutely require > synchronization to any other surfaces forming the window. > > Playing a video should not require the decorations to be committed for > each video frame. > We don't need to avoid synchronization. It's simply desirable. However you do realize that almost every call into libwayland requires synchronization anyway? All rendering, memory management, resizing will require synchronization. Why are you so reluctant to introduce some insignificant synchronization given how much it simplifies the protocol? It's not for performance since libwayland is filled with synchronization and probably many other operations. It's because it's too hard to use, since resizing will require much more complex and expensive synchronization to work. If you absolutely can't tolerate any synchronization in that case (which we won't be able to avoid at the libwayland level anyway) a simpler solution is to let wl_surface.commit atomically commit itself and all children recursively. You then commit to two separate wl_surfaces in the main and the component thread both of which have the top-level wl_surface as a parent. However to do this we need a way to map a surface without a buffer (or use a transparent one...) since the top-level wl_surface can't have content. It also won't allow eglSwapBuffers to work in subsurfaces (if we could even guarantee that it's non-blocking), but that will be rectified by the wl_egl_window_* additions we discussed. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Proposal to change subsurface extension
On Thu, 13 Jun 2013 12:35:36 +0200 John Kåre Alsaker wrote: > I propose the we should change the commit behavior to having commit > on the toplevel wl_surface > commit itself and all it's subsurfaces atomically. Commiting on > subsurfaces should be a no-op. When a component is running asynchronously, constantly sending new state to a sub-surface, how do you guarantee, that a toplevel commit uses a consistent set of state for the sub-surface? > That is to allow eglSwapBuffers to be used in subsurfaces, should you > manage to get it to be non-blocking. > This isn't a huge loss since clients only need to atomically commit > all surfaces anyway. No, they don't. We want a component to be able to run independently in normal circumstances when it does not absolutely require synchronization to any other surfaces forming the window. Playing a video should not require the decorations to be committed for each video frame. > This has a number of benefits > - We can get rid of the commit modes (and the set_sync/set_desync > request) and wl_surface.commit becomes easy to reason about That would be nice, but I haven't seen any feasible scheme that would work so. > - Commiting all surfaces becomes a single request instead of having to > walking the surface tree bottom up commiting surface along in > synchronized mode The most common operation will be committing individual surfaces independently at arbitrary times. Only resizing will always require committing through the whole tree. > - The compositor doesn't have to manage more than 2 states per surface > (pending and current) Right, currently we need 3 sets of state. Nice to get rid of, but not a big deal. > I don't see any drawbacks from this or the reason for the complexity > in the current extension See above. - pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Proposal to change subsurface extension
I propose the we should change the commit behavior to having commit on the toplevel wl_surface commit itself and all it's subsurfaces atomically. Commiting on subsurfaces should be a no-op. That is to allow eglSwapBuffers to be used in subsurfaces, should you manage to get it to be non-blocking. This isn't a huge loss since clients only need to atomically commit all surfaces anyway. This has a number of benefits - We can get rid of the commit modes (and the set_sync/set_desync request) and wl_surface.commit becomes easy to reason about - Commiting all surfaces becomes a single request instead of having to walking the surface tree bottom up commiting surface along in synchronized mode - The compositor doesn't have to manage more than 2 states per surface (pending and current) I don't see any drawbacks from this or the reason for the complexity in the current extension ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: The way to use system cursor and custom(client) cursor
On Wed, 12 Jun 2013 12:54:57 -0700 Bill Spitzak wrote: > Pekka Paalanen wrote: > > > I guess the question for the Wayland developer community is, do we > > want such cursor theme settings in the shell protocol, or is that > > something that should be left for DEs to solve in their own > > configuration systems? > > Any solution should involve everything the user calls "themes". > > Historically clients that did nothing automatically get the "theme" > for the cursor and for the window borders. But they had to write a > whole lot of code to change the "theme" for the button widgts. > > This historical artifact has led to lots of people saying these are > somehow special and therefore there must be special api in Wayland > for them. But this is illogical, the user sees no difference between > them, so any solution must solve the buttons and every other "theme". > > So there should be no special "this is the cursor theme" api in > Wayland. > > If some genius out there can design a "this is the entire theme" api > then maybe Wayland can do that. But I suspect any attempt will by > like .Xdefaults and be just as useless. > > So I suspect leaving it for the DE's to solve would be the right > approach. Bill, for once, I agree with you. Elvis, looks like it would be a long road to solve in a standard way, or even on a per toolkit/DE basis. The only thing existing applications can generally support for now is to restart all Wayland clients for reloading the cursor theme based on file symlinks (the server can keep on running, if it does not load any cursors itself). Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On Wed, 12 Jun 2013 18:31:17 -0700 Bill Spitzak wrote: > Rafael Antognolli wrote: > > >> Rafael Antognolli > > > > I've just updated the proposal, considering my last statement. Take > > a look at it and see if it fits your suggestion. > > > > This lets us with 2 surface types (toplevel and fullscreen), and 5 > > states (maximized, minimized, sticky, always_on_top and transient) > > and their respective parameters. > > > > https://github.com/antognolli/wayland/wiki/Surface-States > > Possibly, if setting the "transient" state requires also sending the > parent as a parameter, and clearing it is how you set it to null? But > you need to solve your question about how to give parameters when > setting states. > > I personally feel this api and the subwindow api should be merged as > they are extremely similar. The only difference is that the > compositor is allowed to insert other surfaces between the transient > window and it's parent, but not subwindows and their parent. There is no other subwindow API than what the wl_shell offers, i.e. precisely set_transient and friends. - pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] compositor-drm: free plane resources using drm function.
Free plane resources using drmModeFreePlaneResources() Signed-off-by: Samuel Iglesias Gonsalvez --- src/compositor-drm.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/compositor-drm.c b/src/compositor-drm.c index 76d0810..8787723 100644 --- a/src/compositor-drm.c +++ b/src/compositor-drm.c @@ -2005,8 +2005,7 @@ create_sprites(struct drm_compositor *ec) wl_list_insert(&ec->sprite_list, &sprite->link); } - free(plane_res->planes); - free(plane_res); + drmModeFreePlaneResources(plane_res); } static void -- 1.7.10.4 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: minimized and stick windows
On 12/06/2013 21:39, Bill Spitzak wrote: Shell surface types, exclusive: - top-level - transient (umm, what was this for, again?) - popup (menu?) Transcient is for dialog (modal?) boxes, isn’t it? It means "this window stays above another one". Transient cannot be a type, but instead a state of a surface. It has to be done by setting a "parent surface" which means that the compositor keeps the surface above the parent. It does not imply anything else, in particular the client decides whether either surface is currently visible. It can be a type as long as we allow type switching. Regarding the types we more or less agreed on already, thas sounds sensible to me. The client has to be able to arbitrarily rearrange the parent pointers. This means it can set them to null (since otherwise it is not possible to get all rearrangements if the compositor rejects any attempts that make a loop). Therefore a "transient surface" can become a "main surface" and thus they must be the same object. This is a requirement so that non-trivial clients can be written that are not forced to blink the transient windows to change their parenting. Do you have a use case for this scenario ? There are probably some I cannot see, but maybe could we solve them another way. Popups are also transient windows (and thus normal windows) but they have some effects on event delivery when they are first mapped. Same question, do you have a use case for a popup surface that you would reparent? For our current use case (menus, do we have another one?) this is unlikely (afaict, I am not a toolkit guy). Thanks, -- Quentin “Sardem FF7” Glidic ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
