On Thu, Oct 1, 2015 at 1:59 PM, Carlos Garnacho wrote:
> On Thu, Oct 1, 2015 at 9:47 PM, Bill Spitzak wrote:
> > I really do not like the idea that the compositor is responsible for
> > matching up modifiers with actions.
> >
> > Still trying to figure out why the destination cannot pick one of
On Thu, Oct 1, 2015 at 6:49 PM, Jonas Ådahl wrote:
>
> I think that if we want to make it possible to change the relative
> position of a popup/tooltip/popover in response to the parent surface
> moving (like keeping a popover inside the visible area) we really should
> use the second approach. I
On Fri, Oct 2, 2015 at 6:32 AM, Manuel Bachmann
wrote:
>
> * Daniels, I totally agree with you that "raise()" is a bad choice of
> wording, it offers false expectations, and we agreed with Jasper that
> present() is a lot better (plus, it resembles a "present()" function
> present in popular tool
On 23 September 2015 at 23:35, Olivier Fourdan wrote:
> bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92076
> Signed-off-by: Olivier Fourdan
Seems sane,
Reviewed-by: Dave Airlie
> ---
> hw/xwayland/xwayland-output.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
>
On Fri, Oct 02, 2015 at 03:48:33PM +0300, Pekka Paalanen wrote:
> On Fri, 2 Oct 2015 12:53:13 +0100
> Auke Booij wrote:
>
> > On 1 October 2015 at 20:00, Nils Chr. Brause
> > wrote:
>
> > > I would prefer, if the enum attributes would also name the interface,
> > > where the enum can be found,
On Fri, Oct 02, 2015 at 01:42:03PM -0700, Bryce Harrington wrote:
> On Fri, Oct 02, 2015 at 05:32:59PM +0800, Jonas Ådahl wrote:
> > Instead of doing things that do the equivalent of using
> > wl_display_prepare_read() and friends, just use the public API. The
> > only semantical difference is that
On Fri, Oct 02, 2015 at 05:32:59PM +0800, Jonas Ådahl wrote:
> Instead of doing things that do the equivalent of using
> wl_display_prepare_read() and friends, just use the public API. The
> only semantical difference is that we will now unlock and lock the mutex
> more times compared to before.
>
On Fri, Oct 02, 2015 at 05:32:58PM +0800, Jonas Ådahl wrote:
> There was documentation about how to integrate the display server file
> descriptor in the documentation about wl_display_dispatch_pending().
> This is not the right place to put it, and it also had incorrect usage
> of the API (calling
On Fri, Oct 02, 2015 at 05:32:56PM +0800, Jonas Ådahl wrote:
> Change the wording a bit to describe how it is done (which explains to
> the name of the function) as well as a note about that we actually will
> dispatch events that are received.
>
> Signed-off-by: Jonas Ådahl
Reviewed-by: Bryce Ha
On Fri, Oct 02, 2015 at 05:32:54PM +0800, Jonas Ådahl wrote:
> Blocking in general is not what means it is required to flush, but
> blocking on input from the wl_display file descriptor.
>
> Signed-off-by: Jonas Ådahl
Reviewed-by: Bryce Harrington
> ---
> src/wayland-client.c | 8
> 1
On Fri, Oct 02, 2015 at 05:32:53PM +0800, Jonas Ådahl wrote:
> Some rewording to improve grammar a bit with some additions about the
> type expectations of va_list arguments.
>
> Signed-off-by: Jonas Ådahl
Reviewed-by: Bryce Harrington
> ---
> src/wayland-client.c | 12 +++-
> 1 file c
On Fri, Oct 02, 2015 at 05:32:52PM +0800, Jonas Ådahl wrote:
> Signed-off-by: Jonas Ådahl
Reviewed-by: Bryce Harrington
> ---
> src/wayland-client.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/wayland-client.c b/src/wayland-client.c
> index d5a3bb4..e4b659e 1006
On Fri, Oct 02, 2015 at 05:32:55PM +0800, Jonas Ådahl wrote:
> In the documentation we refer to "an event queue" in various places and
> from the beginning it is unclear what event queue this means. So,
> instead of having a paragraph in the end mentioning this, move the
> detailed documentation to
On 2 October 2015 at 14:49, Victor Berger wrote:
> Le 2015-10-02 15:16, Pekka Paalanen a écrit :
>>
>> On Fri, 2 Oct 2015 13:50:42 +0100
>> Auke Booij wrote:
>>>
>>>
>>> [start]
>>> The enum and bitfield attributes are in principle for documentation
>>> purposes only. The enum and bitfield attrib
On Fri, 02 Oct 2015 15:49:15 +0200
Victor Berger wrote:
> Le 2015-10-02 15:16, Pekka Paalanen a écrit :
> > On Fri, 2 Oct 2015 13:50:42 +0100
> > Auke Booij wrote:
> >>
> >> [start]
> >> The enum and bitfield attributes are in principle for documentation
> >> purposes only. The enum and bitfiel
Le 2015-10-02 15:16, Pekka Paalanen a écrit :
On Fri, 2 Oct 2015 13:50:42 +0100
Auke Booij wrote:
[start]
The enum and bitfield attributes are in principle for documentation
purposes only. The enum and bitfield attributes may also be used by
bindings, but only in such a way that code written p
On Thu, 2015-10-01 at 21:36 +0200, Carlos Garnacho wrote:
> But this is a very valid concern, if you preemptively accept() with a
> random mimetype, the user quickly finishes the drag before transfers
> are done, and it isn't accepted in the end, you'd get the wrong
> feedback, and the wrong outcom
Hi Jonas, Daniel, Derek, Bill,
My apologizes for the late answer, I initiallty wanted to come back Monday
with a new test case, and missed some answers.
* Jonas, good point, I forgot to bump the protocol here. I really think it
fits into xdg-shell ; what are you thinking of when you are referring
On Fri, 2 Oct 2015 13:50:42 +0100
Auke Booij wrote:
> Maybe a solution can be found in more languages, and we can make the
> compatibility, that e.g. Pekka is looking for, a requirement for
> bindings, rather than make compatibility a requirement for the
> protocol writers. So something along the
On Fri, 02 Oct 2015 14:43:57 +0200
Victor Berger wrote:
> Le 2015-10-02 14:12, Auke Booij a écrit :
> > However, I'm not sure who you are trying to protect here. Everyone
> > agrees that the new attributes should not change anything for C/C++,
> > and in the current patches, they don't. And the o
Le 2015-10-02 14:12, Auke Booij a écrit :
However, I'm not sure who you are trying to protect here. Everyone
agrees that the new attributes should not change anything for C/C++,
and in the current patches, they don't. And the other bindings writers
understand the compatibility issues regarding th
On 2 October 2015 at 13:12, Auke Booij wrote:
> The wayland protocol currently does not specify the enum attribute,
> and I see no way how to write an API whose entire purpose is to
> *break* when you erroneously mix up enum attribute data, without
> breaking API as this data is added.
Actually,
On Fri, 2 Oct 2015 12:53:13 +0100
Auke Booij wrote:
> On 1 October 2015 at 20:00, Nils Chr. Brause wrote:
> > I would prefer, if the enum attributes would also name the interface,
> > where the enum can be found, e.g.:
> >
> > If two enums in different interfaces happen to have the same na
Le 02/10/2015 03:13, Bryce Harrington a écrit :
> Addresses this error reported by Denis Denisov:
>
> [src/scanner.c:1415]: (error) Resource leak: input
>
> Signed-off-by: Bryce Harrington
>
> v2: Also close input for other exit points in main.
> Signed-off-by: Bryce Harrington
Reviewed-by:
This version takes in account last Jonas Ådahl's remarks.
David FORT (1):
wayland: add a release request on wl_seat
protocol/wayland.xml | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
--
1.9.1
___
wayland-devel mailing list
way
This is required if we want to correctly remove a wl_seat compositor-side. A
wl_seat is announced as a global object, then it is bound by the client. When
the compositor wants to remove the seat, it shall announce the global removal of
the object. The client can then call the release request on the
On 2 October 2015 at 12:31, Pekka Paalanen wrote:
>> I know that several people have proposed patches on this - Bill, Nils
>> and Auke at least. Since there's a definite need for this, and since
>> agreement appears to be not far off, I would like to get this landed
>> this release. And ideally
On 1 October 2015 at 20:00, Nils Chr. Brause wrote:
>> Since Auke's patchset proposalis the most recent, let's take that one as
>> the candidate for landing. Gentlemen, I'd like to ask you to review
>> these three patches [5,6,7] and either give your Reviewed-by's or flag
>> specific improvements
Thanks for bringing this up again, Bryce.
On 1 October 2015 at 18:59, Jasper St. Pierre wrote:
> We have a few constraints. First off, not all enums are closed. Some
> are intentionally open, like xdg_shell.state. So we definitely need a
> distinction between a closed enum and an open enum. I'm n
Hi all,
let's add Jeroen, Jason, Boyan to CC.
The fundamental requirement here is that we must not break existing
code or users. All arguments I have can be traced back to this simple
statement.
First, I would rather keep the wl_array discussion in a separate thread
and not mix it up here. What
On Fri, 25 Sep 2015 12:43:55 +0200
Victor Berger wrote:
> On 2015-09-25 12:25, Nils Chr. Brause wrote :
> > Hi,
> >
> > On Fri, Sep 25, 2015 at 10:52 AM, Victor Berger
> > wrote:
> >> The questions about how breaking evolutions will be handled need to be
> >> specified as well: how should an o
Hi all,
Any chance to get a review of this patch?
Cheers,
Olivier
- Original Message -
> As mentioned in https://bugs.freedesktop.org/show_bug.cgi?id=92076#c5
>
> Tested-by: Artem Chudinov
>
> Cheers,
> Olivier
> ___
> xorg-de...@lists.x.org
On Fri, 25 Sep 2015 12:25:51 +0200
"Nils Chr. Brause" wrote:
> Hi,
>
> On Fri, Sep 25, 2015 at 10:52 AM, Victor Berger
> wrote:
> >
> > What I meant here is that the format and contents of the XML files is
> > currently defined by the implementation of the C scanner, which is a less
> > than op
Signed-off-by: Jonas Ådahl
---
src/wayland-client.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/wayland-client.c b/src/wayland-client.c
index d5a3bb4..e4b659e 100644
--- a/src/wayland-client.c
+++ b/src/wayland-client.c
@@ -158,7 +158,7 @@ display_fatal_error(struct wl
Instead of doing things that do the equivalent of using
wl_display_prepare_read() and friends, just use the public API. The
only semantical difference is that we will now unlock and lock the mutex
more times compared to before.
Signed-off-by: Jonas Ådahl
---
There is no real need to merge this p
In the documentation we refer to "an event queue" in various places and
from the beginning it is unclear what event queue this means. So,
instead of having a paragraph in the end mentioning this, move the
detailed documentation to the function with the queue explicitly passed.
Signed-off-by: Jonas
Blocking in general is not what means it is required to flush, but
blocking on input from the wl_display file descriptor.
Signed-off-by: Jonas Ådahl
---
src/wayland-client.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/wayland-client.c b/src/wayland-client.c
in
There was documentation about how to integrate the display server file
descriptor in the documentation about wl_display_dispatch_pending().
This is not the right place to put it, and it also had incorrect usage
of the API (calling wl_display_dispatch_queue() on input on an unrelated
fd) as an examp
The current documentation about wl_display_dispatch() states one may not
mix wl_display_dispatch(_queue)() with wl_display_prepare_read() and
friends, but this is a misconception about how
wl_display_dispatch(_queue)() works. The fact is that the dispatch
functions does the equivalent of what the p
Change the wording a bit to describe how it is done (which explains to
the name of the function) as well as a note about that we actually will
dispatch events that are received.
Signed-off-by: Jonas Ådahl
---
src/wayland-client.c | 16
1 file changed, 12 insertions(+), 4 deletio
Some rewording to improve grammar a bit with some additions about the
type expectations of va_list arguments.
Signed-off-by: Jonas Ådahl
---
src/wayland-client.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/src/wayland-client.c b/src/wayland-client.c
index e4b
On Thu, 1 Oct 2015 18:13:29 -0700
Bryce Harrington wrote:
> Addresses this error reported by Denis Denisov:
>
> [src/scanner.c:1415]: (error) Resource leak: input
>
> Signed-off-by: Bryce Harrington
>
> v2: Also close input for other exit points in main.
> Signed-off-by: Bryce Harrington
On Thu, 01 Oct 2015 17:03:47 +0200
Robert Folland wrote:
> The monitor/camera input receiving the signal is providing a list of
> resolutions in its EDID data, and I guess one is preferred as a
> native resolution. But as long as there are more entries in that EDID
> list, would it not be a good
43 matches
Mail list logo
