I can't get one thing out of this discussion.
So you are arguing about client side VS server side decorations,
handling of moves/resizes, maybe even buttons scroll bars etc.
But all wayland does is provide a communication channel that enables
"clients" to draw in the GPU memory, and then "composit
Here is the first version of the patch :)
Regards,
Iskren
On Mon, Apr 11, 2011 at 9:00 PM, Iskren Chernev wrote:
> I also thought of this, but I think in one unix packet more than one
> message can be stored, which makes skipping of a single message impossible
> without the number of f
I don't think this lengthy discussion led to any concrete answers, but I do
think that the questions are important and need such answers.
I'll try to summarize the problems that need attention:
1. screen locking
1.1 who is going to implement it: compositor/compositor plugin/app
1.2 inhibit locking
27;m probably missing something here, sorry if this is a stupid question. It
> sounds like the client is required to do something with every fd found in a
> message, whether they understood it or not, but that has to be wrong!
>
>
> Iskren Chernev wrote:
>
>> Hello,
>>
>
2011/4/11 Kristian Høgsberg
> On Sun, Apr 10, 2011 at 1:47 PM, Iskren Chernev
> wrote:
> > Hello,
> >
> > I think I can do the second point in the TODO file:
> >
> > The message format has to include information about number of fds
> > in the message
Hello,
I think I can do the second point in the TODO file:
The message format has to include information about number of fds
in the message so we can skip a message correctly. Or we should
just give up on trying to recover from unknown messages. We need
to make sure you never get a message from
from there.
>
> Kristian
>
> On Mar 13, 2011, at 4:26 PM, Iskren Chernev
> wrote:
>
> According to the epoll(7) man page, closing a file descriptor removes it
> from all epoll sets as long as it hasn't been copied (and other copies are
> not closed):
>
> Q6 Will cl
Are you sure you make && make install the wayland library first, and then
the demo? Also double check all environmental variables from the build
tutorial. You may also add
PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1
because on my system pkg-config just skipped some libraries.
Regards,
Iskren
On Sun, Mar 13,
ation about copied fs via dup* etc)
So maybe just closing the fds is the cleanest solution, given that only
library code can manage them and won't copy them.
Regards,
Iskren
On Sun, Mar 13, 2011 at 9:33 PM, Iskren Chernev wrote:
> Reply-To-All :)
>
>
> -- Forwarded mes
Reply-To-All :)
-- Forwarded message --
From: Iskren Chernev
Date: 2011/3/13
Subject: Re: minor fixes in event-loop.c
To: Kristian Høgsberg
I fixed the "close fd" ones, but its not perfect:
-- in what order should we do the epoll_ctl, close and free?
-- what shoul
Some patches for event-loop.c -- the signal & timer fds were never closed.
In the future do you prefer patches standalone or archived?
Regards,
Iskren
From 4313eca27b083b18dc01f127ca927fc0849fe0ee Mon Sep 17 00:00:00 2001
From: Iskren Chernev
Date: Sun, 13 Mar 2011 16:54:07 +0200
Sub
Well, with your patch it doesn't seem to crash. There is also no list
corruption, as far as I could test it :)
Regards,
Iskren
2011/3/13 Kristian Høgsberg
> On Fri, Mar 11, 2011 at 7:32 PM, Iskren Chernev
> wrote:
> > Hello,
> > I found a bug and fixed it with the pa
extend my explanation in the
previous email ;-)
Regards,
Iskren
On Sat, Mar 12, 2011 at 10:54 PM, Iskren Chernev
wrote:
> In my opinion the problem is this:
> The code to remove the element from the list is called every time, and the
> code to insert it is called only when 'surfac
In my opinion the problem is this:
The code to remove the element from the list is called every time, and the
code to insert it is called only when 'surface'. So in case surface is NULL
the item won't be added, but will be removed next time the function is
entered. Isn't that the case?
I don't hav
r it is free, and a double free is a
> bug.
>
> On 03/12/2011 07:01 AM, Iskren Chernev wrote:
> > Well, the actual problem is that something was removed twice. And I know
> where this place is, but I couldn't know if you would like to remove
> elements multiple times with
if an
element is already in a list or not. So if there is a way to know that, why
not make a check inside wl_list_remove, just to make sure.
I'll fix it the way you want it to be :)
Regards,
Iskren
On Sat, Mar 12, 2011 at 1:07 PM, Marty Jack wrote:
>
>
> On 03/11/2011 07:32 PM, I
L for example. Then if you
erase it again the list becomes corrupt. I nullified the prev/next and check
in the begining of wl_list_remove for not-in-list elements and just ignore
them. That seems to fix it.
Regards,
Iskren
From 15de592a8adb3007f813a278f00ddf4727f757f3 Mon Sep 17 00:00:00 2001
From
Ooops I didn't sent you the latest version of the final patch :)
On Fri, Mar 11, 2011 at 4:54 PM, Iskren Chernev wrote:
> Some resources were not freed if the create function exited earlier.
>
> I'm not sure how important these patches are. If they are I can make
> anoth
gards,
Iskren
From 57f2ef62b7c6c01a4aa1e6944812b97f0ec7b9b4 Mon Sep 17 00:00:00 2001
From: Iskren Chernev
Date: Fri, 11 Mar 2011 14:19:00 +0200
Subject: [PATCH 1/4] Better cleanup on display creation failure.
---
wayland/wayland-server.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
p 17 00:00:00 2001
From: Iskren Chernev
Date: Sun, 6 Mar 2011 20:48:51 +0200
Subject: [PATCH 2/2] Moved macros build at the top of libxkbcommon.
xproto depends on xorg/util/macros, so the macros should be intalled first.
---
building.html | 12 ++--
1 files changed, 6 insertions(+), 6
20 matches
Mail list logo
