RE: [PATCH v1] wayland-api: added name/seatname properties to the wl_output
> > On Fri, 17 Oct 2014 12:37:37 +0300 > Imran Zaman wrote: > > > In a multi-seat configuration, clients may need to filter out the > > outputs based on the (udev) seat it is hooked to or based on the name > > of the output. > > Since version of the output is increased, the change does not affect > > the current implementation and is optional whoever wants to use the > > properties of the output (e.g. its very similar that input which has > > the name property attached to it). > > > > Signed-off-by: Imran Zaman > > I explained this to you in IRC, and I will document it here again. > > The seatname event is the wrong approach to solving the issue, and will not be > accepted. The other event, output name, might be useful though, but we need > to look at it separately and see what use cases it serves. > > > First, we need to define some concepts. > > A physical seat is a set of physical input and output devices. Each physical > seat > would have a different person working on it. Every person has his own > monitors, > keyboards, mice, etc. Most often, these seats are completely isolated, in that > one person cannot touch another person's desktop or apps. People like privacy. > > Multi-seat means multiple physical seats, which are all served by the same > machine. Implementing the isolation is the major issue here, and also what I > understand is the primary problem you are trying to solve. > > Wayland's wl_seat is not a physical seat. It is not a seat at all. > wl_seat is just a collection of input devices (no output devices!). > Several mice under the same wl_seat act as a single pointer. Several keyboards > under the same wl_seat act as a single keyboard. > > A physical seat may contain multiple outputs (monitors) and multiple wl_seats. > All these wl_seats will share the same desktop and user. That desktop expands > to all the outputs of the physical seat. Multiple wl_seats on the same server > is > not multi-seat, it is more like multi-pointer and multi-keyboard. You get one > pointer per wl_seat, and one keyboard focus per wl_seat. Each wl_seat may be > typing to a different window at the same time, within the same desktop. > You are absolutely right. But I think wl_seat is equal to physical seat in some conditions and we could use wl_seat as physical seat in our problem. Which component will define physical seat ? We could bind input devices to wl_seat through udev rules and bind outputs to wl_seat through weston.ini, so we could think wl_seat is equal to physical seat if we set all the config file correctly. This way we could use wl_seat to do resource isolation. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [PATCH 2/2] clients: Maximize window when double touch on title bar
> > > Signed-off-by: Xiong Zhang
> > ---
> > clients/window.c| 26 --
> > shared/cairo-util.h | 7 +++
> > shared/frame.c | 49 +
> > 3 files changed, 80 insertions(+), 2 deletions(-)
> >
> > diff --git a/clients/window.c b/clients/window.c index
> > 7c9c518..a608a84 100644
> > --- a/clients/window.c
> > +++ b/clients/window.c
> > @@ -363,6 +363,7 @@ struct window_frame {
> >
> > uint32_t last_time;
> > uint32_t did_double, double_click;
> > + int32_t last_id, double_id;
> > };
> >
> > struct menu {
> > @@ -2380,7 +2381,23 @@ frame_touch_down_handler(struct widget
> > *widget, struct input *input, {
> > struct window_frame *frame = data;
> >
> > - frame_touch_down(frame->frame, input, id, x, y);
> > + frame->double_click = 0;
> > + if (time - frame->last_time <= DOUBLE_CLICK_PERIOD &&
> > + frame->last_id == id) {
> > + frame->double_click = 1;
> > + frame->did_double = 1;
> > + frame->double_id = id;
> > + } else
> > + frame->did_double = 0;
> > +
> > + frame->last_time = time;
> > + frame->last_id = id;
> > +
> > + if (frame->double_click)
> > + frame_double_touch_down(frame->frame, input, id, x, y);
> > + else
> > + frame_touch_down(frame->frame, input, id, x, y);
> > +
> > frame_handle_status(frame, input, time,
> > THEME_LOCATION_CLIENT_AREA);
>
> >Hi,
>
> >hmm, should this perhaps be restricted to the case, where you start
> >with no touches down, then one touch id does down-up, then again
> >down-up, and only interpret that as a double-touch?
>
> In order to support multi touch, I didn't do this restriction.
>
> >With your current code, isn't is possible to keep, say, one finger
> >down while double-touching with another finger? Is that intended?
> >Thanks,
> >pq
>
> It is my intend to keep one finger down while double-touching with another
> finger.
> So that we can operate with both hands and support multi touch.
>But touch points are never independent, are they?
>Doesn't putting one finger down take an implicit grab, which causes all
>additional fingers to be restricted to the
>surface with the grab?
Yes, I agree with you.
>You cannot distinguish left hand from right, fingers all create just arbitrary
>touch points.
>In src/input.c it is written around line 1523:
> /* the first finger down picks the view, and all further go
>* to that view for the remainder of the touch session i.e.
>* until all touch points are up again. */
>So that means that you cannot hold a finger down on one window, and then
>double-tap another window.
So this means that all touch points must be in one window in order to support
multi touch. Weston have given us such limitation.
>Does it really make sense to be able to hold one finger down on the same
>window, and double-tap with another?
>If I hold a finger down on the window, can I usually use another finger to
>push button widgets on the same
>window? By "usually" I mean in whatever touch interfaces there are on the
>market / in the wild.
In a virtual key board, one finger could hold Shift key and another finger
could single or double touch other key to enter capital like physical key board.
>How would you distinguish a "left thumb down on something, drag & drop
>something else with right index
>finger" from the "zoom pinch gesture"?
If all touch points are in one window at the same time, each touch point has a
unique touch ID. Using this ID, APP could identify them. Left thumb's drog &
dorp and Right index finger 's zoom gesture are independent.
My current code is compatible with your proposal restriction, and it could also
add multi touch support in one window.
>Thanks,
>pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [PATCH 2/2] clients: Maximize window when double touch on title bar
On Thu, 12 Jun 2014 11:06:26 +0800
Xiong Zhang wrote:
> Signed-off-by: Xiong Zhang
> ---
> clients/window.c| 26 --
> shared/cairo-util.h | 7 +++
> shared/frame.c | 49 +
> 3 files changed, 80 insertions(+), 2 deletions(-)
>
> diff --git a/clients/window.c b/clients/window.c
> index 7c9c518..a608a84 100644
> --- a/clients/window.c
> +++ b/clients/window.c
> @@ -363,6 +363,7 @@ struct window_frame {
>
> uint32_t last_time;
> uint32_t did_double, double_click;
> + int32_t last_id, double_id;
> };
>
> struct menu {
> @@ -2380,7 +2381,23 @@ frame_touch_down_handler(struct widget *widget, struct
> input *input,
> {
> struct window_frame *frame = data;
>
> - frame_touch_down(frame->frame, input, id, x, y);
> + frame->double_click = 0;
> + if (time - frame->last_time <= DOUBLE_CLICK_PERIOD &&
> + frame->last_id == id) {
> + frame->double_click = 1;
> + frame->did_double = 1;
> + frame->double_id = id;
> + } else
> + frame->did_double = 0;
> +
> + frame->last_time = time;
> + frame->last_id = id;
> +
> + if (frame->double_click)
> + frame_double_touch_down(frame->frame, input, id, x, y);
> + else
> + frame_touch_down(frame->frame, input, id, x, y);
> +
> frame_handle_status(frame, input, time, THEME_LOCATION_CLIENT_AREA);
>Hi,
>hmm, should this perhaps be restricted to the case, where you start
>with no touches down, then one touch id does down-up, then again
>down-up, and only interpret that as a double-touch?
In order to support multi touch, I didn't do this restriction.
>With your current code, isn't is possible to keep, say, one finger down
>while double-touching with another finger? Is that intended?
>Thanks,
>pq
It is my intend to keep one finger down while double-touching with another
finger.
So that we can operate with both hands and support multi touch.
> }
>
> @@ -2391,7 +2408,12 @@ frame_touch_up_handler(struct widget *widget,
> {
> struct window_frame *frame = data;
>
> - frame_touch_up(frame->frame, input, id);
> + if (frame->double_id == id && frame->did_double) {
> + frame->did_double = 0;
> + frame->double_id = 0;
> + frame_double_touch_up(frame->frame, input, id);
> + } else
> + frame_touch_up(frame->frame, input, id);
> frame_handle_status(frame, input, time, THEME_LOCATION_CLIENT_AREA);
> }
>
> diff --git a/shared/cairo-util.h b/shared/cairo-util.h
> index 4e736ef..92f9e74 100644
> --- a/shared/cairo-util.h
> +++ b/shared/cairo-util.h
> @@ -215,6 +215,13 @@ frame_double_click(struct frame *frame, void *pointer,
> uint32_t button, enum frame_button_state state);
>
> void
> +frame_double_touch_down(struct frame *frame, void *data, int32_t id,
> + int x, int y);
> +
> +void
> +frame_double_touch_up(struct frame *frame, void *data, int32_t id);
> +
> +void
> frame_repaint(struct frame *frame, cairo_t *cr);
>
> #endif
> diff --git a/shared/frame.c b/shared/frame.c
> index 768cc2e..774f499 100644
> --- a/shared/frame.c
> +++ b/shared/frame.c
> @@ -868,6 +868,55 @@ frame_double_click(struct frame *frame, void *data,
> }
>
> void
> +frame_double_touch_down(struct frame *frame, void *data, int32_t id,
> + int x, int y)
> +{
> + struct frame_touch *touch = frame_touch_get(frame, data);
> + struct frame_button *button = frame_find_button(frame, x, y);
> + enum theme_location location;
> +
> + if (touch && button) {
> + touch->button = button;
> + frame_button_press(touch->button);
> + return;
> + }
> +
> + location = theme_get_location(frame->theme, x, y,
> + frame->width, frame->height,
> + frame->flags & FRAME_FLAG_MAXIMIZED ?
> + THEME_FRAME_MAXIMIZED : 0);
> +
> + switch (location) {
> + case THEME_LOCATION_TITLEBAR:
> + frame->status |= FRAME_STATUS_MAXIMIZE;
> + break;
> + case THEME_LOCATION_RESIZING_TOP:
> + case THEME_LOCATION_RESIZING_BOTTOM:
> + case THEME_LOCATION_RESIZING_LEFT:
> + case THEME_LOCATION_RESIZING_RIGHT:
> + case THEME_LOCATION_RESIZING_TOP_LEFT:
> + case THEME_LOCATION_RESIZING_TOP_RIGHT:
> + case THEME_LOCATION_RESIZING_BOTTOM_LEFT:
> + case THEME_LOCATION_RESIZING_BOTTOM_RIGHT:
> + frame->status |= FRAME_STATUS_RESIZE;
> + break;
> + default:
> + break;
> + }
> +}
> +
> +void
> +frame_double_touch_up(struct frame *frame, void *data, int32_t id)
> +{
> + struct frame_touch *touch = frame_touch_get(frame, data);
> +
> + if (touch && touch->button) {
> + frame_button_release(touch->button);
> + frame_touch_destro
RE: Need help in builing Mesa
I never met this problem. But you can try to install llvm-3.3-dev. thanks -Original Message- From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On Behalf Of Srivardhan M S Sent: Thursday, March 27, 2014 1:13 PM To: Zhang, Xiong Y Cc: wayland-devel@lists.freedesktop.org Subject: Re: Need help in builing Mesa Thanks Zhang, Now am struck with another issue: configure: error: Could not find llvm shared libraries: Please make sure you have built llvm with the --enable-shared option and that your llvm libraries are installed in /usr/lib/llvm-2.9/lib If you have installed your llvm libraries to a different directory you can use the --with-llvm-prefix= configure flag to specify this directory. NOTE: Mesa is attempting to use llvm shared libraries by default. If you do not want to build with llvm shared libraries and instead want to use llvm static libraries then add --disable-llvm-shared-libs to your configure invocation and rebuild. I've installed all llvm libraries. I did "sudo apt-get install llvm*" and installed all llvm libs. Still am getting the error. Can you pls let me know how I can proceed? Thank-you, Sri On Thu, Mar 27, 2014 at 10:20 AM, Zhang, Xiong Y wrote: > You can build Mesa with --disable-dri3 > > thanks > -Original Message- > From: wayland-devel > [mailto:wayland-devel-boun...@lists.freedesktop.org] On Behalf Of > Srivardhan M S > Sent: Thursday, March 27, 2014 12:25 PM > To: wayland-devel@lists.freedesktop.org > Subject: Need help in builing Mesa > > Hi, > > I am new to Wayland. I am following the instructions in the link > http://wayland.freedesktop.org/building.html to build wayland. I successfully > cloned wayland and drm and compiled them. But am struck in mesa. > > I've cloned the mesa code. When I run the autogen.sh as in the instructions, > I get following error: > checking for DRI3PROTO... no > configure: error: Package requirements (dri3proto >= 1.0) were not met: > > No package 'dri3proto' found > > Consider adjusting the PKG_CONFIG_PATH environment variable if you installed > software in a non-standard prefix. > > Alternatively, you may set the environment variables DRI3PROTO_CFLAGS and > DRI3PROTO_LIBS to avoid the need to call pkg-config. > See the pkg-config man page for more details. > > Am using Ubuntu 12.04 and am not able to find the DRI3PROTO package via > apt-get. Can pls let me know how I can proceed. > > Thank-you, > Sri > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: Need help in builing Mesa
You can build Mesa with --disable-dri3 thanks -Original Message- From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On Behalf Of Srivardhan M S Sent: Thursday, March 27, 2014 12:25 PM To: wayland-devel@lists.freedesktop.org Subject: Need help in builing Mesa Hi, I am new to Wayland. I am following the instructions in the link http://wayland.freedesktop.org/building.html to build wayland. I successfully cloned wayland and drm and compiled them. But am struck in mesa. I've cloned the mesa code. When I run the autogen.sh as in the instructions, I get following error: checking for DRI3PROTO... no configure: error: Package requirements (dri3proto >= 1.0) were not met: No package 'dri3proto' found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables DRI3PROTO_CFLAGS and DRI3PROTO_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. Am using Ubuntu 12.04 and am not able to find the DRI3PROTO package via apt-get. Can pls let me know how I can proceed. Thank-you, Sri ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 02/12] shell.c: Restore maximized and fullscreen window on destroyed output
On Tue, 2014-03-18 at 10:21 +0200, Conselvan De Oliveira, Ander wrote:
> On 03/18/2014 07:39 AM, Zhang, Xiong Y wrote:
> > On Mon, 2014-03-17 at 19:17 +0200, Ander Conselvan de Oliveira wrote:
> >> On 03/07/2014 10:27 AM, Xiong Zhang wrote:
> >> > When maximized or fullscreen window is on destroyed output, compositor
> >> > can't change these windows to normal window without notify client,
> >> > otherwise maximize icon or F11 buttion lose its effect after output
> >> > unplug.
> >> >
> >> > Instead we keep these window as maximized or fullscreen, just change
> >> > it's size to target output.
> >>
> >> I'm not sure about this. xdg-shell lets us handle this properly and
> >> wl_shell should be deprecated at some point, so I'm more inclined to
> >> keep the current behavior.
> >
> >>
> >> Cheers,
> >> Ander
> >>
> > yes, using xdg-shell, maximize icon and F11 button can take effect after
> > output unplug.
> > But server secretly changes window's state from maximized to unmaximized
> > without notifying client, it's unreasonable.
>
> What I meant is that xdg-shell provides mechanism to notify the client
> if it looses the maximized or fullscreen state. If I understand
> correctly, xdg-shell is an attempt to do wl_shell right and once it is
> finished wl_shell will be deprecated. So in my understanding, as long as
> we do the right thing with xdg-shell we are OK.
>
> But as I said, I'm not sure. I don't like the behavior of taking a
> fullscreen surface from an unplugged output and making it fullscreen in
> another output. I'd prefer to unfullscreen it. But if we must do
> something sensible with wl_shell, then I guess this is the way to go.
>
> Cheers,
> Ander
I like your ideal that restore maximized and full screen window to
normal , the patch should be like this:
shell.c: Restore maximized and fullscreen window on destroyed output
Signed-off-by: Xiong Zhang
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 2cc9407..4c2b409 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -5529,7 +5529,7 @@ workspace_move_surface_down_binding(struct
weston_seat *seat, uint32_t time,
static void
shell_reposition_view_on_output_destroy(struct weston_view *view)
{
- struct weston_output *output, *first_output;
+ struct weston_output *output;
struct weston_compositor *ec = view->surface->compositor;
struct shell_surface *shsurf;
float x, y;
@@ -5566,9 +5566,18 @@ shell_reposition_view_on_output_destroy(struct
weston_view *view)
if (shsurf) {
shsurf->saved_position_valid = false;
- shsurf->next_state.maximized = false;
- shsurf->next_state.fullscreen = false;
- shsurf->state_changed = true;
+
+ /* Restore maxmized window */
+ if (shsurf->state.maximized)
+ xdg_surface_change_state(shsurf,
+
XDG_SURFACE_STATE_MAXIMIZED,
+0, 0);
+
+ /* Restore fullscreen window */
+ if (shsurf->state.fullscreen)
+ xdg_surface_change_state(shsurf,
+
XDG_SURFACE_STATE_FULLSCREEN,
+0, 0);
}
}
thanks
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 02/12] shell.c: Restore maximized and fullscreen window on destroyed output
On Mon, 2014-03-17 at 19:17 +0200, Ander Conselvan de Oliveira wrote:
On 03/07/2014 10:27 AM, Xiong Zhang wrote:
> When maximized or fullscreen window is on destroyed output, compositor
> can't change these windows to normal window without notify client,
> otherwise maximize icon or F11 buttion lose its effect after output unplug.
>
> Instead we keep these window as maximized or fullscreen, just change
> it's size to target output.
I'm not sure about this. xdg-shell lets us handle this properly and
wl_shell should be deprecated at some point, so I'm more inclined to
keep the current behavior.
Cheers,
Ander
yes, using xdg-shell, maximize icon and F11 button can take effect after output
unplug.
But server secretly changes window's state from maximized to unmaximized
without notifying client, it's unreasonable. If the unplugged output is much
larger than remaining output, the maximized window can't been fully displayed
on remaining output when the output of maximized window is unplugged. In order
to restore this window to normal, user must move this window to see the
maximize icon. It isn't convenient for user.
thanks.
>
> Signed-off-by: Xiong Zhang
> mailto:xiong.y.zh...@intel.com>>
> ---
> desktop-shell/shell.c | 24 +---
> 1 file changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
> index bee1b0b..02dd1b8 100644
> --- a/desktop-shell/shell.c
> +++ b/desktop-shell/shell.c
> @@ -5534,6 +5534,7 @@ shell_reposition_view_on_output_destroy(struct
> weston_view *view)
> struct shell_surface *shsurf;
> float x, y;
> int visible;
> + struct weston_view *black_view;
>
> x = view->geometry.x;
> y = view->geometry.y;
> @@ -5557,6 +5558,8 @@ shell_reposition_view_on_output_destroy(struct
> weston_view *view)
> x = first_output->x + first_output->width / 4;
> y = first_output->y + first_output->height / 4;
>
> + output = first_output;
> +
> weston_view_set_position(view, x, y);
> } else
> weston_view_geometry_dirty(view);
> @@ -5566,9 +5569,24 @@ shell_reposition_view_on_output_destroy(struct
> weston_view *view)
>
> if (shsurf) {
> shsurf->saved_position_valid = false;
> - shsurf->next_state.maximized = false;
> - shsurf->next_state.fullscreen = false;
> - shsurf->state_changed = true;
> +
> + /* Resize maxmized window to target output. */
> + if (shsurf->state.maximized)
> + set_maximized(shsurf, output);
> +
> + /* Resize fullscreen window to target output. */
> + if (shsurf->state.fullscreen) {
> + black_view = shsurf->fullscreen.black_view->surface;
> + weston_surface_destroy(black_view->surface);
> + shsurf->fullscreen.black_view = NULL;
> +
> + set_fullscreen(shsurf,
> +shsurf->fullscreen.type,
> +shsurf->fullscreen.framerate,
> +output);
> + }
> +
> + shsurf->state_changed = false;
> }
> }
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC v2] Wayland presentation extension (video protocol)
On Thu, 2014-01-30 at 17:35 +0200, Pekka Paalanen wrote: > Hi, > > it's time for a take two on the Wayland presentation extension. > > > 1. Introduction > > The v1 proposal is here: > http://lists.freedesktop.org/archives/wayland-devel/2013-October/011496.html > > In v2 the basic idea is the same: you can queue frames with a > target presentation time, and you can get accurate presentation > feedback. All the details are new, though. The re-design started > from the wish to handle resizing better, preferably without > clearing the buffer queue. > > All the changed details are probably too much to describe here, > so it is maybe better to look at this as a new proposal. It > still does build on Frederic's work, and everyone who commented > on it. Special thanks to Axel Davy for his counter-proposal and > fighting with me on IRC. :-) > > Some highlights: > > - Accurate presentation feedback is possible also without > queueing. > > - You can queue also EGL-based rendering, and get presentation > feedback if you want. Also EGL can do this internally, too, as > long as EGL and the app do not try to use queueing at the same time. > > - More detailed presentation feedback to better allow predicting > future display refreshes. > > - If wl_viewport is used, neither video resolution changes nor > surface (window) size changes alone require clearing the queue. > Video can continue playing even during resizes. Sorry, I can't understand this. Could you explain this more? What's the current problem for resizing window? How will you resolve it in presentation extensions? thanks > > Thanks, > pq > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 5/9] compositor: Output unplug in clone mode
On Fri, 2014-02-14 at 09:56 +0200, Pekka Paalanen wrote: > On Fri, 14 Feb 2014 15:17:40 +0800 > Xiong Zhang wrote: > Hi, > > just a general note: it seems the DRM backend code is getting into > pretty deep indentation levels. I would recommend splitting chunks out > into functions where you have a logical does-one-thing block, even > if the function would be only used in one place. It makes the code flow > easier to read, when the blocks have been chosen properly and the > resulting functions have descriptive names. Only if possible, of course. > > Thanks for your recommendation. I will remember it and modify the code. thanks > Thanks, > pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/9] compositor: Output repaint in clone mode
On Fri, 2014-02-14 at 09:49 +0200, Pekka Paalanen wrote:
> On Fri, 14 Feb 2014 15:17:37 +0800
> Xiong Zhang wrote:
>
> > Because slave output doesn't in compositor->output_list,
> > the output->repaint()is called from master output only.
> > When master output repaint,all the slave output should
> > repaint also.
> >
> > Slave output share fb with master output,when both slave and
> > master have finished page flip, the fb obj can be released.
>
> Hi,
>
> ok, so core's finish_frame will be called when all flips of a master
> output and its slaves have completed. If the refresh rates of these
> outputs are different, I think it means that the perceived frame rate
> (the frequency at which finish_frame is called) will fluctuate over
> time. That will have very interesting consequences for presentation
> prediction and feedback.
Thanks for your remind. Frequency different between outputs is indeed a
challenge for clone mode.
The perceived frame rate will be the lowest refresh rate in master and
its slaves. This will have influence on presentation prediction.
>
> OTOH, the future will bring dynamically varied refresh rate monitors,
> so client's should be prepared for fluctuations in the apparent vblank
> frequency anyway.
>
> I'm not claiming your patch creates a problem, I think we can cope with
> it, but it will be interesting nevertheless. Just pointing out we
> should keep this in mind.
>
> We may need to tweak finish_frame calling logic a bit, so that it gets
> the flip completion timestamp of the master output, and not whatever
> output was the last one. But that will only be a concern when the
> presentation extension lands. I think... unless we care about the
> timestamp carried by the frame callbacks.
>
>
yes, this is a good ideal. finish_frame should get the flip completion
timestamp of the master output.
But client will get frame callback when both master and its slaves
finish flip.
thanks
> Thanks,
> pq
>
>
> > Signed-off-by: Xiong Zhang
> > ---
> > src/compositor-drm.c | 112
> > ++-
> > src/compositor.c | 3 +-
> > 2 files changed, 112 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> > index 6773226..ce85aec 100644
> > --- a/src/compositor-drm.c
> > +++ b/src/compositor-drm.c
> > @@ -155,6 +155,7 @@ struct drm_output {
> >
> > uint32_t transform;
> > int scale, mm_width, mm_height;
> > + uint32_t page_flip_count;
> >
> > struct gbm_surface *surface;
> > struct gbm_bo *cursor_bo[2];
> > @@ -591,8 +592,9 @@ drm_output_repaint(struct weston_output *output_base,
> > struct drm_sprite *s;
> > struct drm_mode *mode;
> > int ret = 0;
> > + struct drm_output *clone_output;
> >
> > - if (output->destroy_pending)
> > + if (output->destroy_pending || output->base.is_slave)
> > return -1;
> >
> > if (!output->next)
> > @@ -612,6 +614,25 @@ drm_output_repaint(struct weston_output *output_base,
> > goto err_pageflip;
> > }
> > output_base->set_dpms(output_base, WESTON_DPMS_ON);
> > +
> > + wl_list_for_each(clone_output, &output->base.clone_output_list,
> > +base.link) {
> > + mode = container_of(clone_output->base.current_mode,
> > + struct drm_mode, base);
> > +
> > + ret = drmModeSetCrtc(compositor->drm.fd,
> > +clone_output->crtc_id,
> > +output->next->fb_id, 0, 0,
> > +&clone_output->connector_id, 1,
> > +&mode->mode_info);
> > + if (ret) {
> > + weston_log("set mode failed:%m\n");
> > + goto err_pageflip;
> > + }
> > +
> > + clone_output->base.set_dpms(&clone_output->base,
> > + WESTON_DPMS_ON);
> > + }
> > }
> >
> > if (drmModePageFlip(compositor->drm.fd, output->crtc_id,
> > @@ -622,6 +643,23 @@ drm_output_repaint(struct weston_output *output_base,
> > }
> >
> > output->page_flip_pending = 1;
> > + output->page_flip_count++;
> > +
> > + /* clone output repaint*/
> > + wl_list_for_each(clone_output, &output->base.clone_output_list,
> > +base.link) {
> > + if (drmModePageFlip(compositor->drm.fd,
> > + clone_output->crtc_id,
> > + output->next->fb_id,
> > + DRM_MODE_PAGE_FLIP_EVENT,
> > + clone_output) < 0) {
> > + weston_log("queueing pageflip failed:%m\n");
> > + goto err_pageflip;
> > + }
> > +
> > + clone_output->page_flip_pend
Re: [PATCH weston 4/4] compositor: Move view repositioning logic into shell
On Wed, 2014-01-29 at 18:47 +0200, Ander Conselvan de Oliveira wrote:
> Remove the listener for output destroy from weston_view and instead
> iterate views owned by the shell in its own output destroy listener.
>
> This simplifies the code a bit since keeping the view listening for the
> destroy on the right output was a bit complicated. This also removes the
> function pointer output_destroyed from weston_view. The only user for it
> was desktop shell, but now this is all handled in shell.c.
> ---
> desktop-shell/shell.c | 86
> +--
> src/compositor.c | 68
> src/compositor.h | 8 -
> 3 files changed, 70 insertions(+), 92 deletions(-)
>
> diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
> index 888e33b..fb69794 100644
> --- a/desktop-shell/shell.c
> +++ b/desktop-shell/shell.c
> @@ -2956,8 +2956,6 @@ shell_handle_surface_destroy(struct wl_listener
> *listener, void *data)
>
> static void
> shell_surface_configure(struct weston_surface *, int32_t, int32_t);
> -static void
> -shell_surface_output_destroyed(struct weston_surface *);
>
> struct shell_surface *
> get_shell_surface(struct weston_surface *surface)
> @@ -2994,7 +2992,6 @@ create_common_surface(void *shell, struct
> weston_surface *surface,
>
> surface->configure = shell_surface_configure;
> surface->configure_private = shsurf;
> - surface->output_destroyed = shell_surface_output_destroyed;
>
> shsurf->shell = (struct desktop_shell *) shell;
> shsurf->unresponsive = 0;
> @@ -4793,19 +4790,6 @@ shell_surface_configure(struct weston_surface *es,
> int32_t sx, int32_t sy)
> }
> }
>
> -static void
> -shell_surface_output_destroyed(struct weston_surface *es)
> -{
> - struct shell_surface *shsurf = get_shell_surface(es);
> -
> - assert(shsurf);
> -
> - shsurf->saved_position_valid = false;
> - shsurf->next_state.maximized = false;
> - shsurf->next_state.fullscreen = false;
> - shsurf->state_changed = true;
> -}
> -
> static void launch_desktop_shell_process(void *data);
>
> static void
> @@ -5425,11 +5409,81 @@ workspace_move_surface_down_binding(struct
> weston_seat *seat, uint32_t time,
> }
>
> static void
> +shell_reposition_view_on_output_destroy(struct weston_view *view)
> +{
> + struct weston_output *output, *first_output;
> + struct weston_compositor *ec = view->surface->compositor;
> + struct shell_surface *shsurf;
> + float x, y;
> + int visible;
> +
> + x = view->geometry.x;
> + y = view->geometry.y;
> +
> + /* At this point the destroyed output is not in the list anymore.
> + * If the view is still visible somewhere, we leave where it is,
> + * otherwise, move it to the first output. */
> + visible = 0;
> + wl_list_for_each(output, &ec->output_list, link) {
> + if (pixman_region32_contains_point(&output->region,
> +x, y, NULL)) {
> + visible = 1;
> + break;
> + }
> + }
> +
> + if (!visible) {
> + first_output = container_of(ec->output_list.next,
> + struct weston_output, link);
> +
> + x = first_output->x + first_output->width / 4;
> + y = first_output->y + first_output->height / 4;
> + }
> +
> + weston_view_set_position(view, x, y);
If view is visible, this view's geometry won't be changed.
weston_view_set_position() won't mark this view as dirty, so this view
doesn't have chance to reassign a output and this view will disappear.
> +
> + shsurf = get_shell_surface(view->surface);
> +
> + if (shsurf) {
> + shsurf->saved_position_valid = false;
> + shsurf->next_state.maximized = false;
> + shsurf->next_state.fullscreen = false;
> + shsurf->state_changed = true;
> + }
> +}
> +
> +static void
> +shell_reposition_views_on_output_destroy(struct shell_output *shell_output)
> +{
> + struct desktop_shell *shell = shell_output->shell;
> + struct weston_output *output = shell_output->output;
> + struct weston_layer *layer;
> + struct weston_view *view;
> +
> + /* Move all views in the layers owned by the shell */
> + wl_list_for_each(layer, shell->fullscreen_layer.link.prev, link) {
> + wl_list_for_each(view, &layer->view_list, layer_link) {
> + if (view->output != output)
> + continue;
> +
> + shell_reposition_view_on_output_destroy(view);
> + }
> +
> + /* We don't start from the beggining of the layer list, so
> + * make sure we don't wrap around it. */
> + if (layer == &shell->background_layer)
> + break;
> + }
> +}
> +
> +static void
> handle_output_destroy(struct w
RE: [PATCH] compositor: Ensure views on hiden workspace are listening correct output
> @@ -406,7 +406,8 @@ weston_view_output_destroy_handler(struct wl_listener
> *listener,
> struct weston_output, link);
>
> x = first_output->x + first_output->width / 4;
> - y = first_output->y + first_output->height / 4;
> + if (y > first_output->y)
> + y = first_output->y + first_output->height / 4;
> }
> We should move this repositioning logic into the shell. I think the proper
> fix for the workspace case then would be to cause all the hidden surfaces to
> have their saved positions invalidated and then run the initial positioning
> algorithm when the user makes them visible by switching workspaces.
There is no saved positions for the views on hiden workspace. Shell change
views->geometry.transformation_list to show or hide views in
workspace_translate_in() and workspace_translate_out() function. We can't
change hiden view's y coordinate in weston_view_output_destroy_handler(),
otherwise this hiden view will never see again.
> weston_view_assign_output(struct weston_view *ev)
> }
> pixman_region32_fini(®ion);
>
> - if (ev->output_mask != 0) {
> + if (!wl_list_empty(&ev->output_destroy_listener.link) && mask != 0)
> +{
> wl_list_remove(&ev->output_move_listener.link);
> wl_list_remove(&ev->output_destroy_listener.link);
> }
>I sent a patch yesterday to fix a case where we couldn't just
>wl_list_remove() the listener. Do you still need the wl_list_empty() check
>after that?
You mean this patch:
24dff2b7 compositor:Clean up view output move and destroy listeners
If it is the above patch, I still need the wl_list_empty() check.
Even without output unplug, the list of output->destroy_signal is mess when we
change workspace.
Consider the following situation:
1. the view is visible,
view is in the list of output->destroy_signal
2. Changing workspace, the view is invisible.
View is still in the output->destroy_signal with ev->output_mask = 0
3. Changing workspace, the view is visible again.
Because ev->output_mask is 0 after step 2, we won't remove view from the
list of output->destroy_signal and add view to the list of
output->destroy_signal again in this step.
So from now on, the list of output->signal is mess. Once this output is
unplugged, we will iterate this list, if there are many views in the list,
system will enter into deadloop to iterate this list again and again.
thanks
-Original Message-
From: Ander Conselvan de Oliveira [mailto:conselv...@gmail.com]
Sent: Saturday, December 21, 2013 3:18 AM
To: Zhang, Xiong Y; Conselvan De Oliveira, Ander
Cc: wayland-devel@lists.freedesktop.org
Subject: Re: [PATCH] compositor: Ensure views on hiden workspace are listening
correct output
On 12/19/2013 11:26 AM, Xiong Zhang wrote:
> The views on hiden workspace can't restored correctly when their
> output was unplugged. There are two reasons:
>
> First: the views on hiden workspace is restored through animation
> which will change y coordinate continually, if the y coordinate of
> invisible views are setted to first_output->height/4, these views will
> be changed to some invisible region by animation.
>
> Second: the wrong way to manage view->output_destroy_listener.link.
> Considering the following serials:
> a. the view is visible, so the view listen one output signal b. the
> view is invisible, view->output_mask = 0 and view is still listenering
> the previous output signal c. the view is visible again. We will add
> view to previous output signal again without removing the view from
> the previous output signal. So the listener list of previous output's
> signal is wrong at this point.When the output is unplgged, the system
> will dead loop on the listener list of this output signal.
>
> Signed-off-by: Xiong Zhang
> ---
> src/compositor.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/src/compositor.c b/src/compositor.c index
> 6ca297a..9929be1 100644
> --- a/src/compositor.c
> +++ b/src/compositor.c
> @@ -383,7 +383,7 @@ weston_view_output_destroy_handler(struct
> wl_listener *listener,
>
> /* the child window's view->geometry is a relative coordinate to
>* parent view, no need to move child_view. */
> - if (ev->geometry.parent)
> + if (ev->geometry.parent || wl_list_empty(&ec->output_list))
> return;
>
> x = ev->geometry.x;
> @@ -406,7 +406,8 @@ weston_view_output_destroy_handler(struct wl_listener
> *listener,
> struct weston_output
RE: [PATCH 1/3] shell: restore app on non default and unplugged output
Hi, Ander:
Thanks for your review. Your idea is feasible.
>> To achieve that, we could add an output_destroyed() function pointer in
>> weston_surface
But I think we could add an output_destroyed() function pointer in weston_view
not in Weston_surface, because as Jason's idea one surface may have several
views, what we moved is view not surface.
Because each output has a destroy_signal, we should register view's
output_destroy_handler in Weston_view_assign_output(). So when one view is
moved from one output to another output, the output_destroyed_handler should
register again.
clamp_coordinate() is a common function and will be used in src/input.c and
src/shell.c, I can implement a function weston_coordinate_clamp() in
compositor.c and export it, is this OK ?
Thanks.
-Original Message-
From: Ander Conselvan de Oliveira [mailto:conselv...@gmail.com]
Sent: Tuesday, December 03, 2013 11:06 PM
To: Zhang, Xiong Y
Cc: wayland-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/3] shell: restore app on non default and unplugged output
Hi Xiong,
It seems that we need different logic for moving the views depending on the
surface role, so I'm thinking this code should actually be part of a surface
role implementation. For instance, instead of implementing the logic of moving
the pointer surface in the shell, that would go in src/input.c together with
the implementation of pointer_cursor_surface_configure().
To achieve that, we could add an output_destroyed() function pointer in
weston_surface, that would be called from an output_destroy_listener in
weston_view. That should simplify the code below quite a bit since traversing
the list of views would be done by the wl_signal_emit() code.
The output_destroyed() entry point could receive the new output as a parameter,
so the role-specific logic would only have to determine where in that output
the new surface should be and move it. And of course handle any role-specific
needs, such as warping the pointer.
I have some comments about the coding style below.
On 12/03/2013 05:25 AM, Xiong Zhang wrote:
> if the unplugged output isn't the default output, move cursor and APP
> widow to default output
The commit message should be properly capitalized and punctuated.
>
> Signed-off-by: Xiong Zhang
> ---
> src/shell.c | 190
> ++--
> 1 file changed, 186 insertions(+), 4 deletions(-)
>
> diff --git a/src/shell.c b/src/shell.c index dfcb525..16d22f1 100644
> --- a/src/shell.c
> +++ b/src/shell.c
> @@ -6061,15 +6061,197 @@ workspace_move_surface_down_binding(struct
> weston_seat *seat, uint32_t time,
> take_surface_to_workspace_by_seat(shell, seat, new_index);
> }
>
> +/* if (*x, *y) will be moved beyong target_output, clamp it*/
Beyond is misspelled and there's a space missing in the end. I'd also recommend
properly capitalizing and punctuating the sentences.
/* If (*x, *y) will be removed beyond target_output, clamp it. */
> +static int
> +clamp_coordinate(struct weston_output *target_output,
> + struct weston_output *original_output,
> + float *x, float *y)
The parameters should be aligned with the parenthesis, i.e.,
clamp_coordinate(struct weston_output *target_output,
struct weston_output *original_output,
> +{
> + int32_t rel_x, rel_y;
> + int result = 0;
> +
> + rel_x = *x - original_output->x;
> + rel_y = *y - original_output->y;
> +
> + if (rel_x > target_output->width) {
> + *x = original_output->x + target_output->width / 4;
> + result = 1;
> + }
> + if (rel_y > target_output->height) {
> + *y = original_output->y + target_output->height / 4;
> + result = 1;
> + }
> + return result;
> +}
> +
> +static void
> +handle_view_on_destroyed_output(struct weston_view *view,
> + struct weston_output *target_output) {
> + float new_x, new_y, original_x, original_y;
> +
> + /* the child window's view->geometry is a relative coordinate to */
> + /* parent view, no need to move child_view */
We format multi-line comments like this:
/* First line.
* Second line. */
> + if (view->geometry.parent)
> + return;
> +
> + original_x = view->geometry.x;
> + original_y = view->geometry.y;
> +
> + clamp_coordinate(target_output, view->output,
> + &original_x, &original_y);
> +
> + new_x = target_output->x + original_x - view->output->x;
> + new_y = target_output->y + original_y - view->output->y;
> + weston_view_set_posit
RE: [PATCH 0/9] implement multi screen clone mode in drm-backend.so
Yes, per compositor clone mode is the same as X server clone mode. Per output clone mode is more convenient and usable. I will implement it using a "clone" config option in the output section of Weston.ini file. thanks From: Jason Ekstrand [mailto:ja...@jlekstrand.net] Sent: Wednesday, October 23, 2013 10:18 AM To: Zhang, Xiong Y Cc: wayland-devel@lists.freedesktop.org Subject: Re: [PATCH 0/9] implement multi screen clone mode in drm-backend.so Xiong, I'm not sure that we need to go that far right now. I'm fine for now with just a config option. My primary concern is that you should be able to have three outputs A, B, and C where A and B are masters and C is cloned to A. In your original implementation it looked to me like it was only possible to have one master and if you had three outputs then they would all have to show the same thing. --Jason Ekstrand On Tue, Oct 22, 2013 at 9:06 PM, Zhang, Xiong Y mailto:xiong.y.zh...@intel.com>> wrote: So you want to adjust output's work mode (clone or extend) at runtime. Is this correct a new protocol should be added ? thanks From: Jason Ekstrand [mailto:ja...@jlekstrand.net<mailto:ja...@jlekstrand.net>] Sent: Wednesday, October 23, 2013 9:52 AM To: Zhang, Xiong Y Cc: wayland-devel@lists.freedesktop.org<mailto:wayland-devel@lists.freedesktop.org> Subject: Re: [PATCH 0/9] implement multi screen clone mode in drm-backend.so Xiong, A "clone" option would be one way to configure it. I just don't want to be tied to a single master output. --Jason On Tue, Oct 22, 2013 at 8:46 PM, Zhang, Xiong Y mailto:xiong.y.zh...@intel.com>> wrote: Jason, You mean that we can add a "clone" config option in output section of Weston.ini file. The "clone" config option decide whether this output is a slave output and which master output this slave output clone from . Is my understand correct ? thanks From: Jason Ekstrand [mailto:ja...@jlekstrand.net<mailto:ja...@jlekstrand.net>] Sent: Sunday, October 13, 2013 10:53 AM To: Zhang, Xiong Y Cc: wayland-devel@lists.freedesktop.org<mailto:wayland-devel@lists.freedesktop.org> Subject: Re: [PATCH 0/9] implement multi screen clone mode in drm-backend.so Xiong, I'm sorry for taking so long to reply; I meant to do so sooner but haven't found the time. First off, I'm glad to see someone implementing output cloning. It makes for all sorts of interesting cases that have yet to be tested. Also, I plan to implement it in the wayland backend at some point in the not-so-distant future. (Yes, it does make sense to put it in the wayland backend.) My biggest concern with your current implementation is that you are doing things in terms of a compositor-wide "clone mode" instead of per output "this output is a clone of that one". I think it is reasonable for a person to want, for instance three outputs A, B, and C where A and B are "masters" and C is a clone of A. Making it a compositor-wide flag would completely rule out this case. Thanks, --Jason Ekstrand On Tue, Sep 17, 2013 at 10:50 PM, Xiong Zhang mailto:xiong.y.zh...@intel.com>> wrote: the theory for clone mode is: all the outputs share the same fb, when primary output do modeset and pageflip, clone output do this also. I fulfill repaint, VT switch and hotplug function. I don't implement dynamical setting output's mdoe. Xiong Zhang (9): add multi-screen-mode option to weston.ini find primary output during drm_compositor_create in clone mode one pointer exist in only one output output gl repaint in clone mode deal with VT switch in clone mode hot plug add a output in clone mode maximize and fullscreen support in clone mode hot plug remove a output in clone mode improve hotplug remove a output in clone mode src/compositor-drm.c | 390 +++ src/compositor.c | 28 src/compositor.h | 9 ++ src/input.c | 7 +- src/shell.c | 10 +- src/zoom.c | 1 + weston.ini | 1 + 7 files changed, 414 insertions(+), 32 deletions(-) -- 1.8.3.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org<mailto:wayland-devel@lists.freedesktop.org> http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [PATCH 0/9] implement multi screen clone mode in drm-backend.so
So you want to adjust output's work mode (clone or extend) at runtime. Is this correct a new protocol should be added ? thanks From: Jason Ekstrand [mailto:ja...@jlekstrand.net] Sent: Wednesday, October 23, 2013 9:52 AM To: Zhang, Xiong Y Cc: wayland-devel@lists.freedesktop.org Subject: Re: [PATCH 0/9] implement multi screen clone mode in drm-backend.so Xiong, A "clone" option would be one way to configure it. I just don't want to be tied to a single master output. --Jason On Tue, Oct 22, 2013 at 8:46 PM, Zhang, Xiong Y mailto:xiong.y.zh...@intel.com>> wrote: Jason, You mean that we can add a "clone" config option in output section of Weston.ini file. The "clone" config option decide whether this output is a slave output and which master output this slave output clone from . Is my understand correct ? thanks From: Jason Ekstrand [mailto:ja...@jlekstrand.net<mailto:ja...@jlekstrand.net>] Sent: Sunday, October 13, 2013 10:53 AM To: Zhang, Xiong Y Cc: wayland-devel@lists.freedesktop.org<mailto:wayland-devel@lists.freedesktop.org> Subject: Re: [PATCH 0/9] implement multi screen clone mode in drm-backend.so Xiong, I'm sorry for taking so long to reply; I meant to do so sooner but haven't found the time. First off, I'm glad to see someone implementing output cloning. It makes for all sorts of interesting cases that have yet to be tested. Also, I plan to implement it in the wayland backend at some point in the not-so-distant future. (Yes, it does make sense to put it in the wayland backend.) My biggest concern with your current implementation is that you are doing things in terms of a compositor-wide "clone mode" instead of per output "this output is a clone of that one". I think it is reasonable for a person to want, for instance three outputs A, B, and C where A and B are "masters" and C is a clone of A. Making it a compositor-wide flag would completely rule out this case. Thanks, --Jason Ekstrand On Tue, Sep 17, 2013 at 10:50 PM, Xiong Zhang mailto:xiong.y.zh...@intel.com>> wrote: the theory for clone mode is: all the outputs share the same fb, when primary output do modeset and pageflip, clone output do this also. I fulfill repaint, VT switch and hotplug function. I don't implement dynamical setting output's mdoe. Xiong Zhang (9): add multi-screen-mode option to weston.ini find primary output during drm_compositor_create in clone mode one pointer exist in only one output output gl repaint in clone mode deal with VT switch in clone mode hot plug add a output in clone mode maximize and fullscreen support in clone mode hot plug remove a output in clone mode improve hotplug remove a output in clone mode src/compositor-drm.c | 390 +++ src/compositor.c | 28 src/compositor.h | 9 ++ src/input.c | 7 +- src/shell.c | 10 +- src/zoom.c | 1 + weston.ini | 1 + 7 files changed, 414 insertions(+), 32 deletions(-) -- 1.8.3.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org<mailto:wayland-devel@lists.freedesktop.org> http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [PATCH 0/9] implement multi screen clone mode in drm-backend.so
Jason, You mean that we can add a "clone" config option in output section of Weston.ini file. The "clone" config option decide whether this output is a slave output and which master output this slave output clone from . Is my understand correct ? thanks From: Jason Ekstrand [mailto:ja...@jlekstrand.net] Sent: Sunday, October 13, 2013 10:53 AM To: Zhang, Xiong Y Cc: wayland-devel@lists.freedesktop.org Subject: Re: [PATCH 0/9] implement multi screen clone mode in drm-backend.so Xiong, I'm sorry for taking so long to reply; I meant to do so sooner but haven't found the time. First off, I'm glad to see someone implementing output cloning. It makes for all sorts of interesting cases that have yet to be tested. Also, I plan to implement it in the wayland backend at some point in the not-so-distant future. (Yes, it does make sense to put it in the wayland backend.) My biggest concern with your current implementation is that you are doing things in terms of a compositor-wide "clone mode" instead of per output "this output is a clone of that one". I think it is reasonable for a person to want, for instance three outputs A, B, and C where A and B are "masters" and C is a clone of A. Making it a compositor-wide flag would completely rule out this case. Thanks, --Jason Ekstrand On Tue, Sep 17, 2013 at 10:50 PM, Xiong Zhang mailto:xiong.y.zh...@intel.com>> wrote: the theory for clone mode is: all the outputs share the same fb, when primary output do modeset and pageflip, clone output do this also. I fulfill repaint, VT switch and hotplug function. I don't implement dynamical setting output's mdoe. Xiong Zhang (9): add multi-screen-mode option to weston.ini find primary output during drm_compositor_create in clone mode one pointer exist in only one output output gl repaint in clone mode deal with VT switch in clone mode hot plug add a output in clone mode maximize and fullscreen support in clone mode hot plug remove a output in clone mode improve hotplug remove a output in clone mode src/compositor-drm.c | 390 +++ src/compositor.c | 28 src/compositor.h | 9 ++ src/input.c | 7 +- src/shell.c | 10 +- src/zoom.c | 1 + weston.ini | 1 + 7 files changed, 414 insertions(+), 32 deletions(-) -- 1.8.3.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org<mailto:wayland-devel@lists.freedesktop.org> http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [PATCH 2/2] compositor.c: restore surface->plane from destroyed plane to primary plane
>There is more work involved in fixing this - it's a somewhat bigger issue. We >do need to move surfaces back to the primary plane if they were on a plane >owned by the output as your patch does. But we also need to reset >surface->output if it points to >the destroyed output. >Probably by moving the surface back to one of the remaining outputs and >calling weston_surface_update_transform(), which will recompute the current >output. Yes, there is more work to fix this issue. Actually I have been working on this issue for almost one month that moving surface on destroyed output to default output as you said. Currently I have implement this function if system remove the last outpu in output_list, but if system remove the first output, some issue still need be fixed. After I fix these issue, I will send the patch set to maillist. But I think we can merge this patch in 1.3 release first, at least with this patch if user remove one output, system won't occur segment fault and mouse is usable, plug in the destroyed output again, everything can be restored normally. That's why I just send out these two patches firstly when I saw you mentioned this issue on the mail of "Wayland and Weston 1.3 releases are out" >I'm not quite sure how we'll do that... the cursor surface should be handled >in input.c, but all shell surfaces should be moved by shell.c. >Maybe they can just listen on the output->destroy_signal and move their >surfaces when that signal fires. >compositor-drm.c is still responsible for moving all surfaces out of planes >being destroyed, and it can do that just by looping through >compositor->surface_list. But I don't want to move them into the Every client APP has its own cursor surface, if mouse focus isn't on this app's cursor surface, this app's cursor surface won't on cursor_layer and compositor->surface_list. If mouse focus is on destroyed output but isn't on this APP when output is removed, then mouse is moved to this app after removing output, this cursor surface will be repainted and segment fault occur. So looping through compositor->surface_list can't get this kind hiden cursor surface and plane should track all the surface belonged to it. >primary plane. When we move a surface to a different output, it may end out >in a different overlay plane when we repaint that output. >Moving it to the primary and then back into an overlay plane means that we >generate unecessary damage. Yes, this generate unnecessary damage. >I think we can change weston_surface_damage_below() to just do nothing if >surface->plane is NULL. We can then set surface->plane to NULL for those >surface that points to a plane that is owned by an unplugged output. So you mean that surface-> plane is set to NULL when surface is created and set to NULL also when its output is unplugged, then change weston_surface_damage_below() to just do nothing if surface->plane is NULL. I think this is great to avoid unnecessary damage thanks -Original Message- From: Kristian Høgsberg [mailto:hoegsb...@gmail.com] Sent: Saturday, October 12, 2013 2:05 AM To: Zhang, Xiong Y Cc: wayland-devel@lists.freedesktop.org Subject: Re: [PATCH 2/2] compositor.c: restore surface->plane from destroyed plane to primary plane On Fri, Oct 11, 2013 at 02:43:08PM +0800, Xiong Zhang wrote: > In drm backend, the plane pointer of cursor surface point to > drm_output->cursor_plane. > when this output is removed, drm_output->cursor_plane is destroyed, > but cursor_surface->plane doesn't restored to primary plane. So once > mouse move to this cursor_surface and system will repaint this > cursor_surface, segment fault will occure in > weston_surface_damage_below() function. > > plane should track all the surfaces belonged to it, when plane is > destroyed, restroe surface on destroyed plane to primary plane. There is more work involved in fixing this - it's a somewhat bigger issue. We do need to move surfaces back to the primary plane if they were on a plane owned by the output as your patch does. But we also need to reset surface->output if it points to the destroyed output. Probably by moving the surface back to one of the remaining outputs and calling weston_surface_update_transform(), which will recompute the current output. I'm not quite sure how we'll do that... the cursor surface should be handled in input.c, but all shell surfaces should be moved by shell.c. Maybe they can just listen on the output->destroy_signal and move their surfaces when that signal fires. compositor-drm.c is still responsible for moving all surfaces out of planes being destroyed, and it can do that just by looping through compositor->surface_list. But I don't want to move them i
RE: [PATCH 4/9] output gl repaint in clone mode
The primary output will wait clone output. Until all the finish of clone
output's page flip, primary output can send frame callback to clients and begin
the next page flip.
thanks
-Original Message-
From: wayland-devel-bounces+xiong.y.zhang=intel@lists.freedesktop.org
[mailto:wayland-devel-bounces+xiong.y.zhang=intel@lists.freedesktop.org] On
Behalf Of Axel Davy
Sent: Thursday, September 19, 2013 4:21 PM
To: wayland mailing list
Subject: Re: [PATCH 4/9] output gl repaint in clone mode
How does this work if the primary output frequency is more than the clone
output?
I'm afraid the weston log might become very big after a while when running a
such a configuration
Axel Davy
Le 18/09/2013 05:50, Xiong Zhang a écrit :
> Only repsone to primary output repaint request; Primary output and
> clone output share the same frame buffer, once primary output do page
> flip, clone output will do page flip also. When both primary output
> and clone output finish the page flip, the fb obj can be released.
>
> Signed-off-by: Xiong Zhang
> ---
> src/compositor-drm.c | 101
> +++
> src/compositor.c | 9 +
> 2 files changed, 110 insertions(+)
>
> diff --git a/src/compositor-drm.c b/src/compositor-drm.c index
> 8d16d29..0b9ab45 100644
> --- a/src/compositor-drm.c
> +++ b/src/compositor-drm.c
> @@ -103,6 +103,8 @@ struct drm_compositor {
>
> clockid_t clock;
> struct udev_input input;
> +
> + uint32_t flip_counter;
> };
>
> struct drm_mode {
> @@ -581,6 +583,12 @@ drm_output_repaint(struct weston_output *output_base,
> struct drm_sprite *s;
> struct drm_mode *mode;
> int ret = 0;
> + struct drm_output *clone_output;
> +
> + /*ignore clone output repaint request*/
> + if ((compositor->base.multiscreen_mode == WESTON_MULTISCREEN_CLONE) &&
> + output_base != compositor->base.primary_output)
> + return;
>
> if (!output->next)
> drm_output_render(output, damage); @@ -598,6 +606,22 @@
> drm_output_repaint(struct weston_output *output_base,
> return;
> }
> output_base->set_dpms(output_base, WESTON_DPMS_ON);
> + if (compositor->base.multiscreen_mode ==
> WESTON_MULTISCREEN_CLONE) {
> + wl_list_for_each(clone_output,
> &compositor->base.output_list, base.link) {
> + if (&clone_output->base != output_base) {
> + mode =
> container_of(clone_output->base.current, struct drm_mode, base);
> + ret =
> drmModeSetCrtc(compositor->drm.fd, clone_output->crtc_id,
> +
> output->next->fb_id, 0, 0,
> +
> &clone_output->connector_id, 1,
> +
> &mode->mode_info);
> + if (ret) {
> + weston_log("set mode failed:
> %m\n");
> + return;
> + }
> +
> clone_output->base.set_dpms(&clone_output->base, WESTON_DPMS_ON);
> + }
> + }
> + }
> }
>
> if (drmModePageFlip(compositor->drm.fd, output->crtc_id, @@ -608,6
> +632,21 @@ drm_output_repaint(struct weston_output *output_base,
> }
>
> output->page_flip_pending = 1;
> + compositor->flip_counter++;
> +
> + if (compositor->base.multiscreen_mode == WESTON_MULTISCREEN_CLONE) {
> + wl_list_for_each(clone_output, &compositor->base.output_list,
> base.link) {
> + if (&clone_output->base != output_base) {
> + if (drmModePageFlip(compositor->drm.fd,
> clone_output->crtc_id,
> +
> output->next->fb_id,
> +
> DRM_MODE_PAGE_FLIP_EVENT, clone_output) < 0) {
> + weston_log("queueing pageflip failed:
> %m\n");
> + return;
> + }
> + compositor->flip_counter++;
> + }
> + }
> + }
>
> drm_output_set_cursor(output);
>
> @@ -666,9 +705,19 @@ drm_output_start_repaint_loop(struct weston_output
> *output_base)
> struct drm_compositor *compositor = (struct drm_compositor *)
> output_base->compositor;
> uint32_t fb_id;
> + struct drm_output *clone_output;
>
> struct timespec ts;
>
> + /* ignore clone output repaint request */
> + /* clear clone_output->repaint_
