On Fri, 28 Feb 2020 at 10:06, Erik Faye-Lund
wrote:
> On Fri, 2020-02-28 at 11:40 +0200, Lionel Landwerlin wrote:
> > Yeah, changes on vulkan drivers or backend compilers should be
> > fairly
> > sandboxed.
> >
> > We also have tools that only work for intel stuff, that should never
> > trigger
On Fri, 28 Feb 2020 at 10:06, Erik Faye-Lund
wrote:
> On Fri, 2020-02-28 at 11:40 +0200, Lionel Landwerlin wrote:
> > Yeah, changes on vulkan drivers or backend compilers should be
> > fairly
> > sandboxed.
> >
> > We also have tools that only work for intel stuff, that should never
> > trigger
On Fri, 28 Feb 2020 at 10:06, Erik Faye-Lund
wrote:
> On Fri, 2020-02-28 at 11:40 +0200, Lionel Landwerlin wrote:
> > Yeah, changes on vulkan drivers or backend compilers should be
> > fairly
> > sandboxed.
> >
> > We also have tools that only work for intel stuff, that should never
> > trigger
On Fri, 28 Feb 2020 at 10:06, Erik Faye-Lund
wrote:
> On Fri, 2020-02-28 at 11:40 +0200, Lionel Landwerlin wrote:
> > Yeah, changes on vulkan drivers or backend compilers should be
> > fairly
> > sandboxed.
> >
> > We also have tools that only work for intel stuff, that should never
> > trigger
On Fri, 28 Feb 2020 at 08:48, Dave Airlie wrote:
> On Fri, 28 Feb 2020 at 18:18, Daniel Stone wrote:
> > The last I looked, Google GCP / Amazon AWS / Azure were all pretty
> > comparable in terms of what you get and what you pay for them.
> > Obviously providers like Packet
On Fri, 28 Feb 2020 at 08:48, Dave Airlie wrote:
> On Fri, 28 Feb 2020 at 18:18, Daniel Stone wrote:
> > The last I looked, Google GCP / Amazon AWS / Azure were all pretty
> > comparable in terms of what you get and what you pay for them.
> > Obviously providers like Packet
On Fri, 28 Feb 2020 at 08:48, Dave Airlie wrote:
> On Fri, 28 Feb 2020 at 18:18, Daniel Stone wrote:
> > The last I looked, Google GCP / Amazon AWS / Azure were all pretty
> > comparable in terms of what you get and what you pay for them.
> > Obviously providers like Packet
On Fri, 28 Feb 2020 at 08:48, Dave Airlie wrote:
> On Fri, 28 Feb 2020 at 18:18, Daniel Stone wrote:
> > The last I looked, Google GCP / Amazon AWS / Azure were all pretty
> > comparable in terms of what you get and what you pay for them.
> > Obviously providers like Packet
On Fri, 28 Feb 2020 at 08:48, Dave Airlie wrote:
> On Fri, 28 Feb 2020 at 18:18, Daniel Stone wrote:
> > The last I looked, Google GCP / Amazon AWS / Azure were all pretty
> > comparable in terms of what you get and what you pay for them.
> > Obviously providers like Packet
On Fri, 28 Feb 2020 at 03:38, Dave Airlie wrote:
> b) we probably need to take a large step back here.
>
> Look at this from a sponsor POV, why would I give X.org/fd.o
> sponsorship money that they are just giving straight to google to pay
> for hosting credits? Google are profiting in some minor
Hi Matt,
On Thu, 27 Feb 2020 at 23:45, Matt Turner wrote:
> We're paying 75K USD for the bandwidth to transfer data from the
> GitLab cloud instance. i.e., for viewing the https site, for
> cloning/updating git repos, and for downloading CI artifacts/images to
> the testing machines (AFAIU).
I
On Fri, 28 Feb 2020 at 03:38, Dave Airlie wrote:
> b) we probably need to take a large step back here.
>
> Look at this from a sponsor POV, why would I give X.org/fd.o
> sponsorship money that they are just giving straight to google to pay
> for hosting credits? Google are profiting in some minor
On Fri, 28 Feb 2020 at 03:38, Dave Airlie wrote:
> b) we probably need to take a large step back here.
>
> Look at this from a sponsor POV, why would I give X.org/fd.o
> sponsorship money that they are just giving straight to google to pay
> for hosting credits? Google are profiting in some minor
On Fri, 28 Feb 2020 at 03:38, Dave Airlie wrote:
> b) we probably need to take a large step back here.
>
> Look at this from a sponsor POV, why would I give X.org/fd.o
> sponsorship money that they are just giving straight to google to pay
> for hosting credits? Google are profiting in some minor
On Fri, 28 Feb 2020 at 03:38, Dave Airlie wrote:
> b) we probably need to take a large step back here.
>
> Look at this from a sponsor POV, why would I give X.org/fd.o
> sponsorship money that they are just giving straight to google to pay
> for hosting credits? Google are profiting in some minor
On Fri, 28 Feb 2020 at 03:38, Dave Airlie wrote:
> b) we probably need to take a large step back here.
>
> Look at this from a sponsor POV, why would I give X.org/fd.o
> sponsorship money that they are just giving straight to google to pay
> for hosting credits? Google are profiting in some minor
Hi Matt,
On Thu, 27 Feb 2020 at 23:45, Matt Turner wrote:
> We're paying 75K USD for the bandwidth to transfer data from the
> GitLab cloud instance. i.e., for viewing the https site, for
> cloning/updating git repos, and for downloading CI artifacts/images to
> the testing machines (AFAIU).
I
Hi Matt,
On Thu, 27 Feb 2020 at 23:45, Matt Turner wrote:
> We're paying 75K USD for the bandwidth to transfer data from the
> GitLab cloud instance. i.e., for viewing the https site, for
> cloning/updating git repos, and for downloading CI artifacts/images to
> the testing machines (AFAIU).
I
Hi Matt,
On Thu, 27 Feb 2020 at 23:45, Matt Turner wrote:
> We're paying 75K USD for the bandwidth to transfer data from the
> GitLab cloud instance. i.e., for viewing the https site, for
> cloning/updating git repos, and for downloading CI artifacts/images to
> the testing machines (AFAIU).
I
Hi Matt,
On Thu, 27 Feb 2020 at 23:45, Matt Turner wrote:
> We're paying 75K USD for the bandwidth to transfer data from the
> GitLab cloud instance. i.e., for viewing the https site, for
> cloning/updating git repos, and for downloading CI artifacts/images to
> the testing machines (AFAIU).
I
Hi Matt,
On Thu, 27 Feb 2020 at 23:45, Matt Turner wrote:
> We're paying 75K USD for the bandwidth to transfer data from the
> GitLab cloud instance. i.e., for viewing the https site, for
> cloning/updating git repos, and for downloading CI artifacts/images to
> the testing machines (AFAIU).
I
Hi Drew,
On Thu, 27 Feb 2020 at 22:43, Drew DeVault wrote:
> I rigged up SourceHut CI for use with gitlab.fd.o several months ago, as
> part of investigation to see if wlroots and sway could be moved there.
> It's still set up - anyone with a sr.ht account can go to dispatch.sr.ht
> and create a
Daniel, fuck off, and never email me again.
On Thu, 27 Feb 2020 at 16:56, Debian Community News Team
wrote:
>
>
> Please update your bookmarks and RSS subscriptions to use the new links
> / feeds below.
>
> A number of differences of opinion have emerged in the Debian Community
> recently.
>
>
Hi,
On Tue, 25 Feb 2020 at 07:17, Pankaj Bharadiya
wrote:
> @@ -415,18 +415,26 @@ skl_program_scaler(struct intel_plane *plane,
> u16 y_vphase, uv_rgb_vphase;
> int hscale, vscale;
> const struct drm_plane_state *state = _state->uapi;
> + u32 src_w =
Hi,
On Tue, 25 Feb 2020 at 07:17, Pankaj Bharadiya
wrote:
> @@ -415,18 +415,26 @@ skl_program_scaler(struct intel_plane *plane,
> u16 y_vphase, uv_rgb_vphase;
> int hscale, vscale;
> const struct drm_plane_state *state = _state->uapi;
> + u32 src_w =
Hi,
On Tue, 11 Feb 2020 at 23:21, Eric Engestrom wrote:
> On Thursday, 2020-02-06 17:46:36 +, Li, Juston wrote:
> > Yes, drm.h was copied from 'make headers_install' from drm-misc-next.
> > It had been updated fairly recently so GETFB2 is the only delta.
> >
> > Sorry, I didn't see the
, and since free(NULL) is defined to be
safe, this entire function can be defined as drmFree(ptr) without the
comment or early return.
I would like this to be changed before merging. After the revision,
this patch is:
Signed-off-by: Daniel Stone
Cheers,
Daniel
Hi Devashish,
It sounds like your application, as well as eglinfo, are not even
trying to use Wayland. Maybe they are autodetecting the platform
incorrectly and trying to use GBM instead. This could perhaps be
solved by setting the $WAYLAND_DISPLAY environment variable to the
name of the socket
commits.
Thanks for writing this up Daniel, and for reminding me about it some
time later as well ...
Reviewed-by: Daniel Stone
Cheers,
Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
commits.
Thanks for writing this up Daniel, and for reminding me about it some
time later as well ...
Reviewed-by: Daniel Stone
Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi,
On Fri, 3 Jan 2020 at 16:57, Eric Anholt wrote:
> marge broke over the holidays due to a gitlab upgrade. It's unclear
> when we'll get it back up -- daniels might do a downgrade but is
> currently out sick
>
> https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/228
I've pushed a
Hi Tian,
On Sat, 28 Dec 2019 at 01:14, Tian Tao wrote:
> @@ -118,11 +119,9 @@ static void hibmc_plane_atomic_update(struct drm_plane
> *plane,
> writel(gpu_addr, priv->mmio + HIBMC_CRT_FB_ADDRESS);
>
> reg = state->fb->width * (state->fb->format->cpp[0]);
> - /* now
On Wed, 11 Dec 2019 at 22:35, Timothy Arceri wrote:
> So it seems lately we have been increasingly merging patches with made
> up names, or single names etc [1]. The latest submitted patch has the
> name Icecream95. This seems wrong to me from a point of keeping up the
> integrity of the project.
Hi,
On Tue, 19 Nov 2019 at 11:48, Guillermo Rodriguez
wrote:
> El mar., 19 nov. 2019 a las 11:47, Pekka Paalanen ()
> escribió:
> > If the OSD is just a piece of a bigger application and only needs to be
> > on top of that application's windows, you could probably use xdg
> > extensions or a
Hi,
On Thu, 14 Nov 2019 at 22:44, Scott Anderson wrote:
> On 15/11/19 4:04 am, Drew DeVault wrote:
> > I think that there would be value in being able to suggest that a
> > particluar buffer be scanned out for performance reasons. But, as a
> > suggestion, and not a demand, and definitely not
: Roman Gilg @romangg
* Qt: Johan Helsing @johanhelsing
* Weston: Daniel Stone @daniels, Pekka Paalanen @pq
* wlroots (& its users): Drew DeVault @ddevault, Simon Ser @emersion
If we find interest from other projects, we can use their membership
applications as a first test of our gover
Hi,
On Wed, 6 Nov 2019 at 02:47, Dave Airlie wrote:
> Otherwise I think this seems fine, though it does beg the question in
> my mind of what happens if I get 2 8K monitors, and plug the first
> tile of one in, and the second tile of the other in.
Honestly in that case I think 'you get to
Hi,
On Wed, 6 Nov 2019 at 02:47, Dave Airlie wrote:
> Otherwise I think this seems fine, though it does beg the question in
> my mind of what happens if I get 2 8K monitors, and plug the first
> tile of one in, and the second tile of the other in.
Honestly in that case I think 'you get to
Hi Andrzej,
On Mon, 2019-11-04 at 23:12 +0100, Andrzej Pietrasiewicz wrote:
> + if (mode_cmd->modifier[0]) {
I believe this can still be DRM_FORMAT_MOD_INVALID, which != 0. You
probably want to explicitly check if it's an AFBC modifier.
> + const struct drm_format_info *info;
>
Hi Andrzej,
Thanks for taking this on! It's looking better than v1 for sure. A few
things below:
On Mon, 2019-11-04 at 23:12 +0100, Andrzej Pietrasiewicz wrote:
> +bool drm_afbc_check_offset(struct drm_device *dev,
> +const struct drm_mode_fb_cmd2 *mode_cmd)
> +{
> +
Hi Thierry,
On Fri, 25 Oct 2019 at 12:36, Thierry Reding wrote:
> On Thu, Oct 24, 2019 at 01:45:16PM -0700, Rajat Jain wrote:
> > I did think about having a state variable in software to get and set
> > this. However, I think it is not very far fetched that some platforms
> > may have "hardware
Hi Thierry,
On Fri, 25 Oct 2019 at 12:36, Thierry Reding wrote:
> On Thu, Oct 24, 2019 at 01:45:16PM -0700, Rajat Jain wrote:
> > I did think about having a state variable in software to get and set
> > this. However, I think it is not very far fetched that some platforms
> > may have "hardware
Hey,
On Tue, 22 Oct 2019 at 11:30, Daniel Vetter wrote:
> On Tue, Oct 22, 2019 at 10:58:02AM +0200, Rohan Garg wrote:
> > This approach also future proof's us to be able to label any handles, not
> > just
> > GEM handle.
>
> I don't expect we'll ever merge any non-gem drivers in the future
Hi Rohan,
On Fri, 11 Oct 2019 at 15:30, Rohan Garg wrote:
> DRM_IOCTL_DUMB_SET_LABEL lets you label GEM objects, making it
> easier to debug issues in userspace applications.
I'm not sure if this was pointed out already, but dumb buffers != GEM
buffers. GEM buffers _can_ be dumb, but might not
Hi Andrzej,
On Fri, 11 Oct 2019 at 12:18, Andrzej Pietrasiewicz
wrote:
> @@ -32,6 +35,46 @@ rockchip_fb_alloc(struct drm_device *dev, const struct
> drm_mode_fb_cmd2 *mode_cm
> int ret;
> int i;
>
> + if (mode_cmd->modifier[0]) {
> + const struct
Hi,
On Fri, 11 Oct 2019 at 08:46, Daniel Vetter wrote:
> On Thu, Oct 10, 2019 at 7:32 PM Ayan Halder wrote:
> > On Thu, Oct 10, 2019 at 03:41:15PM +0200, Neil Armstrong wrote:
> > > Sorry I don't understand, you ask me to limit AFBC to ABGR ?
> >
> > Apologies for the confusion, as per the
On Thu, 10 Oct 2019 at 01:21, Simon Ser wrote:
> This is v4 of the proposal.
>
> Changes from v3 to v4: relax implementation requirements for inclusion
> in "xdg" and "wp" (Jonas, Drew).
>
> Diff: https://
Hi,
On Mon, 7 Oct 2019 at 19:16, Keith Packard wrote:
> Daniel Stone writes:
> > I think there would be a load of value in starting with simple helpers
> > which can be used independently of any larger scheme, tackling that
> > list above.
>
> Yeah, a helper library t
On Mon, 7 Oct 2019 at 19:16, Keith Packard wrote:
> Daniel Stone writes:
> > I think there would be a load of value in starting with simple helpers
> > which can be used independently of any larger scheme, tackling that
> > list above.
>
> Yeah, a helper library t
Hi,
On Mon, 7 Oct 2019 at 18:35, Daniel Stone wrote:
> There are definitely a few annoying problems which we should have
> common resolution for. I'm thinking of:
> - [...]
Oh, and add backlight handling to that list.
Cheers,
Daniel
___
Hi Keith,
On Sat, 5 Oct 2019 at 17:16, Keith Packard wrote:
> During XDC this year, we heard a few presentations and had a lot of
> hallway talk about sharing code for driving DRM/KMS for display.
Definitely. That would be great.
> I think the general consensus is that there is enough shared
>
; Let's not expose the ->set_damage_region() method until the core is
> fixed to handle that properly.
>
> Cc: mesa-sta...@lists.freedesktop.org
> Signed-off-by: Boris Brezillon
Acked-by: Daniel Stone
___
mesa-dev mailing list
mes
Hi Boris,
On Tue, 1 Oct 2019 at 09:25, Boris Brezillon
wrote:
> On Mon, 2 Sep 2019 16:32:01 +0200 Michel Dänzer wrote:
> > On 2019-08-30 7:00 p.m., Boris Brezillon wrote:
> > > So, next question is, do you think it's acceptable to pass a
> > > DRIcontext here, and if not, do you have any idea
Hi Kyle,
On Fri, 27 Sep 2019 at 17:06, Kyle Brenneman wrote:
> Okay, I've imported the Github repository here:
> https://gitlab.freedesktop.org/glvnd/libglvnd
That's great, thanks! I've given Adam Jackson access as requested (go
to the 'members' tab from the glvnd group page). It sounds like it
Hi Linus,
On Fri, 27 Sep 2019 at 13:37, Linus Walleij wrote:
> Also the ILI9322 can actually set up gamma correction which is
> very nice for professional applications. I haven't seen any way for
> DRM to do gamma correction properly or any framework for it
> to adjust and propagate gamma
Hi Liviu,
On Wed, 18 Sep 2019 at 13:04, Liviu Dudau wrote:
> On Wed, Sep 18, 2019 at 09:49:40AM +0100, Daniel Stone wrote:
> > I totally agree. Framebuffers aren't about the underlying memory they
> > point to, but about how to _interpret_ that memory: it decorates a
> &g
On Wed, 18 Sep 2019 at 20:43, Mark Janes wrote:
> Adam Jackson writes:
> > Strictly, the "Reporter" access level and above can manage labels,
> > milestones require "Developer" or above. Not super meaningful since the
> > mesa group really only has Developer or above.
> >
> > I'm not super
Hi all,
On Tue, 17 Sep 2019 at 13:53, Daniel Vetter wrote:
> On Mon, Sep 09, 2019 at 01:42:53PM +, Ayan Halder wrote:
> > Let us ignore how the protected system memory is allocated and for the
> > scope of
> > this discussion, we want to figure out the best way possible for the
> >
c.c#L280
> >
> > While at it also document that we have immutable zpos properties in
> > some cases.
> >
> > Reported-by: Pekka Paalanen
> > Cc: Pekka Paalanen
> > Reviewed-by: Pekka Paalanen
> > Cc: Ilia Mirkin
> > Acked-by: Ilia Mirkin
> &g
Hi,
On Wed, 4 Sep 2019 at 15:12, Chuck Atkins wrote:
> Can we use Gitlab's GitHub import feature?
>
> https://gitlab.freedesktop.org/help/user/project/import/github.md
>
> I haven't used it before but it looks like it will migrate everything, i.e.
> repo, issues, prs, etc.
Yeah, we definitely
Hi,
On Sat, 31 Aug 2019 at 20:34, Matt Turner wrote:
> Getting patches into libglvnd has proven quite difficult (see [0] for
> example). There was some talk of moving it to FreeDesktop Gitlab on
> IRC recently. Can we move forward with that? Are there objections to
> doing so?
We'd be happy to
Hi Sichem,
On Sat, 31 Aug 2019 at 03:01, Sichem Zhou wrote:
> I hope to make a follow up to this thread. I made a change and submitted to
> MR but it seemed to gain little interest so I am trying my luck here.
>
> My problem is that I need to change `xkb_keymap` in the Weston run time,
>
Hi Boris,
On Sat, 31 Aug 2019 at 18:33, Boris Brezillon
wrote:
> On Sat, 31 Aug 2019 17:06:30 +0100 Daniel Stone wrote:
> > On Fri, 30 Aug 2019 at 17:00, Rohan Garg wrote:
> > > Both the BO cache and the transient pool are shared across
> > > context's. Protect a
*ctx,
> - struct panfrost_batch *batch,
> +panfrost_job_clear(struct panfrost_batch *batch,
> unsigned buffers,
> const union pipe_color_union *color,
> double depth, unsigned stencil);
The series looks good
Hi Boris,
On Sat, 31 Aug 2019 at 11:47, Boris Brezillon
wrote:
> Right now, the transient memory allocator implements its own BO caching
> mechanism, which is not really needed since we already have a generic
> BO cache. Let's simplify things a bit.
>
> [...]
>
> bool fits_in_current =
Hi Rohan,
On Fri, 30 Aug 2019 at 17:00, Rohan Garg wrote:
> Both the BO cache and the transient pool are shared across
> context's. Protect access to these with mutexes.
These fixes seem right to me, and (minus the issues Boris pointed
out), both are:
Reviewed-by: Daniel Stone
I
Hi,
On Thu, 29 Aug 2019 at 21:35, Chris Wilson wrote:
> Quoting Kristian Høgsberg (2019-08-29 21:20:12)
> > On Thu, Aug 29, 2019 at 12:44 PM Chris Wilson
> > wrote:
> > > Quoting Kenneth Graunke (2019-08-29 19:52:51)
> > > > - Moving bug reports between the kernel and Mesa would be harder.
> >
>
> Do you need me to land this?
>
> Since wayland-protocols is still using email workflow, please give all
> your Reviewed-by and Acked-by tags explicitly.
With the same rationale - this will only hurt people generating rich
bindings, who are the exact people who want it - this is:
Hi,
On Wed, 28 Aug 2019 at 11:18, Michel Dänzer wrote:
> On 2019-08-28 3:08 a.m., Eric Engestrom wrote:
> > On Tuesday, 2019-08-27 13:31:22 +, Jose Fonseca wrote:
> >> Appveyor seems to be building other MR 1781:
> >>
> >> https://ci.appveyor.com/project/mesa3d/mesa-re1yd/builds/26989425
>
Hi Andreas,
On Sun, 25 Aug 2019 at 21:11, Andreas Bergmeier wrote:
> For a few weeks now I am working on implementing Vulkan for VideoCore 6 AKA
> 42 (using V3D/DRM). Don't hold you breath ;)
Great! I can't say much about the specifics of VideoCore hardware, but
at least for some of the common
Hi Sichem,
On Mon, 26 Aug 2019 at 02:38, Sichem Zhou wrote:
> I found that currently there is no way to change `xkb_keymap` after Weston is
> running.
>
> By different backends, xkb_info in wayland works differently, for example,
> the wayland and x11 backend, weston_keyboard is initialized
Hi Robert,
On Wed, 14 Aug 2019 at 11:49, Robert Chiras wrote:
> + case DRM_FORMAT_BGR565: /* BG16 */
> + if (mxsfb->devdata->ipversion < 4)
> + goto err;
> + writel(CTRL2_ODD_LINE_PATTERN(CTRL2_LINE_PATTERN_BGR) |
> +
On Fri, 9 Aug 2019 at 10:47, HalleyZhao wrote:
> some buffer attributes may influence how weston use it, for example: tiling
> mode, Swizzling, compression.
> weston may depend on these attribute to decide to assign the buffer to a hw
> plane or composite it as texture.
Yes. The open-source
Hi,
On Wed, 7 Aug 2019 at 10:37, Jani Nikula wrote:
> On Tue, 06 Aug 2019, Daniel Stone wrote:
> > On Tue, 6 Aug 2019 at 15:00, Daniel Vetter wrote:
> >> Daniel, I guess your fd.o server-side script will have some helpful
> >> reminder to please use dim, and if you
Hi,
On Tue, 6 Aug 2019 at 15:00, Daniel Vetter wrote:
> Yeah, I can do that quick patch when you've pushed this one. Better to
> plug this process hole quickly.
>
> Daniel, I guess your fd.o server-side script will have some helpful
> reminder to please use dim, and if you do so, please upgrade?
overs _all_ the "git push" instances in DIM and is:
> Reviewed-by: Emil Velikov
I haven't taken a close look at dim lately, but Emil's comment sounds
like a good one. With that, this is (with my repo admin hat on):
Acked-by: Daniel Stone
Cheers,
Daniel
__
Hi,
On Tue, 6 Aug 2019 at 10:58, Daniel Vetter wrote:
> On Tue, Aug 6, 2019 at 11:55 AM Emil Velikov wrote:
> > On Tue, 6 Aug 2019 at 10:49, Daniel Vetter wrote:
> > > The thing is, dim push shouldn't allow you to do that. And the patches
> > > have clearly been applied with dim apply (or at
Hi,
On Tue, 6 Aug 2019 at 10:58, Daniel Vetter wrote:
> On Tue, Aug 6, 2019 at 11:55 AM Emil Velikov wrote:
> > On Tue, 6 Aug 2019 at 10:49, Daniel Vetter wrote:
> > > The thing is, dim push shouldn't allow you to do that. And the patches
> > > have clearly been applied with dim apply (or at
Hi,
On Tue, 6 Aug 2019 at 10:58, Daniel Vetter wrote:
> On Tue, Aug 6, 2019 at 11:55 AM Emil Velikov wrote:
> > On Tue, 6 Aug 2019 at 10:49, Daniel Vetter wrote:
> > > The thing is, dim push shouldn't allow you to do that. And the patches
> > > have clearly been applied with dim apply (or at
On Thu, 25 Jul 2019 at 10:17, HalleyZhao wrote:
> looking for an example to use in EGL
Weston itself provides an example of using dma-fences with EGL - both
extracting them from EGL to refer to previous rendering, and asking
EGL to wait on them.
If you're looking for an example of how you would
On Thu, 25 Jul 2019 at 04:34, HalleyZhao wrote:
> in Mesa, I could find some implement for vulkan, but not for EGL.
>
> maybe, desktop developer care more on mesa than mobile developers, and most
> desktop driver does implicitly sync instead of depending on
>
Hi Barry,
On Sun, 21 Jul 2019 at 00:33, Barry Song <21cn...@gmail.com> wrote:
> if i want to send the framebuffers using DRM backend as the video src
> in gstreamer to networks through rtsp, does weston have an existing
> solution.
>
> i mean something similar with the below for /dev/fb0 backend:
Hi,
On Sat, 6 Jul 2019 at 18:39, Ilia Mirkin wrote:
> I see this as driving away contributions, esp from new people. MR's
> are annoying to create, since they require dealing with the hosting
> provider, getting it to host clones, etc. Everyone has email.
My position - and the evidence of
Hi,
On Fri, 5 Jul 2019 at 14:51, Alyssa Rosenzweig
wrote:
> > + switch(whandle->modifier) {
> > + case DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_ROCKCHIP):
> > + rsc->layout = PAN_AFBC;
> > + break;
>
> Why ROCKCHIP in particular? AFBC fourcc codes are based on
On Fri, 5 Jul 2019 at 14:38, Alyssa Rosenzweig
wrote:
> > +bool should_tile = !is_streaming && is_texture && is_2d &&
> > !is_scanout;
>
> I'm not opposed, but why can't we tile PIPE_BIND_SHARED textures? lima
> does exactly that. If we can't tile them, we certainly can't AFBC them.
We
Hi,
On Thu, 4 Jul 2019 at 09:47, Tomeu Vizoso wrote:
> On Thu, 4 Jul 2019 at 10:05, Tomeu Vizoso wrote:
> > -pres->layout = should_tile ? PAN_TILED : PAN_LINEAR;
> > + if (want_afbc || (is_renderable && can_afbc && !is_texture))
> > +pres->layout = PAN_AFBC;
>
> We
Hi Tomeu,
On Thu, 4 Jul 2019 at 09:05, Tomeu Vizoso wrote:
> @@ -362,14 +392,19 @@ panfrost_resource_create_bo(struct panfrost_screen
> *screen, struct panfrost_reso
>
> /* Tiling textures is almost always faster, unless we only use it
> once */
>
> +bool can_afbc =
Hi Drew,
On Wed, 3 Jul 2019 at 08:16, Drew DeVault wrote:
> Instead of assuming the first will be suitable. kmscube fails to start
> for me without this change.
There are a couple of unrelated changes combined in here, but I think
the core one is good.
eglChooseConfig has some really useful
Hi,
To be honest, I haven't been able to look too closely at this one. I
wasn't able to easily reason about the twists and turns, so had to run
away to reviews elsewhere. But as long as we reload every single
region passed in - be it individually or just lazily pulling in the
extents, it's
Hi Colin,
On Wed, 26 Jun 2019 at 14:24, Colin King wrote:
> There are a couple of spelling mistakes in dm_error messages and
> a comment. Fix these.
Whilst there, you might fix the '[next[' typo in the commit message.
Cheers,
Daniel
___
dri-devel
Hi Colin,
On Wed, 26 Jun 2019 at 14:24, Colin King wrote:
> There are a couple of spelling mistakes in dm_error messages and
> a comment. Fix these.
Whilst there, you might fix the '[next[' typo in the commit message.
Cheers,
Daniel
Hi Alyssa,
On Tue, 25 Jun 2019 at 19:54, Alyssa Rosenzweig
wrote:
> @@ -2,6 +2,7 @@
> * Copyright (c) 2011-2013 Luc Verhaegen
> * Copyright (c) 2018 Alyssa Rosenzweig
> * Copyright (c) 2018 Vasily Khoruzhick
> + * Copyright (c) 2019 Collabora
Please use 'Collabora, Ltd.' as that's our
or a particular drawable.
> >
> > Based on a commit originally authored by:
> > Harish Krupo
> > renamed extension, retargeted at DRI drawable instead of context,
> > rewritten description
>
> Oops, this patch is missing Daniel's SoB.
Hi,
On Tue, 25 Jun 2019 at 16:07, Jason Ekstrand wrote:
> On Tue, Jun 25, 2019 at 4:04 AM Daniel Stone wrote:
>> On Tue, 25 Jun 2019 at 07:26, Simon Ser wrote:
>> > > I noticed that original patch (v1) for gbm_bo_create_with_modifiers did
>> > > have usage a
Hi,
On Mon, 24 Jun 2019 at 19:51, Simon Ser wrote:
> +GBM_EXPORT struct gbm_bo *
> +gbm_bo_create_with_modifiers2(struct gbm_device *gbm,
> + uint32_t width, uint32_t height,
> + uint32_t format,
> + const
Hi,
On Tue, 25 Jun 2019 at 07:26, Simon Ser wrote:
> > I noticed that original patch (v1) for gbm_bo_create_with_modifiers did
> > have usage at first but it was removed during the review. I'm having
> > trouble digging what was the reason for this?
>
> I'm not sure either. Daniel said it was a
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.
>
401 - 500 of 9461 matches
Mail list logo
