This commit results in garbage output for r600g when building with
OpenGL (not ES) as enabled by my patches:
https://github.com/Zoxc/weston/commits/gl-rebase. (--enable-opengl on
configure)
It works on i965 so I was wondering how well tested this is on Gallium drivers?
On Fri, Mar 7, 2014 at 7:05
On Sun, Apr 27, 2014 at 12:30 PM, Wolfgang Draxinger
wrote:
> On Sun, 27 Apr 2014 12:11:39 +0200
> John Kåre Alsaker
> wrote:
>
>> I implemented support for ABGR16161616 framebuffers in mesa/wl_drm.
>> My patch has bit-rotted a bit now, but it gives you an idea about
I implemented support for ABGR16161616 framebuffers in mesa/wl_drm.
My patch has bit-rotted a bit now, but it gives you an idea about what to do:
https://github.com/Zoxc/mesa/commit/73f39f1366287bab02c993cb3537980e89b3cdca
My motivation for this was to have clients render with linear gamma.
One t
The rationale here is, that this line would create an instance of
gl_renderer_interface in every compilation unit that included
gl-renderer.h. This is not necessary, and it can actually be harmful by
masking the real exported gl_renderer_interface symbol, if you added
another compilation unit to gl
upport? Do you have new features lined up that rely on this?
>
> I always found that debugging generated shaders was fairly difficult and
> annoying, and while the old code isn't great, I find it's a lot simple to
> understand.
>
>
> On Tue, Apr 8, 2014 at 3:26 PM, John
---
src/gl-renderer.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/gl-renderer.h b/src/gl-renderer.h
index db42f6c..6cd5f54 100644
--- a/src/gl-renderer.h
+++ b/src/gl-renderer.h
@@ -101,4 +101,3 @@ struct gl_renderer_interface {
void (*print_egl_error_state)(void);
};
-struct
On Thu, Apr 3, 2014 at 11:12 AM, Niels Ole Salscheider
wrote:
> Zoxc did not like the way I handle the "uncorrected" case because it is a bit
> ugly and breaks blending in the uncorrected area. Instead of using a mask to
> opt-out from color management, he suggests to just attach the output color
On Wed, Mar 12, 2014 at 7:32 PM, Bill Spitzak wrote:
> Isn't Wayland differentiating between the "selection" and the clipboard?
It is not doing that at the moment. Only explicit clipboard actions
are supposed to be used.
>
> The selection is changed when the user selects an object.The clipboard i
0001-protocol-replace-the-usage-of-selection-with-clipboa.patch
Description: Binary data
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
On Wed, Jun 19, 2013 at 4:50 AM, John Kåre Alsaker
wrote:
> I don't see a way to have a group of surfaces in sync with a video
> surface operating independently on top work in the current
> implementation without locking. It seems that only work for a single
> surface and not a
Here is my current color management protocol for Wayland clients. The
basic idea is that the compositor sends two color spaces to the
clients. A compositing color space which the compositor prefers since
it would require no conversions. A full-screen color space which the
compositor can be able to
I don't see a way to have a group of surfaces in sync with a video
surface operating independently on top work in the current
implementation without locking. It seems that only work for a single
surface and not a group of surfaces. The current implementation then
also requires the ability to map a
On Thu, Jun 13, 2013 at 2:42 PM, Pekka Paalanen wrote:
> Libwayland does not synchronize, it only protects the queues for the
> very short moment each time they are modified. It does not cause one
> application component to stall and wait for another component to wake
> up, realize there is somet
On Thu, Jun 13, 2013 at 1:04 PM, Pekka Paalanen wrote:
> On Thu, 13 Jun 2013 12:35:36 +0200
> John Kåre Alsaker wrote:
>
> > I propose the we should change the commit behavior to having commit
> > on the toplevel wl_surface
> > commit itself and all it's subs
I propose the we should change the commit behavior to having commit on the
toplevel wl_surface
commit itself and all it's subsurfaces atomically. Commiting on subsurfaces
should be a no-op.
That is to allow eglSwapBuffers to be used in subsurfaces, should you
manage to get it to be non-blocking.
Th
You should execute the ioctl in fbdev_set_screen_info.
I don't see the codepath which results in cmap.transp being not set in the
test for it.
You don't initialize cmap.red so the test for it gives an undefined result.
Don't define macros in the middle of code with a literal that's only used
onc
May I suggest
https://github.com/Zoxc/weston/commit/062f5ca5dc5809c027f693f2d642bc24f568e348instead?
On Wed, Jun 5, 2013 at 11:21 AM, Ander Conselvan de Oliveira <
conselv...@gmail.com> wrote:
> From: Ander Conselvan de Oliveira
>
> When attaching a new buffer, the EGL images created for the pr
On Wed, Jun 5, 2013 at 3:11 AM, Bill Spitzak wrote:
> John Kåre Alsaker wrote:
>
> This is still a problem without any high-DPI stuff. You could just as
>> easily have an input device with a resolution 3 times higher than the
>> display.
>>
>
> I am worried t
On Tue, Jun 4, 2013 at 10:24 PM, Bill Spitzak wrote:
> John Kåre Alsaker wrote:
>
> And I'm worried that high-resolution pointing devices will be
>> ignored by clients that immediately round to the nearest buffer pixel.
>>
>> Presumably they wouldn't
On Mon, Jun 3, 2013 at 10:21 PM, Bill Spitzak wrote:
> + Clients get input in exact pixels (no rounding errors).
>> + Clients doesn't have to transform input events in order to match the
>> sizes used by buffers.
>
> You said "pels" don't match buffer pixels. Therefore a transformation is
> nee
On Mon, Jun 3, 2013 at 2:22 PM, Pekka Paalanen wrote:
> On Tue, 28 May 2013 19:27:35 +0200
> John Kåre Alsaker wrote:
>
> > My proposal is simply to let the compositor tell the client how much
> larger
> > it wants the client to render content. The client can then tel
My proposal is simply to let the compositor tell the client how much larger
it wants the client to render content. The client can then tell the
compositor how much larger it made content in the window. Armed with this
information the compositor can size the window accordingly.
Note that this impli
On Tue, May 28, 2013 at 3:40 PM, Pekka Paalanen wrote:
> On Tue, 28 May 2013 15:10:53 +0200
> John Kåre Alsaker wrote:
>
> > On Thu, May 23, 2013 at 2:57 AM, Kristian Høgsberg >wrote:
> >
> > > I read through the latest wayland protocol patches and the discus
On Thu, May 23, 2013 at 2:57 AM, Kristian Høgsberg wrote:
> I read through the latest wayland protocol patches and the discussion
> around them and didn't seen anything I didn't like. I think the
> approach here is good and agree with the consensus. This patch series
> looks great too and I like
I see Alexander Larsson added a scaled flag to the output modes. Presumably
this is because he scales down the width and height of the mode by the
scaling factor of the output.
This probably shouldn't be done. The scaling factor only works for the
current mode. It isn't representative for the othe
On Tue, May 21, 2013 at 5:35 PM, Bill Spitzak wrote:
>However both proposals have this problem if pre-compositing is not done,
and most practical shells I can figure out can't do pre-compositing because
that requires another buffer for every parent, so maybe this is not a big
deal.
Pre-compositin
On Tue, May 14, 2013 at 9:46 PM, Bill Spitzak wrote:
>
>
> John Kåre Alsaker wrote:
>
>>
>> I expect a compositor to render deviations of the desired scaling
>> factor without scaling windows. The range when this is allowed is
>> reported to cl
On Tue, May 14, 2013 at 9:16 PM, Bill Spitzak wrote:
> John Kåre Alsaker wrote:
>
> The size of a window should always be in pixels at the protocol level.
>>
>
> Note that this is in direct contradiction to the proposed scaler api. In
> it the size of the window is in t
On Tue, May 14, 2013 at 5:49 PM, Alexander Larsson wrote:
> On tis, 2013-05-14 at 17:00 +0200, John Kåre Alsaker wrote:
>
>
> > Obviously they are defined as such right now, since there is
> > no scaling.
> > But, the pa
On Tue, May 14, 2013 at 3:19 PM, Alexander Larsson wrote:
> On tis, 2013-05-14 at 13:19 +0200, John Kåre Alsaker wrote:
> > On Tue, May 14, 2013 at 11:25 AM, Alexander Larsson
> >
> >
> > I don't think it should really be allowed to not apply the
> &g
On Tue, May 14, 2013 at 2:51 PM, Alexander Larsson wrote:
> On tis, 2013-05-14 at 13:44 +0200, John Kåre Alsaker wrote:
> > I'd only accept a proposal which makes the clients tell the compositor
> > how much they increased the size of their window. If the compositor
> >
I'd only accept a proposal which makes the clients tell the compositor how
much they increased the size of their window. If the compositor wants to
resize anything it should resize the entire window and not individual
surfaces/buffers. This also avoids having to position subsurfaces and have
config
On Tue, May 14, 2013 at 11:25 AM, Alexander Larsson wrote:
> On tis, 2013-05-14 at 07:11 +0200, John Kåre Alsaker wrote:
>
> >
> > While this isn't a huge problem on GL-based compositors it
> > will cause a problem for software compositors. Any scalin
> I expect a compositor to render deviations of the desired scaling factor
> without scaling windows. The range when this is allowed is reported to
> clients so they can try to render at a size which will avoid scaling.
>
> For example a compositor may want to use a 1-1.2 range with 1.1 as the
> de
On Mon, May 13, 2013 at 8:52 PM, Jason Ekstrand wrote:
> On Mon, May 13, 2013 at 9:54 AM, Alexander Larsson wrote:
>
>>
>> On mån, 2013-05-13 at 14:40 +0200, John Kåre Alsaker wrote:
>>
>> >
>> > I don't think this will work in pract
On Mon, May 13, 2013 at 2:19 PM, Alexander Larsson wrote:
> On mån, 2013-05-13 at 14:00 +0200, John Kåre Alsaker wrote:
>
> > > Clients can easily scale larger features like icons, padding
> > and fonts
> > > and round them to pixel si
Mon, May 13, 2013 at 1:26 PM, Alexander Larsson wrote:
> On mån, 2013-05-13 at 12:40 +0200, John Kåre Alsaker wrote:
>
> > The scaling factor should not have any affect of any coordinate system
> > or anything else in the protocol. It should only affect the size in
> > p
On Mon, May 13, 2013 at 1:28 PM, Alexander Larsson wrote:
> On mån, 2013-05-13 at 13:26 +0200, John Kåre Alsaker wrote:
> > For the wl_output case I suggest we add a 'done' event which signals
> > that the compositor is done sending a batch of events for an wl_output
For the wl_output case I suggest we add a 'done' event which signals that
the compositor is done sending a batch of events for an wl_output and
related extension objects (which versioned message arguments won't handle).
This would be analogous to wl_surface.commit, only coming from the server
side.
On Mon, May 13, 2013 at 11:56 AM, Alexander Larsson wrote:
> On ons, 2013-05-08 at 22:58 +0200, John Kåre Alsaker wrote:
> > I think we should allow fractional scale factors. Clients which only
> > support integer scale factors should round the scale factor they get
> > to
I think we should allow fractional scale factors. Clients which only
support integer scale factors should round the scale factor they get to a
whole number.
We should implement this by adding a scale_factor event on wl_output (which
clients can get at any time).
When clients have rendered their co
h);
>
> Richard
>
> On 2 May 2013 21:57, John Kåre Alsaker
> wrote:
> > EDID parsing should probably be moved out of compositor-drm since other
> > backends can provide EDIDs too.
> >
> >
> > On Thu, May 2, 2013 at 10:38 PM, Richard Hughes
> wrot
EDID parsing should probably be moved out of compositor-drm since other
backends can provide EDIDs too.
On Thu, May 2, 2013 at 10:38 PM, Richard Hughes wrote:
> This code was originally written by Soren Sandmann
> and was
> found here: http://people.gnome.org/~ssp/randr/edid-parse.c
>
> The co
I'd suggest that client should use subsurfaces if they want multiple
colorspaces in a window. They might have to do that anyway since they may
want a different pixel format.
On Thu, May 2, 2013 at 8:58 AM, Pekka Paalanen wrote:
> On Wed, 1 May 2013 17:03:30 -0400
> Kristian Høgsberg wrote:
>
>
On Tue, Apr 30, 2013 at 10:49 PM, Jason Ekstrand wrote:
> On Tue, Apr 30, 2013 at 2:29 PM, Bill Spitzak wrote:
>
>> I'm not clear on why Wayland's design requires adding 2 dummy objects to
>> the api (in this case the "wl_scalar" factory and the per-surface
>> "wl_surface_scalar") rather than jus
I'd say we should split the cropping and scaling request into two.
Specifying a scaling with a NULL buffer should still set the surface size,
so we can have surfaces with only an input region.
I don't see a way to disable scaling and cropping, could passing 0 as width
and height do that?
On Tue
You should drop the code changes since they already allow relative paths.
You just changed it to only allow base filenames.
On Tue, Apr 23, 2013 at 2:54 PM, Quentin Glidic <
sardemff7+wayl...@sardemff7.net> wrote:
> From: Quentin Glidic
>
> Signed-off-by: Quentin Glidic
> ---
> man/weston.man
any pending updates for outputs in
colord_output_removed.
On Thu, Apr 4, 2013 at 5:33 PM, Richard Hughes wrote:
> On 4 April 2013 07:58, John Kåre Alsaker wrote:
>> The weston_color_manager struct could lose the state field
>
> All fixed in the newest patchset, thanks for your det
The weston_color_manager struct could lose the state field. The CMS
plugins allocates it and can add state as needed. You should move the
weston_cms_output_added call below weston_output_init (which
initializes the compositor pointer in the outputs) and drop the first
argument from output_added, ou
I'd say we make it a ./configure option which builds a shared library
which talks to colord over D-Bus. It can then be packaged separately
by distros. A weston.ini option should be added to pick the CMS plugin
to load. lcms2 can be added as a dependency for the weston side code
(it will probably be
My planned approach was to make colord and Oyranos plugins for Weston.
The plugins would provide the CMSes with information about the outputs
and Weston in return gets ICC profiles for them (which contains gamma
curves). Weston needs the full ICC profile in order to do proper color
correction and t
The extension should be added to weston-egl-ext.h instead.
On Wed, Mar 20, 2013 at 6:05 PM, Rob Bradford wrote:
> From: Rob Bradford
>
> In 1c169ff support is added for using the EGL_BUFFER_AGE_EXT extension
> including runtime detection of whether the extension is available. This change
> exten
wl_egl_window_take_buffer might also facilitate sharing wl_buffers
between processes.
On Mon, Mar 4, 2013 at 1:51 PM, John Kåre Alsaker
wrote:
> On Mon, Mar 4, 2013 at 11:56 AM, Pekka Paalanen wrote:
>> On Mon, 4 Mar 2013 11:12:23 +0100
>> John Kåre Alsaker wrote:
>>
>&
I believe this is the wrong approach. I'd rather see some generic way
to share any wl_object between clients securely. I don't see a
transfer of ownership of your handle which means any client and get
access to it.
I'd rather have something like this:
One connection uses
I suggest we apply all of them except the last 4 which add dispatcher
support. That allows us to slowly fix the other projects with the new
API.
On Sat, Mar 16, 2013 at 9:25 PM, Scott Moreau wrote:
> Hi Jason,
>
> I appreciate your work here. These patches can potentially lower the
> entry barrie
I don't see why we'd want to remove properties from the output object.
They are still useful for the very common case where a surface is on a
single output only. For example, if a surface is on multiple outputs
with mismatching subpixel layouts, it could turn off subpixel
rendering.
Having clients
On Mon, Mar 4, 2013 at 11:56 AM, Pekka Paalanen wrote:
> On Mon, 4 Mar 2013 11:12:23 +0100
> John Kåre Alsaker wrote:
>
>> On Mon, Mar 4, 2013 at 9:48 AM, Pekka Paalanen wrote:
>> > On Sun, 3 Mar 2013 02:26:10 +0100
>> > John Kåre Alsaker wrote:
&g
On Mon, Mar 4, 2013 at 9:48 AM, Pekka Paalanen wrote:
> On Sun, 3 Mar 2013 02:26:10 +0100
> John Kåre Alsaker wrote:
>
>> This patchset introduces wl_egl_window_take_buffer and wl_egl_window_commit
>> to the native wayland-egl platform.
>>
>> wl_egl_window
This adds support for desktop OpenGL which can be enabled by with
./configure --enable-opengl.
Most of the differences in API between OpenGL and OpenGL ES is hidden by
the new gl_renderer fields.
It also accesses GLES2 extensions by including GLES2/gl2platform.h directly.
---
configure.ac
---
clients/simple-egl.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/clients/simple-egl.c b/clients/simple-egl.c
index 26ebe5c..8138a02 100644
--- a/clients/simple-egl.c
+++ b/clients/simple-egl.c
@@ -365,6 +365,7 @@ redraw(void *data, struct wl_callback *callback
---
src/egl/drivers/dri2/platform_wayland.c| 106 ++---
src/egl/wayland/wayland-egl/wayland-egl-priv.h | 2 +
src/egl/wayland/wayland-egl/wayland-egl.c | 22 +
3 files changed, 102 insertions(+), 28 deletions(-)
diff --git a/src/egl/drivers/dri2/platform_wa
---
src/egl/drivers/dri2/platform_wayland.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/src/egl/drivers/dri2/platform_wayland.c
b/src/egl/drivers/dri2/platform_wayland.c
index 6e702ab..56f5d3c 100644
--- a/src/egl/drivers/dri2/platform_wayland.
---
src/wayland-egl.h | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/wayland-egl.h b/src/wayland-egl.h
index 8255151..49bd9f7 100644
--- a/src/wayland-egl.h
+++ b/src/wayland-egl.h
@@ -30,7 +30,7 @@ extern "C" {
#include
-#define WL_EGL_PLATFORM 1
+#define WL_
This patchset introduces wl_egl_window_take_buffer and wl_egl_window_commit to
the native wayland-egl platform.
wl_egl_window_take_buffer gives a way to get a wl_buffer from an wl_egl_window.
The application is expected to attach this to one or multiple wl_surfaces and
the EGL implementation
wil
---
src/compositor-drm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 3c44f7a..f60fce9 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -1174,6 +1174,9 @@ init_egl(struct drm_compositor *ec)
{
ec->gbm = gbm_create_
This also ensures we destroy all EGL images if a plane fails to be created.
---
src/gl-renderer.c | 42 ++
1 file changed, 26 insertions(+), 16 deletions(-)
diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index 778fedd..c2d2490 100644
--- a/src/gl-render
---
src/gl-renderer.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index 7a19b26..778fedd 100644
--- a/src/gl-renderer.c
+++ b/src/gl-renderer.c
@@ -1772,8 +1772,6 @@ gl_renderer_setup(struct weston_compositor *ec,
EGLSurface egl_surface)
This eliminates the multiplication of the alpha uniform for the common case
of surfaces with 1.0 as alpha.
---
src/gl-internal.h | 1 +
src/gl-renderer.c | 14 --
src/gl-shaders.c | 6 +++---
3 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/src/gl-internal.h b/src/gl-
This makes compositing gamma correct by assuming all input surfaces are in
the sRGB color space. It can be enabled by setting color-managed to true
in the compositor section of weston.ini.
It's implemented by converting from sRGB gamma using the new
CONVERSION_FROM_SRGB
shader attribute and drawi
---
src/gl-internal.h | 5 ++
src/gl-renderer.c | 170 --
2 files changed, 158 insertions(+), 17 deletions(-)
diff --git a/src/gl-internal.h b/src/gl-internal.h
index f27b221..205c2d9 100644
--- a/src/gl-internal.h
+++ b/src/gl-internal.h
@@ -
This adds support for desktop OpenGL which can be enabled by with
./configure --enable-opengl.
Most of the differences in API between OpenGL and OpenGL ES is hidden by
the new gl_renderer fields.
It also accesses GLES2 extensions by including GLES2/gl2platform.h directly.
---
configure.ac
This add a more flexible way of generating shaders. It generates all valid
combinations of different input, conversion and output pipelines, which
can easily be extended with more if desired.
---
src/gl-internal.h | 65 +++--
src/gl-renderer.c | 71 +++---
src/gl-shaders.c | 700 +++
rer.c
endif
diff --git a/src/gl-internal.h b/src/gl-internal.h
new file mode 100644
index 000..2e55313
--- /dev/null
+++ b/src/gl-internal.h
@@ -0,0 +1,144 @@
+/*
+ * Copyright © 2012 Intel Corporation
+ * Copyright © 2012 John Kåre Alsaker
+ *
+ * Permission to use, copy, modify, distribute
What's the reason for this change and where is EGL initialized for
outputs created on the fly?
On Tue, Jan 22, 2013 at 5:07 PM, Ander Conselvan de Oliveira
wrote:
> ---
> src/compositor-drm.c | 30 ++
> 1 file changed, 18 insertions(+), 12 deletions(-)
>
> diff --gi
On Thu, Jan 10, 2013 at 9:49 AM, Pekka Paalanen wrote:
> On Wed, 9 Jan 2013 18:14:12 +0100
> John Kåre Alsaker wrote:
>
>> On Wed, Jan 9, 2013 at 10:53 AM, Pekka Paalanen wrote:
>> > On Tue, 8 Jan 2013 21:50:20 +0100
>> > John Kåre Alsaker wrote:
>
On Wed, Jan 9, 2013 at 10:53 AM, Pekka Paalanen wrote:
> On Tue, 8 Jan 2013 21:50:20 +0100
> John Kåre Alsaker wrote:
>
>> My goals for a subsurface implementation are these:
>> - Allow nesting to ease interoperability for client side code.
>> - Allow a surface wit
EGLDisplay, EGLSurface, EGLNativeDisplayType and EGLNativeWindowType
should all be void *. With that change you can get rid of the ugly
typecasts.
On Tue, Jan 8, 2013 at 5:09 PM, Vasily Khoruzhick wrote:
>
> +typedef int EGLDisplay;
> +typedef int EGLSurface;
> +typedef long int EGLNativeDisplayT
On Tue, Jan 8, 2013 at 9:14 PM, Vasily Khoruzhick wrote:
> On Tue, Jan 8, 2013 at 10:50 PM, John Kåre Alsaker
> wrote:
>
> Hi John,
>
>> I'd like for output_create, output_destroy, renderer_destroy,
>> set_border and repaint_output to be virtual functions as part
.
- Allow clients to commit a set of surfaces.
On Tue, Jan 8, 2013 at 8:50 AM, Pekka Paalanen wrote:
> Hi John,
>
> thanks for the comments, I have some more questions about your
> suggestions.
>
>
> On Mon, 7 Jan 2013 16:56:47 +0100
> John Kåre Alsaker wrote:
>
>> On Fri
013 at 8:22 PM, Kristian Høgsberg wrote:
> On Tue, Jan 8, 2013 at 1:36 PM, John Kåre Alsaker
> wrote:
>> I'd like to see this callback in a buffer manager abstraction which
>> could encapsulate EGL and X11/fb/kms buffer management and get rid of
>> duplicated code for the
I'd like to see this callback in a buffer manager abstraction which
could encapsulate EGL and X11/fb/kms buffer management and get rid of
duplicated code for the renderers. However if it's added to
weston_renderer, it should be destroyed by the compositor and not by
the backends.
On Tue, Jan 8, 20
The use-shm variable (which I assume stand for use-x11-shm) and
configuration option should probably be renamed to use-pixman so it
could be used with multiple backends and not be easily confused with
wl_shm.
On Mon, Jan 7, 2013 at 7:49 PM, Kristian Høgsberg wrote:
> On Mon, Jan 07, 2013 at 08:39
On Fri, Dec 21, 2012 at 12:56 PM, Pekka Paalanen wrote:
> Hi all,
>
> we started a discussion about sub-surfaces in Wayland in [1].
> Based on that, and with heavy limiting of scope, I present my first
> sub-surface draft:
>
> http://cgit.collabora.com/git/user/pq/wayland.git/log/?h=subsurface-v1
On Tue, Dec 18, 2012 at 10:29 AM, Pekka Paalanen wrote:
> On Mon, 17 Dec 2012 15:47:43 +
> Richard Hughes wrote:
>
>> On 5 December 2012 14:32, Pekka Paalanen wrote:
>> > One of the most important use cases is a video player in a window. It
>> > has XRGB or ARGB window decorations, usually t
On Tue, Dec 18, 2012 at 2:59 PM, John Kåre Alsaker
wrote:
> On Tue, Dec 18, 2012 at 6:40 AM, Bill Spitzak wrote:
>>
>> On Dec 17, 2012, at 5:01 PM, John Kåre Alsaker wrote:
>>
>>
>> Then a client such as gimp could draw all it's display into a single bu
On Tue, Dec 18, 2012 at 6:40 AM, Bill Spitzak wrote:
>
> On Dec 17, 2012, at 5:01 PM, John Kåre Alsaker wrote:
>
>
> Then a client such as gimp could draw all it's display into a single buffer.
>
> To get the different color correction of the center display, it woul
On Mon, Dec 17, 2012 at 11:40 PM, Bill Spitzak wrote:
> That brings up an interesting possibility: can a subsurface (or any surface)
> image be a subrectangle of an image used for another surface? I'm thinking
> this would be possible, provided the client can tell the wayland server to
> use an ar
On Thu, Dec 13, 2012 at 11:47 PM, Bill Spitzak wrote:
> I see no reason for extra objects. What I would do is add a "parent" to the
> normal surface. If it is NULL then it is a "main" surface. If it points at
> another surface then it is a subsurface or a floating window. The "parent"
> can be cha
t_position and commit_surface requests atomically.
On Thu, Dec 13, 2012 at 3:30 PM, Pekka Paalanen wrote:
> Hi John,
>
>
> On Thu, 13 Dec 2012 14:51:17 +0100
> John Kåre Alsaker wrote:
>
>> Here is my "subsurface" proposal. I don't
Here is my "subsurface" proposal. I don't like video sinks (or other
things) running on an independent framerate. I don't want to maintain
more state in the compositor side for them or have increased
complexity in the protocol. They are inefficient and can be solved by
a number of other ways. In th
On Mon, Nov 19, 2012 at 9:05 PM, Bill Spitzak wrote:
>
>
> John Kåre Alsaker wrote:
>>
>> On Mon, Nov 19, 2012 at 8:32 PM, Bill Spitzak wrote:
>>>
>>> Can somebody explain why compiling weston with the switch
>>> "--with-cairo-glesv2"
On Mon, Nov 19, 2012 at 8:32 PM, Bill Spitzak wrote:
> Can somebody explain why compiling weston with the switch
> "--with-cairo-glesv2" would perhaps fix the weston clients (I am not at my
> machine to try this so I don't know if it does). Doesn't that switch *make*
> it use EGL rather than havin
On Mon, Nov 19, 2012 at 9:21 AM, Pekka Paalanen wrote:
> On Sat, 17 Nov 2012 03:23:54 +0100
> John Kåre Alsaker wrote:
>
>> This adds support for desktop OpenGL which can be enabled by with
>> ./configure --enable-opengl.
>>
>> Most of the differences in AP
On Mon, Nov 19, 2012 at 9:46 AM, Pekka Paalanen wrote:
> On Sat, 17 Nov 2012 03:23:54 +0100
> John Kåre Alsaker wrote:
>
>> This adds support for desktop OpenGL which can be enabled by with
>> ./configure --enable-opengl.
>>
>> Most of the differences in AP
On Mon, Nov 19, 2012 at 9:52 AM, Pekka Paalanen wrote:
> On Sat, 17 Nov 2012 03:23:57 +0100
> John Kåre Alsaker wrote:
>
>> This makes compositing gamma correct by assuming all input surfaces are in
>> the sRGB color space. It can be enabled by setting color-managed to true
This also ensures we destroy all EGL images if a plane fails to be created.
---
src/gl-renderer.c | 43 +++
1 file changed, 27 insertions(+), 16 deletions(-)
diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index c82bed8..b022ba6 100644
--- a/src/gl-rende
---
src/gl-renderer.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/gl-renderer.c b/src/gl-renderer.c
index 5847e12..c82bed8 100644
--- a/src/gl-renderer.c
+++ b/src/gl-renderer.c
@@ -1725,8 +1725,6 @@ gl_renderer_setup(struct weston_compositor *ec,
EGLSurface egl_surface)
This eliminates the multiplication of the alpha uniform for the common case
of surfaces with 1.0 as alpha.
---
src/gl-internal.h | 1 +
src/gl-renderer.c | 14 --
src/gl-shaders.c | 6 +++---
3 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/src/gl-internal.h b/src/gl-
This makes compositing gamma correct by assuming all input surfaces are in
the sRGB color space. It can be enabled by setting color-managed to true
in the compositor section of weston.ini.
It's implemented by converting from sRGB gamma using the new
CONVERSION_FROM_SRGB
shader attribute and drawi
---
src/gl-internal.h | 5 ++
src/gl-renderer.c | 170 --
2 files changed, 158 insertions(+), 17 deletions(-)
diff --git a/src/gl-internal.h b/src/gl-internal.h
index 83b351f..40f109b 100644
--- a/src/gl-internal.h
+++ b/src/gl-internal.h
@@ -
1 - 100 of 194 matches
Mail list logo
