xorg.conf sample for xwayland with wlshm DDX.
Hello, I am currently on a machine that has a nvidia graphics but i am running into issues with xwayland with the nouveau DDX .. i had started a help thread to which i am still waiting for a response from the wayland team. Mean while i was trying to use the wlshm DDX which is generic and uses software rendering as per the xwayland documents. the guide also says that to let X load the wlshm module.. wlshm requires an xorg.conf containing 'Driver "wlshm"' i am not sure how to put an entry like this in the $WLD/share/X11/xorg.conf.d/10-evdev.conf conf file.. can anyone please suggest me how a working .conf file looks like so that the wlshm module is loaded by X? And is the conf file above that i mentioned correct place to make any such modification? I guess once the correct env vars are exported .. the forked X from weston should use the conf files from the $WLD path and not from the /usr/share location? Please correct if i am wrong. Thanks n Regards, Ashish ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC xserver] xwayland: HACK: Don't roundtrip in DRI2 authentication mechanism
On Tue, Jan 22, 2013 at 08:19:12PM -0200, Tiago Vignatti wrote:
> Signed-off-by: Tiago Vignatti
> ---
> hw/xfree86/dri2/dri2.c | 60
> ++--
> hw/xfree86/dri2/dri2.h |8 -
> hw/xfree86/dri2/dri2ext.c | 10 +-
> hw/xfree86/xwayland/xwayland-drm.c | 22 +
> 4 files changed, 89 insertions(+), 11 deletions(-)
>
> diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
> index b08618a..a529d5e 100644
> --- a/hw/xfree86/dri2/dri2.c
> +++ b/hw/xfree86/dri2/dri2.c
> @@ -99,6 +99,7 @@ typedef struct _DRI2Screen {
> const char *deviceName;
> int fd;
> unsigned int lastSequence;
> +ClientPtr blockedAuthClient;
Nothing prevents multiple client from trying to authenticate at the
same time. We can't just support one blocked auth client at a time.
If another client initiates and auth sequence in the middle of another
clients auth sequence, you just overwrite blockedAuthClient in
DRI2Authenticate. This leaves the first client stuck in ignored mode.
> DRI2CreateBufferProcPtr CreateBuffer;
> DRI2DestroyBufferProcPtr DestroyBuffer;
> @@ -1122,13 +1123,65 @@ DRI2AuthMagic (ScreenPtr pScreen, uint32_t magic)
> return (*ds->LegacyAuthMagic) (ds->fd, magic);
> }
>
> +/*
> + * Return TRUE if it has a blocked client waiting authentication or
> + * FALSE otherwise.
> + */
> Bool
> -DRI2Authenticate(ScreenPtr pScreen, uint32_t magic)
> +DRI2HasBlockedAuthClient(ScreenPtr pScreen)
> {
> DRI2ScreenPtr ds = DRI2GetScreen(pScreen);
>
> -if (ds == NULL || (*ds->AuthMagic) (pScreen, magic))
> -return FALSE;
> +if (ds == NULL)
> + return FALSE;
> +
> +if (!ds->blockedAuthClient)
> + return FALSE;
> +else
> + return TRUE;
> +}
> +
> +/*
> + * Attend blocked client that was asking for authentication. In other words,
> + * it will process the DRI2Authenticate request again.
> + *
> + * This has to be called only if the client has been in fact authenticated by
> + * DRM, meaning the token magic was accepted.
> + */
> +void
> +DRI2AttendBlockedAuthClient(ScreenPtr pScreen)
> +{
> +DRI2ScreenPtr ds = DRI2GetScreen(pScreen);
> +
> +if (ds == NULL || !DRI2HasBlockedAuthClient(pScreen))
> + return;
> +
> +AttendClient(ds->blockedAuthClient);
> +}
> +
> +Bool
> +DRI2Authenticate(ScreenPtr pScreen, uint32_t magic, ClientPtr client)
> +{
> +DRI2ScreenPtr ds = DRI2GetScreen(pScreen);
> +
> +fprintf(stderr, "%s (blocked client: %p)\n", __func__,
> ds->blockedAuthClient);
> +if (ds == NULL)
> + return FALSE;
> +
> +if (DRI2HasBlockedAuthClient(pScreen) &&
> + ds->blockedAuthClient == client) {
> + ds->blockedAuthClient = NULL;
> + return TRUE;
> +}
> +
> +/* XXX: this assumes magic will never fail */
But it *can* fail. If the X server or wayland server is vt-switched
away, it can't authenticate new drm clients. Instead, we can use a
specific return code to indicate "please block the client". Currently
the return code convention for ds->AuthMagic is a little inconsistent.
In the non-xwayland case, the DDX returns the return value of
drmAuthMagic, which is 0 for success and -errno in case of error. In
the xwayland case, we return 0 for success or an X error code
(BadAlloc etc). We could use -EAGAIN as a AuthMagic return value to
indicate that the authentication is in progress.
But I think we may be better off just adding a new
DRI2AuthMagic3ProcPtr, that lets dri2.c pass the client to the auth
function. That way the auth function can just call IgnoreClient, and
dri2 can check client->ignoreCount > 0 to see whether or not it should
send a reply. The other point here is that when xwayland gets the
authenticate reply, it needs to call back into dri2.c to send the
reply and unblock the client and for that it needs to get the client
ptr in the first place.
Finally, we can't change DRI2Authenticate, since it's xserver ABI.
That doesn't mean we can't add a new function for ProcDRI2Authenticate
to call. This function will essentially look like DRI2Authenticate,
except it takes a ClientPtr as well and passes that to ds->AuthMagic3.
> +if ((*ds->AuthMagic) (pScreen, magic)) {
> + ResetCurrentRequest(client);
We don't need ResetCurrentRequest() after all. There's no need to
reset the request, we've processed it and we're just waiting to send
the reply. In other words all we need is
if (ds == NULL || (*ds->AuthMagic3) (pScreen, pClient, magic))
return FALSE;
> + client->sequence--;
> + IgnoreClient(client);
> + ds->blockedAuthClient = client;
> + return FALSE;
> +}
>
> return TRUE;
> }
> @@ -1198,6 +1251,7 @@ DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info)
> ds->screen = pScreen;
> ds->fd = info->fd;
> ds->deviceName = info->deviceName;
> +ds->blockedAuthClient = NULL;
> dri2_major = 1;
>
> ds->CreateBuffer = info->CreateBuffer;
RE: ask for help about multi-display in wayland
Jack, The last Wayland/Weston version we (EMGD on TNC) supported was 1.0.1 and Clone/Extended mode is not possible on Weston without modifying the source. Thanks, BoonWooi -Original Message- From: wayland-devel-bounces+boon.wooi.tay=intel@lists.freedesktop.org [mailto:wayland-devel-bounces+boon.wooi.tay=intel@lists.freedesktop.org] On Behalf Of Xu, Jack Sent: Monday, January 28, 2013 8:50 AM To: Pekka Paalanen Cc: wayland-devel@lists.freedesktop.org Subject: RE: ask for help about multi-display in wayland We'll find time to update it and test the bug. In fact, we tried to update to date 0821 and 0918, both had errors. Thanks, Jack -Original Message- From: wayland-devel-bounces+jack.xu=intel@lists.freedesktop.org [mailto:wayland-devel-bounces+jack.xu=intel@lists.freedesktop.org] On Behalf Of Pekka Paalanen Sent: Friday, January 25, 2013 5:36 PM To: Xu, Jack Cc: wayland-devel@lists.freedesktop.org Subject: Re: ask for help about multi-display in wayland On Fri, 25 Jan 2013 08:58:39 + "Xu, Jack" wrote: > Hardware is Intel Atom E660, output is LDVS(flat panel monitor) and > SDVO(SAMSUNG SynMaster 730BA) Kernel is 3.4.7, we use emgd (version > 2667) Ok, I'm not familiar with EMGD. > Wayland library is libwayland-emgd.so.1.5.15.3226, Weston version > 0.94.90 (EMGD has their own fork of libwayland?) Sorry, I meant, can you reproduce this issue with the master branch git versions of libwayland and weston, or are they somehow incompatible with the rest of the system you have? That's a pretty old Weston, can't you at least use the 1.0.4 releases of both? 1.0 series could get bug fixes still. Thanks, pq > -Original Message- > From: wayland-devel-bounces+jack.xu=intel@lists.freedesktop.org > [mailto:wayland-devel-bounces+jack.xu=intel@lists.freedesktop.org] > On Behalf Of Pekka Paalanen > Sent: Friday, January 25, 2013 4:48 PM > To: Xu, Jack > Cc: wayland-devel@lists.freedesktop.org > Subject: Re: ask for help about multi-display in wayland > > On Fri, 25 Jan 2013 08:24:35 + > "Xu, Jack" wrote: > > > Here is the weston log, hope it can help. > > Hi, > > I see PowerVR SGX as the renderer, what hardware is this? Please, explain the > hardware, monitors and their connections, what kernel and user space drivers > you use, etc. > > (Also, a pre-0.95 Weston.) > > > - With one mouse plugged in, two mouse cursor on each output and > > move in the same way and position - seems like clone mode, but > > actually works in extended mode. We are using Weston, backend is > > drm-backend. > > My wild guess at this point would be a kernel driver bug, since I have never > heard of such mouse cursor problem on PCs. > > I wonder if hardware cursors are being used... > > Can you check with libwayland and Weston master revision? > > > Thanks, > pq > > > -Original Message- > > From: wayland-devel-bounces+jack.xu=intel@lists.freedesktop.org > > [mailto:wayland-devel-bounces+jack.xu=intel@lists.freedesktop.or > > g] > > On Behalf Of Pekka Paalanen > > Sent: Monday, January 21, 2013 6:58 PM > > To: Xu, Jack > > Cc: Xie, Qi; wayland-devel@lists.freedesktop.org > > Subject: Re: ask for help about multi-display in wayland > > > > On Mon, 21 Jan 2013 01:12:18 + > > "Xu, Jack" wrote: > > > > > Hi, > > > We are trying to enable two applications display on two screens > > > separately. Currently we can drag the application another screen. > > > But the "mouse" always appears on both screens. And we don't know how to > > > display the application on selected screen by default when it's launched. > > > The questions are: > > > > > > 1. How the application choose which screen to display in > > > multi-display mode? > > > > So far the shell protocol has output definitions only in the set_maximized > > and set_fullscreen requests. You have to extend the protocol for other > > cases, as there is no way yet. > > > > The shell interfaces are far from complete at this time. > > > > What application is this? Is it a generic application, or some desktop > > environment component? > > > > > Is there any configuration file for it ? (We don't want to modify > > > and recompile the applications.) > > > > No. You will need to modify and recompile anyway, if not the application, > > then the toolkit, to take advantage of any features that might allow > > choosing the initial output. > > > > > 2. How to configure the mouse display in multi-display mode? > > > > > > We want only one mouse all the time. > > > > Are you saying that you see several mouse cursors at the same time, one on > > each output, while having only one pointer device? If so, that is a Weston > > bug. Do they both move, or does always only one of them move? > > What Weston backend are you using? Are you even using Weston? > > > > > > Thanks, > > pq > > ___ > > wayland-devel mailing list > > wayland-
Questions and thoughts about input method protocol
Hi, With the comment on the recent patches for the input method protocol, it seems that we are finally on the way to support cursor following. However I still have some questions about the protocol (and it's limitation). 1, Is there any plan to support xwayland? I believe it is important to support using input method in x clients running on xwayland. IMHO, the input method can still use xim or it's own protocol to get key event from and send input result (as well as preedit etc.) to the client running on xwayland with no problem. However, I cannot see a perfect solution to make cursor following works using the proposed way to locate the input overlay surface. For application using xim, maybe it is possible to let xwayland handle the events and then forward them to the text-model. However, first of all, this cannot work for x client talking with input method using a private protocol and it will be a HGE regression if we force all x clients to use the broken xim (application frozen, wrong support of cursor following and preedit etc.). Moreover, since xim support is so different in different applications, the input method sometimes have to do some hack on xim, which will not very likely be something we want to add in xwayland. (Maybe adding some interface to interact with xwayland to set cursor position on certain x window surfaces?) 2, Is it possible for the input method to know anything about the client? Some famous (Chinese) input methods (on Mac and Windows) support the so-called context awareness, in another word, the input method will use some information of the client to determine the candidate words list (and its order). This may not be that useful for Latin based languages (although it may also be good if you want to provide spelling hints) but if your are facing a language with 3000-5000 frequently used characters and frequently used words 10-100 times of this number depending on your context, this shouldn't be ridicules at all. Currently, although I don't know any input method on linux support context awareness, it is possible to do this under X since all the necessary information is accessible to the input method. These include all general information the window system and a plugin running in the client's process can know, including (most important and useful) window titles (with other WM related properties like icon names, application names etc.), pid's (plus host's for X) and window id's etc. The pid's and window id's are also very useful for getting more information from the underlying system (/proc for example) about the client (e.g. command line arguments) and can also be used to provide per program or per window input state for some programs (Fcitx support both.) Right now I don't think there is any way to get these information from the input method protocol. It will be a big regression (not as big as not supporting cursor following in x clients though) if this cannot be supported in wayland. NOTE: The "context type" added in the recent patches may also be helpful on this but they are different. It is indeed helpful for input method to know the user is typing in a url/search bar instead of a normal text entry but the stuff you may want to search may be very different on amazon and arxiv. 3, Is it possible to let the user move the keyboard panel while keeping it off from the cursor position when possible? Maybe it is already possible and I just don't fully understand the input_panel interface but anyway I guess this should be supported, either by the compositor or make it possible to let input methods support it. 4, For running different component of the input method in different processes. >From the updated doc string of input_panel, you are saying it is only possible for one client to bind to the interface. Well, IMHO, I don't really think this is necessary. It will be indeed a problem if two input methods both want to handle key events on the same seat. This can be easily avoided by only allowing one client binding to the input_method interface. The input method can just quit/disable wl support/retry later/do what ever it want if that bind fails. However, for the input_panel interface, I don't really think this is necessary. For conflict with another input method, this should be already handled by the input_method interface. Also this can increase the flexibility of the input method by allowing virtual keyboard and input overlay window drawing by two different process (not only just in a single process although different with the one binding to the input_method interface which get key events). 5, For the proposed input_panel_surface::cursor_position event. I guess it will be better to change it to a cursor_rect event which also includes the size of the cursor. No? 6, Some random stuff of the current interface. There seems to be a password context type. I think normally a password field will not have input context or is that for using virtual keyboard in passwor
Re: [PATCH 1/2] matrix: track transform type
On Mon, Jan 28, 2013 at 03:41:09PM -0800, Bill Spitzak wrote:
> This is very very useful, however the proposed set is not really correct:
>
> >>+enum weston_matrix_transform_type {
> >>+ WESTON_MATRIX_TRANSFORM_TRANSLATE = (1 << 0),
> >>+ WESTON_MATRIX_TRANSFORM_SCALE = (1 << 1),
> >>+ WESTON_MATRIX_TRANSFORM_ROTATE = (1 << 2),
> >>+ WESTON_MATRIX_TRANSFORM_OTHER = (1 << 3),
> >>+};
>
> These either have misleading names or are not really useful
> (translate will probably be true in all cases, things that can do
> rotate can usually do skew, does scale include reflections, etc).
This makes no sense, the flags describe exactly what kind of
transformation the matrix represents to the level of detail that we
need to know. If you want to understand how the flags are used, I
suggest you read the patch.
> Useful things to know about the current transform (a,b,c,d,x,y are
> the 2x3 affine matrix):
>
> - Are x and y integers?
>
> - If it is a 90 degree rotation or reflection (meaning either b and
> c are zero, or a and d are zero).
>
> - No scaling: abs(ad-bc) == 1.
>
> - No perspective (third column of 3x3 matrix is 0, 0, 1).
They are only "useful things" if we actaully rely on that property.
As it is, we don't have a use for this information so there's no point
in tracking it.
Kristian
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] protocol: Add a request and event to identify the visible area for a surface
On Mon, Jan 28, 2013 at 03:07:02PM -0800, Bill Spitzak wrote: > It would be nice if there was a clear way to find out *all* the > visible area. Right now it looks like I have to try a really large > rectangle and just hope I have managed to cover all of the current > output. It seems to me that getting rid of the rectangle and > returning the result as though it was infinite in size would be > simpler and cover what I would imagine a toolkit will actually do. > Is there a reason for the rectangle? > > Another idea is to allow it to return a clip that is *larger* than > the rectangle. This may be useful if the visible area is > discontiguous: only the areas that intersect the rectangle are > returned, and if none do then the "closest" one is returned. May be > useful if a surface spans more than one output. It's done this way so that the compositor can provide the biggest possible visible area for the rectangle of interest. If your main surface is rotated, the edges of the screen are at an angle with the window edges. How do you define "the biggest visible area" in that case? What if panels or other desktop elements form a non-rectangular region - we would have to return a very pessimistic "biggest rectangle", while a probe function like this will allow the compositor to intersect the proposed position against its internal geometry. > This should replace all the proposed automatic-positioning of child > surfaces in the shell api. That was never going to work except for > trivial popup modal questions. Real overlays want to draw graphics > in both the overlay and main window pointing at each other, and > popup in positions that use complex rules (like a submenu on the > opposite side of a parent, or the parent menu shifted over so that a > potential submenu can appear) that cannot be conveyed from client to > server without the server becoming a program interpreter. I don't know what you're talking about, there's no automatic child surface positioning in shell and there never has been. Please familiarize yourself with the protocol and code before posting. Kristian ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 1/2] matrix: track transform type
This is very very useful, however the proposed set is not really correct:
+enum weston_matrix_transform_type {
+ WESTON_MATRIX_TRANSFORM_TRANSLATE = (1 << 0),
+ WESTON_MATRIX_TRANSFORM_SCALE = (1 << 1),
+ WESTON_MATRIX_TRANSFORM_ROTATE = (1 << 2),
+ WESTON_MATRIX_TRANSFORM_OTHER = (1 << 3),
+};
These either have misleading names or are not really useful (translate
will probably be true in all cases, things that can do rotate can
usually do skew, does scale include reflections, etc).
Useful things to know about the current transform (a,b,c,d,x,y are the
2x3 affine matrix):
- Are x and y integers?
- If it is a 90 degree rotation or reflection (meaning either b and c
are zero, or a and d are zero).
- No scaling: abs(ad-bc) == 1.
- No perspective (third column of 3x3 matrix is 0, 0, 1).
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] protocol: Add a request and event to identify the visible area for a surface
It would be nice if there was a clear way to find out *all* the visible area. Right now it looks like I have to try a really large rectangle and just hope I have managed to cover all of the current output. It seems to me that getting rid of the rectangle and returning the result as though it was infinite in size would be simpler and cover what I would imagine a toolkit will actually do. Is there a reason for the rectangle? Another idea is to allow it to return a clip that is *larger* than the rectangle. This may be useful if the visible area is discontiguous: only the areas that intersect the rectangle are returned, and if none do then the "closest" one is returned. May be useful if a surface spans more than one output. This should replace all the proposed automatic-positioning of child surfaces in the shell api. That was never going to work except for trivial popup modal questions. Real overlays want to draw graphics in both the overlay and main window pointing at each other, and popup in positions that use complex rules (like a submenu on the opposite side of a parent, or the parent menu shifted over so that a potential submenu can appear) that cannot be conveyed from client to server without the server becoming a program interpreter. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 1/2] matrix: track transform type
On Mon, Jan 28, 2013 at 10:40:28PM +0300, Vasily Khoruzhick wrote:
> Introduce several matrix transform types and track type for matrix.
> Could be usefull for activating some fastpath that depends on some
> transform type.
Look good, both committed. We could simplify the logic in
weston_surface_update_transform() a bit now, by just always
multiplying the transformation_list matrices and then setting enabled
if surface->tranform.matrix.type > TRANSLATE. And of course
weston_matrix_invert() could use the matrix.type now to fast-path
translation matrices, and then we could just move that call to the
generic weston_surface_update_transform() as well.
Kristian
> Signed-off-by: Vasily Khoruzhick
> ---
> shared/matrix.c | 23 ---
> shared/matrix.h | 10 ++
> src/compositor.c | 3 +++
> src/shell.c | 17 +
> 4 files changed, 38 insertions(+), 15 deletions(-)
>
> diff --git a/shared/matrix.c b/shared/matrix.c
> index 11b5b95..3ff4089 100644
> --- a/shared/matrix.c
> +++ b/shared/matrix.c
> @@ -21,6 +21,7 @@
> * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> */
>
> +#include
> #include
> #include
> #include
> @@ -46,7 +47,8 @@ WL_EXPORT void
> weston_matrix_init(struct weston_matrix *matrix)
> {
> static const struct weston_matrix identity = {
> - { 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1 }
> + .d = { 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1 },
> + .type = 0,
> };
>
> memcpy(matrix, &identity, sizeof identity);
> @@ -69,6 +71,7 @@ weston_matrix_multiply(struct weston_matrix *m, const
> struct weston_matrix *n)
> for (j = 0; j < 4; j++)
> tmp.d[i] += row[j] * column[j * 4];
> }
> + tmp.type = m->type | n->type;
> memcpy(m, &tmp, sizeof tmp);
> }
>
> @@ -76,7 +79,8 @@ WL_EXPORT void
> weston_matrix_translate(struct weston_matrix *matrix, float x, float y,
> float z)
> {
> struct weston_matrix translate = {
> - { 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, x, y, z, 1 }
> + .d = { 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, x, y, z, 1 },
> + .type = WESTON_MATRIX_TRANSFORM_TRANSLATE,
> };
>
> weston_matrix_multiply(matrix, &translate);
> @@ -86,12 +90,24 @@ WL_EXPORT void
> weston_matrix_scale(struct weston_matrix *matrix, float x, float y,float z)
> {
> struct weston_matrix scale = {
> - { x, 0, 0, 0, 0, y, 0, 0, 0, 0, z, 0, 0, 0, 0, 1 }
> + .d = { x, 0, 0, 0, 0, y, 0, 0, 0, 0, z, 0, 0, 0, 0, 1 },
> + .type = WESTON_MATRIX_TRANSFORM_SCALE,
> };
>
> weston_matrix_multiply(matrix, &scale);
> }
>
> +WL_EXPORT void
> +weston_matrix_rotate_xy(struct weston_matrix *matrix, float cos, float sin)
> +{
> + struct weston_matrix translate = {
> + .d = { cos, sin, 0, 0, -sin, cos, 0, 0, 0, 0, 1, 0, 0, 0, 0,
> 1 },
> + .type = WESTON_MATRIX_TRANSFORM_ROTATE,
> + };
> +
> + weston_matrix_multiply(matrix, &translate);
> +}
> +
> /* v <- m * v */
> WL_EXPORT void
> weston_matrix_transform(struct weston_matrix *matrix, struct weston_vector
> *v)
> @@ -249,6 +265,7 @@ weston_matrix_invert(struct weston_matrix *inverse,
> weston_matrix_init(inverse);
> for (c = 0; c < 4; ++c)
> inverse_transform(LU, perm, &inverse->d[c * 4]);
> + inverse->type = matrix->type;
>
> return 0;
> }
> diff --git a/shared/matrix.h b/shared/matrix.h
> index bacb7bf..47354f6 100644
> --- a/shared/matrix.h
> +++ b/shared/matrix.h
> @@ -24,8 +24,16 @@
> #ifndef WESTON_MATRIX_H
> #define WESTON_MATRIX_H
>
> +enum weston_matrix_transform_type {
> + WESTON_MATRIX_TRANSFORM_TRANSLATE = (1 << 0),
> + WESTON_MATRIX_TRANSFORM_SCALE = (1 << 1),
> + WESTON_MATRIX_TRANSFORM_ROTATE = (1 << 2),
> + WESTON_MATRIX_TRANSFORM_OTHER = (1 << 3),
> +};
> +
> struct weston_matrix {
> float d[16];
> + unsigned int type;
> };
>
> struct weston_vector {
> @@ -42,6 +50,8 @@ void
> weston_matrix_translate(struct weston_matrix *matrix,
> float x, float y, float z);
> void
> +weston_matrix_rotate_xy(struct weston_matrix *matrix, float cos, float sin);
> +void
> weston_matrix_transform(struct weston_matrix *matrix, struct weston_vector
> *v);
>
> int
> diff --git a/src/compositor.c b/src/compositor.c
> index a2e95c9..5ac43f2 100644
> --- a/src/compositor.c
> +++ b/src/compositor.c
> @@ -539,6 +539,7 @@ weston_surface_update_transform_enable(struct
> weston_surface *surface)
> surface->transform.enabled = 1;
>
> /* Otherwise identity matrix, but with x and y translation. */
> + surface->transform.position.matrix.type =
> WESTON_MATRIX_TRANSFORM_TRANSLATE;
> surface->transform.position.matrix.d[12] = surface->geometry.x;
> surface->transform.position.matri
[PATCH 2/2] pixman-renderer: handle surface transform matrix properly
Signed-off-by: Vasily Khoruzhick
---
src/pixman-renderer.c | 107 ++
1 file changed, 90 insertions(+), 17 deletions(-)
diff --git a/src/pixman-renderer.c b/src/pixman-renderer.c
index 8d95197..908824c 100644
--- a/src/pixman-renderer.c
+++ b/src/pixman-renderer.c
@@ -104,8 +104,72 @@ pixman_renderer_read_pixels(struct weston_output *output,
return 0;
}
+#define D2F(v) pixman_double_to_fixed((double)v)
+
+static void
+repaint_region_complex(struct weston_surface *es, struct weston_output *output,
+ pixman_region32_t *region)
+{
+ struct pixman_renderer *pr =
+ (struct pixman_renderer *) output->compositor->renderer;
+ struct pixman_surface_state *ps = get_surface_state(es);
+ struct pixman_output_state *po = get_output_state(output);
+ int nrects, i;
+ pixman_box32_t *rects;
+
+ /* Pixman supports only 2D transform matrix, but Weston uses 3D,
+* so we're omitting Z coordinate here
+*/
+ pixman_transform_t transform = {{
+ { D2F(es->transform.matrix.d[0]),
+ D2F(es->transform.matrix.d[4]),
+ D2F(es->transform.matrix.d[12]),
+ },
+ { D2F(es->transform.matrix.d[1]),
+ D2F(es->transform.matrix.d[5]),
+ D2F(es->transform.matrix.d[13]),
+ },
+ { D2F(es->transform.matrix.d[3]),
+ D2F(es->transform.matrix.d[7]),
+ D2F(es->transform.matrix.d[15]),
+ }
+ }};
+
+ pixman_transform_invert(&transform, &transform);
+
+ pixman_image_set_transform(ps->image, &transform);
+ pixman_image_set_filter(ps->image, PIXMAN_FILTER_BILINEAR, NULL, 0);
+
+ rects = pixman_region32_rectangles(region, &nrects);
+ for (i = 0; i < nrects; i++) {
+ pixman_image_composite32(PIXMAN_OP_OVER,
+ ps->image, /* src */
+ NULL /* mask */,
+ po->shadow_image, /* dest */
+ rects[i].x1, rects[i].y1, /* src_x, src_y */
+ 0, 0, /* mask_x, mask_y */
+ rects[i].x1, rects[i].y1, /* dst_x, dst_y */
+ rects[i].x2 - rects[i].x1, /* width */
+ rects[i].y2 - rects[i].y1 /* height */
+ );
+
+ if (!pr->repaint_debug)
+ continue;
+
+ pixman_image_composite32(PIXMAN_OP_OVER,
+ pr->debug_color, /* src */
+ NULL /* mask */,
+ po->shadow_image, /* dest */
+ 0, 0, /* src_x, src_y */
+ 0, 0, /* mask_x, mask_y */
+ rects[i].x1, rects[i].y1, /* dest_x, dest_y */
+ rects[i].x2 - rects[i].x1, /* width */
+ rects[i].y2 - rects[i].y1 /* height */);
+ }
+}
+
static void
-repaint_region(struct weston_surface *es, struct weston_output *output,
+repaint_region_simple(struct weston_surface *es, struct weston_output *output,
pixman_region32_t *region, pixman_region32_t *surf_region,
pixman_op_t pixman_op)
{
@@ -126,15 +190,18 @@ repaint_region(struct weston_surface *es, struct
weston_output *output,
pixman_region32_init(&final_region);
pixman_region32_copy(&final_region, surf_region);
- if (es->transform.enabled) {
+ pixman_image_set_filter(ps->image, PIXMAN_FILTER_NEAREST, NULL, 0);
+ pixman_image_set_transform(ps->image, NULL);
+
+ if (!es->transform.enabled) {
+ pixman_region32_translate(&final_region, es->geometry.x,
es->geometry.y);
+ } else {
weston_surface_to_global_float(es, 0, 0, &surface_x,
&surface_y);
pixman_region32_translate(&final_region, (int)surface_x,
(int)surface_y);
- } else
- pixman_region32_translate(&final_region, es->geometry.x,
es->geometry.y);
+ }
/* That's what we need to paint */
pixman_region32_intersect(&final_region, &final_region, region);
-
rects = pixman_region32_rectangles(&final_region, &nrects);
for (i = 0; i < nrects; i++) {
@@ -192,20 +259,26 @@ draw_surface(struct weston_surface *es, struct
weston_output *output,
goto out;
}
- /* blended region is whole surface minus opaque region: */
- pixman_region32_init_rect(&surface_blend, 0, 0,
- es->geometry.width, es->geometry.height);
- pixman_region32_subtract(&surface_blend, &surface_blend, &es->opaque);
-
- if (pixman_region32_not_empty(&es->opaque)) {
- repaint_region(es, output, &repaint, &es->opaque,
PIXMAN_OP_SRC);
- }
-
- if (pixman_region32_not_empty(&surface_blend)) {
- repaint_region(es
[PATCH 1/2] matrix: track transform type
Introduce several matrix transform types and track type for matrix.
Could be usefull for activating some fastpath that depends on some
transform type.
Signed-off-by: Vasily Khoruzhick
---
shared/matrix.c | 23 ---
shared/matrix.h | 10 ++
src/compositor.c | 3 +++
src/shell.c | 17 +
4 files changed, 38 insertions(+), 15 deletions(-)
diff --git a/shared/matrix.c b/shared/matrix.c
index 11b5b95..3ff4089 100644
--- a/shared/matrix.c
+++ b/shared/matrix.c
@@ -21,6 +21,7 @@
* CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
+#include
#include
#include
#include
@@ -46,7 +47,8 @@ WL_EXPORT void
weston_matrix_init(struct weston_matrix *matrix)
{
static const struct weston_matrix identity = {
- { 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1 }
+ .d = { 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1 },
+ .type = 0,
};
memcpy(matrix, &identity, sizeof identity);
@@ -69,6 +71,7 @@ weston_matrix_multiply(struct weston_matrix *m, const struct
weston_matrix *n)
for (j = 0; j < 4; j++)
tmp.d[i] += row[j] * column[j * 4];
}
+ tmp.type = m->type | n->type;
memcpy(m, &tmp, sizeof tmp);
}
@@ -76,7 +79,8 @@ WL_EXPORT void
weston_matrix_translate(struct weston_matrix *matrix, float x, float y, float
z)
{
struct weston_matrix translate = {
- { 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, x, y, z, 1 }
+ .d = { 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, x, y, z, 1 },
+ .type = WESTON_MATRIX_TRANSFORM_TRANSLATE,
};
weston_matrix_multiply(matrix, &translate);
@@ -86,12 +90,24 @@ WL_EXPORT void
weston_matrix_scale(struct weston_matrix *matrix, float x, float y,float z)
{
struct weston_matrix scale = {
- { x, 0, 0, 0, 0, y, 0, 0, 0, 0, z, 0, 0, 0, 0, 1 }
+ .d = { x, 0, 0, 0, 0, y, 0, 0, 0, 0, z, 0, 0, 0, 0, 1 },
+ .type = WESTON_MATRIX_TRANSFORM_SCALE,
};
weston_matrix_multiply(matrix, &scale);
}
+WL_EXPORT void
+weston_matrix_rotate_xy(struct weston_matrix *matrix, float cos, float sin)
+{
+ struct weston_matrix translate = {
+ .d = { cos, sin, 0, 0, -sin, cos, 0, 0, 0, 0, 1, 0, 0, 0, 0,
1 },
+ .type = WESTON_MATRIX_TRANSFORM_ROTATE,
+ };
+
+ weston_matrix_multiply(matrix, &translate);
+}
+
/* v <- m * v */
WL_EXPORT void
weston_matrix_transform(struct weston_matrix *matrix, struct weston_vector *v)
@@ -249,6 +265,7 @@ weston_matrix_invert(struct weston_matrix *inverse,
weston_matrix_init(inverse);
for (c = 0; c < 4; ++c)
inverse_transform(LU, perm, &inverse->d[c * 4]);
+ inverse->type = matrix->type;
return 0;
}
diff --git a/shared/matrix.h b/shared/matrix.h
index bacb7bf..47354f6 100644
--- a/shared/matrix.h
+++ b/shared/matrix.h
@@ -24,8 +24,16 @@
#ifndef WESTON_MATRIX_H
#define WESTON_MATRIX_H
+enum weston_matrix_transform_type {
+ WESTON_MATRIX_TRANSFORM_TRANSLATE = (1 << 0),
+ WESTON_MATRIX_TRANSFORM_SCALE = (1 << 1),
+ WESTON_MATRIX_TRANSFORM_ROTATE = (1 << 2),
+ WESTON_MATRIX_TRANSFORM_OTHER = (1 << 3),
+};
+
struct weston_matrix {
float d[16];
+ unsigned int type;
};
struct weston_vector {
@@ -42,6 +50,8 @@ void
weston_matrix_translate(struct weston_matrix *matrix,
float x, float y, float z);
void
+weston_matrix_rotate_xy(struct weston_matrix *matrix, float cos, float sin);
+void
weston_matrix_transform(struct weston_matrix *matrix, struct weston_vector *v);
int
diff --git a/src/compositor.c b/src/compositor.c
index a2e95c9..5ac43f2 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -539,6 +539,7 @@ weston_surface_update_transform_enable(struct
weston_surface *surface)
surface->transform.enabled = 1;
/* Otherwise identity matrix, but with x and y translation. */
+ surface->transform.position.matrix.type =
WESTON_MATRIX_TRANSFORM_TRANSLATE;
surface->transform.position.matrix.d[12] = surface->geometry.x;
surface->transform.position.matrix.d[13] = surface->geometry.y;
@@ -2754,12 +2755,14 @@ weston_output_compute_transform(struct weston_output
*output)
int flip;
weston_matrix_init(&transform);
+ transform.type = WESTON_MATRIX_TRANSFORM_ROTATE;
switch(output->transform) {
case WL_OUTPUT_TRANSFORM_FLIPPED:
case WL_OUTPUT_TRANSFORM_FLIPPED_90:
case WL_OUTPUT_TRANSFORM_FLIPPED_180:
case WL_OUTPUT_TRANSFORM_FLIPPED_270:
+ transform.type |= WESTON_MATRIX_TRANSFORM_OTHER;
flip = -1;
break;
default:
diff --git a/src/shell.c b/src/shell.c
index dcbabf3..a99786b 100644
--- a/src/shell.c
+++ b/src/shell.c
Re: Wayland GTK+ support is in Ubuntu, Fedora, and Gentoo
2013/1/28 : > I updated http://www.chaosreigns.com/wayland/state/ "Qt5 support is complete except for client side decorations (CSD)." qtwayland master branch has now complete CSD support. It also supports the new wayland-cursor API. For terminals you might want to add this: https://github.com/hawaii-desktop/terminal Runs on Qt 5. Another one is https://github.com/jorgen/yat which is written in C++ and QML. > I converted the section on distro support to a table: > http://www.chaosreigns.com/wayland/state/#distributions [cut] > The other big thing is Qt5, which was released on 2012-12-19. I suspect > there are no distros that include official packages at all yet, let alone > including wayland support. And I think there are still very few > applications which have been ported (from older Qt releases, which is > required). Could you please add Maui to the distributions list (http://www.maui-project.org)? It's far from a major distribution but Wayland is (one of) the main points :) Also uses Qt 5 for its desktop. -- Out of the box experience http://www.maui-project.org/ ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 06/11] shell: Organize workspace containers by output
On Mon, Jan 28, 2013 at 10:33 AM, Pekka Paalanen wrote:
> Hi Jonas,
>
> this raised a couple of thoughts, inline below.
>
>
> On Sat, 26 Jan 2013 15:33:36 +0100
> Jonas Ådahl wrote:
>
>> Instead of having one global workspace container, have one container per
>> output. This means that every output will have its own set of workspaces
>> with its own workspace state.
>>
>> New surfaces are added to the current workspace on the container of the
>> output the surface was positioned at.
>>
>> The workspace manager interface is currently limited to only represent
>> the container of the first output. All events and requests are handleded
>> as if there was only one container.
>>
>> The keyboard bindings for changing workspaces are updated to change the
>> state of the container of the output where the pointer is on. If no
>> pointer exists, the workspace changing bindings are no-ops.
>>
>> Signed-off-by: Jonas Ådahl
>> ---
>> src/shell.c | 367
>> +++
>> 1 file changed, 266 insertions(+), 101 deletions(-)
>>
>> diff --git a/src/shell.c b/src/shell.c
>> index c5bb9c4..45e70f0 100644
>> --- a/src/shell.c
>> +++ b/src/shell.c
>> @@ -36,6 +36,7 @@
>> #include "compositor.h"
>> #include "desktop-shell-server-protocol.h"
>> #include "workspaces-server-protocol.h"
>> +#include "../shared/hash.h"
>> #include "../shared/config-parser.h"
>>
>> #define DEFAULT_NUM_WORKSPACES 1
>> @@ -62,6 +63,8 @@ struct workspace_container {
>> unsigned int current;
>> unsigned int num;
>>
>> + struct weston_output *output;
>> +
>> struct weston_animation animation;
>> struct wl_list anim_sticky_list;
>> int anim_dir;
>> @@ -120,7 +123,7 @@ struct desktop_shell {
>> struct wl_listener lock_surface_listener;
>>
>> struct {
>> - struct workspace_container container;
>> + struct hash_table *table;
>> unsigned int default_num;
>>
>> struct wl_list client_list;
>> @@ -234,9 +237,6 @@ static void
>> activate(struct desktop_shell *shell, struct weston_surface *es,
>>struct weston_seat *seat);
>>
>> -static struct workspace *
>> -get_current_workspace(struct desktop_shell *shell);
>> -
>> static struct shell_surface *
>> get_shell_surface(struct weston_surface *surface);
>>
>> @@ -576,50 +576,98 @@ workspace_restack_surface(struct workspace *ws, struct
>> shell_surface *shsurf)
>> }
>>
>> static struct workspace *
>> -get_workspace(struct desktop_shell *shell, unsigned int index)
>> +workspace_container_get(struct workspace_container *container,
>> + unsigned int index)
>> {
>> - struct workspace **pws = shell->workspaces.container.workspaces.data;
>> - assert(index < shell->workspaces.container.num);
>> - pws += index;
>> - return *pws;
>> + struct workspace **pws = container->workspaces.data;
>> + return *(pws + index);
>> }
>>
>> static struct workspace *
>> -get_current_workspace(struct desktop_shell *shell)
>> +workspace_container_get_current(struct workspace_container *container)
>> {
>> - return get_workspace(shell, shell->workspaces.container.current);
>> + return workspace_container_get(container, container->current);
>> }
>>
>> -static void
>> -activate_workspace(struct desktop_shell *shell, unsigned int index)
>> +static struct workspace_container *
>> +find_first_workspace_container(struct desktop_shell *shell)
>> {
>> - struct workspace *ws;
>> + struct weston_output *output;
>> + struct workspace_container *container;
>>
>> - ws = get_workspace(shell, index);
>> - wl_list_insert(&shell->panel_layer.link, &ws->layer.link);
>> + output = container_of(shell->compositor->output_list.next,
>> + struct weston_output, link);
>
> I'd like to have an assert added with all code that assumes we have at
> least one output. There will be a time when we want to be able to deal
> with a temporary zero outputs cases, and having asserts around will make
> finding all places that need fixing easier. Or something to the same
> effect.
Sounds like a good precaution, until we handle the case properly.
>
> Hmm, or maybe just grepping for output_list with a container_of is
> enough.
>
>> + container = hash_table_lookup(shell->workspaces.table, output->id);
>> +
>> + return container;
>> +}
>> +
>> +static struct workspace_container *
>> +find_focused_workspace_container(struct desktop_shell *shell,
>> + struct wl_seat *seat)
>> +{
>> + int x, y;
>> + struct weston_output *output;
>> +
>> + if (seat->pointer == NULL)
>> + return NULL;
>> +
>> + x = wl_fixed_to_int(seat->pointer->x);
>> + y = wl_fixed_to_int(seat->pointer->y);
>> + wl_list_for_each(output, &shell->compositor->output_list, link)
>> + if (pixman_region32_contains_point(&output->region,
>> +
Re: [PATCH] protocol: Add a request and event to identify the visible area for a surface
On Mon, Jan 28, 2013 at 05:18:34PM +, Rob Bradford wrote: > From: Rob Bradford > > Add a probe_area request to the wl_shell_surface interface along with a > visible_area event to communicate the result of the probe. > > The intention of this request and event is to allow the client to try and > refine the placement of popup windows that would otherwise be unusable. This looks good. The separate result object makes it pretty simple and allows for sending off a bunch of queries and get a bunch of replies using only one ruondtrip. I think we should document the self-destructing nature of the results object though. I know that wl_callback (only other object with this behavior) isn't documented like that, but we should do that for new interfaces. Kristian > --- > protocol/wayland.xml | 36 > 1 file changed, 36 insertions(+) > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > index 0ce68ef..a12cbbc 100644 > --- a/protocol/wayland.xml > +++ b/protocol/wayland.xml > @@ -729,6 +729,42 @@ > to the client owning the popup surface. > > > + > + > + > +Asks the compositor what the visible area for a surface would be if > it > +was positioned with the proposed rectangle relative to the provided > +surface. The visible_area event will be fired with the area that the > +compositor would show. The client can then use this information to > +reposition the surface as appropriate for its needs. The intention is > +for this request to be used by clients looking to find the ideal > +location for a popup window whilst still respecting the borders of > the > +output. > + > + > + > + > + > + > + > + > + > + > + > + > +This event is fired in response to the probe_area request on the > +object returned for that request. It returns the visible area that > +the surface would occupy when taking into consideration the > +output's edges. If the width or height is zero this indicates that > the > +window would not be visible at all in that dimension. In that case > the > +x and y values represent the distance to the edge of the viewable > +area. > + > + > + > + > + > + > > > > -- > 1.8.0.2 > > ___ > 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 GTK+ support is in Ubuntu, Fedora, and Gentoo
This leaves Arch conspicuously missing it, but when I opened a bug requesting it, they increased the severity and assigned two people, which seems promising. I think this is pretty cool, because it marks the first native wayland support included in major distros. For clients that don't use the wayland protocol directly. Ubuntu: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/954352 (I find this Ubuntu saga entertaining.) Fedora: http://comments.gmane.org/gmane.linux.redhat.fedora.devel/173778 Gentoo: http://packages.gentoo.org/package/x11-libs/gtk+ Arch: https://bugs.archlinux.org/task/33577 I updated http://www.chaosreigns.com/wayland/state/ I converted the section on distro support to a table: http://www.chaosreigns.com/wayland/state/#distributions My page of what gtk applications work with wayland is pretty out of date, so Martin Minarik started a wiki page to list updated info: http://www.chaosreigns.com/wiki/Wayland_what_works You're encouraged to add to / update it. The thing I'm looking forward to most is the xwm-client stuff Tiago Vignatti is working on. Because when I last tried using weston as my primary UI, I was getting some occasional xwayland crashes, which I think I was told were tough to debug before xwm is split out to a separate client. But I just noticed this split might not be deemed worthwhile, and I guess I need to check for those crashes again. After that, I'm looking forward to xwayland (x.org modifications) getting committed upstream so it can also be included in distros. The other big thing is Qt5, which was released on 2012-12-19. I suspect there are no distros that include official packages at all yet, let alone including wayland support. And I think there are still very few applications which have been ported (from older Qt releases, which is required). There are three workarounds for Ubuntu specific bugs related to using the Wayland backend of GTK+ near the top of https://launchpad.net/~darxus/+archive/wayland-gtk-quantal -- "The most elementary and valuable statement in science, the beginning of wisdom is: 'I do not know'." - Data, ST:TNG 2x2 Where Silence Has Lease http://www.ChaosReigns.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] terminal: Handle the window close event.
On Mon, Jan 28, 2013 at 01:11:06AM -0800, Dima Ryazanov wrote:
> There may be multiple windows open, so destroy the terminal instead of
> exiting.
Thanks, good fix, committed. Just a stylistic nitpick: we treat
commit subjects as headers wrt to punctuation (eg like a newspaper
headline) so they don't end in '.'.
Kristian
> Signed-off-by: Dima Ryazanov
> ---
> clients/terminal.c |9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/clients/terminal.c b/clients/terminal.c
> index 25acc81..664df5d 100644
> --- a/clients/terminal.c
> +++ b/clients/terminal.c
> @@ -2069,6 +2069,14 @@ fullscreen_handler(struct window *window, void *data)
> window_set_fullscreen(window, !window_is_fullscreen(terminal->window));
> }
>
> +static void
> +close_handler(struct window *window, void *data)
> +{
> + struct terminal *terminal = data;
> +
> + terminal_destroy(terminal);
> +}
> +
> static int
> handle_bound_key(struct terminal *terminal,
>struct input *input, uint32_t sym, uint32_t time)
> @@ -2541,6 +2549,7 @@ terminal_create(struct display *display)
> window_set_keyboard_focus_handler(terminal->window,
> keyboard_focus_handler);
> window_set_fullscreen_handler(terminal->window, fullscreen_handler);
> + window_set_close_handler(terminal->window, close_handler);
>
> widget_set_redraw_handler(terminal->widget, redraw_handler);
> widget_set_resize_handler(terminal->widget, resize_handler);
> --
> 1.7.10.4
>
> ___
> 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
[PATCH 2/2] window: Use probe area to position popup window so it always visible
From: Rob Bradford
With this change the popup menu will not go beyond the borders of the output.
---
clients/window.c | 58
1 file changed, 50 insertions(+), 8 deletions(-)
diff --git a/clients/window.c b/clients/window.c
index 2baf4d9..28d0bd6 100644
--- a/clients/window.c
+++ b/clients/window.c
@@ -359,6 +359,8 @@ struct menu {
int count;
int release_count;
menu_func_t func;
+ int width;
+ int height;
};
struct tooltip {
@@ -3747,6 +3749,46 @@ menu_redraw_handler(struct widget *widget, void *data)
cairo_destroy(cr);
}
+static void
+probe_result_visible_area (void *data,
+ struct wl_probe_result *wl_probe_result,
+ int32_t x, int32_t y,
+ int32_t w, int32_t h)
+{
+ struct menu *menu = data;
+ struct window *window = menu->window;
+ struct input *input = menu->input;
+
+ /* Clipped to the left */
+ if (x != window->x)
+ window->x = x;
+
+ /* Clipped to the top */
+ if (y != window->y)
+ window->y = y;
+
+ /* Clipped to the right */
+ if (x == window->x && w < menu->width)
+ window->x = window->x - (menu->width - w);
+
+ /* Clipped to the bottom */
+ if (y == window->y && h < menu->height)
+ window->y = y - (menu->height - h);
+
+ input_ungrab(input);
+ wl_shell_surface_set_popup(window->shell_surface, input->seat,
+ display_get_serial(window->display),
+ window->parent->surface,
+ window->x, window->y, 0);
+
+ input_grab(input, menu->widget, 0);
+ window_schedule_resize(window, menu->width, menu->height);
+}
+
+struct wl_probe_result_listener probe_result_listener = {
+probe_result_visible_area,
+};
+
void
window_show_menu(struct display *display,
struct input *input, uint32_t time, struct window *parent,
@@ -3756,6 +3798,7 @@ window_show_menu(struct display *display,
struct window *window;
struct menu *menu;
const int32_t margin = 3;
+ struct wl_probe_result *result;
menu = malloc(sizeof *menu);
if (!menu)
@@ -3776,24 +3819,23 @@ window_show_menu(struct display *display,
menu->time = time;
menu->func = func;
menu->input = input;
+ menu->width = 200;
+ menu->height = menu->count * 20 + margin * 2;
window->type = TYPE_MENU;
window->x = x;
window->y = y;
- input_ungrab(input);
- wl_shell_surface_set_popup(window->shell_surface, input->seat,
- display_get_serial(window->display),
- window->parent->surface,
- window->x, window->y, 0);
-
widget_set_redraw_handler(menu->widget, menu_redraw_handler);
widget_set_enter_handler(menu->widget, menu_enter_handler);
widget_set_leave_handler(menu->widget, menu_leave_handler);
widget_set_motion_handler(menu->widget, menu_motion_handler);
widget_set_button_handler(menu->widget, menu_button_handler);
- input_grab(input, menu->widget, 0);
- window_schedule_resize(window, 200, count * 20 + margin * 2);
+ result = wl_shell_surface_probe_area(window->parent->shell_surface,
+window->x, window->y,
+menu->width, menu->height);
+
+ wl_probe_result_add_listener(result, &probe_result_listener, menu);
}
void
--
1.8.0.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 1/2] shell: Implement the probe_area request on the shell surface
From: Rob Bradford
---
src/shell.c | 81 -
1 file changed, 80 insertions(+), 1 deletion(-)
diff --git a/src/shell.c b/src/shell.c
index aa1c7c1..58b5892 100644
--- a/src/shell.c
+++ b/src/shell.c
@@ -1914,6 +1914,84 @@ shell_surface_set_popup(struct wl_client *client,
shsurf->popup.y = y;
}
+
+static void
+shell_surface_probe_area(struct wl_client *client,
+struct wl_resource *resource,
+int x,
+int y,
+int w,
+int h,
+uint32_t result_id)
+{
+ struct wl_resource result;
+ struct shell_surface *shsurf = resource->data;
+ struct {
+ struct {
+ int x;
+ int y;
+ } tl, br;
+ } orig, new;
+
+ int output_w, output_h;
+
+ int new_x, new_y, new_w, new_h;
+
+ output_w = shsurf->surface->output->current->width;
+ output_h = shsurf->surface->output->current->height;
+
+ /* orig and new are in global co-ordinates */
+ orig.tl.x = shsurf->surface->geometry.x + x;
+ orig.tl.y = shsurf->surface->geometry.y + y;
+ orig.br.x = orig.tl.x + w;
+ orig.br.y = orig.tl.y + h;
+
+ new = orig;
+
+ /* Clamp the top left so it is inside */
+ if (orig.tl.x < 0)
+ new.tl.x = 0;
+ if (orig.tl.y < 0)
+ new.tl.y = 0;
+ if (orig.tl.x > output_w)
+ new.tl.x = output_w;
+ if (orig.tl.y > output_h)
+ new.tl.y = output_h;
+
+ /* Clamp the bottom right so it is inside */
+ if (orig.br.x < 0)
+ new.br.x = 0;
+ if (orig.br.y < 0)
+ new.br.y = 0;
+ if (orig.br.x > output_w)
+ new.br.x = output_w;
+ if (orig.br.y > output_h)
+ new.br.y = output_h;
+
+ /* Translate back into relative co-ordinates */
+ new_x = new.tl.x - shsurf->surface->geometry.x;
+ new_y = new.tl.y - shsurf->surface->geometry.y;
+ new_w = new.br.x - new.tl.x;
+ new_h = new.br.y - new.tl.y;
+
+ memset(&result, 0, sizeof(result));
+
+ result.object.interface = &wl_probe_result_interface;
+ result.object.id = result_id;
+ result.destroy = NULL;
+ result.client = client;
+ result.data = NULL;
+
+ wl_client_add_resource(client, &result);
+
+ wl_resource_post_event(&result,
+ WL_PROBE_RESULT_VISIBLE_AREA,
+ new_x, new_y,
+ new_w, new_h);
+
+ wl_resource_destroy(&result);
+}
+
static const struct wl_shell_surface_interface shell_surface_implementation = {
shell_surface_pong,
shell_surface_move,
@@ -1924,7 +2002,8 @@ static const struct wl_shell_surface_interface
shell_surface_implementation = {
shell_surface_set_popup,
shell_surface_set_maximized,
shell_surface_set_title,
- shell_surface_set_class
+ shell_surface_set_class,
+ shell_surface_probe_area
};
static void
--
1.8.0.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] protocol: Add a request and event to identify the visible area for a surface
From: Rob Bradford Add a probe_area request to the wl_shell_surface interface along with a visible_area event to communicate the result of the probe. The intention of this request and event is to allow the client to try and refine the placement of popup windows that would otherwise be unusable. --- protocol/wayland.xml | 36 1 file changed, 36 insertions(+) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 0ce68ef..a12cbbc 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -729,6 +729,42 @@ to the client owning the popup surface. + + + +Asks the compositor what the visible area for a surface would be if it +was positioned with the proposed rectangle relative to the provided +surface. The visible_area event will be fired with the area that the +compositor would show. The client can then use this information to +reposition the surface as appropriate for its needs. The intention is +for this request to be used by clients looking to find the ideal +location for a popup window whilst still respecting the borders of the +output. + + + + + + + + + + + + +This event is fired in response to the probe_area request on the +object returned for that request. It returns the visible area that +the surface would occupy when taking into consideration the +output's edges. If the width or height is zero this indicates that the +window would not be visible at all in that dimension. In that case the +x and y values represent the distance to the edge of the viewable +area. + + + + + + -- 1.8.0.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 06/11] shell: Organize workspace containers by output
Hi Jonas,
this raised a couple of thoughts, inline below.
On Sat, 26 Jan 2013 15:33:36 +0100
Jonas Ådahl wrote:
> Instead of having one global workspace container, have one container per
> output. This means that every output will have its own set of workspaces
> with its own workspace state.
>
> New surfaces are added to the current workspace on the container of the
> output the surface was positioned at.
>
> The workspace manager interface is currently limited to only represent
> the container of the first output. All events and requests are handleded
> as if there was only one container.
>
> The keyboard bindings for changing workspaces are updated to change the
> state of the container of the output where the pointer is on. If no
> pointer exists, the workspace changing bindings are no-ops.
>
> Signed-off-by: Jonas Ådahl
> ---
> src/shell.c | 367
> +++
> 1 file changed, 266 insertions(+), 101 deletions(-)
>
> diff --git a/src/shell.c b/src/shell.c
> index c5bb9c4..45e70f0 100644
> --- a/src/shell.c
> +++ b/src/shell.c
> @@ -36,6 +36,7 @@
> #include "compositor.h"
> #include "desktop-shell-server-protocol.h"
> #include "workspaces-server-protocol.h"
> +#include "../shared/hash.h"
> #include "../shared/config-parser.h"
>
> #define DEFAULT_NUM_WORKSPACES 1
> @@ -62,6 +63,8 @@ struct workspace_container {
> unsigned int current;
> unsigned int num;
>
> + struct weston_output *output;
> +
> struct weston_animation animation;
> struct wl_list anim_sticky_list;
> int anim_dir;
> @@ -120,7 +123,7 @@ struct desktop_shell {
> struct wl_listener lock_surface_listener;
>
> struct {
> - struct workspace_container container;
> + struct hash_table *table;
> unsigned int default_num;
>
> struct wl_list client_list;
> @@ -234,9 +237,6 @@ static void
> activate(struct desktop_shell *shell, struct weston_surface *es,
>struct weston_seat *seat);
>
> -static struct workspace *
> -get_current_workspace(struct desktop_shell *shell);
> -
> static struct shell_surface *
> get_shell_surface(struct weston_surface *surface);
>
> @@ -576,50 +576,98 @@ workspace_restack_surface(struct workspace *ws, struct
> shell_surface *shsurf)
> }
>
> static struct workspace *
> -get_workspace(struct desktop_shell *shell, unsigned int index)
> +workspace_container_get(struct workspace_container *container,
> + unsigned int index)
> {
> - struct workspace **pws = shell->workspaces.container.workspaces.data;
> - assert(index < shell->workspaces.container.num);
> - pws += index;
> - return *pws;
> + struct workspace **pws = container->workspaces.data;
> + return *(pws + index);
> }
>
> static struct workspace *
> -get_current_workspace(struct desktop_shell *shell)
> +workspace_container_get_current(struct workspace_container *container)
> {
> - return get_workspace(shell, shell->workspaces.container.current);
> + return workspace_container_get(container, container->current);
> }
>
> -static void
> -activate_workspace(struct desktop_shell *shell, unsigned int index)
> +static struct workspace_container *
> +find_first_workspace_container(struct desktop_shell *shell)
> {
> - struct workspace *ws;
> + struct weston_output *output;
> + struct workspace_container *container;
>
> - ws = get_workspace(shell, index);
> - wl_list_insert(&shell->panel_layer.link, &ws->layer.link);
> + output = container_of(shell->compositor->output_list.next,
> + struct weston_output, link);
I'd like to have an assert added with all code that assumes we have at
least one output. There will be a time when we want to be able to deal
with a temporary zero outputs cases, and having asserts around will make
finding all places that need fixing easier. Or something to the same
effect.
Hmm, or maybe just grepping for output_list with a container_of is
enough.
> + container = hash_table_lookup(shell->workspaces.table, output->id);
> +
> + return container;
> +}
> +
> +static struct workspace_container *
> +find_focused_workspace_container(struct desktop_shell *shell,
> + struct wl_seat *seat)
> +{
> + int x, y;
> + struct weston_output *output;
> +
> + if (seat->pointer == NULL)
> + return NULL;
> +
> + x = wl_fixed_to_int(seat->pointer->x);
> + y = wl_fixed_to_int(seat->pointer->y);
> + wl_list_for_each(output, &shell->compositor->output_list, link)
> + if (pixman_region32_contains_point(&output->region,
> +x, y, NULL))
> + return hash_table_lookup(shell->workspaces.table,
> + output->id);
>
> - shell->workspaces.container.current = index;
> + return NULL;
> +}
> +
[PATCH weston] terminal: Handle the window close event.
There may be multiple windows open, so destroy the terminal instead of exiting.
Signed-off-by: Dima Ryazanov
---
clients/terminal.c |9 +
1 file changed, 9 insertions(+)
diff --git a/clients/terminal.c b/clients/terminal.c
index 25acc81..664df5d 100644
--- a/clients/terminal.c
+++ b/clients/terminal.c
@@ -2069,6 +2069,14 @@ fullscreen_handler(struct window *window, void *data)
window_set_fullscreen(window, !window_is_fullscreen(terminal->window));
}
+static void
+close_handler(struct window *window, void *data)
+{
+ struct terminal *terminal = data;
+
+ terminal_destroy(terminal);
+}
+
static int
handle_bound_key(struct terminal *terminal,
struct input *input, uint32_t sym, uint32_t time)
@@ -2541,6 +2549,7 @@ terminal_create(struct display *display)
window_set_keyboard_focus_handler(terminal->window,
keyboard_focus_handler);
window_set_fullscreen_handler(terminal->window, fullscreen_handler);
+ window_set_close_handler(terminal->window, close_handler);
widget_set_redraw_handler(terminal->widget, redraw_handler);
widget_set_resize_handler(terminal->widget, resize_handler);
--
1.7.10.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
