Hi all,
It's been quite some time since our last weston release, and there's
been some discussion of getting the next one out in the January to March
timeframe (this would be the last release to have an autotools build, btw).
Does anyone have objections to an early February freeze and a March
Am 18.01.19 um 09:08 schrieb Graeme Gill:> Maybe rendering specifically
for one output is sufficient
> as long as the secondary displays (however that is determined!) look
> OK with a fallback conversion by the compositor.
Currently the first or main monitor is the primary rendering target. As
On Fri, Jan 18, 2019 at 11:53:07AM +0200, Pekka Paalanen wrote:
> On Tue, 12 Dec 2017 23:10:18 +0200
> Marius Vlad wrote:
>
> > This is particularly useful when cross-compiling and we need to specify a
> > custom
> > datadir path for wayland-protocols. Cross-compilation toolchain is usually
> >
On Tue, 12 Dec 2017 23:10:18 +0200
Marius Vlad wrote:
> This is particularly useful when cross-compiling and we need to specify a
> custom
> datadir path for wayland-protocols. Cross-compilation toolchain is usually
> immutable, and in this way we can modify wayland-protocols independently from
On Mon, 7 Jan 2019 17:19:20 -0800
Lloyd Pique wrote:
> Hi Pekka,
>
> I did upload a new set of patches back in September:
>
> https://patchwork.freedesktop.org/patch/247841/
> https://patchwork.freedesktop.org/patch/247842/
> https://patchwork.freedesktop.org/patch/247843/
>
> I understand
Sharma, Shashank wrote:
Hi,
> Yes, this is very accurate. We are planning to add a protocol extension,
> which will allow
> a client to pass the buffers colorspace information to the compositor. And
> compositor
> already has HW's color capabilities (drm properties per plane and CRTC), and
>
Adam Jackson wrote:
Hi,
> This isn't necessarily true. The server is free to just draw a black
> rectangle (or nothing) instead if the image doesn't match the target
> colorspace. If you want to handle the case of cloned outputs or
> crossing output borders, let the client attach one image per
Pekka Paalanen wrote:
Hi,
> If a wl_surface straddles multiple outputs simultaneously, then
> wl_surface.enter/leave events indicate the surface being on all those
> outputs at the same time. The client is expected to take all the
> entered outputs into consideration when it chooses how to
