On Monday, March 4th, 2024 at 15:04, Garg, Nemesa wrote:
> This is generic as sharpness effect is applied post blending. Depending
> on the color gamut, pixel format and other inputs the image gets
> blended and once we get blended output it can be sharpened based on
> strength value provided by
al hardware (Pekka)
> v4: Update the docs to indicate the list is "in order of preference"
> Add a a link to the mutter MR
>
> Cc: Simon Ser
> Cc: Jonas Ådahl
> Cc: Daniel Stone
> Cc: Sameer Lattannavar
> Cc: Sebastian Wick
> Acked-by: Harry Wentland
How much of this is Intel-specific? Are there any hardware vendors with
a similar feature? How much is the "sharpness" knob tied to Intel hardware?
Thanks! This iteration of the first 3 patches LGTM, I've pushed them to
drm-misc-next. I've made two adjustments to make checkpatch.pl happy:
- s/uint64_t/u64/
- Fix indentation for a drm_dbg_atomic()
://lore.kernel.org/intel-gfx/y6gx7z17wmdsk...@ideak-desk.fi.intel.com/
Signed-off-by: Simon Ser
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Lyude Paul
Cc: Imre Deak
---
drivers/gpu/drm/drm_atomic_helper.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu
On Wednesday, August 23rd, 2023 at 12:53, Simon Ser wrote:
> On Tuesday, August 8th, 2023 at 17:04, James Zhu jam...@amd.com wrote:
>
> > I have a MR for libdrm to support drm nodes type up to 2^MINORBITS
> > nodes which can work with these patches,
> >
> > https
On Tuesday, August 8th, 2023 at 17:04, James Zhu wrote:
> I have a MR for libdrm to support drm nodes type up to 2^MINORBITS
> nodes which can work with these patches,
>
> https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/305
FWIW, this MR has been merged, so in theory this kernel patch
On Thursday, August 17th, 2023 at 21:33, Dmitry Baryshkov
wrote:
> We have been looking for a way to document that the corresponding DP
> port is represented by the USB connector on the device.
>
> Consequently, I believe the best way to document it, would be to use
> DisplayPort / USB, when
On Thursday, August 3rd, 2023 at 22:44, Laurent Pinchart
wrote:
> On Thu, Aug 03, 2023 at 03:31:16PM +0000, Simon Ser wrote:
>
> > On Thursday, August 3rd, 2023 at 17:22, Simon Ser cont...@emersion.fr wrote:
> >
> > > The KMS docs describe "subconnector&qu
On Thursday, August 3rd, 2023 at 17:36, Dmitry Baryshkov
wrote:
> On Thu, 3 Aug 2023 at 18:31, Simon Ser cont...@emersion.fr wrote:
>
> > On Thursday, August 3rd, 2023 at 17:22, Simon Ser cont...@emersion.fr wrote:
> >
> > > The KMS docs describe "subconnect
On Thursday, August 3rd, 2023 at 17:22, Simon Ser wrote:
> The KMS docs describe "subconnector" to be defined as "downstream port" for
> DP.
> Can USB-C (or USB) be seen as a DP downstream port?
To expand on this a bit: I'm wondering if we're mixing apples and
ora
On Wednesday, August 2nd, 2023 at 21:23, Dmitry Baryshkov
wrote:
> >> >> + { DRM_MODE_SUBCONNECTOR_USB, "USB" }, /* DP */
> >> >
> >> > Should this be DRM_MODE_SUBCONNECTOR_USB_C and "USB-C", in case we get
> >> > another USB type later ?
> >>
> >> Hmm, which id should I use
On Thursday, July 27th, 2023 at 14:01, Christian König
wrote:
> > We do need patches to stop trying to infer the node type from the minor
> > in libdrm, though. Emil has suggested using sysfs, which we already do
> > in a few places in libdrm.
>
> That sounds like a really good idea to me as
On Monday, July 24th, 2023 at 23:14, Michał Winiarski
wrote:
> Having a limit of 64 DRM devices is not good enough for modern world
> where we have multi-GPU servers, SR-IOV virtual functions and virtual
> devices used for testing.
> Let's utilize full minor range for DRM devices.
> To avoid
Any news about this patch?
This adds more information to the hotplug uevent and lets user-space
know that it's about a particular connector only.
v2: don't rely on the changed HPD pin bitmask to count changed
connectors (Jani)
Signed-off-by: Simon Ser
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: Rodrigo Vivi
Cc: Gustavo
On Wednesday, June 21st, 2023 at 14:26, Jani Nikula
wrote:
> On Wed, 21 Jun 2023, Simon Ser cont...@emersion.fr wrote:
>
> > On Wednesday, June 21st, 2023 at 14:11, Jani Nikula jani.nik...@intel.com
> > wrote:
> >
> > > On Wed, 21 Jun 2023, Si
On Wednesday, June 21st, 2023 at 14:11, Jani Nikula
wrote:
> On Wed, 21 Jun 2023, Simon Ser cont...@emersion.fr wrote:
>
> > On Wednesday, June 21st, 2023 at 14:05, Jani Nikula jani.nik...@intel.com
> > wrote:
> >
> > > > - if (changed)
&
On Wednesday, June 21st, 2023 at 14:05, Jani Nikula
wrote:
> > - if (changed)
> > + if (hweight32(changed) == 1)
> > + drm_kms_helper_connector_hotplug_event(first_changed_connector);
>
> What if more than one connector share the same hpd pin?
Ah, I did not believe this could happen. I'll
This adds more information to the hotplug uevent and lets user-space
know that it's about a particular connector only.
Signed-off-by: Simon Ser
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: Rodrigo Vivi
Cc: Gustavo Sousa
Cc: Imre Deak
Cc: Lucas De Marchi
---
drivers/gpu/drm/i915/display
Reviewed-by: Simon Ser
Acked-by: Simon Ser
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?
The Intel counterpart is also:
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
] is not registered
Skip these unregistered connectors to allow user-space to turn them
off.
Fixes part of this wlroots issue:
https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3407
Signed-off-by: Simon Ser
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Lyude Paul
---
drivers/gpu/drm/i915/display/intel_dp_mst.c
It can be surprising for user-space to see unrelated connectors,
CRTCs and planes being implicitly pulled into the atomic commit.
Log when that happens.
Signed-off-by: Simon Ser
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Lyude Paul
---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 4
1 file
Reviewed-by: Simon Ser
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
On Wednesday, March 23rd, 2022 at 13:02, Jani Nikula
wrote:
> Simon and Daniel also tell me on IRC we can't just modify the base block
> extension count to match HF-EEODB to dodge the problem, because the EDID
> gets exposed to userspace.
I'm not familiar how the EDID blob gets exposed to
On Friday, February 18th, 2022 at 12:54, Hans de Goede
wrote:
> On 2/18/22 12:39, Simon Ser wrote:
> > On Friday, February 18th, 2022 at 11:38, Hans de Goede
> > wrote:
> >
> >> What I'm reading in the above is that it is being considered to allow
> >&g
On Friday, February 18th, 2022 at 11:38, Hans de Goede
wrote:
> What I'm reading in the above is that it is being considered to allow
> changing the panel-orientation value after the connector has been made
> available to userspace; and let userspace know about this through a uevent.
>
> I
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
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
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
Pushed patches 1 & 2 to drm-misc-next. Thanks for your contribution!
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++) {
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
Reviewed-by: Simon Ser
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
For the include/uapi/drm/drm_fourcc.h changes:
Acked-by: Simon Ser
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
Ping
Ping, anyone up for a review?
Pushed this one doc patch with Daniel's R-b on IRC.
Reviewed-by: Simon Ser
But this this touches a lot of different drivers, not sure we can just
merge this via drm-misc-next?
In any case, please ping me again in a week if this hasn't been merged
by then.
___
Intel-gfx mailing list
Intel-gfx
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.
>
> Using a pair of properties, preference and active, to ask for something
> and then check what actually worked is
On Tuesday, June 22nd, 2021 at 11:50, Werner Sembach
wrote:
> Unknown is when no monitor is connected or is when the
> connector/monitor is disabled.
I think the other connector props (link-status, non-desktop, etc) don't
have a special "unset" value, and instead the value is set to a random
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
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
Mention that connectors need to be referenced manually if they are
to be accessed after the iteration has progressed or ended.
Signed-off-by: Simon Ser
---
include/drm/drm_connector.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/drm/drm_connector.h b/include/drm
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 | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git
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
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.
[1]: https://github.com/swaywm/wlroots/pull/2959
Simon Ser (7):
drm/sysfs
On Thursday, May 27th, 2021 at 12:33 PM, Daniel Vetter wrote:
> > The sync_file is also import/exportable to a certain drm_syncobj timeline
> > point (or as binary signal). So no big deal, we are all compatible here :)
> > I just thought that it might be more appropriate to return a drm_syncobj
On Monday, May 17th, 2021 at 8:16 PM, Nieto, David M
wrote:
> Btw is DRM_MAJOR 226 consider uapi? I don't see it in uapi headers.
It's not in the headers, but it's de facto uAPI, as seen in libdrm:
> git grep 226
xf86drm.c
99:#define DRM_MAJOR 226 /* Linux */
On Wednesday, May 12th, 2021 at 3:04 PM, Ville Syrjälä
wrote:
> > Adoption:
> >
> > A KDE dev wants to implement the settings in the KDE settings GUI:
> >
> > https://gitlab.freedesktop.org/drm/amd/-/issues/476#note_912370
> >
> > Tuxedo Computers (my employer) wants to implement the settings
Continuing on that idea to push for enabling the cap in more cases: do
we have a policy to require new drivers to always support modifiers?
That would be nice, even if it's just about enabling LINEAR.
___
Intel-gfx mailing list
Reviewed-by: Simon Ser
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Thursday, April 22nd, 2021 at 10:54 AM, Hans de Goede
wrote:
> I guess Marco was waiting for the kernel bits too land before submitting
> these,
> but I agree that it would probably be good to have these submitted now, we
> can mark them as WIP to avoid them getting merged before the kernel
Hi,
On Wednesday, April 21st, 2021 at 10:47 PM, Hans de Goede
wrote:
> There now is GNOME userspace code using the new properties:
> https://hackmd.io/@3v1n0/rkyIy3BOw
Thanks for working on this.
Can these patches be submitted as merge requests against the upstream
projects? It would be nice
Reviewed-by: Simon Ser
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tuesday, April 13th, 2021 at 11:49 AM, Daniel Vetter
wrote:
> + * Note that userspace can check the DRM_CAP_ADDFB2_MODIFIERS driver
Prepend an ampersand like so and a hyperlink will be rendered:
Note that userspace can check the _CAP_ADDFB2_MODIFIERS driver
Acked-by: Simon Ser
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Side note: I feel like we could have better lines of communication
between kernel devs and user-space devs. The new uAPI requirements seem
to be a high barrier to entry for kernel devs. However sometimes
user-space devs might be interested in helping out with the user-space
part…
Maybe it would
On Friday, February 12th, 2021 at 1:57 PM, Emil Velikov
wrote:
> On Fri, 5 Feb 2021 at 22:01, Chris Wilson wrote:
> >
> > Userspace has discovered the functionality offered by SYS_kcmp and has
> > started to depend upon it. In particular, Mesa uses SYS_kcmp for
> > os_same_file_description()
On Wednesday, February 10th, 2021 at 2:16 PM, Daniel Vetter
wrote:
> On Tue, Feb 09, 2021 at 04:14:01PM -0800, Manasi Navare wrote:
>
> > These additional checks added to avoid EBUSY give unnecessary WARN_ON
> > in case of big joiner used in i915 in which case even if the modeset
> > is
failed
> due invalid damage clips
>
> Cc: Simon Ser
> Cc: Gwan-gyeong Mun
> Cc: Sean Paul
> Cc: Fabio Estevam
> Cc: Deepak Rawat
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: José Roberto de Souza
After looking at the kernel code,
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?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Already fixed in 0003b687ee6d ("drm: fix oops in
drm_atomic_set_crtc_for_connector"). Thanks.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Thanks!
Acked-by: Simon Ser
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Friday, October 23, 2020 10:39 PM, Ville Syrjala
wrote:
> From: Ville Syrjälä ville.syrj...@linux.intel.com
>
> The code responsible for creating the IN_FORMATS
> blob is broken when the driver doesn't provide a
> .format_mod_supported() hook. It just copies in
> the format list, but leaves
On Friday, October 23, 2020 5:27 PM, Ville Syrjälä
wrote:
> These are two extreme cases:
Thanks!
> > I'm trying to get
> > a fix for my user-space 1, and I'm wondering if int32_t is enough
> > after dividing by mode->htotal.
> > CC Pekka, just FYI (I think Weston has similar code).
>
> What's
On Thursday, October 22, 2020 12:14 PM, Ville Syrjälä
wrote:
> On Wed, Oct 21, 2020 at 08:13:43PM -0700, Randy Dunlap wrote:
>
> > Hi,
> > With linux-next 20201021, when booting up, I am seeing this:
> > [ 0.560896] UBSAN: signed-integer-overflow in
> > ../drivers/gpu/drm/drm_modes.c:765:20
>
For the docs:
Acked-by: Simon Ser
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tuesday, October 13, 2020 4:26 PM, Simon Ser wrote:
> On Monday, October 12, 2020 8:41 PM, Pankaj Bharadiya
> pankaj.laxminarayan.bharad...@intel.com wrote:
>
> > Now, Sameer has implemented Integer scaling in Kodi Retro gaming
> > framework which demonstrate how
On Monday, October 12, 2020 8:41 PM, Pankaj Bharadiya
wrote:
> Now, Sameer has implemented Integer scaling in Kodi Retro gaming
> framework which demonstrate how Integer scaling gives distinctive
> look to pixel art games when played on higher resolution monitors.
>
> Kodi patches are reviewed
On Monday, October 12, 2020 8:41 PM, Pankaj Bharadiya
wrote:
> +/**
> + * DOC: CRTC scaling filter property
> + *
> + * SCALING_FILTER:
> + *
> + * Indicates scaling filter to be used for CRTC scaler
> + *
> + * The value of this property can be one of the following:
> + * Default:
> + *
> +/**
> + * DOC: Plane scaling filter property
> + *
> + * SCALING_FILTER:
> + *
> + * Indicates scaling filter to be used for plane scaler
> + *
> + * The value of this property can be one of the following:
> + * Default:
> + * Driver's default scaling filter
> + * Nearest
> > + igt_output_set_prop_value(output,
> > IGT_CONNECTOR_WRITEBACK_OUT_FENCE_PTR, (uint64_t)out_fence_ptr);
>
> On ARM (32bits), this cast creates a compilation error since the
> pointer size isn't an uint64_t.
Does casting to uintptr_t before uint64_t fix it?
Hi,
On Monday, March 30, 2020 8:38 PM, Pankaj Bharadiya
wrote:
> Userspace patch series link: https://github.com/lrusak/xbmc/pull/24
This pull request is against a fork, not the official Kodi repository.
Are there any plans to upstream the change so that users can benefit
from it? Is there a
On Monday, March 30, 2020 8:38 PM, Pankaj Bharadiya
wrote:
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 906771e03103..b0335e9d887c 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -509,6 +509,18 @@ Variable Refresh
Adding zeis...@freebsd.org for FreeBSD. I'll try to see if I can ping
some NetBSD/OpenBSD folks too.
On Tuesday, November 12, 2019 4:03 PM, Daniel Vetter
wrote:
> Hi all,
>
> Dave and me chatted about this last week on irc. Essentially we have:
>
> $ git grep SPDX.*GPL --
zpos
values for two different planes, either make the ordering unspecified. To allow
drivers that don't know the relative ordering between two planes to still
expose the zpos property, choose the latter solution.
Signed-off-by: Simon Ser
---
drivers/gpu/drm/drm_blend.c | 8
1 file changed
This patch adds the Type-C port number to the encoder name. This is an
alternative to [1].
[1]: https://patchwork.freedesktop.org/series/65695/
Signed-off-by: Simon Ser
Cc: Imre Deak
Cc: Manasi Navare
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 11 ++-
1 file
This patch adds a line with the port name to connectors in
debugfs/i915_debug_info. If the port is Type-C, the Type-C port number is
printed too.
Signed-off-by: Simon Ser
Cc: Imre Deak
Cc: Manasi Navare
Reviewed-by: Imre Deak
---
Resending v2 to the correct mailing list.
drivers/gpu/drm
On Thursday, April 18, 2019 8:20 AM, Simon Ser wrote:
> On Wednesday, April 17, 2019 11:35 PM, Simon Ser cont...@emersion.fr wrote:
>
> > In terms of graphs, if a plane is a node and a two-plane overlap is an
> > edge, it means we want a complete graph (each node has an edg
On Wednesday, April 17, 2019 11:35 PM, Simon Ser wrote:
> In terms of graphs, if a plane is a node and a two-plane overlap is an
> edge, it means we want a complete graph (each node has an edge to all
> other nodes). If we only have square planes, it's already impossible to
> get a so
>
> > > > Op 16-04-2019 om 15:20 schreef Ville Syrjälä:
> > > >
> > > > > On Sat, Apr 13, 2019 at 11:13:27AM +, Simon Ser wrote:
> > > > >
> > > > > > From: Ville Syrjälä ville.syrj...@linux.intel.com
> > > > >
From: Ville Syrjälä
This adds basic immutable support for the zpos property. The zpos increases
from bottom to top: primary, sprites, cursor.
Signed-off-by: Ville Syrjälä
[cont...@emersion.fr: adapted for latest drm-tip]
Signed-off-by: Simon Ser
---
Maarten, could your review this patch
Hi Jani,
git blame says you are familiar with intel_primary_plane_create! Would
you have some time to review this patch?
Thanks!
--
Simon Ser
https://emersion.fr
> From: Ville Syrjälä
>
> This adds basic immutable support for the zpos property. The zpos increases
> from bottom to
From: Ville Syrjälä
This adds basic immutable support for the zpos property. The zpos increases
from bottom to top: primary, sprites, cursor.
Signed-off-by: Ville Syrjälä
[cont...@emersion.fr: adapted for latest drm-tip]
Signed-off-by: Simon Ser
---
Changes in v2: set correct author and S-o
On Tuesday, April 2, 2019 3:35 PM, Joonas Lahtinen
wrote:
> Quoting Simon Ser (2019-03-30 00:19:25)
>
> > From: emersion cont...@emersion.fr
>
> Please fix your From: field.
Gah.
> > This adds basic immutable support for the zpos property. The zpos increases
> &g
From: emersion
This adds basic immutable support for the zpos property. The zpos increases
from bottom to top: primary, sprites, cursor.
Signed-off-by: Simon Ser
---
This is based on a previous patch by Ville [1] that I wanted to review.
Unfortunately the patch no longer applies, so here
96 matches
Mail list logo
