Done.
Kristian
On Mon, Mar 25, 2013 at 6:34 PM, Dave Airlie wrote:
> On Tue, Mar 26, 2013 at 8:10 AM, Scott Moreau wrote:
>> I wanted to make it public, that I have been officially banned from
>> #wayland on irc.frenode.net by krh. I have never seen him ban anyone
>> from his channel and I do n
On Mon, Mar 25, 2013 at 4:34 PM, Dave Airlie wrote:
> On Tue, Mar 26, 2013 at 8:10 AM, Scott Moreau wrote:
>> I wanted to make it public, that I have been officially banned from
>> #wayland on irc.frenode.net by krh. I have never seen him ban anyone
>> from his channel and I do not believe he has
On Tue, Mar 26, 2013 at 8:10 AM, Scott Moreau wrote:
> I wanted to make it public, that I have been officially banned from
> #wayland on irc.frenode.net by krh. I have never seen him ban anyone
> from his channel and I do not believe he has any intention of lifting
> the ban.
> This goes to show,
On 03/25/2013 04:28 PM, Pekka Paalanen wrote:
You only need the Weston fork, just use libwayland from upstream.
noupe. Scott actually just needs to fork desktop plugin or maybe not
even that, just to create a new desktop client for starting his . I've
created two examples of repository here
I wanted to make it public, that I have been officially banned from
#wayland on irc.frenode.net by krh. I have never seen him ban anyone
from his channel and I do not believe he has any intention of lifting
the ban.
This goes to show, that my efforts are in fact completely unwelcome by
Kristian. I
On segunda-feira, 25 de março de 2013 15.12.47, Scott Moreau wrote:
> > Try to do your changes in a different extension. Copy the current wl_shell
> > into a new one and modify it to your heart's desire. If, at the end of
> > your experiment, you conclude that the current wl_shell is flawed by
> >
On Mon, Mar 25, 2013 at 3:08 PM, Thiago Macieira
wrote:
> On segunda-feira, 25 de março de 2013 14.45.21, Scott Moreau wrote:
>> Northfield stands on the shoulders of giants, years worth of work and
>> history to get to the point where we are today. It has been some 8
>> years since compiz has exp
This patch implements a popup stack. When the first popup is opened
the grab is started, and it is added to a list. Further popups will
be added to this list but the grab won't change. When a popup is
closed it is removed from the list and, if it is now empty, the grab
is ended.
A click outside the
On segunda-feira, 25 de março de 2013 14.45.21, Scott Moreau wrote:
> Northfield stands on the shoulders of giants, years worth of work and
> history to get to the point where we are today. It has been some 8
> years since compiz has exposed these many restrictions found in X
> protocol. We want ce
On 25.03.2013 21:33, Thiago Macieira wrote:
> On segunda-feira, 25 de março de 2013 19.49.32, Uli Schlachter wrote:
>> So wl_display_acquire_fd() would do:
>>
>> if (old_state == VOLUNTEER_READER) {
>> write(display->reader_pipe[1], &c, 1);
>> pthread_cond_wait(&display->pipe_co
Hi Casey,
On Mon, Mar 25, 2013 at 2:28 PM, Casey Dahlin wrote:
> On Mon, Mar 25, 2013 at 02:14:23PM -0600, Scott Moreau wrote:
>> Sorry, I misspoke here. What I meant was, "This isn't about the
>> wayland core protocol, the core wayland developers have this part
>> covered. This is about raising
On segunda-feira, 25 de março de 2013 19.49.32, Uli Schlachter wrote:
> So wl_display_acquire_fd() would do:
>
> if (old_state == VOLUNTEER_READER) {
> write(display->reader_pipe[1], &c, 1);
> pthread_cond_wait(&display->pipe_cond, &display->mutex);
> read(display->reade
On Mon, Mar 25, 2013 at 02:14:23PM -0600, Scott Moreau wrote:
> Sorry, I misspoke here. What I meant was, "This isn't about the
> wayland core protocol, the core wayland developers have this part
> covered. This is about raising the bar on the effects users expect to
> see in a wayland compositor a
>
> Casey: The point is, this isn't just a frivolous fork. This isn't
> about wayland.
Sorry, I misspoke here. What I meant was, "This isn't about the
wayland core protocol, the core wayland developers have this part
covered. This is about raising the bar on the effects users expect to
see in a wa
On segunda-feira, 25 de março de 2013 13.42.31, Kristian Høgsberg wrote:
> which returns the display fd and blocks any thread trying to read from
> the fd. Calling wl_display_dispatch() will read events, release the fd
> and the dispatch events. Alternatively, if after acquiring and polling
> th
On Mon, Mar 25, 2013 at 1:11 PM, Casey Dahlin wrote:
> On Mon, Mar 25, 2013 at 12:59:22PM -0600, Scott Moreau wrote:
>> Hi Casey,
>>
>> On Mon, Mar 25, 2013 at 12:53 PM, Casey Dahlin wrote:
>> > On Mon, Mar 25, 2013 at 12:51:07PM -0600, Scott Moreau wrote:
>> >> Yes, there is no reason to fork li
On Mon, 25 Mar 2013 12:51:07 -0600
Scott Moreau wrote:
> Hey Casey,
>
> On Mon, Mar 25, 2013 at 12:46 PM, Casey Dahlin wrote:
> > On Mon, Mar 25, 2013 at 12:41:59PM -0600, Scott Moreau wrote:
> >> "The key point to understand is, that this is not a new protocol in its
> >> own right. It *is* th
On Mon, Mar 25, 2013 at 12:59:22PM -0600, Scott Moreau wrote:
> Hi Casey,
>
> On Mon, Mar 25, 2013 at 12:53 PM, Casey Dahlin wrote:
> > On Mon, Mar 25, 2013 at 12:51:07PM -0600, Scott Moreau wrote:
> >> Yes, there is no reason to fork libwayland. And I don't feel this is a
> >> true fork, just a
Hi Casey,
On Mon, Mar 25, 2013 at 12:53 PM, Casey Dahlin wrote:
> On Mon, Mar 25, 2013 at 12:51:07PM -0600, Scott Moreau wrote:
>> Yes, there is no reason to fork libwayland. And I don't feel this is a
>> true fork, just a temporary rename to avoid the confusion it might
>> otherwise cause, remai
On Mon, Mar 25, 2013 at 12:51:07PM -0600, Scott Moreau wrote:
> Yes, there is no reason to fork libwayland. And I don't feel this is a
> true fork, just a temporary rename to avoid the confusion it might
> otherwise cause, remaining under the 'wayland' name. Wayland has been
> in my github repo sin
Hey Casey,
On Mon, Mar 25, 2013 at 12:46 PM, Casey Dahlin wrote:
> On Mon, Mar 25, 2013 at 12:41:59PM -0600, Scott Moreau wrote:
>> "The key point to understand is, that this is not a new protocol in its
>> own right. It *is* the wayland protocol, with a few minor additions
>> that make it possib
On 25.03.2013 18:42, Kristian Høgsberg wrote:
[...]
> @@ -847,45 +973,105 @@ dispatch_event(struct wl_display *display, struct
> wl_event_queue *queue)
> }
>
> static int
> -dispatch_queue(struct wl_display *display,
> -struct wl_event_queue *queue, int block)
> +read_events(struct
On Mon, Mar 25, 2013 at 12:41:59PM -0600, Scott Moreau wrote:
> "The key point to understand is, that this is not a new protocol in its
> own right. It *is* the wayland protocol, with a few minor additions
> that make it possible to do new interesting things."
Then don't fork the library.
"A few
Hi Casey,
On Mon, Mar 25, 2013 at 12:00 PM, Casey Dahlin wrote:
> On Mon, Mar 25, 2013 at 02:43:27AM -0600, Scott Moreau wrote:
>> What Northfield *is not*
>> - A fork that will change protocol in fundamental ways that diverts
>> from the wayland EGL spec
>> - A project that aims to cause divisio
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 think my email was pretty rambling and I sho
Jerome Glisse wrote:
The object that displays the window buffer could be a curved surface.
Imagine HUDs with a curved glass (in that case the effect is permanent
and no client should do sub pixel rendering)
Or consider fragment shaders applied to the window buffer. One cannot
apply fragement sh
On Mon, Mar 25, 2013 at 02:43:27AM -0600, Scott Moreau wrote:
> What Northfield *is not*
> - A fork that will change protocol in fundamental ways that diverts
> from the wayland EGL spec
> - A project that aims to cause divisions in the community or the Linux
> Desktop code
> - A project that break
2013/3/24 Pekka Paalanen :
> [...]
>> On DPI side i only proposed that client tell the compositor the DPI at
>> which it rendered its buffer so that compositor can upscale on high
>> dpi display.
>
> Exactly that is going to be a problem, since I expect rounding
> errors to produce nice 1-pixel gli
The current thread model assumes that the application or toolkit will have
a thread that either polls the display fd and dispatches events or just
dispatches in a loop. Only the main thread will read from the fd while
all other threads will block on a pthread condition and expect the main
thread t
On Sun, Mar 24, 2013 at 01:49:05PM +0100, Uli Schlachter wrote:
> Hi again,
>
> On 22.03.2013 02:29, Kristian Høgsberg wrote:
> > On Thu, Mar 21, 2013 at 05:13:47PM +0100, Uli Schlachter wrote:
> >> On 21.03.2013 15:20, Kristian Høgsberg wrote:
> [...]
> >>> + * Calling wl_display_lock_fd() ensure
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 think my email was pretty rambling and I should not have
sent it. Can try to say what I wanted in a *short* way:
On Fri, Mar 22, 2013 at 12:10 PM, U. Artie Eoff
wrote:
> From: "U. Artie Eoff"
>
> Fixes https://bugs.freedesktop.org/show_bug.cgi?id=61997
Ok, I see. I think it would be better to add a RELATIVE_MOTION flag
to notify_motion() so we don't have to duplicate the notify_motion
logic in notify_moti
Pekka Paalanen wrote:
I always tend to assume we do not communicate the matrix, since that
exposes the global or output coordinate system, and surface
positions.
The transform is between the 0,0,w,h rectangle that the client claims
the surface occupies and the contents of the buffer. It does
On Mon, 25 Mar 2013 16:38:01 +0100
Renaud Hébert wrote:
> On Fri, 22 Mar 2013 23:51:41 +0200, Pekka Paalanen
> wrote:
> >This introduces temporary glitches, which we work hard to eliminate.
> >Unless you mean window outline moves instead of window content?
> >
> >(Window outline resizes are actu
As you said in the other email thread, it seems that your end goal is
more related with desktop aesthetics and building a pretty DE. Thus core
compositor and protocol development is not the priority.
So in my opinion I'm not sure that forking Wayland/XWayland/Mesa or any
of the projects bein
On Fri, 22 Mar 2013 23:51:41 +0200, Pekka Paalanen
wrote:
>This introduces temporary glitches, which we work hard to eliminate.
>Unless you mean window outline moves instead of window content?
>
>(Window outline resizes are actually something I'd personally like
>to see, would make Weston on Raspb
> The original compiz implementation is written in C. At the very end of
> 2008, 12/24, Compiz++ was unveiled. Compiz++ was a C++ version of
> compiz that was intended to be more easily maintainable.
> Unfortunately, all of the plugins had to be ported. The majority of
> this work was done by an as
Ok, I admit it, you caught me. As much as I tried to say it isn't, it
is. GH Next was a preliminary code name for the patches housed on the
'next' branches of wayland/weston in github. However, it is now
officially a fork at the request of Kristian Høgsberg.
soreau: it's a fork
have the guts to
38 matches
Mail list logo
