Hi Jonas,
On Tue, Nov 12, 2013 at 10:50:56PM +0100, Jonas Ådahl wrote:
> Wayland compositors are expected to deal with input device processing
> themselves providing input events according to the Wayland protocol to
> the clients. So far only weston has had more than basic support for
> processing
On Tue, Nov 12, 2013 at 9:12 PM, Jasper St. Pierre
wrote:
> On Wed, Nov 13, 2013 at 12:01 AM, wuzhiwen
> wrote:
>>
>> Hi all,
>> I am trying to enabling sprites for drm-backend on Intel Tizen IVI
>> platform
>> using Intel Gen Graphic, and found a commit (de37d67ac5a3d6, Fri Nov 2
>> 10:14:40 201
On Wed, Nov 13, 2013 at 12:01 AM, wuzhiwen wrote:
> Hi all,
> I am trying to enabling sprites for drm-backend on Intel Tizen IVI platform
> using Intel Gen Graphic, and found a commit (de37d67ac5a3d6, Fri Nov 2
> 10:14:40 2012) which always disable sprites by setting "sprites_are_broken
> =
> 1".
Hi all,
I am trying to enabling sprites for drm-backend on Intel Tizen IVI platform
using Intel Gen Graphic, and found a commit (de37d67ac5a3d6, Fri Nov 2
10:14:40 2012) which always disable sprites by setting "sprites_are_broken =
1". I just commented this line and enabled sprites for drm-backend,
A bug in Weston's toytoolkit gave me an hour of debugging headaches.
Improve the error messages that we send if a client requests an invalid
global, either by name or by version.
---
src/wayland-server.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/wayland-ser
---
protocol/.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/protocol/.gitignore b/protocol/.gitignore
index a67e944..78f49d2 100644
--- a/protocol/.gitignore
+++ b/protocol/.gitignore
@@ -1 +1,2 @@
wayland.html
+.wayland.xml.valid
--
1.8.4.2
_
These aren't supported under xdg_shell, at least not right now.
If xdg_shell ever gets support for them, we can revert this commit
and adapt it.
---
clients/fullscreen.c | 19 +++
clients/transformed.c | 21 +
clients/window.c | 11 +--
clients/win
If a client adds a subsurface, we need to make sure it's allocated
properly, so queue a resize and redraw on the parent window.
---
clients/window.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/clients/window.c b/clients/window.c
index 5a1c8ec..df56bd9 100644
--- a/clients/window.c
+++ b
Transient windows, at least not as they are today, don't exist in
xdg_shell. Subsurfaces allow for specially placed surfaces relative
to a window, so use these instead.
---
clients/window.c | 47 ---
1 file changed, 8 insertions(+), 39 deletions(-)
diff
Replace the use of the deprecated wl_shell and wl_shell_surface with
the new and improved xdg_shell protocol Rafael Antognolli and I have
been working on. This is an unstable protocol, and it will adapt to
the needs of desktop environments organically.
I've tested these lightly with mutter-wayland
It seems to be the same as window_move, except it ignores the passed
in serial (???) and instead just uses the one of the display.
---
clients/flower.c | 3 +--
clients/fullscreen.c | 3 +--
clients/transformed.c | 3 +--
clients/window.c | 10 --
clients/window.h | 2 -
We want to remove support for these deprecated interfaces. Since
nothing is using them, this is a simple change.
---
clients/window.c | 12
clients/window.h | 6 --
2 files changed, 18 deletions(-)
diff --git a/clients/window.c b/clients/window.c
index 0e5fce2..29ca42d 100644
--
It seems that this was only used by the popup menu infrastructure,
which can handle this all on its own. Implementing e.g. transients
in the future can be done with a simple xdg_shell_set_transient_for.
---
clients/image.c| 2 +-
clients/terminal.c | 2 +-
clients/view.c | 2 +-
clients
xdg_shell changes this around so that they are flags on the remote
object itself, not separate surface types. Move to a system where
we calculate the state from the flags ourselves and set the appropriate
wl_shell_surface type.
When we port to xdg_shell, we'll drop these flags and simply sync
on t
---
clients/.gitignore | 2 +
clients/Makefile.am| 8 +-
clients/window.c | 306 +--
protocol/Makefile.am | 3 +-
protocol/xdg-shell.xml | 385 +
5 files changed, 530 insertions(+), 174 deleti
On Tue, Nov 12, 2013 at 1:50 PM, Jonas Ådahl wrote:
> Hi,
>
> Wayland compositors are expected to deal with input device processing
> themselves providing input events according to the Wayland protocol to
> the clients. So far only weston has had more than basic support for
> processing raw input
On Tue, Nov 12, 2013 at 10:55:05PM +0100, Jonas Ådahl wrote:
> Signed-off-by: Jonas Ådahl
> ---
> src/evdev.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Looks good, applied.
Kristian
> diff --git a/src/evdev.c b/src/evdev.c
> index b3609d5..ec18d99 100644
> --- a/src/evdev.c
> +++
Pekka Paalanen wrote:
The source rectangle *must* be in buffer pixels. Putting it in
buffer_scale units makes absolutely no sense, as the buffer_scale is in
effect ignored for this surface, overridden entirely by the scaling.
That means that dst_width and dst_height will be required to be in
On Tue, Oct 01, 2013 at 12:52:28AM +0100, Neil Roberts wrote:
> This wraps all accesses to an SHM buffer between wl_shm_buffer_begin
> and end so that wayland-shm can install a handler for SIGBUS and catch
> attempts to pass the compositor a buffer that is too small.
>
> Note, this patch doesn't d
On Tue, Oct 01, 2013 at 12:51:29AM +0100, Neil Roberts wrote:
> Linux will let you mmap a region of a file that is larger than the
> size of the file. If you then try to read from that region the process
> will get a SIGBUS signal. Currently the clients can use this to crash
> a compositor because
Signed-off-by: Jonas Ådahl
---
src/filter.c | 1 -
src/filter.h | 1 -
2 files changed, 2 deletions(-)
diff --git a/src/filter.c b/src/filter.c
index a55ebf2..89237bf 100644
--- a/src/filter.c
+++ b/src/filter.c
@@ -323,7 +323,6 @@ create_pointer_accelator_filter(accel_profile_func_t
profile)
Signed-off-by: Jonas Ådahl
---
src/evdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/evdev.c b/src/evdev.c
index b3609d5..ec18d99 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -691,7 +691,7 @@ evdev_notify_keyboard_focus(struct weston_seat *seat,
uint32_t *k;
Hi,
Wayland compositors are expected to deal with input device processing
themselves providing input events according to the Wayland protocol to
the clients. So far only weston has had more than basic support for
processing raw input events from evdev.
In order to avoid reimplementing support for
Pekka Paalanen wrote:
The surface size has never been limited to multiples of buffer_scale.
The *buffer* size is.
Note, that when we talk about surface size, it is always given in the
surface coordinate units, unless said otherwise.
You are probably referring to the view size on the output, th
argh, Pekka (pq) just told me in #wayland that we're probably talking
about two different things here. Sorry, my confusion.
If you were mentioning about building an Gentoo package out of Chromium
Wayland, then no, I don't think anyone tried that yet. As mentioned in
the blog announcement messa
If a view which has focus is destroyed, we would send a leave
event while changing focus, causing a segfault. Prevent this
by listening to the view's destroy signal and removing it from
the pointer focus.
Signed-off-by: Emilio Pozuelo Monfort
---
src/compositor.h | 1 +
src/input.c | 22 ++
On Tue, Nov 12, 2013 at 9:10 AM, Artsiom Anikeyenka
wrote:
> Hi, guys,
>
> So there is this "building wayland" sequence of steps (wayland, drm, mesa,
> etc...). Is there a document somewhere decribing how all these interact
> whith each other and why we need to install this or that? I'm looking in
no, there isn't any automated compilation tool yet.
To be honest I'm not entirely sure whether it's worthing having such
tool. We basically have Ozone-Wayland repository to be cloned in which
pulls in all the remaining dependencies (well, not libwayland...) and
for that we'd need about half do
Hi
Out of interest is there an ebuild available for this?
Cheers
Mike
On 11 Nov 2013 21:40, "Tiago Vignatti" wrote:
>
> We are happy to announce the first "preview" of Chromium browser with
> Wayland support, using Ozone-Wayland implementation. Check the announcement
> and the details here ple
Hi, guys,
So there is this "building wayland" sequence of steps (wayland, drm, mesa,
etc...). Is there a document somewhere decribing how all these interact
whith each other and why we need to install this or that? I'm looking into
what's available on the official wayland site and over the interne
On Mon, 11 Nov 2013 18:26:45 +0100
Axel Davy wrote:
> On 11/11/2013, Pekka Paalanen wrote :
> > Hi Axel
> >
> > On Fri, 08 Nov 2013 23:49:25 +0100
> > Axel Davy wrote:
> >
> >> Hello,
> >>
> >> I've read carefully your new protocol proposition,
> >> but I think it doesn't meet the requirements t
On Mon, 11 Nov 2013 21:36:43 +
Daniel Stone wrote:
> Hi,
>
> On 11 November 2013 15:52, Pekka Paalanen wrote:
> > On Fri, 08 Nov 2013 23:49:25 +0100
> > Axel Davy wrote:
> >> Except this problem, I think your protocol proposition is fine.
> >> I suggest to change the spec
> >> to include t
On Mon, 11 Nov 2013 21:42:01 +
Daniel Stone wrote:
> Hi,
>
> On 11 November 2013 15:41, Pekka Paalanen wrote:
> >>
> >>
> >> The buffer_queue interface is removed from the buffer_queue-enabled
> >> surface.
> >
> > This could also mention, that the queue is empti
Perfect, thanks for the links !
Regards,
Tarnyko
Tiago Vignatti writes:
Hi,
On 11/12/2013 11:07 AM, Tarnyko wrote:
Hello Tiago,
Neat, thank you very much for your amazing work !
Fedora binary here ; works fine with a small sample of websites.
You may be aware that some sites aren't worki
On Mon, 11 Nov 2013 10:24:33 -0800
Bill Spitzak wrote:
> Pekka Paalanen wrote:
>
> > Clients will always specify surface content in blocks of
> > buffer_scale x buffer_scale pixels. That is how it was before, and
> > that is how the crop & scale extension uses it.
> >
> > In other words, everyt
On Mon, 11 Nov 2013 10:10:04 -0800
Bill Spitzak wrote:
>
>
> Pekka Paalanen wrote:
>
> >> Sounds right. My main concern was that the scale width+height completely
> >> replaces all uses of the buffer width+height in the visible compositor
> >> api (the buffer width+height is needed to figure
Hi,
On 11/12/2013 11:07 AM, Tarnyko wrote:
Hello Tiago,
Neat, thank you very much for your amazing work !
Fedora binary here ; works fine with a small sample of websites.
You may be aware that some sites aren't working (including Google), and
even know the cause, but anyways, here are some of th
Tiago Vignatti writes:
We are happy to announce the first "preview" of Chromium browser with
Wayland support, using Ozone-Wayland implementation. Check the
announcement and the details here please:
https://01.org/ozone-wayland/blogs/tiagovignatti/2013/chromium-browser-way
land-preview-rele
On Mon, 11 Nov 2013 18:00:54 -0600
Jason Ekstrand wrote:
> On Mon, Nov 11, 2013 at 2:12 PM, Jason Ekstrand wrote:
>
> >
> > On Nov 11, 2013 3:18 AM, "Pekka Paalanen" wrote:
> > >
> > > On Sun, 10 Nov 2013 17:26:28 -0600
> > > Jason Ekstrand wrote:
> > >
> > > > Signed-off-by: Jason Ekstrand
>
On Mon, 11 Nov 2013 10:47:47 -0800
Bill Spitzak wrote:
> Pekka Paalanen wrote:
>
> > Or would you rather have src_x, src_y, src_width, src_height always
> > defined in buffer coordinates, and then buffer_transform and
> > buffer_scale (with their requirement of size being a
> > multiple of buffe
40 matches
Mail list logo
