On Wed, 21 Jul 2021 06:49:32 +
Simon Ser wrote:
> It's not obvious what the fields mean and how they should be used.
> The most important detail is the link to drm_property.flags, which
> describes how property types work.
>
> Signed-off-by: Simon Ser
> Cc: Pekka
d-off-by: Simon Ser
> > Cc: Pekka Paalanen
> > Cc: Daniel Vetter
> > Cc: Leandro Ribeiro
> > ---
> > include/drm/drm_property.h | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/include/drm/drm_property.h b/include/drm/drm_p
On Wed, 21 Jul 2021 13:55:07 -0400
Sean Paul wrote:
> From: Sean Paul
>
> Hi all,
> I just had the pleasure of rebasing this set on our CrOS downstream
> kernel and wanted to resend it for consideration once again. There
> hasn't been any resistence to the set AFAIK, just perhaps not enough
> m
On Thu, 22 Jul 2021 09:48:00 -0400
Sean Paul wrote:
> On Thu, Jul 22, 2021 at 3:49 AM Pekka Paalanen wrote:
> >
> > On Wed, 21 Jul 2021 13:55:07 -0400
> > Sean Paul wrote:
> >
> > > From: Sean Paul
> > >
> > > Hi all,
> > > I ju
ind out why a CRTC gets magically
> > disabled.
> >
> > v2: make log message more explicit, add log messages to
> > drm_framebuffer_remove (Daniel)
> >
> > Signed-off-by: Simon Ser
> > Cc: Daniel Vetter
>
> Looks like some very useful debugging logging.
On Mon, 26 Jul 2021 07:50:32 +
Simon Ser wrote:
> Since there's no struct to attach the docs to, document the IOCTL
> definition.
>
> Signed-off-by: Simon Ser
> Cc: Daniel Vetter
> Cc: Pekka Paalanen
> Cc: Leandro Ribeiro
> ---
> include/uapi/drm/drm.h |
On Wed, 28 Jul 2021 15:31:41 +0200
Christian König wrote:
> Am 28.07.21 um 15:24 schrieb Michel Dänzer:
> > On 2021-07-28 3:13 p.m., Christian König wrote:
> >> Am 28.07.21 um 15:08 schrieb Michel Dänzer:
> >>> On 2021-07-28 1:36 p.m., Christian König wrote:
> At least AMD hardware is
On Wed, 28 Jul 2021 16:30:13 +0200
Christian König wrote:
> Am 28.07.21 um 15:57 schrieb Pekka Paalanen:
> > On Wed, 28 Jul 2021 15:31:41 +0200
> > Christian König wrote:
> >
> >> Am 28.07.21 um 15:24 schrieb Michel Dänzer:
> >>> On 2021-07-28 3:1
On Thu, 29 Jul 2021 10:43:16 +0200
Christian König wrote:
> Am 29.07.21 um 10:23 schrieb Pekka Paalanen:
> > On Wed, 28 Jul 2021 16:30:13 +0200
> > Christian König wrote:
> >
> >> Am 28.07.21 um 15:57 schrieb Pekka Paalanen:
> >>> On Wed, 28 Jul
On Thu, 29 Jul 2021 11:03:36 +0200
Daniel Vetter wrote:
> On Thu, Jul 29, 2021 at 10:17:43AM +0200, Michel Dänzer wrote:
> > On 2021-07-29 9:09 a.m., Daniel Vetter wrote:
> > > On Wed, Jul 28, 2021 at 08:34:13AM -0700, Rob Clark wrote:
> > >> On Wed, Jul 28, 2021 at 6:24 AM Michel Dänzer
>
On Thu, 29 Jul 2021 12:14:18 +0200
Christian König wrote:
> Am 29.07.21 um 11:15 schrieb Pekka Paalanen:
> >
> > If the app happens to be frozen (e.g. some weird bug in fence handling
> > to make it never ready, or maybe it's just bugged itself and never
> >
On Thu, 29 Jul 2021 13:43:20 +0200
Christian König wrote:
> Am 29.07.21 um 13:00 schrieb Pekka Paalanen:
> > On Thu, 29 Jul 2021 12:14:18 +0200
> > Christian König wrote:
> >
> >> Am 29.07.21 um 11:15 schrieb Pekka Paalanen:
> >>> If the app ha
On Thu, 29 Jul 2021 14:18:29 +0200
Daniel Vetter wrote:
> On Thu, Jul 29, 2021 at 12:37:32PM +0300, Pekka Paalanen wrote:
> > On Thu, 29 Jul 2021 11:03:36 +0200
> > Daniel Vetter wrote:
> >
> > > On Thu, Jul 29, 2021 at 10:17:43AM +0200, Michel Dänzer wrote:
On Thu, 29 Jul 2021 15:41:09 +0200
Christian König wrote:
> Am 29.07.21 um 14:49 schrieb Pekka Paalanen:
> > On Thu, 29 Jul 2021 13:43:20 +0200
> > Christian König wrote:
> >
> >> Am 29.07.21 um 13:00 schrieb Pekka Paalanen:
> >>> On Thu, 29 Jul
o force-probe a connector
> anymore. Instead, KMS will perform a regular read-only connector
> query.
>
> Signed-off-by: Simon Ser
> Cc: Daniel Vetter
> Cc: Pekka Paalanen
Hi,
seems like a good idea to me.
Acked-by: Pekka Paalanen
Btw. can force-probe be triggered via sysfs as we
On Mon, 5 Apr 2021 11:41:50 +0530
Sumera Priyadarsini wrote:
> This patchset adds support for emulating virtual hardware with VKMS.
> The virtual hardware mode can be enabled by using the following command
> while loading the module:
> sudo modprobe vkms enable_virtual_hw=1
Hi,
every ti
On Wed, 07 Apr 2021 07:16:30 +
Simon Ser wrote:
> On Wednesday, April 7th, 2021 at 9:02 AM, Pekka Paalanen
> wrote:
>
> > Btw. can force-probe be triggered via sysfs as well and does it require
> > root privs?
>
> sysfs can force-probe like so:
>
>
Hi all,
with display servers proliferating thanks to Wayland, and the Linux
kernel exposing only a very limited set of information based on EDID
(rightfully so!), the need to interpret EDID blobs is spreading even
more. I would like to start the discussion about starting a project to
develop a sha
On Thu, 08 Apr 2021 08:39:10 +
Simon Ser wrote:
> On Wednesday, April 7th, 2021 at 3:51 PM, Ville Syrjälä
> wrote:
>
> > > + * To find out the list of formats that support modifiers, userspace
> > > + * must use the plane IN_FORMATS blob property.
> > >*/
> >
> > Addfb2+modifiers p
On Thu, 8 Apr 2021 13:30:16 +0200
Daniel Vetter wrote:
> On Thu, Apr 08, 2021 at 12:59:19PM +0300, Pekka Paalanen wrote:
> > The point of these documentation patches is to establish the convention
> > that:
> >
> > - drm_mode_get_plane::format_type_ptr is the
On Thu, 08 Apr 2021 16:49:37 +0300
Jani Nikula wrote:
> Anyway, this is only tangentially related to the library. I just think
> we need to take DisplayID better into account also in the *users* of the
> library, as they shouldn't really even look at the EDID if the plain
> DisplayID is there, pe
On Thu, 8 Apr 2021 17:39:22 +0300
Ville Syrjälä wrote:
> On Thu, Apr 08, 2021 at 04:57:51PM +0300, Pekka Paalanen wrote:
> > On Thu, 8 Apr 2021 13:30:16 +0200
> > Daniel Vetter wrote:
> >
> > > > Is it also so that passing MOD_INVALID to the explicit
t some also meant that only implied modifiers are
> acceptable (because actually none of the planes registered supported
> modifiers).
>
> Now that this is all done consistently across all drivers, document
> the rules and enforce it in the drm core.
>
> Cc: Pekka Paalanen
On Tue, 13 Apr 2021 16:11:29 +0200
Daniel Vetter wrote:
> On Tue, Apr 13, 2021 at 02:56:02PM +0300, Pekka Paalanen wrote:
> > On Tue, 13 Apr 2021 11:49:03 +0200
> > Daniel Vetter wrote:
> >
> > > It's very confusing for userspace to have to deal with i
pability a link (Simon)
> - Note that all is lost before 5.1.
>
> Acked-by: Maxime Ripard
> Cc: Simon Ser
> Reviewed-by: Lucas Stach
> Cc: Pekka Paalanen
> Signed-off-by: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> C
On Wed, 21 Apr 2021 10:37:11 +
wrote:
> On 4/21/21 11:15 AM, Daniel Vetter wrote:
> > On Tue, Apr 20, 2021 at 11:37:41AM +, peter.enderb...@sony.com wrote:
> >> But I dont think they will. dma-buf does not have to be mapped to a
> >> process,
> >> and the case of vram, it is not cover
On Thu, 22 Apr 2021 15:10:04 -0300
Leandro Ribeiro wrote:
> Add a small description and document struct fields of
> drm_mode_get_plane.
>
> Signed-off-by: Leandro Ribeiro
> ---
> include/uapi/drm/drm_mode.h | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/include/uap
On Fri, 23 Apr 2021 18:30:33 -0300
Leandro Ribeiro wrote:
> On 4/23/21 8:11 AM, Pekka Paalanen wrote:
> > On Thu, 22 Apr 2021 15:10:04 -0300
> > Leandro Ribeiro wrote:
> >
> >> Add a small description and document struct fields of
> >> drm_mode_get_
On Sat, 24 Apr 2021 05:25:31 -0300
Melissa Wen wrote:
> Add support for composing XRGB888 planes in addition to the ARGB
> format. In the case of an XRGB plane at the top, the composition consists
> of copying the RGB values of a pixel from src to dst and clearing alpha
> channel, without the
On Sat, 24 Apr 2021 05:26:10 -0300
Melissa Wen wrote:
> Add support to overlay plane, in addition to primary and cursor
> planes. In this approach, the plane composition still requires an
> active primary plane and planes are composed associatively in the
> order: (primary <- overlay) <- cursor
>
On Mon, 26 Apr 2021 14:30:53 -0300
Leandro Ribeiro wrote:
> On 4/26/21 7:58 AM, Simon Ser wrote:
> > On Monday, April 26th, 2021 at 9:36 AM, Pekka Paalanen
> > wrote:
> >
> >>>> This should probably explain what the bits in the mask correspond to.
>
On Mon, 26 Apr 2021 14:31:28 -0300
Melissa Wen wrote:
> On 04/26, Daniel Vetter wrote:
> > On Mon, Apr 26, 2021 at 11:03:15AM +0300, Pekka Paalanen wrote:
> > > On Sat, 24 Apr 2021 05:25:31 -0300
> > > Melissa Wen wrote:
> > >
> > > > Add sup
On Mon, 26 Apr 2021 13:38:49 -0400
Harry Wentland wrote:
> ## Introduction
>
> We are looking to enable HDR support for a couple of single-plane and
> multi-plane scenarios. To do this effectively we recommend new
> interfaces to drm_plane. Below I'll give a bit of background on HDR
> and why we
On Wed, 28 Apr 2021 07:21:28 +
Simon Ser wrote:
> > A solution to make this configuration generic and exposed by the kernel
> > would standardise this across Linux
>
> Having a KMS property for this makes sense to me.
>
> Chatting with Jani on IRC, it doesn't seem like there's any EDID or
Adding the previous list of CCs.
On Thu, 29 Apr 2021 10:32:58 +
"Sharma, Shashank" wrote:
> Hello Pekka, Daniel
>
> As discussed over IRC, I have prepared the first version of the EDID parsing
> library, which is hosted here:
> https://github.com/contactshashanksharma/libedid/tree/master
>
On Mon, 26 Apr 2021 22:08:55 +0300
Ville Syrjälä wrote:
> On Mon, Apr 26, 2021 at 02:56:26PM -0400, Harry Wentland wrote:
> > On 2021-04-26 2:07 p.m., Ville Syrjälä wrote:
> > > On Mon, Apr 26, 2021 at 01:38:50PM -0400, Harry Wentland wrote:
> > >> From: Bhawanpreet Lakha
> > >>
> > >> Add t
On Wed, 28 Apr 2021 13:24:27 +0530
Shashank Sharma wrote:
> Assuming these details, A compositor will look for DRM color properties like
> these:
>
> 1. Degamma plane property : To make buffers linear for Gamut mapping
>
> 2. Gamut mapping plane property: To gamut map SRGB buffer to BT2020
>
On Thu, 25 Mar 2021 12:12:09 -0400
Alex Deucher wrote:
> + dri-devel
>
> I don't think it's currently exposed anywhere.
>
> Alex
>
> On Wed, Mar 24, 2021 at 5:11 AM Werner Sembach
> wrote:
> >
> > Hello,
> >
> > is the information which color mode is currently in used for a display
> > (RGB
On Sat, 27 Mar 2021 11:26:26 +
Paul Cercueil wrote:
> It has two mutually exclusive background planes (same Z level) + one
> overlay plane.
What's the difference between the two background planes?
How will generic userspace know to pick the "right" one?
Thanks,
pq
> Le sam. 27 mars 2021
On Mon, 29 Mar 2021 12:41:00 +0100
Paul Cercueil wrote:
> Hi,
>
> Le lun. 29 mars 2021 à 11:15, Pekka Paalanen a
> écrit :
> > On Sat, 27 Mar 2021 11:26:26 +
> > Paul Cercueil wrote:
> >
> >> It has two mutually exclusive background planes (
On Mon, 29 Mar 2021 15:36:27 +
Simon Ser wrote:
> On Monday, March 29th, 2021 at 5:32 PM, Paul Cercueil
> wrote:
>
> > Making the second plane an overlay would break the ABI, which is never
> > something I'm happy to do; but I'd prefer to do it now than later.
>
> Yeah, I wonder if some
On Mon, 4 Jan 2021 16:07:58 -0500
Aurabindo Pillai wrote:
> [Why&How]
> Adds a module parameter to enable experimental freesync video mode modeset
> optimization. Enabling this mode allows the driver to skip a full modeset when
> freesync compatible modes are requested by the userspace. This para
xpectations for primary and cursor planes for
> non-legacy userspace. Note that these docs are for driver developers,
> not userspace developers, so internal kernel APIs are mentionned.
>
> Signed-off-by: Simon Ser
> Reviewed-by: Daniel Vetter
> Cc: Pekka Paalanen
>
>
> v4: fixing rebase gone wrong
>
> v5:
> - Fix typo (Daniel)
> - Mention CAP_ATOMIC instead of CAP_UNIVERSAL_PLANES when referring to
> atomic test-only commits (Daniel)
> - Add newlines at end of sections (Daniel)
>
> Signed-off-by: Simon Ser
> Reviewed-by
On Mon, 18 Jan 2021 09:36:47 -0500
Aurabindo Pillai wrote:
> On Thu, 2021-01-14 at 11:14 +0200, Pekka Paalanen wrote:
> >
> > Hi,
> >
> > please document somewhere that ends up in git history (commit
> > message,
> > code comments, description of the pa
On Tue, 19 Jan 2021 10:50:26 -0500
Aurabindo Pillai wrote:
> Changes in V5
> =
>
> * More info in commit messages on the rationale of changes being added
> to the kernel.
> * Minor fixes
Hi,
thank you for adding the explanations in the commit messages I asked
for. It is now up to D
On Wed, 27 Jan 2021 12:01:55 +0100
Christian König wrote:
> Somewhat correct. This interface here really doesn't make sense since
> the file descriptor representation of DMA-buf is only meant to be used
> for short term usage.
>
> E.g. the idea is that you can export a DMA-buf fd from your dev
On Fri, 29 Jan 2021 13:18:01 +0100
Christian König wrote:
> Am 28.01.21 um 11:01 schrieb Pekka Paalanen:
> > On Wed, 27 Jan 2021 12:01:55 +0100
> > Christian König wrote:
> >
> >> Somewhat correct. This interface here really doesn't make sense since
> &g
mic
completion events.
Can that also be asserted somehow, or does this already do that?
Thanks,
pq
> Cc: Ville Syrjälä
> Cc: Simon Ser
> Cc: Pekka Paalanen
> Cc: Daniel Stone
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Manasi Navare
>
On Wed, 3 Mar 2021 12:44:33 -0800
"Navare, Manasi" wrote:
> On Wed, Mar 03, 2021 at 10:47:44AM +0200, Pekka Paalanen wrote:
> > On Tue, 2 Mar 2021 12:41:32 -0800
> > Manasi Navare wrote:
> >
> > > In case of a modeset where a mode gets split across mu
On Thu, 4 Mar 2021 23:10:57 +0100
Simon Ser wrote:
> Document all of the DRM_CAP_* defines.
>
> Signed-off-by: Simon Ser
> Cc: Daniel Vetter
> Cc: Pekka Paalanen
> ---
> include/uapi/drm/drm.h | 100 +++--
> 1 file changed, 96 in
On Thu, 4 Mar 2021 09:43:22 +0530
Hardik Panchal wrote:
> Hello Sir/Madam,
>
> I am trying to render some stuff using DRM with Qt GUI application and
> decoded stream from Intel H/w decoder.
>
> I have two applications one is for GUI content and another one is for
> decoded video streams. While
On Sat, 06 Mar 2021 10:56:49 +
Simon Ser wrote:
> On Friday, March 5th, 2021 at 9:28 AM, Pekka Paalanen
> wrote:
>
> > > +/**
> > > + * DRM_CAP_DUMB_PREFERRED_DEPTH
> > > + *
> > > + * The preferred depth (in bits) for dumb buffers.
> &
On Mon, 8 Mar 2021 16:52:58 -0800
"Navare, Manasi" wrote:
> On Thu, Mar 04, 2021 at 10:42:23AM +0200, Pekka Paalanen wrote:
> > On Wed, 3 Mar 2021 12:44:33 -0800
> > "Navare, Manasi" wrote:
> >
> > > On Wed, Mar 03, 2021 at 10:47:44AM +02
RIME_FD_TO_HANDLE and DRM_IOCTL_PRIME_HANDLE_TO_FD
> - Explicitly reference CLOCK_REALTIME and CLOCK_MONOTONIC
> - Make it clear DRM_CAP_CRTC_IN_VBLANK_EVENT applies to both DRM_EVENT_VBLANK
> and DRM_EVENT_FLIP_COMPLETE
>
> Signed-off-by: Simon Ser
> Cc: Daniel Vetter
> Cc: Pekka Paala
pability a link (Simon)
> - Note that all is lost before 5.1.
>
> Acked-by: Maxime Ripard
> Cc: Simon Ser
> Reviewed-by: Lucas Stach
> Cc: Pekka Paalanen
> Signed-off-by: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> C
On Wed, 28 Apr 2021 18:36:50 -0300
Leandro Ribeiro wrote:
> In this patch we add a section to document what userspace should do to
> find out the CRTC index. This is important as there are multiple places
> in the documentation that need this, so it's better to just point to
> this section and av
On Wed, 28 Apr 2021 18:36:51 -0300
Leandro Ribeiro wrote:
> Add a small description and document struct fields of
> drm_mode_get_plane.
>
> Signed-off-by: Leandro Ribeiro
Hi,
thanks a lot for revising these.
> ---
> include/uapi/drm/drm_mode.h | 22 ++
> 1 file changed,
On Thu, 29 Apr 2021 13:49:58 +0300
Pekka Paalanen wrote:
> Adding the previous list of CCs.
>
> On Thu, 29 Apr 2021 10:32:58 +
> "Sharma, Shashank" wrote:
>
> > Hello Pekka, Daniel
> >
> > As discussed over IRC, I have prepared the first version
On Mon, 10 May 2021 17:47:01 -0400
Alex Deucher wrote:
> On Fri, May 7, 2021 at 3:27 PM Werner Sembach
> wrote:
> >
> > xrandr --prop and other userspace info tools have currently no way of
> > telling which color configuration is used on HDMI and DP ports.
> >
> > The ongoing transsition from
On Tue, 11 May 2021 12:03:30 +0200
Werner Sembach wrote:
> Am 11.05.21 um 10:07 schrieb Pekka Paalanen:
> > On Mon, 10 May 2021 17:47:01 -0400
> > Alex Deucher wrote:
> >
> >> On Fri, May 7, 2021 at 3:27 PM Werner Sembach
> >> wrote:
> >>>
On Tue, 11 May 2021 18:44:17 +0200
Daniel Vetter wrote:
> On Mon, May 10, 2021 at 12:06:05PM -0700, Rob Clark wrote:
> > On Mon, May 10, 2021 at 10:44 AM Daniel Vetter wrote:
> > >
> > > On Mon, May 10, 2021 at 6:51 PM Rob Clark wrote:
> > > >
> > > > On Mon, May 10, 2021 at 9:14 AM Daniel
On Wed, 12 May 2021 10:44:29 +0200
Daniel Vetter wrote:
> On Wed, May 12, 2021 at 11:23:30AM +0300, Pekka Paalanen wrote:
> > On Tue, 11 May 2021 18:44:17 +0200
> > Daniel Vetter wrote:
> >
> > > On Mon, May 10, 2021 at 12:06:05PM -0700, Rob Clark wrote:
>
On Wed, 12 May 2021 09:50:14 -0300
Leandro Ribeiro wrote:
> On 5/6/21 5:50 AM, Pekka Paalanen wrote:
> > On Wed, 28 Apr 2021 18:36:50 -0300
> > Leandro Ribeiro wrote:
> >
> >> In this patch we add a section to document what userspace should do to
> &g
On Wed, 12 May 2021 07:57:26 -0700
Rob Clark wrote:
> On Wed, May 12, 2021 at 1:23 AM Pekka Paalanen wrote:
> >
> > On Tue, 11 May 2021 18:44:17 +0200
> > Daniel Vetter wrote:
> >
> > > On Mon, May 10, 2021 at 12:06:05PM -0700, Rob Clark wrote:
>
On Fri, 14 May 2021 17:04:51 -0400
Harry Wentland wrote:
> On 2021-04-30 8:53 p.m., Sebastian Wick wrote:
> > On 2021-04-26 20:56, Harry Wentland wrote:
...
> >> Another reason I'm proposing to define the color space (and gamma) of
> >> a plane is to make this explicit. Up until the color spa
On Fri, 14 May 2021 17:05:11 -0400
Harry Wentland wrote:
> On 2021-04-27 10:50 a.m., Pekka Paalanen wrote:
> > On Mon, 26 Apr 2021 13:38:49 -0400
> > Harry Wentland wrote:
...
> >> ## Mastering Luminances
> >>
> >> Now we are able to use the PQ 2084 E
On Mon, 17 May 2021 15:39:03 -0400
Vitaly Prosyak wrote:
> On 2021-05-17 12:48 p.m., Sebastian Wick wrote:
> > On 2021-05-17 10:57, Pekka Paalanen wrote:
> >> On Fri, 14 May 2021 17:05:11 -0400
> >> Harry Wentland wrote:
> >>
> >>>
On Fri, 14 May 2021 17:07:14 -0400
Harry Wentland wrote:
> We are looking to enable HDR support for a couple of single-plane and
> multi-plane scenarios. To do this effectively we recommend new interfaces
> to drm_plane. The first patch gives a bit of background on HDR and why we
> propose these
On Tue, 18 May 2021 10:32:48 -0400
Harry Wentland wrote:
> On 2021-05-17 4:34 a.m., Pekka Paalanen wrote:
> > On Fri, 14 May 2021 17:04:51 -0400
> > Harry Wentland wrote:
> >
> >> On 2021-04-30 8:53 p.m., Sebastian Wick wrote:
> >>>
On Tue, 18 May 2021 10:19:25 -0400
Harry Wentland wrote:
> On 2021-05-18 3:56 a.m., Pekka Paalanen wrote:
> > On Mon, 17 May 2021 15:39:03 -0400
> > Vitaly Prosyak wrote:
> >
> >> On 2021-05-17 12:48 p.m., Sebastian Wick wrote:
...
> >>> I susp
On Wed, 12 May 2021 16:04:16 +0300
Ville Syrjälä wrote:
> On Wed, May 12, 2021 at 02:06:56PM +0200, Werner Sembach wrote:
> > Hello,
> >
> > In addition to the existing "max bpc", and "Broadcast RGB/output_csc" drm
> > properties I propose 4 new properties:
> > "preferred pixel encoding", "acti
On Wed, 19 May 2021 11:53:37 +0300
Pekka Paalanen wrote:
...
> TL;DR:
>
> I would summarise my comments so far into these:
>
> - Telling the kernel the color spaces and letting it come up with
> whatever color transformation formula from those is not enough,
> becau
On Wed, 19 May 2021 10:30:40 -0300
Leandro Ribeiro wrote:
> On 5/6/21 6:10 AM, Pekka Paalanen wrote:
> > On Wed, 28 Apr 2021 18:36:51 -0300
> > Leandro Ribeiro wrote:
> >
> >> Add a small description and document struct fields of
> >> drm_mode_get_
On Wed, 19 May 2021 16:49:35 +0300
Ville Syrjälä wrote:
> On Wed, May 19, 2021 at 12:34:05PM +0300, Pekka Paalanen wrote:
> > On Wed, 12 May 2021 16:04:16 +0300
> > Ville Syrjälä wrote:
> >
> > > On Wed, May 12, 2021 at 02:06:56PM +0200, Werner
ys enable atomic API")
>
> DRM_CLIENT_CAP_ASPECT_RATIO
> 7595bda2fb43 ("drm: Add DRM client cap for aspect-ratio")
>
> DRM_CLIENT_CAP_WRITEBACK_CONNECTORS
> d67b6a206507 ("drm: writeback: Add client capability for exposing writeback
> connectors")
>
On Tue, 18 May 2021 11:14:47 +
Simon Ser wrote:
> Make it clear that the client is responsible for enabling ATOMIC
> prior to enabling WRITEBACK_CONNECTORS. Linkify the reference to
> ATOMIC.
>
> Signed-off-by: Simon Ser
> Cc: Daniel Vetter
> Cc: Daniel Stone
*
> * If set to 1, the DRM core will provide aspect ratio information in modes.
> + * See ``DRM_MODE_FLAG_PIC_AR_*``.
> */
> #define DRM_CLIENT_CAP_ASPECT_RATIO4
>
Good.
Acked-by: Pekka Paalanen
Thanks,
pq
pgpcQLIt2WH3a.pgp
Description: OpenPGP digital signature
On Mon, 30 Nov 2020 10:23:04 +
Simon Ser wrote:
> On Monday, November 30, 2020 2:03 AM, Leandro Ribeiro
> wrote:
>
> > In userspace we can use drmGetConnector() or drmGetConnectorCurrent() in
> > order to retrieve connector information. The difference between both is
> > that the former re
On Mon, 30 Nov 2020 11:16:56 +
Simon Ser wrote:
> On Monday, November 30, 2020 12:13 PM, Pekka Paalanen
> wrote:
>
> > where is the discussion?
>
> https://dri.freedesktop.org/~cbrill/dri-log/?channel=intel-gfx&date=2020-11-26
Thanks, I read that.
> >
On Mon, 30 Nov 2020 12:20:08 +
Simon Ser wrote:
> CC Daniel and Ville
>
> On Monday, November 30, 2020 12:24 PM, Pekka Paalanen
> wrote:
>
> > > > Please record the justitication for that patch in its commit message.
> > > > "Can't"
e should force-probe, and when it shouldn't (Daniel)
>
> Signed-off-by: Simon Ser
> Fixes: 2ac5ef3b2362 ("drm: document drm_mode_get_connector")
> Reviewed-by: Daniel Vetter
> Cc: Pekka Paalanen
> Cc: Ville Syrjala
> ---
> include/uapi/drm/drm_mode.h | 13
On Wed, 2 Dec 2020 08:55:52 +0100
Thomas Zimmermann wrote:
> Hi
>
> Am 01.12.20 um 12:20 schrieb Mikulas Patocka:
> >
> >
> > On Tue, 1 Dec 2020, Thomas Zimmermann wrote:
> >
...
> >> And why can links not run as DRM master mode? If it renders to the
> >> terminal,
> >> it should act lik
On Wed, 2 Dec 2020 23:25:58 +0100
Daniel Vetter wrote:
> Also kinda disappointing that drm_fourcc.h includes drm.h and isn't
> standalone, but I guess that sailed (at least for linux).
Hi,
FWIW, libweston core needs drm_fourcc.h too, even if nothing would ever
use DRM or need libdrm otherwise.
On Thu, 3 Dec 2020 21:45:14 +0100
Daniel Vetter wrote:
> On Thu, Dec 3, 2020 at 7:55 PM James Park wrote:
> >
> > The trailing underscore for DRM_FOURCC_STANDALONE_ isn't
> > intentional, right? Should I put all the integer types, or just the
> > ones that are used in that file?
>
> Yeah tha
On Sun, 06 Dec 2020 15:24:29 +
Simon Ser wrote:
> Sorry, I think I lost track of this thread at some point and forgot
> about it. That said…
>
> On Friday, August 7th, 2020 at 3:06 PM, Daniel Vetter wrote:
>
> > On Fri, Aug 07, 2020 at 12:38:02PM +0300, Pekka Paala
include
order when DRM_FOURCC_STANDALONE is defined anyway.
Thanks.
pq
> On Fri, Dec 4, 2020 at 7:58 AM Daniel Vetter wrote:
>
> > On Fri, Dec 4, 2020 at 9:12 AM Pekka Paalanen wrote:
> > >
> > > On Thu, 3 Dec 2020 21:45:14 +0100
> > > Daniel Vetter wr
FOURCC_STANDALONE would bring?
Thanks,
pq
>
> Thanks,
> James
>
> On Mon, Dec 7, 2020 at 12:51 AM Pekka Paalanen wrote:
>
> > On Fri, 4 Dec 2020 11:07:41 -0800
> > James Park wrote:
> >
> > > I could adjust the block to look like this:
> > &
On Mon, 7 Dec 2020 12:35:14 +0200
Pekka Paalanen wrote:
> On Mon, 7 Dec 2020 01:08:58 -0800
> James Park wrote:
>
> > I'm not completely sure what you're saying, but doesn't drm_base_types.h
> > (now drm_basic_types.h) make things robust to header order? Th
On Mon, 07 Dec 2020 10:53:49 +
Simon Ser wrote:
> On Monday, December 7th, 2020 at 11:49 AM, James Park
> wrote:
>
> > That would work, but that's kind of an annoying requirement. I would
> > prefer the header to be self-sufficient.
>
> I don't want to make it more confusing than before
On Wed, 9 Dec 2020 01:36:37 +0100
Daniel Vetter wrote:
> On Mon, Dec 07, 2020 at 09:10:00AM +, Simon Ser wrote:
> > On Monday, December 7th, 2020 at 9:45 AM, Pekka Paalanen
> > wrote:
> >
> > > > > > > > - * Cursor and ov
gt; >
> > Reword the planes description to make it clear the DRM-internal
> > drm_crtc.primary and drm_crtc.cursor planes are for legacy uAPI.
> >
> > [1]: https://github.com/swaywm/wlroots/pull/2333#discussion_r456788057
> >
> > Signed-off-by: Simon Ser
> >
ed-off-by: James Park
> Acked-by: Simon Ser
Looks good to me.
Reviewed-by: Pekka Paalanen
But with the caveat that I didn't actually test this.
Thanks,
pq
> ---
> include/uapi/drm/drm.h | 12 ++---
> include/uapi/drm/drm_basic_types.h | 52
> +
On Fri, 11 Dec 2020 09:56:07 +0530
Shashank Sharma wrote:
> Hello Simon,
>
> Hope you are doing well,
>
> I was helping out Aurabindo and the team with the design, so I have
> taken the liberty of adding some comments on behalf of the team,
> Inline.
>
> On 11/12/20 3:31 am, Simon Ser wrote:
>
On Fri, 11 Dec 2020 11:28:36 +0100
Christian König wrote:
> Am 11.12.20 um 10:55 schrieb Pekka Paalanen:
> > On Fri, 11 Dec 2020 09:56:07 +0530
> > Shashank Sharma wrote:
> >
> >> Hello Simon,
> >>
> >> Hope you are doing well,
> >&g
On Mon, 14 Dec 2020 21:57:25 +0100
Christian König wrote:
> Am 11.12.20 um 13:20 schrieb Pekka Paalanen:
> > On Fri, 11 Dec 2020 11:28:36 +0100
> > Christian König wrote:
> >
> >> Am 11.12.20 um 10:55 schrieb Pekka Paalanen:
> >>> On Fri, 11 Dec
On Tue, 29 Jun 2021 08:12:54 +
Simon Ser wrote:
> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen
> wrote:
>
> > yes, I think this makes sense, even if it is a property that one can't
> > tell for sure what it does before hand.
> >
> > Usin
On Tue, 29 Jun 2021 13:02:05 +0200
Werner Sembach wrote:
> Am 28.06.21 um 19:03 schrieb Werner Sembach:
> > Am 18.06.21 um 11:11 schrieb Werner Sembach:
> >> Add a new general drm property "active bpc" which can be used by graphic
> >> drivers to report the applied bit depth per pixel back to u
On Tue, 29 Jun 2021 13:39:18 +0200
Werner Sembach wrote:
> Am 29.06.21 um 13:17 schrieb Pekka Paalanen:
> > On Tue, 29 Jun 2021 08:12:54 +
> > Simon Ser wrote:
> >
> >> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen
> >> wrote:
> >>
On Wed, 30 Jun 2021 11:42:10 +0200
Werner Sembach wrote:
> Am 30.06.21 um 10:21 schrieb Pekka Paalanen:
> > On Tue, 29 Jun 2021 13:02:05 +0200
> > Werner Sembach wrote:
> >
> >> Am 28.06.21 um 19:03 schrieb Werner Sembach:
> >>> Am 18.06.21 um 11
1 - 100 of 1102 matches
Mail list logo
