On Tue, Sep 10, 2013 at 4:45 PM, Pekka Paalanen wrote:
> On Tue, 10 Sep 2013 16:13:32 +1000
> Campbell Barton wrote:
>
>> On Tue, Sep 10, 2013 at 3:49 PM, Pekka Paalanen
>> wrote:
>> > On Tue, 10 Sep 2013 14:06:55 +1000
>> > Campbell Barton wrote:
>> >
>> >> Hi, I'm interested to get Blender (O
On Tue, 10 Sep 2013 16:13:32 +1000
Campbell Barton wrote:
> On Tue, Sep 10, 2013 at 3:49 PM, Pekka Paalanen
> wrote:
> > On Tue, 10 Sep 2013 14:06:55 +1000
> > Campbell Barton wrote:
> >
> >> Hi, I'm interested to get Blender (OpenGL 3d graphics application)
> >> running with wayland/weston.
>
On Tue, Sep 10, 2013 at 3:49 PM, Pekka Paalanen wrote:
> On Tue, 10 Sep 2013 14:06:55 +1000
> Campbell Barton wrote:
>
>> Hi, I'm interested to get Blender (OpenGL 3d graphics application)
>> running with wayland/weston.
>>
>> However I cant tell if my configuration can even run simple OpenGL
>>
On Tue, 10 Sep 2013 14:06:55 +1000
Campbell Barton wrote:
> Hi, I'm interested to get Blender (OpenGL 3d graphics application)
> running with wayland/weston.
>
> However I cant tell if my configuration can even run simple OpenGL
> applications (the more recent weston for arch-linux 1.2.2 has no
Hi,
You could use pkg-config to check for wayland-egl and egl.
Best Regards,
Alexander Preisinger
2013/9/10 Campbell Barton
> Hi, I'm interested to get Blender (OpenGL 3d graphics application)
> running with wayland/weston.
>
> However I cant tell if my configuration can even run simple Open
Hi, I'm interested to get Blender (OpenGL 3d graphics application)
running with wayland/weston.
However I cant tell if my configuration can even run simple OpenGL
applications (the more recent weston for arch-linux 1.2.2 has no
"weston-gears").
Whats a good way to see if loading opengl/egl applic
Michale & Nobuhiko,
First of all, thank you for the clarification and thank you for sending
this to the list and being willing to work with the FOSS community to try
and make a standard. I'm sorry that this reply is not inline. I think
that would get disorganized and more confusing but I'll try t
- Original Message -
From: "Pekka Paalanen"
To: "nobuhiko_tanibata"
Cc: "Nobuhiko Tanibata" ;
;
Sent: Sunday, September 08, 2013 6:31 PM
Subject: Re: [PATCH weston 0/6] ivi-shell proposal
On Sun, 08 Sep 2013 00:13:55 +0900
nobuhiko_tanibata wrote:
2013-09-06 19:16 に Pekka Paa
Hi,
On 9 September 2013 16:51, Quentin Glidic
wrote:
> @@ -79,8 +79,8 @@
> cd ..
>
>
> -git clone git://people.freedesktop.org/~iksaif/xf86-video-wlshm
> -cd xf86-video-wlshm
> +git clone
> git://people.freedesktop.org/xorg/driver/xf86-video-wayland
> +cd xf86-video-waylan
From: Quentin Glidic
Signed-off-by: Quentin Glidic
---
xserver.html | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xserver.html b/xserver.html
index 899ba50..5c68055 100644
--- a/xserver.html
+++ b/xserver.html
@@ -44,7 +44,7 @@
X.org
-git clone git://anong
Jason Ekstrand wrote:
Chang,
This patch is, unfortunately, incorrect. Yes, we have a side field that
tells us which side the wl_map was allocated for. However, we use one
wl_map to store both client-side and server-side IDs. The side field,
together with the WL_SERVER_ID_START, allow us t
Is this problem specific to the extension or is it a general problem?
Would there not be the same issue if the session compositor wasn't using
the extension but was creating textures from the client surfaces
instead? Presumably if cards A and B don't share a tiling mode then it
won't be possible fo
I think there is a problem with tiling handling in your patch.
Thinks of a session compositor running on an other graphic card for example.
Main compositor: card A
session compositor: card B. buffer is shared between A and B and when
creating it, tiling was disabled (because A and B share no ti
The nested compositor example now responds to damage requests and
tracks them in the pending buffer state. This isn't currently used for
anything and it is immediately discarded when the surface is commited
but it will be used later when the example is converted to use
subsurfaces.
---
clients/nes
The buffer and frame callback state on the surfaces in the nested
compositor example are now double-buffered so that they only take
effect when the commit request is received. This doesn't really make
much difference for the current state that the example has but it will
be useful when more state i
Eventually the nested compositor example will want to be able to cope
with either rendering as it does now with a blit to an intermediate
surface or by attaching the client buffers directly to a subsurface
without copying. This patch moves the code that is specific to the
blitting mechanism into a
Previously the frame callback list was tracked as part of the global
compositor state. This patch moves the list to be part of the surface
state like it is in Weston. The frame callback now iterates the list
of surfaces to flush all of the callbacks. This change will be useful
when the example is c
Chang,
This patch is, unfortunately, incorrect. Yes, we have a side field that
tells us which side the wl_map was allocated for. However, we use one
wl_map to store both client-side and server-side IDs. The side field,
together with the WL_SERVER_ID_START, allow us to keep everything straight
in
Hi,
Here is a series of patches to provide a way for a nested compositor to
present its clients using subsurfaces so that it can attach the client's
buffers directly to the subsurface without having to perform a blit to an
intermediate buffer.
The first patch is for Mesa which adds an extension c
This copies the buffer reference busy count implementation from Weston
to the nested compositor example and adds an internal nested_buffer
struct that we could eventually use to attach data. This will be
useful to adapt the example to use subsurfaces so that we can attach
our compositor-side buffer
This adds an extension called EGL_WL_create_wayland_buffer_from_image
which adds the following single function:
struct wl_buffer *
eglCreateWaylandBufferFromImageWL(EGLDisplay dpy, EGLImageKHR image);
The function creates a wl_buffer which shares its contents with the given
EGLImage. The expected
---
clients/.gitignore | 2 ++
1 file changed, 2 insertions(+)
diff --git a/clients/.gitignore b/clients/.gitignore
index 484437b..aa5e53c 100644
--- a/clients/.gitignore
+++ b/clients/.gitignore
@@ -8,6 +8,8 @@ weston-flower
weston-fullscreen
weston-gears
weston-image
+weston-nested
+weston-n
This adds a -b option to force the nested compositor example to use
the old blit renderer even if the appropriate extensions are
available.
---
clients/nested.c | 12
1 file changed, 12 insertions(+)
diff --git a/clients/nested.c b/clients/nested.c
index 1ea91a1..9d10476 100644
--- a
Chang,
I think what your doing here may technically be more correct, but I don't
like it for two reasons.
First, I'm not 100% sure how the unions are going to pack and we heavily
use the fact that the bottom bit of the value is for flagging it as unused.
If the next and data fields are different
Adds a second renderer implementation to the nested compositor example
that creates a subsurface for each of the client's surfaces. The
client buffers are directly attached to the subsurface using the
EGL_WL_create_wayland_buffer_from_image extension instead of blitting
them in the redraw_handler.
Adds a simple accessor for the wl_subsurface for widgets created with
window_add_subsurface.
---
clients/window.c | 6 ++
clients/window.h | 3 +++
2 files changed, 9 insertions(+)
diff --git a/clients/window.c b/clients/window.c
index 6854745..a837ec8 100644
--- a/clients/window.c
+++ b/clie
Hi all,
let me give some technical background on the extension, and why we have decided
to design the
first approach of the extensions like it is published from Tanibata-san.
In general, we would like to get the feedback on the extensions, to get it
fitting in the FOSS approach,
fulfilling the i
27 matches
Mail list logo
