Signed-off-by: Jason Ekstrand
---
src/connection.c | 6 --
src/wayland-client.c | 3 +--
src/wayland-private.h| 4 ++--
src/wayland-server.c | 3 +--
tests/connection-test.c | 13 +++--
tests/os-wrappers-test.c | 4 ++--
6 files changed, 17 insertions
Signed-off-by: Jason Ekstrand
---
src/data-device.c| 16
src/wayland-server.c | 6 +-
src/wayland-server.h | 16
src/wayland-shm.c| 24 ++--
4 files changed, 27 insertions(+), 35 deletions(-)
diff --git a/src/data-device.c b
Signed-off-by: Jason Ekstrand
---
src/connection.c | 25 +++--
src/wayland-client.c | 8 ++--
src/wayland-private.h | 11 ---
src/wayland-server.h | 1 +
src/wayland-util.h| 29 -
5 files changed, 54 insertions(+), 20
Signed-off-by: Jason Ekstrand
---
tests/connection-test.c | 12 ++--
tests/os-wrappers-test.c | 4 ++--
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/tests/connection-test.c b/tests/connection-test.c
index 0f6667b..fb0111b 100644
--- a/tests/connection-test.c
+++ b
function
really needs to be called in the first one so it can set up the destroy signal,
however the second one is where the interface and implementaiton are assigned.
In any case, this patch should work and allow weston to build.
Signed-off-by: Jason Ekstrand
---
src/compositor.c | 18
/wayland-devel/2013-March/007830.html
Jason Ekstrand (6):
Change wl_closure_invoke to take an opcode instead of an actual
function pointer
Add wl_resource_init and use it in libwayland implementations of data
sharing and SHM
Add a dispatcher field to wl_object.
Add null dispatchers to
Signed-off-by: Jason Ekstrand
---
src/connection.c | 6 --
src/wayland-client.c | 4 ++--
src/wayland-private.h| 2 +-
src/wayland-server.c | 2 +-
tests/connection-test.c | 13 +++--
tests/os-wrappers-test.c | 4 ++--
6 files changed, 17 insertions(+), 14
Signed-off-by: Jason Ekstrand
---
src/wayland-client.c | 39 ++-
src/wayland-client.h | 2 ++
src/wayland-server.c | 47 ---
src/wayland-server.h | 4
4 files changed, 76 insertions(+), 16 deletions(-)
diff
Signed-off-by: Jason Ekstrand
---
tests/connection-test.c | 12 ++--
tests/os-wrappers-test.c | 4 ++--
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/tests/connection-test.c b/tests/connection-test.c
index 9a07d71..9bd1cb2 100644
--- a/tests/connection-test.c
+++ b
Specifically, the following functions have been added:
- wl_resource_init_d
- wl_client_add_object_d
- wl_client_new_object_d
- wl_proxy_add_listener_d
Signed-off-by: Jason Ekstrand
---
src/wayland-client.c | 30 +-
src/wayland-client.h | 4
src/wayland
wl_resource which may be null in the case that the object was created by
xwayland.
Signed-off-by: Jason Ekstrand
---
src/compositor.c | 18 ++---
src/shell.c| 57 +++---
src/tablet-shell.c | 16 ++-
src/text-backend.c
ion.
Signed-off-by: Jason Ekstrand
---
src/data-device.c| 16
src/wayland-server.c | 6 +-
src/wayland-server.h | 16
src/wayland-shm.c| 24 ++--
4 files changed, 27 insertions(+), 35 deletions(-)
diff --git a/src/data-device.c b/
This commit adds support for custom dispatchers via a new dispatcher field in
wl_object. If the dispatcher field is set to null, the default libffi-based
dispatcher will be used.
Signed-off-by: Jason Ekstrand
---
src/connection.c | 52
Guilio,
The big problem here is that, unlike the server, events client-side
are handled in multiple event loops. Server-side, everything is
handled in a single event loop and events (at least on a per-client
basis) are handled in order (I think this is even in the spec). On
the client-side, where
.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
In general, I like it and we've already talked about it some. I still
have two questions regarding the actions:
1. What exactly does the IGNORE action mean? I think it's probably
ok, but needs
positor goes to draw the surface it would
select the best "child" buffer and use that one to render the surface.
Another type of buffer would be one that wraps another buffer (egl,
or shm) and in tells the compositor to ignore the backing buffer's
size and scale it to the size
> Your proposal is middle ground: a set of buffers, and some
> heuristics applied on their properties to combine those in the
> compositor space. For simplicity, I dare to think one buffer for
> one output is quite clear cut and easier to deal with.
As a word of clarification, I said " keyed to o
---
This patch should actually go at the begining of the series before 1/6. I
accidentally forgot to include it and didn't notice until someone tried to
apply the series.
tests/connection-test.c | 6 +++---
tests/os-wrappers-test.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff
being too rocky.
--Jason Ekstrand
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
one by removing the buffer from the surface.
Many desktop environments have a window preview in the switcher or
somewhere else. If you want to be able to preview minimized windows,
it needs to remain mapped.
I guess I don't necessarily have a problem with the events/requests
core protocol and make sure
we get it right. There is a big limit as to how much of the
"implement it now and fix it later" we can do with the core protocol.
As soon as we have the 1.1 release, we (and the rest of the Linux
community) are stuck with it regardless of whether or not it's a good
implementation.
I hope that's more clear,
--Jason Ekstrand
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
proper sub-pixel rendering inside
> wayland paradigm.
Yes, adding some support for that might be a good idea. However, this
becomes a bit of an issue because the surface might not be rectangular
anymore or it might be rotated. How do you recommend getting around
this?
--Jason Ekstrand
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
sits in that pattern is
essential for proper subpixel rendering.
See also: http://en.wikipedia.org/wiki/Subpixel_rendering#Checkered_RG-BW_layout
--Jason Ekstrand
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.fre
This is the first step towards deprecating wl_resource as a transparent
structure. In the future, wl_resource will be an opaque pointer type and
client code will not have access to its memebers.
---
src/wayland-server.c | 39 +++
src/wayland-server.h | 27
ect uses of
wl_resource from weston to prepare it for the change. I hope to have
this done so that wl_resource can be removed from the public API in
time for 1.2. That said, the exact timeline is up in the air.
Thanks,
--Jason Ekstrand
___
wayland-devel
---
src/wayland-server.h | 3 ++-
src/wayland-shm.c| 49 +++--
2 files changed, 25 insertions(+), 27 deletions(-)
diff --git a/src/wayland-server.h b/src/wayland-server.h
index 2c6efc9..01ef7b5 100644
--- a/src/wayland-server.h
+++ b/src/wayland-se
---
src/egl/wayland/wayland-drm/wayland-drm.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/src/egl/wayland/wayland-drm/wayland-drm.c
b/src/egl/wayland/wayland-drm/wayland-drm.c
index d02aab6..8d4972a 100644
--- a/src/egl/wayland/wayland-drm/wayland-drm
---
src/compositor.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/compositor.c b/src/compositor.c
index b734f67..305efe0 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -1060,7 +1060,7 @@ weston_buffer_reference_handle_destroy(struct wl_listener
*
r is requesting the client to minimize, not simply telling it
that it already is.
3. Some way for the client to unset maximized, minimized etc.
4. An enum and a request telling the compositor which of these
operations is supported. This way the compositor can hide the buttons
or whatever.
n't given that much thought. However if you
wanted to play with it and send a patch to the ML, I'd be more than
happy to take a look at it.
Thanks,
--Jason Ekstrand
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Hi Scott,
> One important thing to note here is that client != surface. In fact,
> clients can have multiple surfaces. We might need to keep this in mind
> for things like closing single surfaces demonstrated here
> https://github.com/soreau/wayland/commit/65f8a3f5f683c3a91913a26496cc373633f01896
plain surface. If some
> + foreign surface is associated with this surface an
> + "foreign_surface_lost" event is emitted to the foreign surface
> + manager with the foreign surface specified.
> +
> +
> +
> +
> +
> + This event will be sent
g it right now would be bad. I'm sorry for any confusion,
--Jason Ekstrand
On Tue, Mar 19, 2013 at 1:15 PM, Jason Ekstrand wrote:
> Devs,
> This is to let you know that we are going to try and depreciate
> wl_resource. I talked with Kristian about it this morning on IRC.
&
information after the
resource is created. However, I don't think we really care about supporting
this anyway.
Comments welcome!
--Jason Ekstrand
---
src/connection.c | 8 ++
src/wayland-private.h | 15 +---
src/wayland-server.c
or can send an event to a surface saying that the state should
> change to a new set of values. Un-minimize just means it turns off the
> minimize bit and sends the new value.
>
> The client can send commands changing the state of surfaces. If it w
On Mon, Mar 25, 2013 at 12:24 PM, Bill Spitzak wrote:
> Jason Ekstrand wrote:
>
>> One more thing before I go onto the technical details: Bill Spitzak.
>> Just because he gets on your nerves doesn't mean you should just
>> ignore him.
>
>
> Thanks but I th
se
are the standard abbreviations for the 8 Wayland data types. Specifically,
"n" stands for new_id, "h" stands for file descriptor. While not strictly
needed, the redundancy serves to make things more explicit in the code.
When I actually send out the patches, I'll put comment
On Tue, Mar 26, 2013 at 8:24 AM, Jason Ekstrand wrote:
> On Mar 26, 2013 3:28 AM, "Dave Airlie" wrote:
>>
>> > +++ b/src/wayland-private.h
>> > @@ -74,15 +74,9 @@ int wl_connection_write(struct wl_connection
>> > *connection, const void *d
issue, it
looks good to me. Good Job!
--Jason Ekstrand
On Tue, Mar 12, 2013 at 6:35 PM, Hardening wrote:
> This is the third version for the FreeRDP based
> compositor. New features:
> * can specifying extra graphical modes
> * supports mode_switching()
> * supports Suppres
w, it can be found here:
http://www.jlekstrand.net/jason/wayland-language-bindings-guide
Don't feel scared to review this one. If you don't know libwayland
internals, this should serve as a half-decent guide to them.
Thanks,
--Jason Ekstrand
Looks good to me. Ship it! This was part of some of my defunct dispatcher
patches at one point. I think this is a lot cleaner than casting all the
time anyway.
--Jason
On Mar 28, 2013 8:58 AM, "Giulio Camuffo" wrote:
> This is needed to make C++ programs that include wayland-server.h build:
> C
Both patches in this series look good to me.
--Jason Ekstrand
On Mar 28, 2013 1:49 PM, "Rob Bradford" wrote:
> From: Rob Bradford
>
> Reorder the error handling in the case that closure is NULL due to ENOMEM
> to
> ensure that we can safely call wl_closure_lookup_obj
gt;
> Anyhow, I think it makes sense to avoid crashing when the server is
> misbehaving, but would it maybe make sense to log a warning about it?
Along those lines there is another one on line 737 in queue_event that we
may want to look at. Again, this should only happen in the case of
misbehaving com
Daniel,
A few quick thoughts, more to come. First, your get_export_surface has two
new_id arguments. I don't think that's intended. Second, we currently have
no way for a client to retrieve data from a buffer. This will be a problem
for client-side compositing.
--Jason Ekstrand
On Ma
esn't work with rdesktop; why is this?
--Jason Ekstrand
On Thu, Mar 28, 2013 at 6:40 PM, Hardening wrote:
> Sorry, my previous post was broken.
>
> This patch is the 5th version of the FreeRDP based compositor.
> Changes from last version:
> * dropped tiling for raw surfaces
On Fri, Mar 29, 2013 at 12:02 PM, Daniel Stone wrote:
> Hi Jason,
>
> On 29 March 2013 16:55, Jason Ekstrand wrote:
>>
>> A few quick thoughts, more to come. First, your get_export_surface has
>> two new_id arguments. I don't think that's intended.
>
&g
Matthias,
Thanks for working on this! My brief reading indicates that you've
done a pretty good job over-all. I'm going throgh your patches now
and so you can expect patch-by-patch comments shortyly.
--Jason Ekstrand
On Sat, Mar 30, 2013 at 12:11 AM, wrote:
> From: Matthias Clas
Ok, so I like moving "Compositors" up a bit but I'm thinking a more
natural place to put it would be after "Architecture" so that the
reader has a better idea of what we mean by a compositor before they
start reading about types of compositors.
--Jason Ekstrand
On Sat,
Looks Good!
--Jason Ekstrand
On Sat, Mar 30, 2013 at 12:11 AM, wrote:
> From: Matthias Clasen
>
> The Wayland Protocol -> Wayland Protocol Overview, to align
> better with the subsequent Wayland Protocol Specification.
> ---
> doc/Wayland/en_US/Protocol.xml | 2 +-
Some of this stuff has been somewhat re-defined lately and may not be
up-to-date. You may want to talk to Kristian or Daniel and see what
the current line-of-thought on types of compositors is. I like the
fact that you expanded on things quite a bit.
--Jason Ekstrand
On Sat, Mar 30, 2013 at 12
Looks Good!
--Jason Ekstrand
On Sat, Mar 30, 2013 at 12:11 AM, wrote:
> From: Matthias Clasen
>
> Turn the bullet-point list into complete sentences.
> ---
> doc/Wayland/en_US/Protocol.xml | 19 ---
> 1 file changed, 4 insertions(+), 15 deletions(-)
&g
Looks Good!
--Jason Ekstrand
On Sat, Mar 30, 2013 at 12:11 AM, wrote:
> From: Matthias Clasen
>
> ---
> doc/Wayland/en_US/Protocol.xml | 71
> ++
> 1 file changed, 31 insertions(+), 40 deletions(-)
>
> diff --git a/doc/Wayland/
Looks Good!
--Jason Ekstrand
On Sat, Mar 30, 2013 at 12:11 AM, wrote:
> From: Matthias Clasen
>
> Say 'object ID' throughout.
> ---
> doc/Wayland/en_US/Protocol.xml | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/doc/Waylan
On Sat, Mar 30, 2013 at 12:11 AM, wrote:
> From: Matthias Clasen
>
> This adds a bit of information about in-order event delivery,
> removes extraneous formatting, and adds a missing period.
> ---
> protocol/wayland.xml | 17 +
> 1 file changed, 9 insertions(+), 8 deletions(-)
>
On Sat, Mar 30, 2013 at 12:11 AM, wrote:
> From: Matthias Clasen
>
> Reword a few things, and add some details.
> ---
> protocol/wayland.xml | 44 ++--
> 1 file changed, 26 insertions(+), 18 deletions(-)
>
> diff --git a/protocol/wayland.xml b/protocol/wa
On Sat, Mar 30, 2013 at 12:11 AM, wrote:
> From: Matthias Clasen
>
> Add some information about wl_callback and its done event.
> ---
> protocol/wayland.xml | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index ad72f
On Sat, Mar 30, 2013 at 12:11 AM, wrote:
> From: Matthias Clasen
>
> Reword some paragraphs, and spell out 'file descriptor'.
> ---
> protocol/wayland.xml | 73
> +++-
> 1 file changed, 49 insertions(+), 24 deletions(-)
>
> diff --git a/protocol/
tion redundancy that the reader has to sort through.
More comments below.
--Jason Ekstrand
On Sat, Mar 30, 2013 at 12:11 AM, wrote:
> From: Matthias Clasen
>
> Add a few missing summaries and descriptions, spell out file
> descriptor, use hyphens in drag-and-drop, don't u
s that are to be parsed by something like
doxygen or javadoc. That said, fixing capitalization in the summaries
wouldn't be bad.
I have a few more general comments at the tops of the reply e-mails I
sent out. Keeping all this in mind, I'd like you to go back through
and make a second ve
On Sat, Mar 30, 2013 at 1:09 PM, wrote:
> From: Matthias Clasen
>
> Add some information about serials, timestamps and their uses
> to the Input section in the protocol overview.
> ---
> doc/Wayland/en_US/Protocol.xml | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/do
Looks Good!
--Jason Ekstrand
On Sat, Mar 30, 2013 at 1:36 PM, wrote:
> From: Matthias Clasen
>
> Explanation received on wayland-devel indicates that it is
> expected compositor behaviour to unmap surfaces without content.
> ---
> protocol/wayland.xml | 3 +++
> 1 file
I don't know that these extra comments are needed. This information
is provided in the protocol documentation. Also, if we do want them,
"timestamp in milliseconds" seems nicer to read than "timestamp with
millisecond granularity".
--Jason Ekstrand
On Sat, Mar 30,
, Mar 30, 2013 at 11:47 PM, Matthias Clasen
wrote:
> On Sat, Mar 30, 2013 at 6:32 PM, Jason Ekstrand wrote
>
>>
>> 1. I said this in one of the e-mails, but avoid unneeded
>> documentation. The documentation as is is fairly sparse and needs to
>> be filled in.
g that, such as by using the
>> serials?
>
>
> Hmmm. I was going to say using the event order, but it all depends on which
> order the devices were read in. So I guess for this case we'd need to go
> with #2.
As a side note, #2 also makes more sense for the wl_pointer wh
Looks good!
--Jason Ekstrand
On Mar 30, 2013 12:24 AM, wrote:
> From: Matthias Clasen
>
> Use NULL consistently. And add some more information in a few
> places.
> ---
> protocol/wayland.xml | 123
> +--
> 1 file chang
Looks good!
--Jason Ekstrand
On Mar 30, 2013 12:30 AM, wrote:
> From: Matthias Clasen
>
> Just cosmetic changes, a few missing periods, and ID was
> not capitalized.
> ---
> protocol/wayland.xml | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
Looks good! Ship it!
--Jason Ekstrand
On Mon, Apr 1, 2013 at 4:43 PM, Hardening wrote:
> This patch is the 6th version of the FreeRDP based compositor.
> Changes from last version:
> * use pixman_image_get_stride() when appropriate
> * always realloc
>
> Reviewed-
://github.com/jekstrand/wayland-java
Jason Ekstrand (2):
Add support for server-side language bindings
Add support for client-side language bindings
src/connection.c | 8
src/wayland-client.c | 92
src/wayland-client.h | 5 +++
src/wayland
of variadic functions.
Signed-off-by: Jason Ekstrand
---
src/connection.c | 8
src/wayland-private.h | 15 +++
src/wayland-server.c | 114 --
src/wayland-server.h | 15 +++
src/wayland-util.h| 40 ++
5
This commit adds support for language bindings on the client half of the
library. The idea is the same as for the server-side dispatchers, only simpler
because of better API isolation of wl_proxy.
Signed-off-by: Jason Ekstrand
---
src/wayland-client.c | 92
Valgrind complains because sometimes padding at the ends of strings and arrays
is left uninitialized. Zeroing out the buffer fixes this problem.
Signed-off-by: Jason Ekstrand
---
src/connection.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/connection.c b/src/connection.c
index
Regression occurred in:
commit 9c0357af6ee42c318ce37b458ae7bdb7d51316cb
Author: Peter Hutterer
Date: Tue Apr 2 09:58:17 2013 +1000
protocol: document wl_pointer, wl_keyboard, wl_touch
---
Thanks to Henri Tuhola for finding this!
protocol/wayland.xml | 4 ++--
1 file changed, 2 insertion
's RDP back-end that provides one seat for each connected RDP
client.
I hope that helps,
--Jason Ekstrand
On Wed, Apr 17, 2013 at 3:26 AM, Andrew Voron wrote:
> Hello.
>
> I want to clarify a seats supporting by wayland(and weston). By "seats
> support" I mean an abilit
#x27;t
think that's supported yet, but it may not take much.
--Jason
>
> -Satyeshwar
>
> -Original Message-
> From: wayland-devel-bounces+satyeshwar.singh=
> intel@lists.freedesktop.org [mailto:
> wayland-devel-bounces+satyeshwar.singh=intel@lists.freedesk
7;m not sure what all this would involve). If the client expects to
be able to do any ioctls on said stream things would get particularly
interesting.
Second is that events may not come directly from the kernel. Once my
Android compositor app gets be
urcc.patch
> Why was that or similar never used? :-)
>
>
> Thanks,
> pq
> _______
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
Thanks,
--Jason Ekstrand
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
it and wl_subcompositor.get_subsurface.
> >> > > +
> >> > > +
> >> >
> >> > Maybe I missed it, but what's the initial z-order for new
> >> > sub-surfaces? I guess it's "top-most" but I think it should be
> &g
uple ideas. Perhaps more immediate
questions are, Is this useful? and, Is this too much of an abuse of
wl_buffer?
Thanks,
--Jason Ekstrand
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
timestamp
> pad_index -- uint -- which gamepad this is
> subtype -- uint -- ordinal identifying the event subtype
> a -- uint -- first parameter
> b -- uint -- second parameter
> c -- uint -- third parameter
> d -- uint -- fourth parameter
>
My feeling on this would be to wait until we have a use-case for it. We
can always bump the version and add an event if it comes up. I think
that's better than just assuming we can do something sensible with four
generic parameters.
>
>
>
> Todd.
>
> --
> Todd Showalter, President,
> Electron Jump Games, Inc.
>
In general, I think it looks pretty good so far.
--Jason Ekstrand
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Todd,
I think you forgot reply-all. I add wayland-devel again.
On Fri, Apr 26, 2013 at 5:50 PM, Todd Showalter wrote:
> On Fri, Apr 26, 2013 at 5:46 PM, Jason Ekstrand
> wrote:
>
> > My first general comment is about floating point. I'm not 100% sure what
> > all wen
I just thought it might be worth mentioning.
--Jason Ekstrand
On Fri, Apr 26, 2013 at 11:38 AM, Jason Ekstrand wrote:
> On Fri, Apr 26, 2013 at 9:14 AM, Jason Ekstrand wrote:
>
>> pq,
>>
>> On Fri, Apr 26, 2013 at 7:09 AM, David Herrmann wrote:
>>
>>> Hi Pekka
On Sun, Apr 28, 2013 at 1:24 AM, Pekka Paalanen wrote:
> On Fri, 26 Apr 2013 09:48:19 -0500
> Jason Ekstrand wrote:
>
> > Wayland Devs,
> >
> > What follows is an idea that's been kicking around my head for a little
> > while now due to a discussion on
On Mon, Apr 29, 2013 at 5:16 AM, Pekka Paalanen wrote:
> On Mon, 29 Apr 2013 09:40:56 +0200
> David Herrmann wrote:
>
> > Hi Pekka
> >
> > On Mon, Apr 29, 2013 at 8:58 AM, Pekka Paalanen
> > wrote:
> > > On Fri, 26 Apr 2013 11:38:12 -0500
> > &
On Mon, Apr 29, 2013 at 2:11 AM, Pekka Paalanen wrote:
> On Sat, 27 Apr 2013 15:18:29 -0500
> Jason Ekstrand wrote:
>
> > Sorry to spam the list, but I had another idea kicking around my head
> > this weekend that I thought was worth sharing. Please note that I
>
so that their in-game chat etc. works. Whatever they use to
handle that could also handle the home button. I'm not sure what they'll
use to do that in the wayland world. They may have some sort of embedded
compositor or just a client-side library that all their games includ
aised.
>
>
>
>
>
>
>
>
>
>
>
>
>
There's only one gaping hole that I see here and that is attach behaviour.
Currently, wl_surface.attach takes an (x, y) position argument telling the
compositor where to place the new buffer relative to the old one. How is
this going to interact with this extension?
I think the problem here is the same one that we've seen before: Surfaces
inherently take their size etc. from the buffer attached to them. While
this works great in the "single image exactly the size it should be on
screen" case, I'm not sure it's working well when we go beyond that.
Unfortunately, I'm not 100% sure how to solve it.
Thanks,
--Jason Ekstrand
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
here needs to be a distinction made here between an extension to
wl_surface and a surface role. The idea of a surface role is that a
surface can be a subsurface, a shell surface, a cursor surface etc, but
only one at any given time. This was (as far as I can
On Thu, May 2, 2013 at 5:51 AM, Pekka Paalanen wrote:
> On Tue, 30 Apr 2013 10:54:25 -0500
> Jason Ekstrand wrote:
> > On Tue, Apr 30, 2013 at 9:06 AM, John Kåre Alsaker <
> > john.kare.alsa...@gmail.com> wrote:
> > > I'd say we should split the
On Thu, May 2, 2013 at 1:22 PM, Daniel Stone wrote:
> Hi,
>
> On 2 May 2013 15:42, Jason Ekstrand wrote:
> > Ok, I see it now. Sorry, but I missed it on my first read-through. Yes,
> it
> > fixes the problem, but in an extremely confusing way. The reason I say
> it
to be more general and future-proof than the
> wl_gamepad_manager
> solution.
>
To tie up my comments, I think this can get far too complicated fast. I
think it's better to have a seat correspond to a focus and allow for the
fact that we may have more than one person to a seat. It's not 100% ideal,
but it's a lot simpler than some strange tree of seats. Besides, if some
compositor wants to do a strange tree of seats, there's nothing in pq's
proposed protocol that would prevent that and games shouldn't care.
--Jason Ekstrand
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
simply to scale the surface for the lower/higher
res monitor?
Also, what happens if you have three monitors with factors 1, 2, and 3?
Can you render at 2 or 3? I guess I'm concerned that we're going to lock
ourselves into a system where monitor sizes have to come in powers of 2 or
we won't be able to make sense of them. Then again, there may be no better
solution.
For reference, this has already been discussed at some length on the list.
The first post to the effect is here:
http://lists.freedesktop.org/archives/wayland-devel/2013-March/007941.html
Also, we need to figure out how this interacts with the proposed scaling
extension. Information can be found here:
http://lists.freedesktop.org/archives/wayland-devel/2013-April/008927.html
Thanks,
--Jason Ekstrand
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
I don't think this is insurmountable, but it's certainly a pain.
In short, I think this is far too complex for what it achieves. In the
case of scaling factor stuff, you can just do it with a second event.
Thanks,
--Jason Ekstrand
_
window
> feature (when a window is pinned, visible on every workspace). Is this
> a desired feature too?
>
I'm not the person to answer that question.
Thanks for looking into this,
--Jason Ekstrand
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
The more I think about this solution, the more I like it. You're right
that clients have no reason to know why a seat gets focus, simply that it
does. Also, it's worth remembering that whatever GUI we present to the
user doesn't have to directly
which
surface. There is nothing in the protocol (a this point) to indicate that
beyond which outputs it is on. Surfaces don't know their absolute
positions.
Second, we are going to have to deal with fractional scaling even if we
restrict to integers. Consider the following example. Say I ha
On Mon, May 13, 2013 at 4:14 PM, Rafael Antognolli wrote:
> Hi Jason,
>
> On Wed, May 8, 2013 at 9:26 PM, Jason Ekstrand
> wrote:
> > Hi Rafael,
> >
> >
> > On Wed, May 8, 2013 at 6:04 PM, Rafael Antognolli
> > wrote:
> >>
> >> He
t make things simpler? Well, there are all sorts of interesting
use-cases out there:
1. Let's say that everyone has PS4 controllers with a keyboard attachment.
Now, we 4 gamepads, 5 mice, and 5 keyboards (one mouse and keyboard from
the desktop setup). However, you probably don&#
On Wed, May 15, 2013 at 9:39 AM, Mikko Levonmaa wrote:
> This allows the shell to inform the surface that it has changed
> state, current supported states are default, minimized, maximized
> and fullscreen. The shell implementation is free to interpret the
> meaning for the state, i.e. the minimiz
On Wed, May 15, 2013 at 1:37 PM, Mikko Levonmaa wrote:
> On Wed, May 15, 2013 at 12:12:43PM -0500, Jason Ekstrand wrote:
> > On Wed, May 15, 2013 at 9:39 AM, Mikko Levonmaa <
> mikko.levon...@gmail.com>
> > wrote:
> >
> > This allows the shell to in
what is
meant by "sticky"?) wouldn't really have anything to do with maximize or
minimize at all. Some flags may just be hints to the compositor or window.
Another example of this would be a "tiled" flag for tiling WM's.
> > ...
> >
> >
&
301 - 400 of 743 matches
Mail list logo
