State that the "KMS Properties" section is mainly for user-space
developers.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
---
Documentation/gpu/drm-kms.rst | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/d
Move drm_blend.c function reference from the KMS properties section to
the plane abstraction section. This makes the KMS properties section
more readable for user-space developers.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
---
Documentation/gpu/drm-kms.rst | 9 ++---
1
Add a new entry for "type" in the section for standard plane properties.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
---
drivers/gpu/drm/drm_plane.c | 39 +
1 file changed, 35 insertions(+), 4 deletions(-)
diff --git a/drive
Re-organize and improve plane property docs.
Simon Ser (8):
drm/doc: rename FB_DAMAGE_CLIPS section
drm/doc: move composition function docs to new section
drm/doc: move damage tracking functions to new section
drm/doc: move color management functions under CRTC section
drm/doc: the KMS
Move drm_color_mgmt function reference from the KMS properties
section to the CRTC abstraction section. This makes the KMS
properties section more readable for user-space developers.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
---
Documentation/gpu/drm-kms.rst | 15
On Wednesday, December 16th, 2020 at 10:19 PM, Daniel Vetter
wrote:
> On Wed, Dec 16, 2020 at 09:22:21PM +0100, Simon Ser wrote:
> > The docs for enum drm_plane_type mention legacy IOCTLs, however the
> > plane type is not tied to legacy IOCTLs, the drm_cursor.primary and
> &
On Wednesday, December 16th, 2020 at 10:23 PM, Daniel Vetter
wrote:
> > + * type:
> > + * Immutable property describing the type of the plane.
> > + *
> > + * For user-space which has enabled the
> > &DRM_CLIENT_CAP_UNIVERSAL_PLANES
>
> While we're at this: Does the kerneldoc for this c
On Thursday, December 17th, 2020 at 11:50 AM, Daniel Vetter
wrote:
> > > > @@ -557,19 +561,20 @@ enum drm_plane_type {
> > > > /**
> > > > * @DRM_PLANE_TYPE_PRIMARY:
> > > > *
> > > > -* Primary planes represent a "main" plane for a CRTC. Primary
> > > > planes
> > > > -*
On Thursday, December 17th, 2020 at 11:52 AM, Daniel Vetter
wrote:
> > > > + * capability, the plane type is just a hint and is mostly
> > > > superseded by
> > > > + * atomic test-only commits. The type hint can still be used to
> > > > come up
> > > > + * more easily with a plane
State that the "KMS Properties" section is mainly for user-space
developers.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
---
Documentation/gpu/drm-kms.rst | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/d
This is v2 for the series "drm/doc: improve plane property docs" [1].
The first 4 commits of v1 aren't re-sent. The last 4 commits of v2 are
new.
[1]: https://patchwork.freedesktop.org/series/85016/
Simon Ser (9):
drm/doc: the KMS properties section is for user-space devs
drm
lso many of these structures aren't really used by
modern user-space.
We can easily convert these remaining old comments to Sphinx style on a
one-by-one basis.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
---
include/uapi/drm/drm.h | 84 +
The documentation build system recognizes "struct XXX" references and
generates links for them.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
---
drivers/gpu/drm/drm_plane.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm
Add a new entry for "type" in the section for standard plane properties.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
---
drivers/gpu/drm/drm_plane.c | 52 ++---
1 file changed, 48 insertions(+), 4 deletions(-)
diff --git a/drive
Document that enabling atomic also enables universal planes and aspect
ratio modes.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
---
include/uapi/drm/drm.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
these docs are for driver developers,
not userspace developers, so internal kernel APIs are mentionned.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
---
include/drm/drm_plane.h | 29 +
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a
Introduce a new "Standard Plane Properties" section for properties
defined in drm_plane.c. Move the mis-placed IN_FORMATS docs there.
Signed-off-by: Simon Ser
Reviewed-by: Daniel Vetter
Cc: Pekka Paalanen
---
Documentation/gpu/drm-kms.rst | 6 ++
drivers/gpu/drm/drm_blen
It doesn't seem like drm.h docs are included anywhere. Render them next
to drm_mode.h, under the "Userspace API Structures" section.
This also allows references to e.g. DRM_CAP_* to be properly linkified
elsewhere in our docs.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc:
Our documentation build system chokes on \file comments. This comment
seems mostly historical and doesn't provide any useful information.
./include/uapi/drm/drm.h:2: warning: Cannot understand * \file drm.h
on line 2 - I thought it was a doc line
Signed-off-by: Simon Ser
Cc: D
Hi,
On Monday, December 21st, 2020 at 2:57 AM, Laurent Pinchart
wrote:
> I started having a look at userspace to see how this could be handled,
> searching for color management support in weston, kwin and wlroots/sway.
> All three support setting the gamma table when using the DRM/KMS
> backend
gt; Signed-off-by: Daniel Vetter
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Thomas Zimmermann
> > Cc: David Airlie
> > Cc: Daniel Vetter
>
> Anyone feeling like an ack on this one?
>From my limited understanding of fbdev, this FIXME so
Previous series: https://patchwork.freedesktop.org/series/85040/
Simon Ser (5):
drm/doc: fix drm_plane_type docs
drm/doc: document the type plane property
drm/doc: re-format drm.h file comment
drm/doc: demote old doc-comments in drm.h
drm/doc: render drm.h uapi docs
Documentation/gpu
lso many of these structures aren't really used by
modern user-space.
We can easily convert these remaining old comments to Sphinx style on a
one-by-one basis.
Signed-off-by: Simon Ser
Acked-by: Daniel Vetter
Cc: Pekka Paalanen
---
include/uapi/drm/drm.h | 84 +-
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
---
include/drm/drm_plane.h | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a
It doesn't seem like drm.h docs are included anywhere. Render them next
to drm_mode.h, under the "Userspace API Structures" section.
This also allows references to e.g. DRM_CAP_* to be properly linkified
elsewhere in our docs.
Signed-off-by: Simon Ser
Acked-by: Daniel Vetter
Cc:
Add a new entry for "type" in the section for standard plane properties.
v3: improve paragraph about mixing legacy IOCTLs with explicit usage,
not that a driver may support cursors without cursor planes (Daniel)
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
---
d
Git.
v3: keep the comment (Daniel)
Signed-off-by: Simon Ser
Acked-by: Daniel Vetter
Cc: Pekka Paalanen
---
include/uapi/drm/drm.h | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 5c31aea1f342..a3ee8e01c295 100644
Hm, a git rebase was missing some of my changes for v3. Sorry about that.
Simon Ser (5):
drm/doc: fix drm_plane_type docs
drm/doc: document the type plane property
drm/doc: re-format drm.h file comment
drm/doc: demote old doc-comments in drm.h
drm/doc: render drm.h uapi docs
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
---
include/drm/drm_plane.h | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a
Add a new entry for "type" in the section for standard plane properties.
v3: improve paragraph about mixing legacy IOCTLs with explicit usage,
not that a driver may support cursors without cursor planes (Daniel)
v4: fixing rebase gone wrong
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Git.
v3: keep the comment (Daniel)
Signed-off-by: Simon Ser
Acked-by: Daniel Vetter
Cc: Pekka Paalanen
---
include/uapi/drm/drm.h | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 5c31aea1f342..a3ee8e01c295 100644
lso many of these structures aren't really used by
modern user-space.
We can easily convert these remaining old comments to Sphinx style on a
one-by-one basis.
Signed-off-by: Simon Ser
Acked-by: Daniel Vetter
Cc: Pekka Paalanen
---
include/uapi/drm/drm.h | 84 +-
It doesn't seem like drm.h docs are included anywhere. Render them next
to drm_mode.h, under the "Userspace API Structures" section.
This also allows references to e.g. DRM_CAP_* to be properly linkified
elsewhere in our docs.
Signed-off-by: Simon Ser
Acked-by: Daniel Vetter
Cc:
A driver must not set drm_crtc.cursor and any of the legacy funcs at the
same time, otherwise it's not clear which one DRM core should use for
legacy cursor updates.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_mode_config.c | 10 ++
1 file changed, 10 inser
nouveau already has something for colorkey:
https://drmdb.emersion.fr/properties/4008636142/colorkey
I know this is marked "not for merge", but it would be nice to discuss
with them and come up with a standardized property.
___
dri-devel mailing list
dri
the comment and the shift.
Found when writing a drm_info patch [1].
[1]: https://github.com/ascent12/drm_info/pull/67
Signed-off-by: Simon Ser
Fixes: d6528ec88309 ("drm/fourcc: Add modifier definitions for describing
Amlogic Video Framebuffer Compression")
Cc: Neil Armstrong
Cc: Sa
/etnaviv_2d_test: explain the errors
tests/etnaviv_2d_test: pick the 2D core
tests/etnaviv_2d_test: check whether the rendering is correct
Nicolas Caramelli (1):
tests/modetest: remove bracket in dump_connectors()
Simon Ser (6):
man: convert to reStructuredText
Document
ff-by: Xiaogang Chen
To the best of my knowledge, this sounds correct.
Please wrap your commit message into 80-character lines so that it's easier
to read. Regardless, this is:
Acked-by: Simon Ser
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Pushed to drm-misc-next with a re-formatted commit message, thanks for
your contribution!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wednesday, December 15th, 2021 at 10:56, Dmitry Baryshkov
wrote:
> + drm_printf(p, "\talpha=%x\n", state->alpha);
Maybe use %04X here to make it clearer that 0x is the max?
v2 looks good to me. A little bit sad about the stringifier duplicating code
with drm_plane_create_blend_mode_property but it's not that of a big deal.
Reviewed-by: Simon Ser
You'll need to set the format_mod_supported hook as well, otherwise the kernel
will expose a bogus IN_FORMATS prop with one modifier and zero formats.
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
Please ping me in a week or so if nobody objected and this isn't merged.
Overall looks good, but it is a bit repetitive to copy & paste this in all
drivers. It'd be nice to provide a core helper to do this, and then drivers
can just set format_mod_supported to the helper if they don't have more
involved logic. Thoughts?
See drm_plane_check_pixel_format, where the logic
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
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 documenta
Reviewed-by: Simon Ser
On Wednesday, December 22nd, 2021 at 10:05, José Expósito
wrote:
> Make "create_in_format_blob" behave as documented.
LGTM, nice!
Reviewed-by: Simon Ser
CC Ville just in case
On Thursday, December 23rd, 2021 at 12:56, Ville Syrjälä
wrote:
> > - /* If we can't determine support, just bail */
> > - if (!plane->funcs->format_mod_supported)
> > - goto done;
> > -
> > mod = modifiers_ptr(blob_data);
> > for (i = 0; i < plane->modifier_count; i++) {
>
Pushed patches 1 & 2 to drm-misc-next. Thanks for your contribution!
Thanks for working on this! I've pushed a patch [1] to drm-misc-next which
touches the same function, can you rebase your patches on top of it?
[1]: https://patchwork.freedesktop.org/patch/467940/?series=98255&rev=3
On Friday, January 7th, 2022 at 18:26, José Expósito
wrote:
> Is there something that needs to improve in the other 4 patches?
> Or just waiting on maintainers input?
Yeah, these patches look good to me. Feel free to add my R-b.
Maintainers for these drivers still need to review/ack/apply them
t; Cc: Pekka Paalanen
> Cc: cont...@emersion.fr
> Cc: wayland-de...@lists.freedesktop.org
> Signed-off-by: Daniel Vetter
This LGTM, thanks for the patch! One tiny nit below, but regardless of
whether it's changed or not:
Reviewed-by: Simon Ser
> ---
> Documentation/gpu/drm-ua
is at XDC 2018, and someone mentioned it could be a good idea to
de-duplicate the work.
Would it be reasonable to expose those as DRM connector properties?
Thanks,
--
Simon Ser
https://emersion.fr
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Monday, December 24, 2018 11:23 AM, Daniel Vetter wrote:
> On Sun, Dec 23, 2018 at 09:16:13AM +0000, Simon Ser wrote:
>
> > Hi all,
> > Right now, the kernel parses EDIDs and exposes some of the data to
> > userspace. For instance, drmModeConnector has mm{Width,
On Tuesday, June 18, 2019 5:19 AM, Rodrigo Siqueira
wrote:
> I made the patch, but when I started to write the commit message, I just
> realized that I did not understand why possible_crtcs should not be
> equal zero. Why can we not use zero?
Hi,
possible_crtcs is a bitfield. If it's zero, it m
Interestingly, even with the previous code, possible_crtcs=1 was
exposed to userspace [1]. I think this is because of a safeguard in
drm_crtc_init_with_planes (drm_crtc.c:284) which sets the primary and
cursor plane's possible_crtcs to the first CRTC if zero.
If we want to warn on possible_crtcs=0
operties
[5]:
https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms.html#existing-kms-properties
--
Simon Ser
https://emersion.fr
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wednesday, June 19, 2019 10:53 PM, Daniel Vetter wrote:
> tldr; Yes, I just didn't get around to it yet.
>
> The rough plan is to actually document ioctls and properties and all
> that stuff in drm-uapi.rst, and then cross-link that with the
> driver-side documentation.
I'm confused regarding
On Thursday, July 11, 2019 11:19 AM, Daniel Vetter wrote:
> Aside: This all kinda doesn't go in the right direction for
> high-performance composing, so I guess I need to get started with typing
> up what that should look like.
Some related logs from IRC:
2019-07-10 19:42:49 danvet ickle, i
On Thursday, July 11, 2019 11:21 AM, Daniel Vetter wrote:
> On Tue, Jun 25, 2019 at 10:38:31PM -0300, Rodrigo Siqueira wrote:
>
> > The compute_crc() function is responsible for calculating the
> > framebuffer CRC value; due to the XRGB format, this function has to
> > ignore the alpha channel du
From: Simon Ser
The VSDB parsing code contains a few len >= N checks, accessing db[N] on
success. However if len == N, db[N] is out-of-bounds.
This commit changes the checks to test for len > N.
Signed-off-by: Simon Ser
---
drivers/gpu/drm/drm_edid.c | 24
Hi,
Please, read this thread:
https://lists.freedesktop.org/archives/dri-devel/2020-March/thread.html#259615
It has a lot of information about the pitfalls of cursor hotspot and
other things done by VM software.
In particular: since the driver will ignore the KMS cursor plane
position set by use
On Friday, June 3rd, 2022 at 16:27, Zack Rusin wrote:
> > In particular: since the driver will ignore the KMS cursor plane
> > position set by user-space, I don't think it's okay to just expose
> > without opt-in from user-space (e.g. with a DRM_CLIENT_CAP).
> >
> > cc wayland-devel and Pekka for
On Friday, June 3rd, 2022 at 16:38, Zack Rusin wrote:
> > On Jun 3, 2022, at 10:32 AM, Simon Ser wrote:
> >
> > ⚠ External Email
> >
> > On Friday, June 3rd, 2022 at 16:27, Zack Rusin wrote:
> >
> >>> In particular: since the driver will ignore
On Friday, June 3rd, 2022 at 17:17, Zack Rusin wrote:
>
> > On Jun 3, 2022, at 10:56 AM, Simon Ser wrote:
> > ⚠ External Email
> >
> > On Friday, June 3rd, 2022 at 16:38, Zack Rusin wrote:
> >
> > > > On Jun 3, 2022, at 10:32 AM, Simon
On Friday, June 3rd, 2022 at 17:32, Zack Rusin wrote:
> > On Jun 3, 2022, at 11:22 AM, Simon Ser wrote:
> > ⚠ External Email
> >
> > On Friday, June 3rd, 2022 at 17:17, Zack Rusin wrote:
> >
> >
> > >
> > >
> > > > On Ju
On Friday, June 3rd, 2022 at 20:31, Zack Rusin wrote:
> > > > > > My proposal was:
> > > > > >
> > > > > > - Introduce DRM_CLIENT_CAP_CURSOR_PLANE_NO_POSITION (or a better
> > > > > > name). Only
> > > > > > user-space which supports the hotspot props will enable it.
> > > > > > - By default, do
On Saturday, June 4th, 2022 at 23:19, Hans de Goede wrote:
> >>> My proposal was:
> >>>
> >>> - Introduce DRM_CLIENT_CAP_CURSOR_PLANE_NO_POSITION (or a better name).
> >>> Only
> >>> user-space which supports the hotspot props will enable it.
> >>> - By default, don't expose a cursor plane, beca
--- Original Message ---
On Sunday, June 5th, 2022 at 17:47, Zack Rusin wrote:
> > > Also, let me point this out because it also seems to be a fundamental
> > > misunderstanding, user space implementing software cursor doesn’t fix
> > > anything. Just leaves everything broken in dif
On Sunday, June 5th, 2022 at 20:16, Zack Rusin wrote:
> > At any rate, I consider broken any driver which exposes a cursor plane,
> > then doesn't display it exactly at the CRTC_X/CRTC_Y
>
> But we do… The cursor is at crtc_x, crtc_y.
How do you show the cursor on the host side then? Pretty sure
Both patches pushed to drm-misc-next, thanks for your contribution!
I agree with what others have replied, just adding a few more details.
On Thursday, June 9th, 2022 at 21:39, Zack Rusin wrote:
> virtualized drivers send drm_kms_helper_hotplug_event which sends a HOTPLUG=1
> event with a changed preferred width/height
(Note: and the "hotplug_mode_update" prope
On Friday, June 10th, 2022 at 10:41, Daniel Vetter wrote:
> Anything I've missed? Or got completely wrong?
This plan looks good to me.
As Pekka mentionned, I'd also like to have a conversation of how far we want to
push virtualized driver features. I think KMS support is a good feature to have
On Friday, June 10th, 2022 at 14:36, Gerd Hoffmann wrote:
> Hi,
>
> > > As Pekka mentionned, I'd also like to have a conversation of how far we
> > > want to
> > > push virtualized driver features. I think KMS support is a good feature
> > > to have
> > > to spin up a VM and have all of the bas
Reviewed-by: Simon Ser
ger types, which fixes the above issue.
>
> [1] https://lkml.org/lkml/2019/6/5/18
>
> Fixes: 8ba16d599374 ("drm/fourcc: Add AMD DRM modifiers.")
> Signed-off-by: Carlos Llamas
Reviewed-by: Simon Ser
Cc'ing Bas as well
> ---
> include/uapi/drm/drm_fourcc.h |
.
v3: (Pekka)
- Mention that a handle can be re-used
- Add unit for pitches/offsets
Signed-off-by: Simon Ser
Reviewed-by: Daniel Vetter
Acked-by: Pekka Paalanen
Cc: Daniel Stone
---
include/uapi/drm/drm_mode.h | 88 +
1 file changed, 60 insertions(+), 28 dele
Reviewed-by: Simon Ser
On Wednesday, January 26th, 2022 at 16:11, Hans de Goede
wrote:
> - * A pointer to the drm_privacy_screen's struct is passed as the void *data
> + * A pointer to the drm_privacy_screen's struct is passed as the void \*data
Maybe we can use @data here instead? It's used to refer to arguments or
On Monday, February 7th, 2022 at 13:55, Hans de Goede
wrote:
> It is not an argument to the function being described
Ah right, makes sense then!
Reviewed-by: Simon Ser
drm_dp_dpcd_read returns the number of bytes read. The previous code
would print garbage on DPCD error, and would exit with on error on
success.
Signed-off-by: Simon Ser
Fixes: cb897542c6d2 ("drm/dp_mst: Fix W=1 warnings")
Cc: Lyude Paul
Cc: Benjamin Gaignard
---
drivers/
On Monday, February 14th, 2022 at 11:38, Andy Shevchenko
wrote:
> > > > IMO *always* prefer a for loop over while or do-while.
> > > >
> > > > The for (i = 0; i < N; i++) is such a strong paradigm in C. You
> > > > instantly know how many times you're going to loop, at a glance. Not so
> > > > w
On Tuesday, February 15th, 2022 at 13:04, Emil Velikov
wrote:
> Greetings everyone,
>
> Padron for joining in so late o/
>
> On Tue, 8 Feb 2022 at 08:42, Hsin-Yi Wang wrote:
> >
> > drm_dev_register() sets connector->registration_state to
> > DRM_CONNECTOR_REGISTERED and dev->registered to true
On Tuesday, February 15th, 2022 at 15:38, Emil Velikov
wrote:
> On Tue, 15 Feb 2022 at 13:55, Simon Ser wrote:
> >
> > On Tuesday, February 15th, 2022 at 13:04, Emil Velikov
> > wrote:
> >
> > > Greetings everyone,
> > >
> > > Padron fo
drm-misc-next has changed this doc comment. Can you rebase your changes?
Any any case, r-b me.
[1]:
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=a3574119826d9a4ef807fb973cf5150c3b90da43
Hi,
On Tuesday, February 15th, 2022 at 17:52, Geert Uytterhoeven
wrote:
> Introduce a fourcc code for a single-channel frame buffer format with two
> darkness levels. This can be used for two-level dark-on-light displays.
The previous patches introduce C1 and R1. Do we really need D1? Can't
we
Reviewed-by: Simon Ser
On Thursday, February 17th, 2022 at 17:12, Geert Uytterhoeven
wrote:
> > What is C0?
>
> A non-existing color-indexed mode with zero colors ;-)
> Introduced purely to make a check like in the comment below work.
> What we really want to check here is if the mode is color-indexed
> or not...
May
On Thursday, April 28th, 2022 at 09:50, Pekka Paalanen
wrote:
> > > > Also like Alex said, the kernel does not know if the user prefers high
> > > > color depth or high refresh rate either. One way to solve that is to
> > > > light up the requested video mode any way the kernel can, and then
> >
On Friday, April 29th, 2022 at 10:55, Hans de Goede wrote:
> I believe that we can fix the new interface, the plan is for there
> to be some helper code to proxy the new connector properties to what
> is still a good old backlight-device internally in the kernel,.
>
> This proxy-ing code could ta
eported in GETCONNECTOR IOCTLs.
The documentation for DRM_CONNECTOR_UNREGISTERED states:
> The connector […] has since been unregistered and removed from
> userspace, or the connector was unregistered before it had a chance
> to be exposed to userspace
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Acked-by: Simon Ser
CC amd-gfx
On Monday, August 1st, 2022 at 15:52, Imre Deak wrote:
> The API change introduced in
>
> commit 30c637151cfa ("drm/plane-helper: Export individual helpers")
>
> was missed in the conflict resolution of
>
> commit d93a13bd75b9 (&qu
The drm_property_create_enum() call for "COLOR_RANGE" contains a tab
character in the middle of the argument list.
Signed-off-by: Simon Ser
---
drivers/gpu/drm/drm_color_mgmt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drive
On Saturday, August 6th, 2022 at 21:56, Hoosier, Matt
wrote:
> Any idea what’s up with some compositors adding code to infer
> DRM_FORMAT_MOD_LINEAR semantics when the buffer’s modifiers are set
> to 0?
What does that mean? A buffer only has a single modifier, and LINEAR == 0.
> Wlroots, for e
(It seems like the list was dropped in my reply, sorry about that.
Re-adding it now.)
On Thursday, August 18th, 2022 at 14:06, Michał Winiarski
wrote:
> On Thu, Aug 18, 2022 at 07:39:13AM +0000, Simon Ser wrote:
>
> > Hm, I'm a bit worried about the user-space implicat
This approach will not break existing user-space AFAIK.
Acked-by: Simon Ser
tch:
https://github.com/Plagman/gamescope/pull/595
IGT patch:
https://patchwork.freedesktop.org/series/107681/
Tested on an AMD Picasso iGPU.
Simon Ser (4):
drm: introduce drm_mode_config.atomic_async_page_flip_not_supported
drm: allow DRM_MODE_PAGE_FLIP_ASYNC for atomic commits
drm:
301 - 400 of 1005 matches
Mail list logo
