Hi all,
I'm jumping back into the Wayland loop after more than a year. My first
port of call is once again building Wayland and Weston and getting some of
the sample clients running. About all I've done so far is install Weston
the quick and dirty (apt-get) way on Ubuntu and read through the build
On Friday 2016-12-02 19:28, Daniel Stone wrote:
>On 2 December 2016 at 18:25, Emil Velikov wrote:
>>
>> The above seems like a strange mix of build tools and (runtime)
>> dependencies.
>
>I was just trying to understand your 'distributions and/or builders
>simply cannot use python/similar tools w
On 2 December 2016 at 18:28, Daniel Stone wrote:
> Hey,
>
> On 2 December 2016 at 18:25, Emil Velikov wrote:
>> On 1 December 2016 at 15:24, Daniel Stone wrote:
>>> On 1 December 2016 at 14:11, Emil Velikov wrote:
This does not mitigate the fact that meson/ninja _does_ have some cool
Hey,
On 2 December 2016 at 18:25, Emil Velikov wrote:
> On 1 December 2016 at 15:24, Daniel Stone wrote:
>> On 1 December 2016 at 14:11, Emil Velikov wrote:
>>> This does not mitigate the fact that meson/ninja _does_ have some cool
>>> features and is noticeably faster _by default_.
>>> Yet the
On 1 December 2016 at 15:24, Daniel Stone wrote:
> Hey Emil,
>
> On 1 December 2016 at 14:11, Emil Velikov wrote:
>> On 1 December 2016 at 11:46, Daniel Stone wrote:
>>> On Intel, the configure stage (autogen / meson -Dfoo) is 14-15x
>>> faster. A complete build is 3x faster, and rebuilding comp
On 2 December 2016 at 14:55, Pekka Paalanen wrote:
> On Fri, 8 Jul 2016 11:29:16 +0100
> Emil Velikov wrote:
>
>> Hi all,
>>
>> Jumping the gun a bit, hope you'll forgive me :-)
>>
>> On 8 July 2016 at 09:17, Quentin Glidic
>> wrote:
>> > On 18/05/2016 14:55, Andrew Kosteltsev wrote:
>>
>> >> T
On Fri, 8 Jul 2016 11:24:15 +0200
Quentin Glidic wrote:
> On 08/07/2016 10:46, Andrew Kosteltsev wrote:
> > Hi Quentin.
> >
> > I see. My suggestion related to simplify the build process on developer
> > machines which doesn't have pre-installed native Wayland package. And
> > also I think it wou
On Fri, 8 Jul 2016 11:29:16 +0100
Emil Velikov wrote:
> Hi all,
>
> Jumping the gun a bit, hope you'll forgive me :-)
>
> On 8 July 2016 at 09:17, Quentin Glidic
> wrote:
> > On 18/05/2016 14:55, Andrew Kosteltsev wrote:
>
> >> Then the user can make use this cross-wayland-scanner in his S
On Mon, 4 Jul 2016 15:58:09 +0200
Quentin Glidic wrote:
> From: Quentin Glidic
>
> This way, we can share modules between libweston-based compositors, but
> they can only be loaded explicitely by the compositor.
>
> Signed-off-by: Quentin Glidic
Hi,
this seems like a fairly big step: we ar
On Mon, 11 Jul 2016 11:05:38 +0200
Giulio Camuffo wrote:
> 2016-07-04 15:58 GMT+02:00 Quentin Glidic :
> > From: Quentin Glidic
> >
> > Use different functions so we cannot load a libweston module in weston
> > or the other way around.
> >
> > Also properly namespace backend_init and use a diffe
Hi Nils,
On 19 November 2016 at 16:29, Niels Ole Salscheider
wrote:
> it has been some time since I proposed the first two RFCs for a color
> management protocol in weston. You can find the old discussions here:
>
> https://lists.freedesktop.org/archives/wayland-devel/2014-March/013951.html
> htt
Am Donnerstag, 1. Dezember 2016, 15:17:53 CET schrieb Graeme Gill:
> Niels Ole Salscheider wrote:
>
> Hi,
>
> > Then they use the "set_colorspace" request
> > to set the color space of their surface to the same color space in order
> > to
> > indicate that the compositor must not perform any addi
Hi,
On 2 December 2016 at 10:21, Pekka Paalanen wrote:
> this patch looks exactly where we would want to end up, but I wonder if
> this should be done more gradually to make things easier for users. How
> about something like:
>
> [...]
>
> We would also want to do this for backend loading to sim
On Mon, 4 Jul 2016 15:58:07 +0200
Quentin Glidic wrote:
> From: Quentin Glidic
>
> Signed-off-by: Quentin Glidic
> ---
> compositor/main.c | 25 +++--
> man/weston.ini.man | 7 +--
> man/weston.man | 7 +--
> tests/weston-tests-env | 7 ---
On Thu, 1 Dec 2016 17:19:41 -0600
Derek Foreman wrote:
> Check that all the objects in an event belong to the same client as
> the resource posting it. This prevents a compositor from accidentally
> mixing client objects and posting an event that causes a client to
> kill itself.
>
> It's inte
15 matches
Mail list logo