nent), and the power savings on a typical laptop
have the potential to be huge. Given the existing toolkit support, it's
also possible someone could start a simple, new environment with Weston
at its core.
Anyway, congrats again!
Thanks,
--
Jesse Barnes, Intel Open Source Technology Cent
gt; So far there are three speakers who lined up, and my feeling is that
> Matthieu and Marc lined up just so that the deadline and requirement
> will be met. So only a single person is intending to come to fosdem and
> has a topic he wants to talk about.
>
> Come on guys. Surely we can do better than that.
I could come up with something, maybe people would be interested in
hearing about some of our recent SoC work? I'd have to see what I
could get approval for, but I could probably find *something* that's
not still secret. :)
--
Jesse Barnes, Intel Open Source Technology Center
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
...
Somewhere must be ignoring the shifts, but it looks like we honor them
in i915... ah no it looks like we don't treat src_w/src_h that way,
just x & y.
Guess we should fix the kernel driver before we have hardware that
actually supports alpha so this will work nicely!
--
Jesse Ba
e all that
most displays actually use reasonably
- a range of 1-10 isn't enough for really smooth fade effects, 1-255
would be better (though clearly not all hw supports it)
Looks good otherwise. With the above addressed either in a revised
patch or patch on top:
Reviewed-by: Je
y(struct weston_shell *base)
> {
> struct wl_shell *shell = container_of(base, struct wl_shell, shell);
> @@ -1904,9 +1933,12 @@ shell_init(struct weston_compositor *ec)
> weston_compositor_add_binding(ec, 0, BTN_LEFT,
> MODIFIER_SUPER | MODIFIER_
easier to match these things at the toolkit level
rather than the protocol level.
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lis
On Fri, 24 Feb 2012 14:34:52 -0500
Kristian Høgsberg wrote:
> On Fri, Feb 24, 2012 at 1:53 PM, Jesse Barnes
> wrote:
> > On Thu, 16 Feb 2012 15:54:41 +0200
> > Tiago Vignatti wrote:
> >
> >> On 02/16/2012 03:46 PM, Michael Hasselmann wrote:
> >>
on tex or not. So if is
> our intention to keep that documentation up to date and alive, then it
> makes perfect sense for me. I didn't hear anything from Kristian about
> it yet though.
Yeah I'd like to see it auto-dumped to the website, perhaps with a
commit hook on the
On Wed, 22 Feb 2012 12:42:59 -0500
Kristian Hoegsberg wrote:
> On Tue, Feb 21, 2012 at 12:56:11PM -0800, Jesse Barnes wrote:
> > GBM needs the buffer format in order to communicate with DRM and clients
> > for things like scanout.
> >
> > So track the DRI format re
the DRM fb
format list).
Signed-off-by: Jesse Barnes
---
include/GL/internal/dri_interface.h |3 +-
src/gallium/state_trackers/dri/drm/dri2.c |6 +
src/gallium/winsys/sw/wayland/wayland_sw_winsys.h |1 +
src/gbm/backends/dri/gbm_dri.c| 45
hat is, that I want to keep it possible to implement
> OpenWF Display with GBM, without DRM.
> So that we have practical example and API towards the
> Wayland-needs-KMS misinformation.
Yep, understood. Does OpenWF have the notion of surface formats like
this?
--
Jesse Bar
On Fri, 10 Feb 2012 11:55:45 +0200
Pekka Paalanen wrote:
> On Thu, 9 Feb 2012 13:12:58 -0800
> Jesse Barnes wrote:
>
> > Add support for assigning surfaces to overlay sprites using the new
> > assign_planes hook.
> >
> > v2: queue per-sprite vblank events t
On Fri, 10 Feb 2012 11:35:50 +0200
Pekka Paalanen wrote:
> On Thu, 9 Feb 2012 13:12:56 -0800
> Jesse Barnes wrote:
>
> > This lets the tests pick up headers from an alternate install root.
> > ---
> > tests/Makefile.am |2 +-
> > 1 files chan
Add support for assigning surfaces to overlay sprites using the new
assign_planes hook.
v2: queue per-sprite vblank events to avoid de-queuing sprite updates
for unrelated outputs (reported by krh)
v3: handle output and surface transformation when calculating src & dest
rects for the sprit
This allows each output back end to optimize drawing using overlay planes
and cursors (yet to be integrated). If a surface is assigned to a
plane, the back end should clear its damage field so that the later
repaint code won't look at it.
---
src/compositor-drm.c |1 +
src/compositor-open
This lets the tests pick up headers from an alternate install root.
---
tests/Makefile.am |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index a1f361e..0b3ed40 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -6,7 +6,7 @@ en
Ok I think these are ready, pending the commit of the DRM format
handling to GBM.
Thanks,
Jesse
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Finally figured out why --enable-cairo-gles2 wasn't working like
configure --help said it should.
---
configure.ac |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index 550bb3c..a2bb537 100644
--- a/configure.ac
+++ b/configure.ac
@@ -96,7 +96,
gt;y1;
> > + pixman_region32_fini(&dest_rect);
> > +
> > + pixman_region32_init(&src_rect);
> > + pixman_region32_intersect(&src_rect, &es->transform.boundingbox,
> > + &output_ba
If you don't have cairo-gl, the gears build won't pick up the -lGL it
needs to build, so add it to Makefile.am.
---
clients/Makefile.am |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/clients/Makefile.am b/clients/Makefile.am
index b64c38a..32fe503 100644
--- a/clients/Ma
Add support for assigning surfaces to overlay sprites using the new
assign_planes hook.
v2: queue per-sprite vblank events to avoid de-queuing sprite updates
for unrelated outputs (reported by krh)
v3: handle output and surface transformation when calculating src & dest
rects for the sprit
This lets the tests pick up headers from an alternate install root.
---
tests/Makefile.am |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index a1f361e..0b3ed40 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -6,7 +6,7 @@ en
This allows each output back end to optimize drawing using overlay planes
and cursors (yet to be integrated). If a surface is assigned to a
plane, the back end should clear its damage field so that the later
repaint code won't look at it.
---
src/compositor-drm.c |1 +
src/compositor-open
This lets the tests pick up headers from an alternate install root.
---
tests/Makefile.am |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index a1f361e..0b3ed40 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -6,7 +6,7 @@ en
Add support for assigning surfaces to overlay sprites using the new
assign_planes hook.
v2: queue per-sprite vblank events to avoid de-queuing sprite updates
for unrelated outputs (reported by krh)
v3: handle output and surface transformation when calculating src & dest
rects for the sprit
This allows each output back end to optimize drawing using overlay planes
and cursors (yet to be integrated). If a surface is assigned to a
plane, the back end should clear its damage field so that the later
repaint code won't look at it.
---
src/compositor-drm.c |1 +
src/compositor-open
Add support for assigning surfaces to overlay sprites using the new
assign_planes hook.
NOTE: this patch fails to handle fbs correctly; a live fb/surface pair
may be removed while still active!
---
configure.ac |2 +-
src/compositor-drm.c | 413 +++
This allows each output back end to optimize drawing using overlay planes
and cursors (yet to be integrated). If a surface is assigned to a
plane, the back end should clear its damage field so that the later
repaint code won't look at it.
---
src/compositor-drm.c |1 +
src/compositor-open
Plane and output handling are mostly the same; they both create fbs for
display and then assign them to either the primary or one of the overlay
planes. So unify them using a new drm_buffer_reference object, making
the plane handling code work much better.
---
src/compositor-drm.c | 411
Each output may have ways of optimizing surface drawing (e.g. by using
sprites), so push the handling of surface assignment to display planes
into the output structure, providing the existing surface setup function
as a helper.
---
configure.ac |2 +-
src/compositor-drm.c | 19
Much of the scanout handling code is only used by the DRM compositor, so
move it over to make it easier to add the sprite handling changes.
---
src/compositor-drm.c | 44 +++-
src/compositor.c | 30 +-
src/compositor.h
Ok these need some actual review. I have things working here (you can
test on a current kernel by enabling the DEBUG_PLANES code) and I think
the infrastructure is starting to look ok, especially now that I don't
leak fbs on every assignment. :)
The new buffer reference code makes things a bit ni
We can use this in the output drivers to figure out if we can use
sprites for example.
diff --git a/src/compositor.c b/src/compositor.c
index 7afec94..87f4fee 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -201,6 +201,7 @@ weston_surface_create(struct weston_compositor *compositor,
To be applied once wayland.xml has full documentation.
---
src/scanner.c | 27 ---
1 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/src/scanner.c b/src/scanner.c
index f88fb4d..ee9af5f 100644
--- a/src/scanner.c
+++ b/src/scanner.c
@@ -292,6 +292,9 @@ star
On Thu, 19 Jan 2012 14:13:36 -0800
Jesse Barnes wrote:
> Add support for arg summaries for use by detailed structure element
> descriptions.
> ---
> protocol/wayland.xml |4 ++-
> src/scanner.c| 76 +
> 2 files chan
Add support for arg summaries for use by detailed structure element
descriptions.
---
protocol/wayland.xml |4 ++-
src/scanner.c| 76 +
2 files changed, 48 insertions(+), 32 deletions(-)
diff --git a/protocol/wayland.xml b/protocol/way
mes be off by
one with a flip complete vs a vblank event (one might come in before
the other). And the setplane call is really vblank sync'd, independent
of when/how the flip was scheduled.
We really need an atomic mode set don't we?
--
Jesse Barnes, Intel Open Source Techn
Much of the scanout handling code is only used by the DRM compositor, so
move it over to make it easier to add the sprite handling changes.
---
src/compositor-drm.c | 44 +++-
src/compositor.c | 30 +-
src/compositor.h
Each output may have ways of optimizing surface drawing (e.g. by using
sprites), so push the handling of surface assignment to display planes
into the output structure, providing the existing surface setup function
as a helper.
---
clients/window.h |3 -
configure.ac |2
This lets me run Weston as root in an ssh window and gdb and get stdout.
---
src/compositor-drm.c |3 ++-
src/tty.c|4 ++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 9e25ffd..1751e72 100644
--- a/src/composi
In assign_planes, we try to assign the primary buffer to the primary
plane, then look for additional surfaces to match to display planes. At
present time, we'll then flip all those buffers onto the screen in a
synchronized way, then clean up and release the buffers when the
corresponding page flip
This set refactors thing a bit more and tries to somewhat unify
presentation of primary and sprite surfaces. I broke something though
because terminal-in-a-sprite no longer works, but I think the
refactoring is interesting to look at anyway.
Any thoughts? Kristian, you mentioned something about
bove
> setup_scanout_surface(). In fact, I think we can roll
> setup_scanout_surface() into that hook and handle pageflipping to
> client buffers in the same hook. It's not all that different.
> Attached a patch/sketch.
So something like this is more like what you had in
eds to move up above
> setup_scanout_surface(). In fact, I think we can roll
> setup_scanout_surface() into that hook and handle pageflipping to
> client buffers in the same hook. It's not all that different.
> Attached a patch/sketch.
Cool, thanks. I'll check it ou
The DRM repaint function can allocate available DRM display planes for
use in drawing surfaces. In some cases a repaint can even be avoided if
only a surface currently using a sprite has been updated.
---
src/compositor-drm.c | 109 +-
1 files chan
Each output may have ways of optimizing surface drawing (e.g. by using
sprites), so push the handling of repaint into the output structure,
providing the existing repaint function as a helper.
---
src/compositor-drm.c |1 +
src/compositor-openwfd.c |1 +
src/compositor-wayland.c |1
I just wanted to get a direction check on this, there are still many
open questions.
The overall goal here is to be able to use overlay planes to display
surfaces at repaint time if possible. For long lived surfaces getting
lots of changes, this can be a big power win since the plane blender is
a
be sure to submit it soon.
Early registration for LPC is open until June 1st, so regardless of
whether you're submitting a topic, if you see discussions or proposed
talks of interest to you, be sure to register soon to get the
discounted rate.
Thanks,
Jesse Barn
additional features it would provide (output
> > management, memory management, execution management)
>
> 3) its got documentation
Jeez, some people want it all.
You looking for docs for the ioctls and such?
--
Jesse Barnes, Intel Open Source Technology Center
ich makes reallocation of the framebuffer
somewhat difficult.
IIRC plymouth or whatever Fedora is using these days uses the KMS APIs
though...
--
Jesse Barnes, Intel Open Source Technology Center
___
wayland-devel mailing list
wayland-devel@l
On Mon, 21 Mar 2011 20:50:20 +0100
Geert Uytterhoeven wrote:
> On Mon, Mar 21, 2011 at 20:25, Jesse Barnes wrote:
> > On Mon, 21 Mar 2011 19:19:43 +
> > timofonic timofonic wrote:
> >> So if KMS is so cool and provides many advantages over fbdev and
> >> s
On Mon, 21 Mar 2011 19:19:43 +
timofonic timofonic wrote:
> So if KMS is so cool and provides many advantages over fbdev and
> such... Why isn't more widely used intead of still relying on fbdev?
> Why still using fbdev emulation (that is partial and somewhat broken,
> it seems) instead using
not like we can't do
> "advanced" things like compositing using the CPU. Transparency may stretch
> it a bit on lower end CPUs, but you don't always need that.
There's nothing in DRM that precludes doing simple fbdev-like drivers
as well, though
to deprecate older input
> protocols over time.
I heard something like that was proposed at the recent Khronos meeting;
it sounded like STREAMS but for input, maybe krh can point you at the
proceedings or something, it seemed like a potentially reasonable way
of handling the variety of input nee
54 matches
Mail list logo
