Hi Drew,
Sorry for the long delay - has taken a while to catch up after
holidays. Thanks for pushing this forward though.
On Mon, 6 May 2019 at 01:41, Drew DeVault wrote:
> I chose not to change the wording of the xdg namespace definition,
> despite Daniel's objection. I couldn't come up with a
Hi,
On Mon, 24 Jun 2019 at 09:00, Jonas Ådahl wrote:
> On Fri, Jun 21, 2019 at 05:35:35PM -0700, Jasper St. Pierre wrote:
> > To be clear, the patch does break backwards compatibility with compositor
> > behavior -- it only weakens a guarantee by saying that transparent
> > fullscreen content is
e it come in
the same version bump, but with that and one small nitpick resolved
this is:
Acked-by: Daniel Stone
- xdg_output_manager.get_xdg_output). This event is only sent once per
+ xdg_output_manager.get_xdg_output) and whenever the description
+ changes. The description i
Hi,
On Fri, 21 Jun 2019 at 17:58, Linus Torvalds
wrote:
> On Thu, Jun 20, 2019 at 9:21 PM Dave Airlie wrote:
> >
> > Just catching up on the week since back from holidays, everything
> > seems quite sane.
>
> .. well, except for anongit.freedesktop.org itself, which seems very
> sick indeed.
>
Hi,
On Wed, 1 May 2019 at 09:53, Pekka Paalanen wrote:
> On Wed, 24 Apr 2019 10:07:47 -0700 Chia-I Wu wrote:
> > Can you commit this patch for me, if all looks good?
>
> I was almost already pushing this, but Daniel said he wants to have
> a good look first.
Indeed, I hadn't followed the
Hi Laurent,
On Tue, 23 Apr 2019 at 16:54, Laurent Pinchart
wrote:
> On Tue, Apr 23, 2019 at 09:59:37AM +0100, Daniel Stone wrote:
> > On Tue, 23 Apr 2019 at 08:26, Daniel Vetter wrote:
> > Totally. Let's take DRM_FORMAT_XRGB + I915_FORMAT_MOD_Y_TILED as
> > an
Hi,
On Tue, 23 Apr 2019 at 08:26, Daniel Vetter wrote:
> On Sun, Apr 21, 2019 at 01:59:04AM +0300, Laurent Pinchart wrote:
> > > > > - drm fourcc code doesn't actually define the drm_format_info
> > > > > uniquely, drivers can override that (that's an explicit design
> > > > > intent of
Hi,
On Wed, 13 Mar 2019 at 01:03, Drew DeVault wrote:
> On 2019-03-08 11:28 AM, Daniel Stone wrote:
> > Under what he's describing, xdg_shell isn't miscategorised, because it
> > _is_ the thing that everyone agrees on and uses. If we reserve xdg_*
> > for uncontrove
Hi Drew,
Thanks for writing this up! I think the broad concept is fine, but a
few things jump out at me:
On Fri, 5 Apr 2019 at 19:43, Drew DeVault wrote:
> I've written up a governance document for us to bikeshed, which is
> included at the end of this email. Some comments upfront.
>
>
Hi,
On Mon, 8 Apr 2019 at 11:02, Pekka Paalanen wrote:
> On Fri, 05 Apr 2019 18:01:45 + Simon Ser wrote:
> > Regarding the need for a new release manager for Wayland, I'd like to
> > step in and volunteer for this role. I'm willing to take the time
> > necessary to (1) learn the current
On Fri, 5 Apr 2019 at 14:52, Derek Foreman
wrote:
> I no longer have as much time to dedicate to this as I used to, so I
> think it would be best if someone else could take over managing the
> releases for Weston and Wayland.
Thanks for everything Derek! Really appreciate what you've done over
On Wed, 3 Apr 2019 at 16:12, Adam Jackson wrote:
> On Wed, 2019-04-03 at 09:23 +0200, Gerd Hoffmann wrote:
> > - Only DRM_FORMAT_RGB565 (depth 16) is supported. The old driver does
> >that too by default. There was a module parameter which enables 24/32
> >bpp support and disables
On Wed, 3 Apr 2019 at 16:12, Adam Jackson wrote:
> On Wed, 2019-04-03 at 09:23 +0200, Gerd Hoffmann wrote:
> > - Only DRM_FORMAT_RGB565 (depth 16) is supported. The old driver does
> >that too by default. There was a module parameter which enables 24/32
> >bpp support and disables
Hi,
On Tue, 2 Apr 2019 at 00:19, Rob Clark wrote:
> On Mon, Apr 1, 2019 at 1:55 PM Jean Hertel wrote:
> > As we have spoken already in the past, I have the intention to move
> > adriconf under the mesa project umbrella, as an official tool for
> > configuring DRI options.
> > I would like to
Hi,
On Fri, 29 Mar 2019 at 18:14, Eric Anholt wrote:
> Paul Kocialkowski writes:
> > I'm not totally convinced that it's okay to have a delay outside of
> > init/enumeration, even if it's a smaller delay.
>
> You'll have non-dumb buffers created during GL context creation, so
> early in xserver
Hi,
On Thu, 28 Mar 2019 at 18:53, Daniel Vetter wrote:
> On Thu, Mar 21, 2019 at 04:27:06PM +0100, Paul Kocialkowski wrote:
> > I don't see other options either, and using firstclose/lastopen feels
> > overall more readable in the driver code.
> >
> > I'm not sure there is such a big overhead
Hi,
On Mon, 3 Dec 2018 at 17:04, Philipp Zabel wrote:
> On Mon, 2018-12-03 at 10:46 -0600, Ryan Pavlik wrote:
> > Add two EDID vendor/product pairs used across a variety of
> > Sensics products, as well as the OSVR HDK and HDK 2.
> >
> > Signed-off-by: Ryan Pavlik
>
> Reviewed-by: Philipp Zabel
Hi Kevin,
On Wed, 13 Mar 2019 at 16:00, Kevin Brace wrote:
> I am not here to side with either one of you (i.e., Luc or you), but I have
> been wondering why some of the older, neglected (I use the word "underserved"
> to describe it) DDXs in general have weird git and ssh clone addresses.
>
d to do is the appropriate small tweaks
when we finalise things. I don't expect to have time to do this any
time soon; I can certainly help others through it if you have issues
or questions, but volunteers would be very much welcome.
On Fri, 22 Feb 2019 at 02:39, Drew DeVault wrote:
> On 2019-02-21 3:47
On Fri, 8 Mar 2019 at 10:52, Luc Verhaegen wrote:
> A quick look over other
> requests back then showed me that it usually took you many days, often
> weeks, to answer new project requests. But when _i_ asked, a not too
> supportive reply was quickly received.
I've snipped most of the misleading
On Fri, 8 Mar 2019 at 10:15, Luc Verhaegen wrote:
> On Fri, Mar 08, 2019 at 10:12:17AM +0900, Daniel Stone wrote:
> > I'll admit that somewhere between writing migration scripts, migrating
> > the other 1,268 repos from git.fd.o, maintaining our new and old
> > infrastru
On Fri, 8 Mar 2019 at 09:52, Luc Verhaegen wrote:
> On Fri, Mar 08, 2019 at 06:37:21AM +0900, Daniel Stone wrote:
> > FWIW, It was unique amongst all Xorg repos in that it didn't have a
> > .git suffix on the directory (i.e. its path was
> > /srv/git.freedesktop.org/git/x
On Fri, 8 Mar 2019 at 04:35, Adam Jackson wrote:
> On Wed, 2019-03-06 at 17:04 +0100, Luc Verhaegen wrote:
> > Is there a reason why, of _all_ drivers listed in
> >
> > https://cgit.freedesktop.org/xorg/driver
> >
> > the Radeonhd repository at
> >
> >
lit single large patch into multiple patches. This
> can
> +happen, for example, if when adding a new feature you notice a bug in
> Weston's
And again.
But the rest looks good to me and I'm thrilled to see it, so:
Reviewed-by: Daniel Stone
Cheers,
Daniel
__
Hi James,
On Fri, 22 Feb 2019 at 13:55, James Feeney wrote:
> On 2/21/19 12:10 PM, Simon Ser wrote:
> > Sorry, these comments feel a bit off-topic here. I'd appreciate if we
> > could stay focused. Thanks!
>
> And, what topic would that be, then, given that the subject of the thread is
>
Hi Thomas,
On Fri, 22 Feb 2019 at 13:18, Thomas Hellstrom wrote:
> I was trying to add Deepak Rawat as a member on the xf86-video-vmware
> project on fdo gitlab. Turns out I have only developer privileges
> there. Could someone please raise that to maintainer or owner?
Bouncing this over to
Hi,
On Tue, 19 Feb 2019 at 18:36, Drew DeVault wrote:
> On 2019-02-19 4:50 PM, Daniel Stone wrote:
> > - other clients: Chromium (client), Firefox, Mesa (EGL/Vulkan)
>
> This might start getting out of hand, I think. Here's an incomplete list
> of clients which
Hi all,
I'd like to open up a discussion on enlarging wayland-protocols to a
wider audience, with a better definition of what it contains.
Currently, wayland-protocols is a relatively small set of protocols
which were either grandfathered in from Weston, or a semi-opinionated
set of protocols
On Mon, 18 Feb 2019 at 10:13, Scott Anderson
wrote:
> On 18/02/19 11:02 pm, Daniel Stone wrote:
> > Doing this gets _really_ tricky as you start considering things like
> > synchronised subsurfaces (which always seems to be the case), since
> > you have to make sure
Hi,
On Fri, 25 Jan 2019 at 16:05, Derek Foreman
wrote:
> On 1/18/19 4:20 PM, Derek Foreman wrote:
> > Does anyone have objections to an early February freeze and a March
> > release? Anyone with large series near completion?
> >
> > Also, I'd like to float the idea of removing the fbdev backend
Hi,
On Mon, 18 Feb 2019 at 18:58, Eric Engestrom wrote:
> On Monday, 2019-02-18 17:31:41 +0000, Daniel Stone wrote:
> > Two hours of end-to-end pipeline time is also obviously far too long.
> > Amongst other things, it practically precludes pre-merge CI: by the
> > time yo
Hi all,
A few people have noted that Mesa's GitLab CI is just too slow, and
not usable in day-to-day development, which is a massive shame.
I looked into it a bit this morning, and also discussed it with Emil,
though nothing in this is speaking for him.
Taking one of the last runs as
ple apparently do use wl_output's
> refresh rate for synchronization purposes in Firefox [1]. I think it
> would be a good thing to make sure people are aware they should be using
> frame callbacks instead.
Thanks a lot for bumping this. Patch is:
Reviewed-by:
Hi Scott,
On Mon, 18 Feb 2019 at 03:27, Scott Anderson
wrote:
> In the Weston implementation, it's simply a case of the compositor
> getting the fence from the client, using eglWaitSyncKHR (or equivilent)
> on it, and passing back a release fence from OUT_FENCE_FD.
Yep, that's pretty much the
Hi,
On Sat, 16 Feb 2019 at 18:21, Josh Triplett wrote:
> On February 16, 2019 6:03:36 AM PST, Daniel Stone
> wrote:
> >In doing the move, I think it makes sense to move the XCB modules in
> >under the xorg/ tree. I've suggested a module map here:
> >https://gitlab.fre
Hi all,
As has been pretty well documented, I'd like to migrate XCB to GitLab
to join the rest of fd.o and X.Org (apart from the kernel and Mesa).
Whilst cgit/anongit would remain as mirrors, they would be read-only;
the sole push point would be GitLab. More details are here, but
essentially you
that you are replying to the original sender (in Reply-To) and not the
list itself.
Cheers,
Daniel
-- Forwarded message -
From: Daniel Stone
Date: Mon, 11 Feb 2019 at 23:38
Subject: PSA: Mailman changes, From addresses no longer accurate
To: ,
Hi all,
We have hit another step change
On Tue, 12 Feb 2019 at 09:46, Daniel Vetter wrote:
> fd.o had to switch to mangling From: addresses for a lot of domains.
> Catch them.
Thanks Daniel.
I'd cite this URL as well:
https://lists.freedesktop.org/archives/freedesktop/2019-February/000396.html
But this is:
Acked-by: Daniel
that you are replying to the original sender (in Reply-To) and not the
list itself.
Cheers,
Daniel
-- Forwarded message -
From: Daniel Stone
Date: Mon, 11 Feb 2019 at 23:38
Subject: PSA: Mailman changes, From addresses no longer accurate
To: ,
Hi all,
We have hit another step change
that you are replying to the original sender (in Reply-To) and not the
list itself.
Cheers,
Daniel
-- Forwarded message -
From: Daniel Stone
Date: Mon, 11 Feb 2019 at 23:38
Subject: PSA: Mailman changes, From addresses no longer accurate
To: ,
Hi all,
We have hit another step change
that you are replying to the original sender (in Reply-To) and not the
list itself.
Cheers,
Daniel
-- Forwarded message -
From: Daniel Stone
Date: Mon, 11 Feb 2019 at 23:38
Subject: PSA: Mailman changes, From addresses no longer accurate
To: ,
Hi all,
We have hit another step change
that you are replying to the original sender (in Reply-To) and not the
list itself.
Cheers,
Daniel
-- Forwarded message -
From: Daniel Stone
Date: Mon, 11 Feb 2019 at 23:38
Subject: PSA: Mailman changes, From addresses no longer accurate
To: ,
Hi all,
We have hit another step change
that you are replying to the original sender (in Reply-To) and not the
list itself.
Cheers,
Daniel
-- Forwarded message -
From: Daniel Stone
Date: Mon, 11 Feb 2019 at 23:38
Subject: PSA: Mailman changes, From addresses no longer accurate
To: ,
Hi all,
We have hit another step change
that you are replying to the original sender (in Reply-To) and not the
list itself.
Cheers,
Daniel
-- Forwarded message -
From: Daniel Stone
Date: Mon, 11 Feb 2019 at 23:38
Subject: PSA: Mailman changes, From addresses no longer accurate
To: ,
Hi all,
We have hit another step change
Hi Eric,
On Fri, 8 Feb 2019 at 15:03, Eric Engestrom wrote:
> Xserver has struct members named `bool`, which means the last commit
> breaks its build with errors like this:
>
> error: two or more data types in declaration specifiers
> Bool bool;
>^
>
> Fix this by making it return a
Hi,
On Fri, 20 Jul 2018 at 19:32, Eric Anholt wrote:
> Harish Krupo writes:
> > Thank you, understood it. I should have read the spec better :(.
> > Also, generalizing Android/deqp's usage seems to be wrong. Android's
> > deqp passed previously even when the driver wasn't restricting the
> >
On Thu, 7 Feb 2019 at 14:59, Eric Engestrom wrote:
> On Wednesday, 2019-02-06 18:36:09 +, Vinson Lee wrote:
> > ../src/gallium/drivers/freedreno/freedreno_resource.c: In function
> > ‘fd_resource_create_with_modifiers’:
> > ../src/gallium/drivers/freedreno/freedreno_resource.c:884:30: error:
Hi Harish,
On Wed, 23 Jan 2019 at 09:35, Pekka Paalanen wrote:
> On Wed, 23 Jan 2019 11:32:34 +0530 Harish Krupo
> wrote:
> > Proposal 1:
> > * Each of the shaders (gamma/degamma/main/tone mapping) would be
> > independent strings.
> > * When the view needs to be rendered, renderer will
Hi Emre,
On Sat, 19 Jan 2019 at 20:39, Ucan, Emre (ADITG/ESB)
wrote:
> I would like to push XDG shell support for ivi-shell:
> https://gitlab.freedesktop.org/wayland/weston/merge_requests/86
>
> It would be great if you and other maintainers can ack and/or review this
> merge request till
Hi Kevin,
On Mon, 28 Jan 2019 at 18:43, Kevin Strasser wrote:
> Set loader caps indicating that wayland can handle both rgba ordering and
> fp16 formats.
>
> NOTE: This requries libwayland to provide definitions for
> WL_SHM_FORMAT_XBGR16161616F and WL_SHM_FORMAT_ABGR16161616F
To be honest, we
ell.
>
> 4 and 5 are:
>
> Reviewed-by: Adam Jackson
And they are also:
Reviewed-by: Daniel Stone
Thanks for chasing this up!
Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
e-time. So, in include/uapi there shouldn't be these numeric
> values.
>
> The strings themselves effectively form the UABI, so I was wondering
> if they should be defined in include/uapi, but you would be the first
> to do that.
>
> Daniel Vetter and/or Daniel Stone mi
e-time. So, in include/uapi there shouldn't be these numeric
> values.
>
> The strings themselves effectively form the UABI, so I was wondering
> if they should be defined in include/uapi, but you would be the first
> to do that.
>
> Daniel Vetter and/or Daniel Stone mi
Hi,
On Fri, 25 Jan 2019 at 23:24, Rob Clark wrote:
> (Hmm, I guess I should take a look at what sort of API gitlab offers,
> but that will probably have to wait until after the branchpoint.. tbh
> I'd actually be pretty happy w/ a gitlab equiv of 'git pw as -s' for
> merging things from
Hi,
On Wed, 23 Jan 2019 at 10:09, Eric Engestrom wrote:
> On Wednesday, 2019-01-23 10:36:15 +0100, Erik Faye-Lund wrote:
> > Sending MRs from the main Mesa repository increase clutter in the
> > repository, and decrease visibility of project-wide branches. So it's
> > better if MRs are sent from
Hi,
On Tue, 22 Jan 2019 at 19:42, Wentland, Harry wrote:
> On 2019-01-22 2:19 p.m., Daniel Vetter wrote:
> > I'd say we'll shrug these cases off as "can't be reasonable tested,
> > won't have an igt". First driver team with hw that can be validated
> > gets to fill the gaps :-) In practice still
Hi,
On Thu, 17 Jan 2019 at 16:35, Jason Ekstrand wrote:
> On January 17, 2019 08:58:03 Erik Faye-Lund
> wrote:
> > Whoops! I meant to say something like "we'd need to be able to
> > distinguis between CI steps that are triggered due to new MRs versus
> > updated MRs, or pushes to existing
Hi,
On Thu, 17 Jan 2019 at 07:38, Erik Faye-Lund
wrote:
> 1. New MRs should probably get their cover-letter automatically sent to
> the mailing list for incrased visibility.
>
> [...]
>
> I don't think any of these issues are show-stoppers from moving
> entirely to MRs, though. Perhaps issue #1
On Wed, 16 Jan 2019 at 16:06, h...@lst.de wrote:
> On Wed, Jan 16, 2019 at 07:28:13AM +, Koenig, Christian wrote:
> > To summarize once more: We have an array of struct pages and want to
> > coherently map that to a device.
>
> And the answer to that is very simple: you can't. What is so
On Wed, 16 Jan 2019 at 16:06, h...@lst.de wrote:
> On Wed, Jan 16, 2019 at 07:28:13AM +, Koenig, Christian wrote:
> > To summarize once more: We have an array of struct pages and want to
> > coherently map that to a device.
>
> And the answer to that is very simple: you can't. What is so
Hi,
On Wed, 16 Jan 2019 at 13:01, Lionel Landwerlin
wrote:
> - It seems we only get notifications when adding to an MR, I could like to
> subscribe to particular tags
If you go to https://gitlab.freedesktop.org/mesa/mesa/labels/ then you
can subscribe to things per-label. That applies to both
Hi,
On Tue, 15 Jan 2019 at 23:47, Matt Turner wrote:
> On Mon, Jan 14, 2019 at 4:36 AM Daniel Stone wrote:
> > On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand wrote:
> > > 5. There's no way with gitlab for Reviewed-by tags to get automatically
> > > applied as
Hey,
On Tue, 15 Jan 2019 at 20:22, Rob Clark wrote:
> On Tue, Jan 15, 2019 at 7:40 AM Daniel Stone wrote:
> > My question would again be what value that brings you. Do you just
> > like seeing the name there, or do you go poke the people on IRC, or
> > follow up via em
buffering.
> > Have you considered tracking/checking how many buffers we have?
>
> A hysteresis value of 18 is just something that worked well in
> practice. It didn't appear to defer the buffer destruction for too long
> while keeping the feedback loop well under control.
Yea
Hi,
On Tue, 15 Jan 2019 at 12:21, Rob Clark wrote:
> On Tue, Jan 15, 2019 at 1:02 AM Tapani Pälli wrote:
> > On 1/14/19 2:36 PM, Daniel Stone wrote:
> > > On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand wrote:
> > > In other projects, we looked for ways to
Hi,
On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand wrote:
> 5. There's no way with gitlab for Reviewed-by tags to get automatically
> applied as part of the merging process. This makes merging a bit more manual
> than it needs to be but is really no worse than it was before.
I'm still on the
Hi Pekka,
On Sat, 12 Jan 2019 at 12:55, Pekka Paalanen wrote:
> since meson is there and autotools on its final count-down, let's update
> the main Weston build guide to use Meson.
Looks good, thanks for doing this. Series is:
Reviewed-by: Daniel Stone
> Things that would need furth
Hi Scott,
[As a general note, I'm on holiday in Australia this month and not
back at work until mid-Jan, so am not reading email very attentively;
if there's something I should be looking at, please either directly CC
me on this address rather than my work email, or poke me on IRC.]
On Fri, 21
I assume it's relatively well known, but here's where I landed.
My plan to fix this, was to bypass XKM support completely, by
integrating the parser into the server. Currently the server forks
xkbcomp to build a particular keymap, xkbcomp produces (lossy) XKM
files, and then the server consumes
I assume it's relatively well known, but here's where I landed.
My plan to fix this, was to bypass XKM support completely, by
integrating the parser into the server. Currently the server forks
xkbcomp to build a particular keymap, xkbcomp produces (lossy) XKM
files, and then the server consumes
I assume it's relatively well known, but here's where I landed.
My plan to fix this, was to bypass XKM support completely, by
integrating the parser into the server. Currently the server forks
xkbcomp to build a particular keymap, xkbcomp produces (lossy) XKM
files, and then the server consumes
excellent leader of our community so far, and I don't
> expect that to change just because you officially wear a new hat.
>
> Acked-by: Eric Anholt
Eric speaks for me.
Acked-by: Daniel Stone
Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi,
On Sat, 8 Dec 2018 at 05:15, Eric Engestrom wrote:
> On Friday, 2018-12-07 10:19:23 +0100, Erik Faye-Lund wrote:
> > Automated emails (and perhaps IRC bot) would be really nice.
>
> Agreed. Email would be great to help with the transition.
> There's work currently being done on GitLab to
Hi all,
Thanks for the CC. I'm on a sabbatical until mid-January; I'll be
around but not following the lists/etc as actively as before. Please
feel free to liberally CC me (on this address, not work) or poke me on
IRC if there's something I should see or could contribute to. I'll
have limited time
Hi Emil,
On Thu, 8 Nov 2018 at 15:26, Emil Velikov wrote:
> On Tue, 30 Oct 2018 at 12:57, Daniel Stone wrote:
> > If the client has requested that AcquireNextImage not block at all, with
> > a timeout of 0, then don't make any non-blocking calls.
> >
> > This w
id, Daniel, since your name is in the maintainers, can I have your
> R-b, please?
The protocol is:
Reviewed-by: Daniel Stone
The Weston implementation looks pretty good so far, though there's no
full implementation of release yet.
Cheers,
Daniel
On Fri, 9 Nov 2018 at 19:13, Eric Engestrom wrote:
> Error message was invalid too, negative values aren't the number of
> devices, they're errno error codes.
>
> Signed-off-by: Eric Engestrom
Reviewed-by: Daniel Stone
___
dri-devel mail
format R8
> libEGL debug: No DRI config supports native format GR88
>
> is a lot easier to understand.
Series is:
Reviewed-by: Daniel Stone
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hi,
On Thu, 8 Nov 2018 at 13:01, Pekka Paalanen wrote:
> On Wed, 07 Nov 2018 20:22:38 + Simon Ser wrote:
> > I missed this before, but: is there a reason why the "linux" prefix has been
> > dropped here? Maybe it should be renamed to
> > zwp_linux_surface_synchronization_v1? What about
Hi,
On Tue, 6 Nov 2018 at 13:11, Eric Engestrom wrote:
> On Friday, 2018-11-02 14:40:49 -0700, Eric Anholt wrote:
> > +GBM_EXPORT char *
> > +gbm_format_get_name(uint32_t gbm_format, struct gbm_format_name_desc *desc)
> > +{
>
> Actually, This won't work with the two GBM_BO_FORMAT_{X,A}RGB;
Hi Alexandros,
On Tue, 8 Aug 2017 at 15:25, Alexandros Frantzis
wrote:
> This protocol specifies a set of interfaces used to control the alpha
> compositing and blending of surface contents.
>
> It's based on the Chromium Wayland protocol of the same name ([1]),
> with a few changes made to the
On Fri, 2 Nov 2018 at 15:58, Emil Velikov wrote:
> Ff| 2 ++
> docs/relnotes/19.0.0.html | 2 +-
> 2 files changed, 3 insertions(+), 1 deletion(-)
> create mode 100644 Ff
>
> diff --git a/Ff b/Ff
> new file mode 100644
> index 000..804e31ab99e
> --- /dev/null
>
Hi Simon,
Thanks a lot for taking this on! :)
On Thu, 1 Nov 2018 at 16:45, Simon Ser wrote:
> This commit introduces a new wp_linux_dmabuf_device_hints object. This object
> advertizes a preferred device via a file descriptor and a set of preferred
> formats/modifiers.
s/advertizes/advertises/g
ture
> clients to use MAP_PRIVATE if they use a seat version above 6.
>
> If a compositor can't use sealing or a similar facility, it should
> still protect itself with copied keymaps, but clients must always
> assume shared mapping of a k
removing a 'see
also' for gbm_bo_format, since we can't also use \sa to refer to a
family of anonymous #defines.
Signed-off-by: Daniel Stone
Reported-by: Pekka Paalanen
---
src/gbm/main/gbm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gbm/main/gbm.c b/src/gbm/main
If the client has requested that AcquireNextImage not block at all, with
a timeout of 0, then don't make any non-blocking calls.
This will still potentially block infinitely given a non-infinte
timeout, but the fix for that is much more involved.
Signed-off-by: Daniel Stone
Cc: mesa-sta
Hi,
On Fri, 26 Oct 2018 at 11:57, Daniel Vetter wrote:
> On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote:
> > On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote:
> > > On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone wrote:
> > > > Yeah, I thi
Hi,
On Fri, 26 Oct 2018 at 11:57, Daniel Vetter wrote:
> On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote:
> > On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote:
> > > On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone wrote:
> > > > Yeah, I thi
Hi,
On Fri, 26 Oct 2018 at 11:57, Daniel Vetter wrote:
> On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote:
> > On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote:
> > > On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone wrote:
> > > > Yeah, I thi
Hi,
On Fri, 26 Oct 2018 at 11:57, Daniel Vetter wrote:
> On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote:
> > On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote:
> > > On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone wrote:
> > > > Yeah, I thi
Hi,
On Fri, 26 Oct 2018 at 11:57, Daniel Vetter wrote:
> On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote:
> > On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote:
> > > On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone wrote:
> > > > Yeah, I thi
Hi,
I've cross-posted this to freedesktop@, as the xdg@ list is only used
for actual specification development.
On Mon, 22 Oct 2018 at 00:36, Jacob Lifshay wrote:
> Hi, we were thinking of asking if freedesktop would host Kazan
> (https://github.com/kazan-3d/kazan) for us, however some of our
On Tue, 16 Oct 2018 at 08:17, Peter Hutterer wrote:
> On Mon, Oct 15, 2018 at 10:49:24AM -0400, Harry Wentland wrote:
> > + \item Support free and open source projects through the
> > freedesktop.org
> > + infrastructure. For projects outside the scope of item (\ref{1})
> > support
> >
On Tue, 16 Oct 2018 at 08:17, Peter Hutterer wrote:
> On Mon, Oct 15, 2018 at 10:49:24AM -0400, Harry Wentland wrote:
> > + \item Support free and open source projects through the
> > freedesktop.org
> > + infrastructure. For projects outside the scope of item (\ref{1})
> > support
> >
On Tue, 16 Oct 2018 at 08:17, Peter Hutterer wrote:
> On Mon, Oct 15, 2018 at 10:49:24AM -0400, Harry Wentland wrote:
> > + \item Support free and open source projects through the
> > freedesktop.org
> > + infrastructure. For projects outside the scope of item (\ref{1})
> > support
> >
On Tue, 16 Oct 2018 at 08:17, Peter Hutterer wrote:
> On Mon, Oct 15, 2018 at 10:49:24AM -0400, Harry Wentland wrote:
> > + \item Support free and open source projects through the
> > freedesktop.org
> > + infrastructure. For projects outside the scope of item (\ref{1})
> > support
> >
On Tue, 16 Oct 2018 at 08:17, Peter Hutterer wrote:
> On Mon, Oct 15, 2018 at 10:49:24AM -0400, Harry Wentland wrote:
> > + \item Support free and open source projects through the
> > freedesktop.org
> > + infrastructure. For projects outside the scope of item (\ref{1})
> > support
> >
patch is:
Reviewed-by: Daniel Stone
I didn't have time to properly look at the others yet, but most of
what you said there makes sense to me, so I'll hang on for a v2.
Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lis
Hi,
On Mon, 1 Oct 2018 at 22:25, Jason Ekstrand wrote:
> index 70594d6c053..2850349a619 100644
> --- a/src/intel/vulkan/anv_image.c
> +++ b/src/intel/vulkan/anv_image.c
> @@ -109,6 +109,8 @@ choose_isl_tiling_flags(const struct
> anv_image_create_info *anv_info,
> case
Hi all,
On Fri, 21 Sep 2018 at 20:59, Daniel Stone wrote:
> On Wed, 29 Aug 2018 at 11:13, Juan A. Suarez Romero
> wrote:
> > This is a first part, version 2, of a more complete proposal to use GitLab
> > CI to
> > build and test Mesa. This first part just adds the
501 - 600 of 9465 matches
Mail list logo
