Jason,
>From my point of view wl_drm isn't link to Mesa, it is only about
exchange buffers by using a file descriptor and, for example, doesn't
rely on EGL.
I understand that other graphic stacks could have defined their own
way to for zero-copy (and so other protocols).
I don't aim to make gstre
On Thu, 28 Nov 2013 10:24:33 +0100
Benjamin Gaignard wrote:
> Jason,
>
> From my point of view wl_drm isn't link to Mesa, it is only about
> exchange buffers by using a file descriptor and, for example, doesn't
> rely on EGL.
>
> I understand that other graphic stacks could have defined their o
Il giorno mar, 26/11/2013 alle 18.19 +0100, Jonny Lamb ha scritto:
> This is the initial version of the weston implementation of the
> wl_scaler protocol extension for surface cropping and scaling. It is
> based on the extension RFC version 3, written by Pekka Paalanen.
Some slightly different pro
Pekka and I already talked about this one and I think it's the right thing
to do.
--Jason Ekstrand
Reviewed-by: Jason Ekstrand
On Nov 26, 2013 11:20 AM, "Jonny Lamb" wrote:
> From: Pekka Paalanen
>
> This removes the calls to weston_surface_buffer_width/height() from
> input.c, which are the l
This one is also a good idea. Removes code duplication and keeps the
surface size calculations in compositor.c where they belong.
--Jason Ekstrand
Reviewed-by: Jason Ekstrand
On Nov 26, 2013 11:20 AM, "Jonny Lamb" wrote:
> From: Pekka Paalanen
>
> Replace the two functions getting the intended
Il giorno gio, 25/07/2013 alle 13.54 +0100, Daniel Stone ha scritto:
> This and the protocol patch both look good to me; in particular I
> (surprisingly) can't see a problem with the versioning! The one thing
> it's missing though, is integration into clients/window.c where it
> sets up the keyboar
The compositor reads the values out from weston.ini, the weston
compositor passes on the values, the weston-info client prints out the
values, and the values are respected in toytoolkit.
---
clients/weston-info.c| 106 ---
clients/window.c |
In the process wl_keyboard's version has been incremented. Given
clients get the wl_keyboard from wl_seat without a version, wl_seat's
version has also been incremented (wl_seat version 4 implies
wl_keyboard version 4).
---
protocol/wayland.xml | 17 +++--
1 file changed, 15 insertions
This one is a nice cleanup.
--Jason Ekstrand
Kristian,
I would recommend pushing the first three right away as they will help with
removing weston_view.width/height.
--Jason Ekstrand
Reviewed-by: Jason Ekstrand
On Nov 26, 2013 11:20 AM, "Jonny Lamb" wrote:
> From: Pekka Paalanen
>
> Gather th
On Mon, 2013-11-25 at 19:27 -0800, Bill Spitzak wrote:
> Why do you think it should not be possible to fullscreen and/or maximize
> child windows? Our software certainly relies on being able to
> full-screen an X transient window (thought it is triansient because we
> are working around window s
Hi,
On 28 November 2013 10:04, Pekka Paalanen wrote:
> On Thu, 28 Nov 2013 10:24:33 +0100
> Benjamin Gaignard wrote:
>> From my point of view wl_drm isn't link to Mesa, it is only about
>> exchange buffers by using a file descriptor and, for example, doesn't
>> rely on EGL.
>>
>> I understand th
On Tue, Nov 26, 2013 at 06:19:43PM +0100, Jonny Lamb wrote:
> From: Pekka Paalanen
>
> Replace the two functions getting the intended surface dimensions from
> the surface's buffer and buffer transformation parameters by a single
> function that just set the surface size according to all the buff
Hi,
On 26 November 2013 17:19, Jonny Lamb wrote:
> +
> +
> +
> +
In the same vein as my reply to Bill, I'd really like to see these
changed to int. I have little sympathy for clients which perform
layout such that their buffer_scale doesn't allow them to represent
their s
From: XiongZhang
full screen black_surface doesn't have associated wl_buffer, so
black_surface->width and height can't get value through
weston_surface_commit(). then weston_surface_damage(black_surface)
will be wrong in shell_stack_fullscreen(), the result is that we
can't see a full screen vie
14 matches
Mail list logo