Daniel Stone wrote:
OK, so what's the point of focus in and out events, if they can be
sent randomly and in fact provide no indication of whether or not
focus is there?
I think I'm still failing to explain this.
The events are not "random". Focus-in events only go to the surface that
has foc
Hi,
On 27 September 2013 17:00, Bill Spitzak wrote:
> Daniel Stone wrote:
>> Yes. If your starting point is that the thing directing your input
>> events and focus shouldn't have to know where to direct its input
>> events or focus, then we disagree on something I consider axiomatic.
>
> I think
2013/9/26 Jason Ekstrand :
[snip]
>> > I'm not a Wayland developer, so I can't say with confidence. But I think
>> > this choice is deferred to the toolkit layer. In this case both
>> > behaviors (server of client side decorations) are potentially useful, so
>> > the protocol shouldn't *require*
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/27/2013 05:02 PM, Bill Spitzak wrote:
> I think it is confusing to call this an "array", rather than
> perhaps a "block" or something.
>
> When I read the documentation I thought the array consisted of N
> pieces of data in wire format, not N by
I think it is confusing to call this an "array", rather than perhaps a
"block" or something.
When I read the documentation I thought the array consisted of N pieces
of data in wire format, not N bytes.
Micah Nordland wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Addition to the wire
Daniel Stone wrote:
Clients should just be
prepared for excess up and down events, and excess focus in/out. Avoiding
them becomes nearly impossible as you are probably noticing, and pretty much
means the compositor must maintain the state of *EVERY* button for *EVERY*
client.
Yes. If your s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Addition to the wire format specification array type definition to say
that array contents are defined by whatever is using the array.
diff --git a/doc/publican/sources/Protocol.xml
b/doc/publican/sources/Protocol.xml
index b79b6be..039d875 100644
- -
Hi,
On 24 September 2013 15:05, Bill Spitzak wrote:
> I really really think this idea should be changed.
With almost zero consideration to the downsides.
> Clients should just be
> prepared for excess up and down events, and excess focus in/out. Avoiding
> them becomes nearly impossible as you
Hi,
On 27 September 2013 03:30, Ran Benita wrote:
> On Thu, Sep 26, 2013 at 06:46:02PM -0500, Jason Ekstrand wrote:
>> Looking at weston's input.c, I am not seeing any evidence that it sends any
>> key events due to an enter. It does resend the modifiers, but that's
>> different. It doesn't mak
Hi,
On 27 September 2013 05:38, Neil Roberts wrote:
> Pekka Paalanen writes:
>> If not, is there not a possibility to break existing applications by
>> blocking too early?
>
> Yes, you're right, the patch is nonsense because it won't work when the
> application does wl_display_dispatch_pending b
Hi,
On 27 September 2013 08:31, Micah Nordland wrote:
> The wire format spec includes an array type:
> array
>
> Starts with 32-bit array size in bytes, followed by the array
> contents verbatim, and finally padding to a 32-bit boundary.
>
> What type are the contents? The protocol descriptio
From: Adrian Negreanu
Add drm_set_master and drm_drop_master
as wrappers for drm(Set|Drop)Master, when building compositor-drm
or as empty functions otherwise.
Signed-off-by: Adrian Negreanu
---
src/launcher-util.c | 28
1 file changed, 24 insertions(+), 4 deleti
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The wire format spec includes an array type:
array
Starts with 32-bit array size in bytes, followed by the array
contents verbatim, and finally padding to a 32-bit boundary.
What type are the contents? The protocol description only uses the
array
Just had my coffe - I mean through suid - i chmod-ed +s the weston
executable.
I can't repro, I don't know what I did at that time.
On Fri, Sep 27, 2013 at 9:03 AM, Damian, Alexandru <
alexandru.dam...@intel.com> wrote:
> Launching weston directly through sudo. The seteuid failed for some reaso
Pekka Paalanen writes:
> If not, is there not a possibility to break existing applications by
> blocking too early?
Yes, you're right, the patch is nonsense because it won't work when the
application does wl_display_dispatch_pending because it might end up
with some events still in the queue but
On Thu, Sep 26, 2013 at 06:46:02PM -0500, Jason Ekstrand wrote:
> > On Thu, Sep 26, 2013 at 5:46 PM, Wander Lairson Costa
> > wrote:
> > > 2013/9/26 Ran Benita :
> > > But this is not the case for the key-replay behavior. There's nothing to
> > > be gained by letting different compositors do diff
You're right, I didn't check other usages.
Please dump this patch, it brings in way more problems than it fixes - I
don't think that looking up in tons of directories a random user-specified
file name is very safe.
I'll resubmit only the relevant bits to prevent crashing if no config file.
Alex
Launching weston directly through sudo. The seteuid failed for some reason
- I didn't track it down - so I added the check.
Alex
On Thu, Sep 26, 2013 at 10:42 PM, Kristian Høgsberg wrote:
> On Wed, Sep 25, 2013 at 02:47:47PM +0100, Alex DAMIAN wrote:
> > From: Alexandru DAMIAN
> >
> > Checking
On Thu, 26 Sep 2013 16:59:13 +0200
Tomeu Vizoso wrote:
> Hi,
>
> somewhat related to the issue of posting vs. queuing buffer.release event
> is a condition I have found that starves idle handlers in window.c.
>
> If the SwapBuffers implementation waits for buffer.release events to make
> sure t
19 matches
Mail list logo
