Re: wayland: how should dispatch the default wayland display queue?

On Tue, 29 Jul 2014 23:32:34 +0200 Eugen Friedrich wrote: > 2014-07-29 20:19 GMT+02:00 Pekka Paalanen : > > > On Tue, 29 Jul 2014 13:00:14 +0200 > > Eugen Friedrich wrote: > > > > > 2014-07-28 12:29 GMT+02:00 Giulio Camuffo : > > > > > > > 2014-07-28 13:19 GMT+03:00 Daniel Stone : > > > > > Hi

[PATCH weston] animation: also change stop value when updating a fade target

If we're fading a view with weston_fade_run() and half way through we want to unfade it we can use weston_fade_update() to set a new alpha target. When the animation finishes, reset_alpha() is called which ensures the alpha value of the view is exactly as requested. Although weston_fade_update() w

Re: RFC : xdg_surface_present() look-and-feel and implementation

On 07/29/2014 03:03 PM, Jason Ekstrand wrote: "Another question for Manuel: Does present() interact with the surface commit? Should it?" Not in a way that I know of. From a compositor point of view, present() (when the user interacts to show) does only change the surface wors

[PATCH 1/1] build: handle special characters when building from git

When building from a git repository, in Makefile.am, the macro creating the "src/git-version.h" file will fail if the last commit subject contains a special character such as ". Escape characters so that the output string is, at worst, empty. Signed-off-by: Manuel Bachmann --- Makefile.am |2

Re: RFC : xdg_surface_present() look-and-feel and implementation

On Tue, Jul 29, 2014 at 3:00 PM, Manuel Bachmann < manuel.bachm...@open.eurogiciel.org> wrote: > Hi Jasper, Jason, > > "Agreed. Especially if you start an application, but it's slow to start, > and you have typed into the current window or have navigated away from it > since, you should get a popu

Re: RFC : xdg_surface_present() look-and-feel and implementation

Hi Jasper, Jason, "Agreed. Especially if you start an application, but it's slow to start, and you have typed into the current window or have navigated away from it since, you should get a popup instead of the window immediately mapped. This is known as "focus stealing prevention"." Good point. I

Re: RFC : xdg_surface_present() look-and-feel and implementation

Hi Bill, "This is not controlled by a count, but by whether a window is already visible or already in the notification state. Clients should be able to send a lot of these in a row. They cannot reliably test if they are invisible and send the request only then, as there is a race condition." Than

Re: wayland: how should dispatch the default wayland display queue?

2014-07-29 20:19 GMT+02:00 Pekka Paalanen : > On Tue, 29 Jul 2014 13:00:14 +0200 > Eugen Friedrich wrote: > > > 2014-07-28 12:29 GMT+02:00 Giulio Camuffo : > > > > > 2014-07-28 13:19 GMT+03:00 Daniel Stone : > > > > Hi Eugen, > > > > > > > > On 27 July 2014 22:16, Eugen Friedrich wrote: > > > >>

Re: RFC : xdg_surface_present() look-and-feel and implementation

On Tue, Jul 29, 2014 at 9:16 PM, Bill Spitzak wrote: > On 07/29/2014 11:40 AM, Manuel Bachmann wrote: > > When creating a xdg_surface, the surface will not be mapped (i.e. shown) >> by desktop-shell anymore. It will only be if xdg_surface_present() has >> been called once. >> > > There seems to

Re: RFC : xdg_surface_present() look-and-feel and implementation

On Tue, Jul 29, 2014 at 12:16 PM, Bill Spitzak wrote: > On 07/29/2014 11:40 AM, Manuel Bachmann wrote: > > When creating a xdg_surface, the surface will not be mapped (i.e. shown) >> by desktop-shell anymore. It will only be if xdg_surface_present() has >> been called once. >> > > There seems to

Re: [PATCH V3] Do not assume 64x64 cursor, added support for other sizes (like in AMD Kaveri, 128x128).

On Tue, Jul 29, 2014 at 3:03 PM, Pekka Paalanen wrote: > On Tue, 29 Jul 2014 13:19:10 +0200 > Daniel Vetter wrote: > >> On Tue, Jul 29, 2014 at 12:55:24AM -0700, Jason Ekstrand wrote: >> > I pushed this one. Let's get a follow-up that lets weston actually use the >> > bigger cursors. It would a

Re: wl_tablet draft v2

I'm more then willing to add something to get the resolution information, it wouldn't be too difficult to implement. I think I'm missing or forgetting something here though; why wouldn't we be able to get an actual value in degrees from the normalized values we're getting from the compositor? The v

Re: RFC : xdg_surface_present() look-and-feel and implementation

On 07/29/2014 11:40 AM, Manuel Bachmann wrote: When creating a xdg_surface, the surface will not be mapped (i.e. shown) by desktop-shell anymore. It will only be if xdg_surface_present() has been called once. There seems to be a design goal in Wayland to prevent clients from making surfaces t

Re: [PATCH V3] Do not assume 64x64 cursor, added support for other sizes (like in AMD Kaveri, 128x128).

On Tue, 29 Jul 2014 13:19:10 +0200 Daniel Vetter wrote: > On Tue, Jul 29, 2014 at 12:55:24AM -0700, Jason Ekstrand wrote: > > I pushed this one. Let's get a follow-up that lets weston actually use the > > bigger cursors. It would also be good to hack together a little client > > that attaches a

[PATCH weston] fullscreen-shell: Fix compiler warnings

--- fullscreen-shell/fullscreen-shell.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fullscreen-shell/fullscreen-shell.c b/fullscreen-shell/fullscreen-shell.c index a8dad8e..25932d4 100644 --- a/fullscreen-shell/fullscreen-shell.c +++ b/fullscreen-shell/fullscreen-shell

RFC : xdg_surface_present() look-and-feel and implementation

Hi folks, (This post follows a discussion which I will link at the end of the mail : *) I have been working on an implementation of xdg_surface_present() for some time now ; here is a proposal with working code. When creating a xdg_surface, the surface will not be mapped (i.e. shown) by desktop-

Re: Keysym event in the text protocol

On 07/28/2014 05:14 PM, Daniel Stone wrote: the fact that our original design for the keyboard interface started off with keysym events _only_ (not on mailing lists, I don't think - was an in-person meeting a couple of years ago) but we couldn't figure out a way to make it work, I'm pretty confi

Re: wayland: how should dispatch the default wayland display queue?

On Tue, 29 Jul 2014 13:00:14 +0200 Eugen Friedrich wrote: > 2014-07-28 12:29 GMT+02:00 Giulio Camuffo : > > > 2014-07-28 13:19 GMT+03:00 Daniel Stone : > > > Hi Eugen, > > > > > > On 27 July 2014 22:16, Eugen Friedrich wrote: > > >> > > >> Hi Daniel, > > >> > > >> thanks, i understood we should

Re: wl_tablet draft v2

On Mon, Jul 28, 2014 at 10:54 AM, Bill Spitzak wrote: > On 07/28/2014 09:41 AM, Jason Gerecke wrote: > >> Normalizing the data is fine, but the resolution data needs to be >> available somewhere as well. The GTK+ API doesn't require anything >> more than the former, but Qt requires that there be s

Re: [PATCH weston] compositor: ignore unmapped sub-surfaces for view_list

On Mon, 28 Jul 2014 23:48:33 -0700 Jason Ekstrand wrote: > Yeah, I think this looks ok. > > Reviewed-by: Jason Ekstrand Pushed, thanks, pq > On Mon, Jul 28, 2014 at 4:06 AM, Pekka Paalanen wrote: > > > From: Pekka Paalanen > > > > It looks like that in the great conversion introducing wes

Re: [PATCH V3] Do not assume 64x64 cursor, added support for other sizes (like in AMD Kaveri, 128x128).

On Tue, Jul 29, 2014 at 12:55:24AM -0700, Jason Ekstrand wrote: > I pushed this one. Let's get a follow-up that lets weston actually use the > bigger cursors. It would also be good to hack together a little client > that attaches a big cursor so we can verify that it's working. I don't > think w

Re: wayland: how should dispatch the default wayland display queue?

2014-07-28 12:29 GMT+02:00 Giulio Camuffo : > 2014-07-28 13:19 GMT+03:00 Daniel Stone : > > Hi Eugen, > > > > On 27 July 2014 22:16, Eugen Friedrich wrote: > >> > >> Hi Daniel, > >> > >> thanks, i understood we should add the wl_display_dispatch_pending call > in > >> the application > >> there i

Re: [PATCH V3] Do not assume 64x64 cursor, added support for other sizes (like in AMD Kaveri, 128x128).

I pushed this one. Let's get a follow-up that lets weston actually use the bigger cursors. It would also be good to hack together a little client that attaches a big cursor so we can verify that it's working. I don't think we need to put it in the repo, I'd just like proof that we're actually ta

Re: [PATCH V3] Do not assume 64x64 cursor, added support for other sizes (like in AMD Kaveri, 128x128).

On 29.07.2014 16:36, Jason Ekstrand wrote: > On Tue, Jul 29, 2014 at 12:17 AM, Michel Dänzer > wrote: > > On 29.07.2014 16:01, Jason Ekstrand wrote: > > Couple thoughs. First, we need to also update > > drm_output_prepare_cursor_view to check against the si

Re: [PATCH V3] Do not assume 64x64 cursor, added support for other sizes (like in AMD Kaveri, 128x128).

On Tue, Jul 29, 2014 at 12:17 AM, Michel Dänzer wrote: > On 29.07.2014 16:01, Jason Ekstrand wrote: > > Couple thoughs. First, we need to also update > > drm_output_prepare_cursor_view to check against the size coming from GBM > > instead of against the hard-coded 64x64 it's currently checking >

Re: [PATCH V3] Do not assume 64x64 cursor, added support for other sizes (like in AMD Kaveri, 128x128).

On 29.07.2014 16:01, Jason Ekstrand wrote: > Couple thoughs. First, we need to also update > drm_output_prepare_cursor_view to check against the size coming from GBM > instead of against the hard-coded 64x64 it's currently checking > against. Without changing that, we are still restricted to 64x6

Re: [PATCH V3] Do not assume 64x64 cursor, added support for other sizes (like in AMD Kaveri, 128x128).

Couple thoughs. First, we need to also update drm_output_prepare_cursor_view to check against the size coming from GBM instead of against the hard-coded 64x64 it's currently checking against. Without changing that, we are still restricted to 64x64 regardless of the GBM checking. Other questions b