Pekka,
I've got just a comple of general comments below.
On Nov 8, 2013 8:46 AM, "Pekka Paalanen" wrote:
>
> Hi all,
>
> this is the v2 of the crop and scale extension, as RFC.
>
> The v1 was in:
> http://lists.freedesktop.org/archives/wayland-devel/2013-April/008927.html
>
> Based on v1, Jonny L
Sending again to the list, as my message apparently didn't get delivered.
From: Rafael Antognolli [rafael.antogno...@intel.com]
Sent: Friday, November 08, 2013 10:52 PM
To: Pekka Paalanen
Cc: wayland-devel@; Kristian Høgsberg; jonny.l...@collabora.co.uk; Dan
Rafael Antognolli wrote:
On Fri, Nov 08, 2013 at 10:59:07AM -0800, Bill Spitzak wrote:
Pekka Paalanen wrote:
Hi all,
this is the v2 of the crop and scale extension, as RFC.
I get the impression that the result of crop+scale is supposed to be exactly
the same as though the client made a sec
On Fri, Nov 08, 2013 at 10:59:07AM -0800, Bill Spitzak wrote:
>
>
> Pekka Paalanen wrote:
> >Hi all,
> >
> >this is the v2 of the crop and scale extension, as RFC.
>
> I get the impression that the result of crop+scale is supposed to be exactly
> the same as though the client made a second buffe
Hello,
I've read carefully your new protocol proposition,
but I think it doesn't meet the requirements to implement
the X Present extension for XWayland.
The problem is that I need to be able to use the frame
request too (I need the frame cal
So, as you've probably already noticed, this version is quite different
from the previous proposal, and a lot of stuff has been "gone missing".
Since I had a big hand in this, so let me explain my motivations here:
I felt that xdg-shell was mostly in bikeshedding mode on the list. It
wasn't really
xdg_shell is a protocol aimed to substitute wl_shell in the long term,
but will not be part of the wayland core protocol. It starts as a
non-stable API, aimed to be used as a development place at first, and
once features are defined as required by several desktop shells, we can
finally make it stab
xdg_shell is a protocol aimed to substitute wl_shell in the long term,
but will not be part of the wayland core protocol. It starts as a
non-stable API, aimed to be used as a development place at first, and
once features are defined as required by several desktop shells, we can
finally make it stab
Hi Bill and Gregory,
So, I talked to Kristian and Jasper on IRC, and we decided to follow a
simpler route, of just adding what is strictly necessary for us right
now. I'm going to send another protocol xml proposal again, on a
following email, but this time without the activate/deactivate part, or
Hi Bill and Gregory,
So, I talked to Kristian and Jasper on IRC, and we decided to follow a
simpler route, of just adding what is strictly necessary for us right
now. I'm going to send another protocol xml proposal again, on a
following email, but this time without the activate/deactivate part, or
On Nov 8, 2013 3:46 AM, "Pekka Paalanen" wrote:
>
> On Thu, 7 Nov 2013 20:13:32 -0600
> Jason Ekstrand wrote:
>
> > Signed-off-by: Jason Ekstrand
> > ---
> > src/compositor-wayland.c | 16
> > src/compositor.c | 1 +
> > 2 files changed, 13 insertions(+), 4 deletions(
Pekka Paalanen wrote:
Hi all,
this is the v2 of the crop and scale extension, as RFC.
I get the impression that the result of crop+scale is supposed to be
exactly the same as though the client made a second buffer of the scale
size, scaled the crop region from the first buffer to this seco
From: Rafael Antognolli
xdg_shell is a protocol aimed to substitute wl_shell in the long term,
but will not be part of the wayland core protocol. It starts as a
non-stable API, aimed to be used as a development place at first, and
once features are defined as required by several desktop shells, w
On Thu, 7 Nov 2013 20:13:32 -0600
Jason Ekstrand wrote:
> Signed-off-by: Jason Ekstrand
> ---
> src/compositor-wayland.c | 16
> src/compositor.c | 1 +
> 2 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/src/compositor-wayland.c b/src/compositor-way
On Thu, 7 Nov 2013 17:46:34 +0200
Oskari Rauta wrote:
> Hi.
>
> I plan to use weston on Raspberry Pi with a touchscreen. I purchased
> a touchscreen that sports a eGalax touch digitizer. It seems not to
> be properly supported by Weston or.. Actually with nearly with any
> software, except tslib
Hi all,
this is the v2 of the crop and scale extension, as RFC.
The v1 was in:
http://lists.freedesktop.org/archives/wayland-devel/2013-April/008927.html
Based on v1, Jonny Lamb has been working on a Weston implementation,
starting from the protocol side, and working towards the renderer
impleme
The field is already set - correctly - in the backend switch_mode.
setting output->current_mode to mode in compositor.c leads to bugs,
since mode can be freed by the shell.
For example, the shell allocates it on the stack for
WL_SHELL_SURFACE_FULLSCREEN_METHOD_DRIVER
---
src/compositor.c | 1 -
1
On Thu, 7 Nov 2013, Ander Conselvan de Oliveira wrote:
We shouldn't have current equals to next in the first place. This can happen
when the repaint loop starts, but that's what the 'if
(output->page_flip_pending)' is for. In any other case, that implies we are
rendering to the front buffer.
Hi,
I have gathered comments and suggestions from colleagues and
wayland-devel reviewers and here is RFC v.2 of our buffer queue +
presentation feedback protocol extension.
Notice the following changes :
---
The field is already set - correctly - in the backend switch_mode.
setting output->current_mode to mode in compositor.c leads to bugs,
since mode can be freed by the shell.
For example, the shell allocates it on the stack for
WL_SHELL_SURFACE_FULLSCREEN_METHOD_DRIVER
Signed-off-by: Axel Davy
---
20 matches
Mail list logo
