On Monday, December 4th, 2023 at 18:51, Abhinav Kumar
wrote:
> > Where are the IGT and userspace for this uAPI addition?
>
> Yes, we made IGT changes to test and validate this. We will post them on
> the IGT dev list shortly and CC you.
>
> We do not have a compositor change yet for this as
Acked-by: Simon Ser
On Saturday, December 2nd, 2023 at 22:41, Dmitry Baryshkov
wrote:
> On Fri, 27 Oct 2023 15:32:50 -0700, Jessica Zhang wrote:
>
> > Some drivers support hardware that have optimizations for solid fill
> > planes. This series aims to expose these capabilities to userspace as
> > some compositors
On Monday, October 30th, 2023 at 11:22, Dmitry Baryshkov
wrote:
> On Mon, 30 Oct 2023 at 12:13, Simon Ser cont...@emersion.fr wrote:
>
> > On Monday, October 30th, 2023 at 10:47, Dmitry Baryshkov
> > dmitry.barysh...@linaro.org wrote:
> >
> > > On Mon, 30 O
On Monday, October 30th, 2023 at 10:47, Dmitry Baryshkov
wrote:
> On Mon, 30 Oct 2023 at 10:19, Heikki Krogerus
> heikki.kroge...@linux.intel.com wrote:
>
> > On Mon, Oct 23, 2023 at 09:24:33PM +0300, Dmitry Baryshkov wrote:
> >
> > > On 15 September 2023 15:14:35 EEST, Heikki Krogerus
> > >
On Wednesday, October 25th, 2023 at 14:45, Dmitry Baryshkov
wrote:
> On 25/10/2023 15:29, Simon Ser wrote:
>
> > On Wednesday, October 25th, 2023 at 14:22, Johan Hovold jo...@kernel.org
> > wrote:
> >
> > > I was just going to post a patch fixing this afte
On Wednesday, October 25th, 2023 at 14:22, Johan Hovold
wrote:
> I was just going to post a patch fixing this after finally investigating
> why the DisplayPort outputs on the X13s were annoyingly identified as
> "Unknown20-1" and "Unknown20-2" instead of the expected "DP-1" and
> "DP-2".
Note,
For the uAPI:
Acked-by: Simon Ser
Thanks for fixing this!
Acked-by: Simon Ser
On Sunday, September 3rd, 2023 at 23:41, Dmitry Baryshkov
wrote:
> To facilitate this, reuse the 'PATH' property, which was used to
> describe the DP port in the DP MST configuration. Use either
> 'typec:portN' to point out to the Type-C port class device, or just
> 'typec:' if the
On Tuesday, January 31st, 2023 at 12:13, Pekka Paalanen
wrote:
> On Tue, 31 Jan 2023 10:06:39 +
> Simon Ser wrote:
>
> > On Tuesday, January 31st, 2023 at 10:25, Pekka Paalanen
> > wrote:
> >
> > > indeed, what about simply using a 1x1 framebuffer f
On Tuesday, January 31st, 2023 at 10:25, Pekka Paalanen
wrote:
> indeed, what about simply using a 1x1 framebuffer for real? Why was that
> approach rejected?
Ideally we don't want to allocate any GPU memory for the solid-fill
stuff. And if we special-case 1x1 FB creation to not be backed by
On Wednesday, January 25th, 2023 at 21:04, Thomas Zimmermann
wrote:
> Not having connectors indicates a driver bug.
Is it? What if all connectors are of the DP-MST type, ie. they are
created on-the-fly?
On Wednesday, January 11th, 2023 at 23:29, Daniel Vetter
wrote:
> On Fri, Jan 06, 2023 at 04:33:04PM -0800, Abhinav Kumar wrote:
> > Hi Daniel
> >
> > Thanks for looking into this series.
> >
> > On 1/6/2023 1:49 PM, Dmitry Baryshkov wrote:
> > > On Fri, 6 Jan 2023 at 20:41, Daniel Vetter
cc'ing Pekka and wayland-devel for userspace devs feedback on the new uAPI.
On Saturday, October 29th, 2022 at 14:08, Dmitry Baryshkov
wrote:
> On 29/10/2022 01:59, Jessica Zhang wrote:
> > Add support for COLOR_FILL and COLOR_FILL_FORMAT properties for
> > drm_plane. In addition, add support
On Saturday, October 29th, 2022 at 13:23, Dmitry Baryshkov
wrote:
> On 29/10/2022 01:59, Jessica Zhang wrote:
>
> > Add support for COLOR_FILL and COLOR_FILL_FORMAT properties for
> > drm_plane. In addition, add support for setting and getting the values
> > of these properties.
> >
> >
On Tuesday, December 21st, 2021 at 13:33, Dmitry Baryshkov
wrote:
> I'd still suggest to fix create_in_format_blob()
Yeah, I agree. I thought there were a good reason why create_in_format_blob()
behaves this way but can't find anything in the Git history, so fixing it to
behave as the
On Tuesday, December 21st, 2021 at 11:48, Dmitry Baryshkov
wrote:
> I think the fix should be applied to the generic code.
Related:
https://lore.kernel.org/dri-devel/t1g_xNE6hgj1nTQfx2UWob1wbsCAxElBvWRwNSY_EzmlEe_9WWpq8-vQKyJPK6wZY8q8BqHl-KoGwS5V91VgN8lGIl3PJt7s2fkdsRd3y70=@emersion.fr/T/#u
Reviewed-by: Simon Ser
Please ping me in a week or so if nobody objected and this isn't merged.
On Thursday, September 9th, 2021 at 18:31, Rob Clark
wrote:
> Yes, I think it would.. and "dma-buf/sync_file: Add SET_DEADLINE
> ioctl" adds such an ioctl.. just for the benefit of igt tests at this
> point, but the thought was it would be also used by compositors that
> are doing such frame
Out of curiosity, would it be reasonable to allow user-space (more
precisely, the compositor) to set the deadline via an IOCTL without
actually performing an atomic commit with the FB?
Some compositors might want to wait themselves for FB fence completions
to ensure a client doesn't block the
21 matches
Mail list logo
