Hi,
On Thu, 15 May 2025 at 19:02, Harry Wentland wrote:
> On 2025-05-15 13:19, Daniel Stone wrote:
> > Yeah, the Weston patches are marching on. We've still been doing a
> > little bit of cleanup and prep work in the background to land them,
> > but we also can't l
Hi,
On Thu, 15 May 2025 at 15:11, Harry Wentland wrote:
> On 2025-05-15 05:45, Simon Ser wrote:
> > I've reviewed all of the core DRM patches :)
> >
> > Have there been updates from user-space implementations?
>
> I know Leandro has been working on Weston to make use of
> this and last year Xaver
Hi Harry,
On Tue, 8 Apr 2025 at 18:30, Harry Wentland wrote:
> On 2025-04-08 12:40, Daniel Stone wrote:
> > OK, Harry's reply cleared that up perfectly - the flexibility that's
> > there at the moment is about being able to reuse colorops for CRTCs in
> > post
Hi there,
On Tue, 1 Apr 2025 at 20:53, Simon Ser wrote:
> On Tuesday, April 1st, 2025 at 17:14, Daniel Stone
> wrote:
> > 'plane' seems really incongruous here. The colorop can be created for
> > any number of planes, but we're setting it to always be bound t
Hi Alex,
On Wed, 26 Mar 2025 at 23:50, Alex Hung wrote:
> +static int drm_colorop_init(struct drm_device *dev, struct drm_colorop
> *colorop,
> + struct drm_plane *plane, enum drm_colorop_type
> type)
> +{
> + struct drm_mode_config *config = &dev->mode_config;
>
the series is:
Acked-by: Daniel Stone
Cheers,
Daniel
On Wed, 15 Jan 2025 at 04:05, Marek Olšák wrote:
> On Tue, Jan 14, 2025 at 12:58 PM Daniel Stone wrote:
>> AMD hardware is the only hardware I know of which doesn't support
>> overaligning. Say (not hypothetically) we have a GPU and a display
>> controller which have a
Hi,
On Tue, 14 Jan 2025 at 09:38, Marek Olšák wrote:
> I would keep the existing modifier interfaces, API extensions, and
> expectations the same as today for simplicity.
Well yes, not just for simplicity, but because everything stops
working if you don't.
> The new linear modifier definition
On Thu, 19 Dec 2024 at 02:54, Marek Olšák wrote:
> On Wed, Dec 18, 2024 at 5:32 AM Brian Starkey wrote:
>> On Wed, Dec 18, 2024 at 11:24:58AM +, Simona Vetter wrote:
>> > For that reason I think linear modifiers with explicit pitch/size
>> > alignment constraints is a sound concept and fits i
On Wed, 18 Dec 2024 at 10:32, Brian Starkey wrote:
> On Wed, Dec 18, 2024 at 11:24:58AM +, Simona Vetter wrote:
> > For that reason I think linear modifiers with explicit pitch/size
> > alignment constraints is a sound concept and fits into how modifiers work
> > overall.
>
> Could we make it
Hi Vignesh,
On Thu, 5 Sept 2024 at 10:41, Vignesh Raman wrote:
> Uprev IGT to the latest version and deqp-runner
> to v0.20.0. Also update expectation files.
Thanks! This is:
Reviewed-by: Daniel Stone
it series adds support in drm-ci to run tests
> for both GPU and display drivers for MediaTek mt8173/mt8183, Rockchip
> rk3288/rk3399, and Amlogic Meson G12B (A311D) platforms.
>
> Update the expectations file, and skip driver-specific tests and
> tools_test on non-intel platforms.
Tha
Hi,
On Wed, 10 Jan 2024 at 10:44, Daniel Vetter wrote:
> On Tue, Jan 09, 2024 at 11:12:11PM +, Andri Yngvason wrote:
> > ţri., 9. jan. 2024 kl. 22:32 skrifađi Daniel Stone :
> > > How does userspace determine what's happened without polling? Will it
> > > onl
Hi,
On Tue, 9 Jan 2024 at 18:12, Andri Yngvason wrote:
> + * active color format:
> + * This read-only property tells userspace the color format actually used
> + * by the hardware display engine "on the cable" on a connector. The
> chosen
> + * value depends on hardware capabilities
On Wed, 15 Feb 2023 at 20:54, Harry Wentland wrote:
> On 2/15/23 06:46, Daniel Stone wrote:
> > On Tue, 14 Feb 2023 at 16:57, Harry Wentland wrote:
> >> On 2/14/23 10:49, Sebastian Wick wrote:
> >> From what I've seen recently I am inclined to favor an incrementa
Hi,
On Tue, 14 Feb 2023 at 16:57, Harry Wentland wrote:
> On 2/14/23 10:49, Sebastian Wick wrote:
> From what I've seen recently I am inclined to favor an incremental
> approach more. The reason is that any API, or portion thereof, is
> useless unless it's enabled full stack. When it isn't it bec
On Sun, 1 May 2022 at 08:08, Paul Menzel wrote:
> Am 26.04.22 um 15:53 schrieb Gong, Richard:
> > I think so. We captured dmesg log.
>
> Then the (whole) system did *not* freeze, if you could still log in
> (maybe over network) and execute `dmesg`. Please also paste the
> amdgpu(?) error logs in t
On Wed, 23 Mar 2022 at 15:14, Alex Deucher wrote:
> On Wed, Mar 23, 2022 at 11:04 AM Daniel Stone wrote:
> > That's not what anyone's saying here ...
> >
> > No-one's demanding AMD publish RTL, or internal design docs, or
> > hardware specs,
Hi Alex,
On Wed, 23 Mar 2022 at 14:42, Alex Deucher wrote:
> On Wed, Mar 23, 2022 at 10:00 AM Daniel Stone wrote:
> > On Wed, 23 Mar 2022 at 08:19, Christian König
> > wrote:
> > > Well the key point is it's not about you to judge that.
> > >
> >
Hi,
On Mon, 21 Mar 2022 at 16:02, Rob Clark wrote:
> On Mon, Mar 21, 2022 at 2:30 AM Christian König
> wrote:
> > Well you can, it just means that their contexts are lost as well.
>
> Which is rather inconvenient when deqp-egl reset tests, for example,
> take down your compositor ;-)
Yeah. Or a
On Wed, 23 Mar 2022 at 08:19, Christian König wrote:
> Am 23.03.22 um 09:10 schrieb Paul Menzel:
> > Sorry, I disagree. The motivation needs to be part of the commit
> > message. For example see recent discussion on the LWN article
> > *Donenfeld: Random number generator enhancements for Linux 5.1
Hi,
On Thu, 17 Mar 2022 at 09:21, Christian König wrote:
> Am 17.03.22 um 09:42 schrieb Sharma, Shashank:
> >> AFAIU you probably want to be passing around a `struct pid *`, and
> >> then somehow use pid_vnr() in the context of the process reading the
> >> event to get the numeric pid. Otherwise
Hi Esaki-san,
On Thu, 13 Jan 2022 at 09:44, Tomohito Esaki wrote:
> Some drivers whose planes only support linear layout fb do not support format
> modifiers.
> These drivers should support modifiers, however the DRM core should handle
> this
> rather than open-coding in every driver.
>
> In thi
Hi Monk,
On Thu, 2 Sept 2021 at 06:52, Liu, Monk wrote:
> I didn't mean your changes on AMD driver need my personal approval or review
> ... and I'm totally already get used that our driver is not 100% under
> control by AMDers,
> but supposedly any one from community (including you) who tend
Hi Mark,
On Wed, 24 Mar 2021 at 14:58, Mark Yacoub wrote:
> So you mean it would make more sense to be more explicit in handling
> DRM_FORMAT_MOD_INVALID as an incoming modifier (which will, just like
> DRM_FORMAT_MOD_LINEAR, will return true in
> dm_plane_format_mod_supported)?
>
That's correc
On Wed, 24 Mar 2021 at 10:53, Bas Nieuwenhuizen
wrote:
> On Wed, Mar 24, 2021 at 11:13 AM Michel Dänzer wrote:
>
>> No modifier support does not imply linear. It's generally signalled via
>> DRM_FORMAT_MOD_INVALID, which roughly means "tiling is determined by driver
>> specific mechanisms".
>>
>
Hi Luben,
On Wed, 2 Sep 2020 at 16:16, Luben Tuikov wrote:
> Not sure how I can do this when someone doesn't want to read up on
> the kref infrastructure. Can you help?
>
> When someone starts off with "My understanding of ..." (as in the OP) you
> know you're
> in trouble and in for a rough tim
Hi Luben,
On Wed, 2 Sep 2020 at 15:51, Luben Tuikov wrote:
> Of course it's true--good morning!
>
> Let me stop you right there--just read the documentation I pointed
> to you at.
>
> No!
>
> I'm sorry, that doesn't make sense.
>
> No, that's horrible.
>
> No, that's horrible.
>
> You need to und
On Thu, 9 Jul 2020 at 09:05, Daniel Vetter wrote:
> On Thu, Jul 09, 2020 at 08:36:43AM +0100, Daniel Stone wrote:
> > On Tue, 7 Jul 2020 at 21:13, Daniel Vetter wrote:
> > > Comes up every few years, gets somewhat tedious to discuss, let's
> > > write this down
explicitly
encode the carrot of dma-fence's positive guarantees, rather than just
the stick of 'don't do this'. ;) Either way, this is:
Acked-by: Daniel Stone
> What I'm not sure about is whether the text should be more explicit in
> flat out mandating the amdkf
Hi,
On Wed, 8 Jul 2020 at 16:13, Daniel Vetter wrote:
> On Wed, Jul 8, 2020 at 4:57 PM Christian König
> wrote:
> > Could we merge this controlled by a separate config option?
> >
> > This way we could have the checks upstream without having to fix all the
> > stuff before we do this?
>
> Since
Hi,
Jumping in after a couple of weeks where I've paged most everything
out of my brain ...
On Fri, 19 Jun 2020 at 10:43, Daniel Vetter wrote:
> On Fri, Jun 19, 2020 at 10:13:35AM +0100, Chris Wilson wrote:
> > > The proposed patches might very well encode the wrong contract, that's
> > > all up
Hi,
On Thu, 11 Jun 2020 at 09:44, Dave Airlie wrote:
> On Thu, 11 Jun 2020 at 18:01, Chris Wilson wrote:
> > Introducing a global lockmap that cannot capture the rules correctly,
>
> Can you document the rules all drivers should be following then,
> because from here it looks to get refactored e
Hi,
On Thu, 14 May 2020 at 14:36, Alex Deucher wrote:
> On Thu, May 14, 2020 at 5:42 AM Daniel Stone wrote:
> > Did this ever go through uAPI review? It's been pushed to the kernel
> > before Mesa review was complete. Even then, Mesa only uses it when
> > behind a
Hi Alex,
On Thu, 30 Apr 2020 at 22:30, Alex Deucher wrote:
> UAPI:
> - Add amdgpu UAPI for encrypted GPU memory
> Used by: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4401
Did this ever go through uAPI review? It's been pushed to the kernel
before Mesa review was complete. Even t
Hi Jan,
On Fri, 28 Feb 2020 at 10:09, Jan Engelhardt wrote:
> On Friday 2020-02-28 08:59, Daniel Stone wrote:
> >I believe that in January, we had $2082 of network cost (almost
> >entirely egress; ingress is basically free) and $1750 of
> >cloud-storage cost (almost all
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 an
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 b
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
se be _very_ careful
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 hav
Hi,
On Tue, 4 Sep 2018 at 11:44, Christian König
wrote:
> Am 04.09.2018 um 12:15 schrieb Daniel Stone:
> > Right. The conclusion, after people went through and started sorting
> > out the kinds of formats for which they would _actually_ export real
> > colour buffers f
Hi,
On Tue, 4 Sep 2018 at 11:05, Daniel Vetter wrote:
> On Tue, Sep 4, 2018 at 3:00 AM, Bas Nieuwenhuizen
> wrote:
> > +/* The chip this is compatible with.
> > + *
> > + * If compression is disabled, use
> > + * - AMDGPU_CHIP_TAHITI for GFX6-GFX8
> > + * - AMDGPU_CHIP_VEGA10 for GFX9+
> >
Hi Rodrigo,
On Wed, 22 Aug 2018 at 17:06, Rodrigo Vivi wrote:
> On Wed, Aug 22, 2018 at 10:19:19AM -0400, Adam Jackson wrote:
> > On Wed, 2018-08-22 at 16:13 +0300, Jani Nikula wrote:
> > > - Sticking to fdo bugzilla and disabling gitlab issues for at least
> > > drm-intel for the time being. D
Hi,
On Wed, 22 Aug 2018 at 15:44, Daniel Vetter wrote:
> On Wed, Aug 22, 2018 at 3:13 PM, Jani Nikula
> wrote:
> > Just a couple of concerns from drm/i915 perspective for starters:
> >
> > - Patchwork integration. I think we'll want to keep patchwork for at
> > least intel-gfx etc. for the ti
Hi,
On Wed, 22 Aug 2018 at 16:02, Emil Velikov wrote:
> On 22 August 2018 at 12:44, Daniel Vetter wrote:
> > I think it's time to brainstorm a bit about the gitlab migration. Basic
> > reasons:
> >
> > - fd.o admins want to deprecate shell accounts and hand-rolled
> > infrastructure, because i
Hi Alexander,
On 12 June 2018 at 14:53, Alexander E. Patrakov wrote:
> Daniel Stone :
>> > That said, I could not even create an account with a noscript/xhtml basic
>> > browser (if you want to test that, install the famous noscript module with
>> > an
>>
Hi Sylvain,
On 12 June 2018 at 13:38, wrote:
> On Tue, Jun 12, 2018 at 12:34:31PM +0100, Daniel Stone wrote:
>> GitLab has a pretty comprehensive and well-documented API which might
>> help if you don't want to use a web browser. There are also clients
>> like
Hi Michel,
On 11 June 2018 at 11:33, Michel Dänzer wrote:
> On 2018-06-08 08:08 PM, Adam Jackson wrote:
>> I'd like us to start moving repos and bug tracking into gitlab.
>> Hopefully everyone's aware that gitlab exists and why fdo projects are
>> migrating to it. If not, the thread about Mesa's
Hi Sylvain,
It looks like Mutt is mangling email addresses - I've fixed Michel's.
On 11 June 2018 at 14:30, wrote:
> On Mon, Jun 11, 2018 at 12:33:52PM +0200, Michel Dänzer wrote:
>> Adding the amd-gfx list, in cases somebody there has concerns or other
>> feedback.
>
> For feedback:
> I attempt
Hi,
On 20 April 2018 at 21:32, Manasi Navare wrote:
> On Wed, Apr 18, 2018 at 09:39:02AM +0200, Daniel Vetter wrote:
>> On Wed, Apr 18, 2018 at 5:58 AM, Keith Packard wrote:
>> > I'd also encourage using a single unit for all of these values,
>> > preferably nanoseconds. Absolute times should al
Hi Alex,
On 30 March 2018 at 15:47, Alex Deucher wrote:
> On Fri, Mar 30, 2018 at 10:11 AM, Daniel Stone wrote:
>> I intend to remove create_handle when all drivers are converted over
>> to placing BOs directly inside drm_framebuffer. For most drivers
>> there's a rel
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Signed-off-by: Daniel Stone
Cc: Alex Deucher
Cc: Christian
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Signed-off-by: Daniel Stone
Cc: Alex Deucher
Cc: Christian
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Signed-off-by: Daniel Stone
Cc: Alex Deucher
Cc: Christian
Hi,
I've been working on a getfb2[0] ioctl, which amongst other things
supports multi-planar framebuffers as well as modifiers. getfb
currently calls the framebuffer's handle_create hook, which doesn't
support multiple planes.
Thanks to Noralf's recent work, drivers can just store GEM objects
dire
Hi,
On 24 April 2017 at 15:26, Ville Syrjälä wrote:
> On Mon, Apr 24, 2017 at 04:54:25PM +0900, Michel Dänzer wrote:
>> On 24/04/17 04:36 PM, Gerd Hoffmann wrote:
>> > When running in opengl mode there will be a hardware-specific mesa
>> > driver in userspace, which will either know what the gpu
Hi Harry,
I've been loathe to jump in here, not least because both cop roles
seem to be taken, but ...
On 13 December 2016 at 01:49, Harry Wentland wrote:
> On 2016-12-11 09:57 PM, Dave Airlie wrote:
>> On 8 December 2016 at 12:02, Harry Wentland wrote:
>> Sharing code is a laudable goal and I a
On 4 August 2016 at 11:01, Michel Dänzer wrote:
> On 04.08.2016 18:51, Daniel Stone wrote:
>> On 4 August 2016 at 04:39, Michel Dänzer wrote:
>>> Patch 6 extends the ioctl with new flags, which allow userspace to
>>> explicitly specify the target vblank seqno. T
Hi,
On 4 August 2016 at 04:39, Michel Dänzer wrote:
> Patch 6 extends the ioctl with new flags, which allow userspace to
> explicitly specify the target vblank seqno. This can also avoid delaying
> flips in some cases where we are already in the target vertical blank
> period when the ioctl is ca
61 matches
Mail list logo
