Ping, anyone up for a review?
FWIW, I've just hit a case where a compositor leaves a "rotation" KMS
prop set behind, then Xorg tries to startup and fails because it doesn't
reset this prop. So none of this is theoretical.
I still think a "reset all KMS props to an arbitrary default value" flag
in drmModeAtomicCommit is the bes
Hi all,
Recently I've been discussing with various people [1] [2] about amdgpu's
handling of KMS planes. AMD hardware is a bit special when it comes to
the cursor plane, and it's not always 100% clear how that maps with the
KMS API.
Up until now we were using cursor and overlay planes in gamescop
> stride
>
I think what's clear is:
- Per-plane property
- In bytes
- Offset between two consecutive rows
How that applies to weird YUV formats is the tricky question…
> Btw. there was a fun argument whether the same modifier value could
> mean different things on different devices.
> On Tue, 07 Sep 2021 10:19:03 +
> Simon Ser wrote:
>
> > FWIW, I've just hit a case where a compositor leaves a "rotation" KMS
> > prop set behind, then Xorg tries to startup and fails because it doesn't
> > reset this prop. So none of this is
Reviewed-by: Simon Ser
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 whol
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 sch
Valve's Steam Deck has a 800x1280 LCD screen.
Signed-off-by: Simon Ser
Cc: Jared Baldridge
Cc: Emil Velikov
Cc: Daniel Vetter
Cc: Hans de Goede
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gp
> > > - move drivers/misc/habanalabs under drivers/gpu/habanalabs and
> > > review/discussions on dri-devel
>
> Wait, why move into gpu? Are we going to do that for all hardware
> accelerators that we currently have in the kernel tree?
>
> These things are not GPUs in the sense of them being "do s
Thanks for the fixup and the quick review!
Reviewed-by: Simon Ser
Ping
On Tuesday, October 12th, 2021 at 12:30, Pekka Paalanen
wrote:
> is there a practise of landing proposal documents in the kernel? How
> does that work, will a kernel tree carry the patch files?
> Or should this document be worded like documentation for an accepted
> feature, and then the patches
Yes, this is expected behavior, even if it's not intuitive. For more
details, see:
https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/110
This function sends a hotplug uevent with a CONNECTOR property.
Signed-off-by: Simon Ser
---
drivers/gpu/drm/drm_sysfs.c | 25 +
include/drm/drm_sysfs.h | 1 +
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
when sending HDCP property update
uevents, see drm_sysfs_connector_status_event.
This has been tested with a wlroots patch [1].
amdgpu and the probe-helper has been updated to use these new fine-grained
uevents.
Changes in v3: rebase
[1]: https://github.com/swaywm/wlroots/pull/2959
Simon Ser (6
This function is the same as drm_kms_helper_hotplug_event, but takes
a connector instead of a device.
Signed-off-by: Simon Ser
---
drivers/gpu/drm/drm_probe_helper.c | 23 +++
include/drm/drm_probe_helper.h | 1 +
2 files changed, 24 insertions(+)
diff --git a/drivers
If an hotplug event only updates a single connector, use
drm_kms_helper_connector_hotplug_event instead of
drm_kms_helper_hotplug_event.
Signed-off-by: Simon Ser
---
drivers/gpu/drm/drm_probe_helper.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a
When link-status changes, send a hotplug uevent which contains the
connector and property ID. That way, user-space can more easily
figure out that only the link-status property of this connector has
been updated.
Signed-off-by: Simon Ser
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 ++
1
When updating a single connector, use
drm_kms_helper_connector_hotplug_event instead of
drm_kms_helper_hotplug_event.
Signed-off-by: Simon Ser
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 4 ++--
2 files
In drm_connector_register, use drm_sysfs_connector_hotplug_event
instead of drm_sysfs_hotplug_event, because the hotplug event
only updates a single connector.
Signed-off-by: Simon Ser
---
drivers/gpu/drm/drm_connector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
On Friday, October 15th, 2021 at 21:44, Ville Syrjälä
wrote:
> > /* Send Hotplug uevent so userspace can reprobe */
> > drm_kms_helper_hotplug_event(connector->dev);
> > + drm_sysfs_connector_status_event(connector,
> > +
> > connector->dev->mode_con
On Friday, October 15th, 2021 at 21:41, Ville Syrjälä
wrote:
> So many things that "changed". Would it not be simpler to just grab the
> first changed connector always, and count how many there were in total?
Indeed, sounds much better. Will do that in the next version.
On Monday, October 18th, 2021 at 10:15, Maxime Ripard wrote:
> I guess we'd also need to update drm_connector_helper_hpd_irq_event ?
Good catch! IIRC this function didn't exist when I first wrote the
patchset.
On Friday, October 15th, 2021 at 22:03, Sam Ravnborg wrote:
> This code is a little confusing to read.
>
> In case we have only one connector with a change we hit the else part.
> What we really want to find out is if we have one or more connectors
> with a change.
> We could do something like:
>
when sending HDCP property update
uevents, see drm_sysfs_connector_status_event.
This has been tested with a wlroots patch [1].
amdgpu and the probe-helper has been updated to use these new fine-grained
uevents.
Changes in v4: address comments from Ville, Maxime and Sam.
Simon Ser (6):
drm
When updating a single connector, use
drm_kms_helper_connector_hotplug_event instead of
drm_kms_helper_hotplug_event.
Signed-off-by: Simon Ser
Reviewed-by: Harry Wentland
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8
drivers/gpu/drm/amd/display/amdgpu_dm
This function is the same as drm_kms_helper_hotplug_event, but takes
a connector instead of a device.
Signed-off-by: Simon Ser
Reviewed-by: Sam Ravnborg
Acked-by: Harry Wentland
---
drivers/gpu/drm/drm_probe_helper.c | 23 +++
include/drm/drm_probe_helper.h | 1 +
2
If an hotplug event only updates a single connector, use
drm_kms_helper_connector_hotplug_event instead of
drm_kms_helper_hotplug_event.
Changes in v4:
- Simplify loop logic (Ville, Sam)
- Update drm_connector_helper_hpd_irq_event (Maxime)
Signed-off-by: Simon Ser
Cc: Ville Syrjala
Cc: Sam
In drm_connector_register, use drm_sysfs_connector_hotplug_event
instead of drm_sysfs_hotplug_event, because the hotplug event
only updates a single connector.
Signed-off-by: Simon Ser
Reviewed-by: Sam Ravnborg
Acked-by: Harry Wentland
---
drivers/gpu/drm/drm_connector.c | 2 +-
1 file
When link-status changes, send a hotplug uevent which contains the
connector ID. That way, user-space can more easily figure out that
only this connector has been updated.
Changes in v4: avoid sending two uevents (Ville)
Signed-off-by: Simon Ser
Cc: Ville Syrjala
---
drivers/gpu/drm/i915
This function sends a hotplug uevent with a CONNECTOR property.
Signed-off-by: Simon Ser
Reviewed-by: Sam Ravnborg
Acked-by: Harry Wentland
---
drivers/gpu/drm/drm_sysfs.c | 25 +
include/drm/drm_sysfs.h | 1 +
2 files changed, 26 insertions(+)
diff --git a
Thanks for having a look at this patch, Pekka!
On Friday, October 8th, 2021 at 09:29, Pekka Paalanen
wrote:
> > +#define DRM_IOCTL_MODE_CLOSEFB DRM_IOWR(0xCF, unsigned int)
>
> Should it have a structure with 'flags' for future-proofing?
>
> ISTR some rule of thumb that everything n
FWIW, I'm using this IOCTL in a wlroots patchset [1].
To detect support for this IOCTL, is there anything better than creating a
DMA-BUF and checking for ENOTTY? I'd like to disable explicit sync at init-time
if this is missing.
[1]: https://github.com/swaywm/wlroots/pull/3282
For the include/uapi/drm/drm_fourcc.h changes:
Acked-by: Simon Ser
On Wednesday, October 27th, 2021 at 15:15, Pekka Paalanen
wrote:
> On Fri, 15 Oct 2021 16:33:43 +
> Simon Ser wrote:
>
> > In drm_connector_register, use drm_sysfs_connector_hotplug_event
> > instead of drm_sysfs_hotplug_event, because the hotplug event
> > only
CC Emma and Maxime
On Saturday, September 18th, 2021 at 11:18, Michael Stapelberg
wrote:
> Hi,
>
> torvalds at linux-foundation.org (Linus Torvalds) writes:
> > Did I fix it up correctly? Who knows. The code makes more sense to me
> > now and seems valid. But I really *really* want to stress ho
Anyone up for a review on this one? Daniel Vetter has ack'ed but
doesn't have time for a full review.
CC Maarten Lankhorst, Maxime Ripard, Michel Dänzer
Who else should I CC?
Maybe try creating multiple physical seats with logind, and start each
compositor on its own seat? A physical seat is a collection of devices like
DRM nodes and evdev device files.
Also udev creates files in /dev/dri/by-path/, these should be stable across
reboots. `udevadm settle` before a compos
When a plane is missing the "alpha blend mode" property, KMS drivers
will use the pre-multiplied mode.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
---
drivers/gpu/drm/drm_blend.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_blend.c b/d
Thanks a lot for the reviews!
One include is v2, the other is v3, or am I missing something?
On Wednesday, September 22nd, 2021 at 11:21, Hans de Goede
wrote:
> I would be happy to work on the plymouth side of this, so that we
> have at least one consumer of such a flag lined up for merging.
Do you have plans to work on the kernel side part of this? If so, feel free to
CC me for a revi
The KMS documentation doesn't say much about the meaning of each
content type. Add a reference to the specification defining them.
Signed-off-by: Simon Ser
Cc: Emmanuel Gil Peyrot
Cc: Daniel Vetter
Cc: Pekka Paalanen
Cc: Ville Syrjala
Cc: Jani Nikula
---
drivers/gpu/drm/drm_connector.
On Monday, October 4th, 2021 at 11:22, Ville Syrjälä
wrote:
> A bit annoying to have to refer to an external spec, but copy pasting
> the whole thing here seems a bit questionable.
Yeah, I'm mostly worried about copyright. We could also invent our own
descriptions (Is that even possible without
This new ADDFB2 flag allows callers to mark a framebuffer as
"persistent", and no longer have RMFB semantics when the DRM
file is closed.
[1]: https://lore.kernel.org/dri-devel/YTJypepF1Hpc2YYT@reader/
Signed-off-by: Simon Ser
Cc: Hans de Goede
Cc: Dennis Filder
Cc: Daniel Vetter
Pushed, thanks!
actoring.
Signed-off-by: Simon Ser
Cc: Hans de Goede
Cc: Dennis Filder
Cc: Daniel Vetter
Cc: Pekka Paalanen
Cc: Rob Clark
Cc: Sean Paul
---
drivers/gpu/drm/drm_framebuffer.c | 51 +++
1 file changed, 31 insertions(+), 20 deletions(-)
diff --git a/drivers
g/dri-devel/20211006151921.312714-1-cont...@emersion.fr/
Signed-off-by: Simon Ser
Cc: Hans de Goede
Cc: Dennis Filder
Cc: Daniel Vetter
Cc: Pekka Paalanen
Cc: Rob Clark
Cc: Sean Paul
---
drivers/gpu/drm/drm_crtc_internal.h | 2 ++
drivers/gpu/drm/drm_framebuffer.c
On Thursday, October 7th, 2021 at 10:10, Hans de Goede
wrote:
> > I think my order of favourites is:
> > 1. RMFB flag
> > 2. ioctl to set an existing FB as persistent
> > 3. ADDFB flag
> >
> > They all seem workable to me.
>
> I fully agree with the above.
Thanks for the feedback! It seems l
On Friday, January 14th, 2022 at 15:16, Andy Shevchenko
wrote:
> Why not enum?
There is no enum for DRM format modifiers.
On Friday, January 14th, 2022 at 16:17, Andy Shevchenko
wrote:
> On Fri, Jan 14, 2022 at 03:07:21PM +0000, Simon Ser wrote:
> > On Friday, January 14th, 2022 at 15:16, Andy Shevchenko
> > wrote:
> >
> > > Why not enum?
> >
> > There is no enum for
On Tuesday, January 18th, 2022 at 12:41, Daniel Vetter wrote:
> On Tue, Jan 18, 2022 at 9:41 AM Geert Uytterhoeven
> wrote:
> >
> > Hi Jani,
> >
> > On Tue, Jan 18, 2022 at 9:38 AM Jani Nikula
> > wrote:
> > > On Mon, 17 Jan 2022, Helge Deller wrote:
> > > > On 1/17/22 22:40, Jani Nikula wro
On Tuesday, January 18th, 2022 at 15:23, Thomas Zimmermann
wrote:
> Am 18.01.22 um 09:10 schrieb Geert Uytterhoeven:
> > Hi Gerd,
> >
> > On Tue, Jan 18, 2022 at 7:30 AM Gerd Hoffmann wrote:
> >> Also note that using a shadow framebuffer allows to decouple fbcon
> >> updates and scanout framebu
Follow-up for the DRM_IOCTL_MODE_GETFB2 docs.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
Cc: Daniel Stone
---
include/uapi/drm/drm_mode.h | 83 -
1 file changed, 55 insertions(+), 28 deletions(-)
diff --git a/include/uapi/drm/drm_mode.h
This driver only advertises XRGB in ssd1307_formats. It would be nice to
expose R8 as well so that user-space can directly produce suitable buffers.
It would also be nice to have some kind of preferred format, so that user-space
knows R8 is preferred over XRGB.
On Monday, January 31st, 2022 at 21:36, Simon Ser wrote:
> This driver only advertises XRGB in ssd1307_formats. It would be nice to
> expose R8 as well so that user-space can directly produce suitable buffers.
> It would also be nice to have some kind of preferred format, so tha
On Tuesday, February 1st, 2022 at 09:26, Geert Uytterhoeven
wrote:
> What's the story with the Rn formats?
>
> The comments say "n bpp Red", while this is a monochrome (even
> inverted) display?
I don't think the color matters that much. "Red" was picked just because it was
an arbitrary color,
On Tuesday, February 1st, 2022 at 09:43, Geert Uytterhoeven
wrote:
> Does there exist another simple test program for showing something
> using the DRM API?
If you're fine with going low-level, there's tentative [1] which can apply an
arbitrary KMS state. See for instance [2] for basic mode-set
igned-off-by: Simon Ser
Reviewed-by: Daniel Vetter
Cc: Pekka Paalanen
Cc: Daniel Stone
---
include/uapi/drm/drm_mode.h | 88 +
1 file changed, 60 insertions(+), 28 deletions(-)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index e1e3516
On Tuesday, February 1st, 2022 at 11:08, Thomas Zimmermann
wrote:
> Am 01.02.22 um 09:36 schrieb Geert Uytterhoeven:
>
> > I'd expect 8-bit grayscale to be Y8 instead.
>
> I like this naming, but DRM_FORMAT_R8 is uapi already. :/ If anything,
> we could add Yn formats in addition to existing Rn
On Tuesday, February 1st, 2022 at 13:58, Noralf Trønnes
wrote:
> It turned out that I wasn't entirely correct here, mpv didn't cope with
> unknown types. In the PR to add support Emil Velikov wondered if libdrm
> should handle these connector names:
Opened this MR to try to make things easier
On Tuesday, February 1st, 2022 at 21:57, Sam Ravnborg wrote:
> As I wrote in another part of this thread(s) - typing the patch is easy.
> But I do not understand the userspace implications so I need someone
> else to say go.
User-space shouldn't really use the connector for anything except makin
Reviewed-by: Simon Ser
Maybe a self-test checking this would be more appropriate?
> +/* 10 bpp Red */
> +#define DRM_FORMAT_R10 fourcc_code('R', '1', '0', ' ') /*
> [15:0] x:R 6:10 little endian */
> +
> +/* 12 bpp Red */
> +#define DRM_FORMAT_R12 fourcc_code('R', '1', '2', ' ') /*
> [15:0] x:R 4:12 little endian */
Are these codes arbitrary, or ar
On Thursday, October 28th, 2021 at 23:49, Simon Ser wrote:
> Are these codes arbitrary, or are they taken from somewhere else?
> If they are arbitrary, maybe it'd be better to pick XR10 and XR12 instead of
> R10 and R12, to allow a future patch to add other format codes with the
On Friday, October 29th, 2021 at 01:30, Laurent Pinchart
wrote:
> I don't think we'll need a format with padding at that end (with data
> aligned to tbe MSB) as that would essentially be DRM_FORMAT_R16.
The X channel doesn't mean that the padding is zeroes: the padding has
undefined contents. S
On Sunday, October 31st, 2021 at 18:05, Simon Ser wrote:
> Playing with
> DRM_FORMAT_BIG_ENDIAN (!) could do the trick.
Hm, nevermind, that wouldn't work, as this would do something like
RRXX.
Reviewed-by: Simon Ser
Acked-by: Simon Ser
Mario Kleiner (1):
headers: drm: Sync with drm-next
Simon Ser (15):
xf86drm: add GEM_CLOSE ioctl wrapper
xf86drmMode: make drm_property_type_is arg const
xf86drmMode: switch to standard inline qualifier
xf86drmMode: simplify drm_property_type_is
amdgpu
s the flag is
set.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
---
include/uapi/drm/drm.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 3b810b53ba8b..9809078b0f51 100644
--- a/include/uapi/drm/drm.h
On Tuesday, November 9th, 2021 at 10:13, Daniel Vetter wrote:
> On Mon, Nov 08, 2021 at 04:18:22PM -0800, James Jones wrote:
> > On 9/6/21 5:28 AM, Simon Ser wrote:
> > > > Since there's a lot of confusion around this, document both the rules
> > > > an
On Tuesday, November 9th, 2021 at 10:24, Daniel Vetter wrote:
> On Tue, Nov 09, 2021 at 08:56:10AM +0000, Simon Ser wrote:
> > There are a few details specific to the GETFB2 IOCTL.
> >
> > It's not immediately clear how user-space should check for the
> > num
H any user-space which looks up the
modifier array without checking the flag is broken already, so
should be fine.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
Cc: Daniel Stone
---
drivers/gpu/drm/drm_framebuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
On Thursday, November 11th, 2021 at 13:50, Ville Syrjälä
wrote:
> On Thu, Nov 11, 2021 at 10:10:54AM +0000, Simon Ser wrote:
> > User-space shouldn't look up the modifier array when the modifier
> > flag is missing, but at the moment no docs make this clear (working
>
On Monday, November 15th, 2021 at 11:22, Jani Nikula
wrote:
> - Adding drm_dbg_connector() which would take drm_connector as context,
> and do drm_dbg_kms() with the above prefix.
This wouldn't work great in case multiple connectors/planes/etc are involved,
or when drm_dbg_atomic() is used.
On Thursday, November 11th, 2021 at 12:50, Daniel Stone
wrote:
> In fairness it is perfectly clear, it's just that I never considered
> calling it without master/admin because why would you ever do that?
FWIW, drm_info does it to display the current buffers metadata. Pretty
useful when debuggin
On Monday, November 15th, 2021 at 15:20, Daniel Vetter wrote:
> On Mon, Nov 15, 2021 at 12:09:47PM +0000, Simon Ser wrote:
> > On Thursday, November 11th, 2021 at 12:50, Daniel Stone
> > wrote:
> >
> > > In fairness it is perfectly clear, it's just that
Hm indeed, RIP. I got confused by this one:
/* Pre-FB_MODIFIERS userspace didn't clear the structs
properly. */
if (!(r->flags & DRM_MODE_FB_MODIFIERS))
continue;
But it's only run for unused planes.
Hi,
>From a user-space point-of-view, we discussed about this patch on IRC a few
days ago [1]. Since this adds a policy decision we think it'd be best to allow
user-space to control this behavior.
Also cc Pekka.
Thanks,
Simon
[1]:
https://oftc.irclog.whitequark.org/dri-devel/2021-11-07#163627
On Friday, November 19th, 2021 at 16:53, Daniel Vetter wrote:
> Random idea ... should we perhaps let userspace connect the boosting? I.e.
> we do a bunch of standardized boost targets (render clocks, display sr
> exit), and userspace can then connect it to whichever input device it
> wants to?
First off, let me reiterate that this feature would be invaluable as user-space
developers. It's often pretty difficult to figure out the cause of an EINVAL,
we have to ask users to follow complicated instructions [1] to grab DRM logs.
Then have to skim through several megabytes of logs to find the
o not look at it unless the flag is
set.
Changes in v2 (Daniel):
- Mention that handles should be used to compute the number of planes,
and only refer to pitches as a fallback.
- Reword bit about undefined modifier.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Acked-by: Pekka Paalanen
Acked-by: D
Bas Nieuwenhuizen (1):
amdgpu: Add new function to get fd.
Eleni Maria Stea (1):
xf86drm: fix compiler warnings
Emmanuel Vadot (2):
ci: Switch freedesktop/ci-templates
ci: Add FreeBSD support
Simon Ser (2):
xf86drm: add drmGetDeviceFromDevId
build: bump
On Tuesday, December 14th, 2021 at 15:49, Emmanuel Gil Peyrot
wrote:
> This makes me think the kernel should populate IN_FORMATS with at least
> the same formats as the format list when supported, or stop advertising
> this property altogether.
Yup. This is a bug in the driver.
> Other composi
On Friday, December 11th, 2020 at 2:50 PM, Pekka Paalanen
wrote:
> is there a reason why one cannot have more primary planes than CRTCs in
> existence?
>
> Daniel implied that in <20201209003637.GK401619@phenom.ffwll.local>,
> but I didn't get the reason for it yet.
>
> E.g. if all your planes a
Ville)
- Fix typos (Ville)
Signed-off-by: Simon Ser
Reviewed-by: Daniel Vetter
Cc: Pekka Paalanen
Cc: Jani Nikula
Cc: Ville Syrjala
---
drivers/gpu/drm/drm_mode_config.c | 21 +
drivers/gpu/drm/drm_plane.c | 6 ++
2 files changed, 27 insertions(+)
diff --git a/driver
com/swaywm/wlroots/pull/2333#discussion_r456788057
Signed-off-by: Simon Ser
Reviewed-by: Daniel Vetter
Acked-by: Pekka Paalanen
---
drivers/gpu/drm/drm_crtc.c | 3 +++
drivers/gpu/drm/drm_plane.c | 16 +---
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drive
If a primary or cursor plane is not compatible with a CRTC it's attached
to via the legacy primary/cursor field, things will be broken for legacy
user-space.
v4: use drm_crtc_mask instead of BIT (Ville)
Signed-off-by: Simon Ser
Reviewed-by: Daniel Vetter
Acked-by: Pekka Paalanen
Cc:
If a CRTC is missing a legacy primary plane pointer, a lot of things
will be broken for user-space: fbdev stops working and the entire legacy
uAPI stops working.
Require all drivers to populate drm_crtc.primary to prevent these
issues. Warn if it's NULL.
Signed-off-by: Simon Ser
Review
Can you add some drm_dbg_atomic logs when the damage is invalid, to make it
easier for user-space to understand why an atomic commit failed?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-deve
failed
> due invalid damage clips
>
> Cc: Simon Ser
> Cc: Gwan-gyeong Mun
> Cc: Sean Paul
> Cc: Fabio Estevam
> Cc: Deepak Rawat
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: José Roberto de Souza
After looking at the kernel code, it seems l
On Monday, December 14th, 2020 at 9:41 AM, Pekka Paalanen
wrote:
> On Fri, 11 Dec 2020 14:39:35 +
> Simon Ser wrote:
>
> > On Friday, December 11th, 2020 at 2:50 PM, Pekka Paalanen
> > wrote:
> >
> > > is there a reason why one cannot ha
Make it more human-readable.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
---
Documentation/gpu/drm-kms.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 3c5ae4f6dfd2..76cf6acc23a5
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
Cc: Daniel Vetter
Cc: Pekka Paalanen
---
Documentation/gpu/drm-kms.rst | 6 ++
drivers/gpu/drm/drm_blend.c | 6 -
Move drm_damage_helper 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 | 15
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 | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/include/drm
201 - 300 of 1005 matches
Mail list logo
