Yeah, I think this looks ok.
Reviewed-by: Jason Ekstrand ja...@jlekstrand.net
On Mon, Jul 28, 2014 at 4:06 AM, Pekka Paalanen ppaala...@gmail.com wrote:
From: Pekka Paalanen pekka.paala...@collabora.co.uk
It looks like that in the great conversion introducing weston_view, one
conditional
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
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 64x64
On Tue, Jul 29, 2014 at 12:17 AM, Michel Dänzer mic...@daenzer.net 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
On 29.07.2014 16:36, Jason Ekstrand wrote:
On Tue, Jul 29, 2014 at 12:17 AM, Michel Dänzer mic...@daenzer.net
mailto:mic...@daenzer.net 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
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
2014-07-28 12:29 GMT+02:00 Giulio Camuffo giuliocamu...@gmail.com:
2014-07-28 13:19 GMT+03:00 Daniel Stone dan...@fooishbar.org:
Hi Eugen,
On 27 July 2014 22:16, Eugen Friedrich fried...@gmail.com wrote:
Hi Daniel,
thanks, i understood we should add the wl_display_dispatch_pending
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 we
On Mon, 28 Jul 2014 23:48:33 -0700
Jason Ekstrand ja...@jlekstrand.net wrote:
Yeah, I think this looks ok.
Reviewed-by: Jason Ekstrand ja...@jlekstrand.net
Pushed, thanks,
pq
On Mon, Jul 28, 2014 at 4:06 AM, Pekka Paalanen ppaala...@gmail.com wrote:
From: Pekka Paalanen
On Mon, Jul 28, 2014 at 10:54 AM, Bill Spitzak spit...@gmail.com 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
On Tue, 29 Jul 2014 13:00:14 +0200
Eugen Friedrich fried...@gmail.com wrote:
2014-07-28 12:29 GMT+02:00 Giulio Camuffo giuliocamu...@gmail.com:
2014-07-28 13:19 GMT+03:00 Daniel Stone dan...@fooishbar.org:
Hi Eugen,
On 27 July 2014 22:16, Eugen Friedrich fried...@gmail.com wrote:
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
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
---
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
+++
On Tue, 29 Jul 2014 13:19:10 +0200
Daniel Vetter dan...@ffwll.ch 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
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
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
On Tue, Jul 29, 2014 at 3:03 PM, Pekka Paalanen ppaala...@gmail.com wrote:
On Tue, 29 Jul 2014 13:19:10 +0200
Daniel Vetter dan...@ffwll.ch 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
On Tue, Jul 29, 2014 at 9:16 PM, Bill Spitzak spit...@gmail.com 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
On Tue, Jul 29, 2014 at 12:16 PM, Bill Spitzak spit...@gmail.com 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
2014-07-29 20:19 GMT+02:00 Pekka Paalanen ppaala...@gmail.com:
On Tue, 29 Jul 2014 13:00:14 +0200
Eugen Friedrich fried...@gmail.com wrote:
2014-07-28 12:29 GMT+02:00 Giulio Camuffo giuliocamu...@gmail.com:
2014-07-28 13:19 GMT+03:00 Daniel Stone dan...@fooishbar.org:
Hi Eugen,
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.
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
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
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
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()
26 matches
Mail list logo
