I think it would be good to clarify that the "format" event is not sent
in this version? And maybe make it a protocol error to send a
format/modifier combination that wasn't advertised?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
ht
On Tue, Apr 16, 2019 at 11:54 AM Simon Ser wrote:
>
> On Tuesday, April 16, 2019 8:06 PM, Chia-I Wu wrote:
> > DRM_FORMAT_MOD_INVALID means to derive the modifier from the dmabuf.
> > It provides legacy support and makes it easier to replace wl_drm.
> >
> > Signed-off-by: Chia-I Wu
> > ---
> >
On Tue, 16 Apr 2019 at 17:03, Pekka Paalanen wrote:
>
> On Tue, 16 Apr 2019 13:33:02 +
> Erwin Burema wrote:
>
> > On Tuesday, 16 April 2019, Pekka Paalanen wrote:
> > > On Tue, 16 Apr 2019 13:11:06 +0200
> > > Erwin Burema wrote:
> > >
> > > > On Tue, 16 Apr 2019 at 12:45, Pekka Paalanen
DRM_FORMAT_MOD_INVALID means to derive the modifier from the dmabuf.
It provides legacy support and makes it easier to replace wl_drm.
v3: DRM_FORMAT_MOD_INVALID must be advertised to be supported (which
requires a version bump)
Signed-off-by: Chia-I Wu
---
.../linux-dmabuf/linux-dmabuf-uns
On Tuesday, April 16, 2019 8:06 PM, Chia-I Wu wrote:
> DRM_FORMAT_MOD_INVALID means to derive the modifier from the dmabuf.
> It provides legacy support and makes it easier to replace wl_drm.
>
> Signed-off-by: Chia-I Wu
> ---
> .../linux-dmabuf/linux-dmabuf-unstable-v1.xml| 16 +
> On Apr 16, 2019, at 05:24, Pekka Paalanen wrote:
>
> Right, but is that an inherent problem in RDP (e.g. being difficult to
> implement), is FreeRDP library not good enough, or is it just the
> Weston backend being not good enough?
It's a quite superficial judgement at this point. Only based
DRM_FORMAT_MOD_INVALID means to derive the modifier from the dmabuf.
It provides legacy support and makes it easier to replace wl_drm.
Signed-off-by: Chia-I Wu
---
.../linux-dmabuf/linux-dmabuf-unstable-v1.xml| 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git
On Tue, Apr 16, 2019 at 2:52 AM Pekka Paalanen wrote:
>
> On Fri, 12 Apr 2019 10:50:49 -0700
> Chia-I Wu wrote:
>
> > Moving the discussion to this patch...
> >
> > This patch clarifies how implicit modifier can be supported, modelling
> > after Weston's behavior. I can see three options
> >
> >
Hello,
Simon Ser, le lun. 15 avril 2019 19:23:51 +, a ecrit:
> On Wednesday, April 3, 2019 4:00 PM, Samuel Thibault
> wrote:
> > Olivier Fourdan, le mer. 03 avril 2019 14:39:29 +0200, a ecrit:
> > > > What we currently have in Wayland is support for AccessX, directly
> > > > implemented in m
On Tue, 16 Apr 2019 13:33:02 +
Erwin Burema wrote:
> On Tuesday, 16 April 2019, Pekka Paalanen wrote:
> > On Tue, 16 Apr 2019 13:11:06 +0200
> > Erwin Burema wrote:
> >
> > > On Tue, 16 Apr 2019 at 12:45, Pekka Paalanen wrote:
> > >
> > > >
> > > > On Sun, 14 Apr 2019 12:57:47 +0200
>
The turnout for the first election and the vote on the bylaw changes was 80%
(56/70).
Harry
On 2019-04-11 8:03 p.m., Harry Wentland wrote:
> To all X.Org Foundation Members:
>
> The 2019 X.Org ballot closed yesterday. There is some good and some bad news.
>
> The Good News:
> The vote on the b
To all X.Org Foundation Members:
as per my last email the election for X.Org board members was invalid due to a
bug with the voting systems. We apologize for this and the inconvenience caused
to you all. The bug has been fixed and tested with a mock election (see results
at the end).
Round 2 o
On Tuesday, 16 April 2019, Pekka Paalanen wrote:
> On Tue, 16 Apr 2019 13:11:06 +0200
> Erwin Burema wrote:
>
> > On Tue, 16 Apr 2019 at 12:45, Pekka Paalanen wrote:
> > >
> > > On Sun, 14 Apr 2019 12:57:47 +0200
> > > Erwin Burema wrote:
> > >
> > > > Without a way to calibrate/profile scr
On Tue, 16 Apr 2019 15:35:45 +0300
Pekka Paalanen wrote:
> On Tue, 16 Apr 2019 13:14:58 +0200
> Erwin Burema wrote:
>
> > On Tue, 16 Apr 2019 at 12:51, Pekka Paalanen wrote:
> > >
> > > On Sun, 14 Apr 2019 12:57:48 +0200
> > > Erwin Burema wrote:
> > >
> > > > ---
> > > > .../cm_waylan
On Tue, 16 Apr 2019 13:14:58 +0200
Erwin Burema wrote:
> On Tue, 16 Apr 2019 at 12:51, Pekka Paalanen wrote:
> >
> > On Sun, 14 Apr 2019 12:57:48 +0200
> > Erwin Burema wrote:
> >
> > > ---
> > > .../cm_wayland_calibration.xml| 106 ++
> > > 1 file changed, 10
On Tue, 16 Apr 2019 13:11:06 +0200
Erwin Burema wrote:
> On Tue, 16 Apr 2019 at 12:45, Pekka Paalanen wrote:
> >
> > On Sun, 14 Apr 2019 12:57:47 +0200
> > Erwin Burema wrote:
> >
> > > Without a way to calibrate/profile screens an color management
> > > protocol looses a lot of its value. So
On 2019-04-16 12:45, Pekka Paalanen wrote:
On Sun, 14 Apr 2019 12:57:47 +0200
Erwin Burema wrote:
Without a way to calibrate/profile screens an color management
protocol looses a lot of its value. So to add this missing feature I
wrote the following protocol.
The idea is that the calibration/
> > Btw. how would a compositor know the bit depth of a monitor and the
> > transport (wire)? I presume there should be some KMS properties for
> > that in addition to connector types.
>
> Huh, this surprises me a bit would have expected KMS to know something
> about the screens attached and which
On Tue, 16 Apr 2019 at 12:51, Pekka Paalanen wrote:
>
> On Sun, 14 Apr 2019 12:57:48 +0200
> Erwin Burema wrote:
>
> > ---
> > .../cm_wayland_calibration.xml| 106 ++
> > 1 file changed, 106 insertions(+)
> > create mode 100644
> > unstable/color-manager-calibra
On Tue, 16 Apr 2019 at 12:45, Pekka Paalanen wrote:
>
> On Sun, 14 Apr 2019 12:57:47 +0200
> Erwin Burema wrote:
>
> > Without a way to calibrate/profile screens an color management
> > protocol looses a lot of its value. So to add this missing feature I
> > wrote the following protocol.
> >
> >
On Sun, 14 Apr 2019 12:57:48 +0200
Erwin Burema wrote:
> ---
> .../cm_wayland_calibration.xml| 106 ++
> 1 file changed, 106 insertions(+)
> create mode 100644
> unstable/color-manager-calibration/cm_wayland_calibration.xml
>
> diff --git a/unstable/color-manag
On Sun, 14 Apr 2019 12:57:47 +0200
Erwin Burema wrote:
> Without a way to calibrate/profile screens an color management
> protocol looses a lot of its value. So to add this missing feature I
> wrote the following protocol.
>
> The idea is that the calibration/profiling SW only sets the RGB
> tri
On Fri, 12 Apr 2019 10:50:49 -0700
Chia-I Wu wrote:
> Moving the discussion to this patch...
>
> This patch clarifies how implicit modifier can be supported, modelling
> after Weston's behavior. I can see three options
>
> 1. DRM_FORMAT_MOD_INVALID means implicit modifier, and is always allow
On Fri, 12 Apr 2019 12:12:06 -0400
Jean-Francois Dagenais wrote:
> > On Apr 12, 2019, at 09:48, Pekka Paalanen wrote:
> >
> > Hi,
> >
> > I believe Mali is the prorietary GPU driver (and a chip family?), so
> > something that implements OpenGL.
>
> Yes, there is an ARM made glue kernel modu
On Tue, 16 Apr 2019 at 08:42, Sebastian Wick
wrote:
>
> On 2019-04-15 23:38, Erwin Burema wrote:
> > On Mon, 15 Apr 2019 at 20:30, Sebastian Wick
> > wrote:
> >>
> >> On 2019-04-14 12:57, Erwin Burema wrote:
> >> > Without a way to calibrate/profile screens an color management
> >> > protocol loo
25 matches
Mail list logo
