On Tue, Jan 23, 2024 at 12:28:33PM +0200, Imre Deak wrote:
> +static char yes_no_chr(int val)
> +{
> + return val ? 'Y' : 'N';
> +}
We have str_yes_no() already.
v> +
> +#define SKIP_DPRX_CAPS_CHECK BIT(0)
> +#define ALLOW_ALLOCATED_BW_CHANGEBIT(1)
> +
> +static bool tunnel_regs_a
t)
> return ret;
>
> + if (intel_connector_needs_modeset(state, connector)) {
> + ret = intel_dp_tunnel_atomic_check_state(state,
> +
> intel_connector->mst_port,
> + intel_connector);
> + if (ret)
> + return ret;
> + }
> +
> return drm_dp_atomic_release_time_slots(&state->base,
>
> &intel_connector->mst_port->mst_mgr,
> intel_connector->port);
> --
> 2.39.2
--
Ville Syrjälä
Intel
const struct intel_connector
> *connector,
> + struct intel_crtc_state
> *crtc_state);
> +
> +int intel_dp_tunnel_atomic_add_state_for_crtc(struct intel_atomic_state
> *state,
> + struct intel_crtc *crtc);
> +int intel_dp_tunnel_atomic_check_link(struct intel_atomic_state *state,
> + struct intel_link_bw_limits *limits);
> +int intel_dp_tunnel_atomic_check_state(struct intel_atomic_state *state,
> +struct intel_dp *intel_dp,
> +struct intel_connector *connector);
> +void intel_dp_tunnel_atomic_alloc_bw(struct intel_atomic_state *state,
> + struct intel_encoder *encoder,
> + const struct intel_crtc_state
> *new_crtc_state,
> + const struct drm_connector_state
> *new_conn_state);
> +void intel_dp_tunnel_atomic_free_bw(struct intel_atomic_state *state,
> + struct intel_encoder *encoder,
> + const struct intel_crtc_state
> *old_crtc_state,
> + const struct drm_connector_state
> *old_conn_state);
> +
> +int intel_dp_tunnel_mgr_init(struct drm_i915_private *i915);
> +void intel_dp_tunnel_mgr_cleanup(struct drm_i915_private *i915);
> +
> +#else
> +
> +static inline int
> +intel_dp_tunnel_detect(struct intel_dp *intel_dp, struct
> drm_modeset_acquire_ctx *ctx)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static inline void intel_dp_tunnel_disconnect(struct intel_dp *intel_dp) {}
> +static inline void intel_dp_tunnel_destroy(struct intel_dp *intel_dp) {}
> +static inline void intel_dp_tunnel_resume(struct intel_dp *intel_dp, bool
> dpcd_updated) {}
> +static inline void intel_dp_tunnel_suspend(struct intel_dp *intel_dp) {}
> +
> +static inline bool intel_dp_tunnel_bw_alloc_is_enabled(struct intel_dp
> *intel_dp)
> +{
> + return false;
> +}
> +
> +static inline void
> +intel_dp_tunnel_atomic_cleanup_inherited_state(struct intel_atomic_state
> *state) {}
> +
> +static inline void
> +intel_dp_tunnel_atomic_compute_stream_bw(struct intel_atomic_state *state,
> + struct intel_dp *intel_dp,
> + const struct intel_connector
> *connector,
> + struct intel_crtc_state *crtc_state) {}
> +
> +static inline int
> +intel_dp_tunnel_atomic_add_state_for_crtc(struct intel_atomic_state *state,
> + struct intel_crtc *crtc)
> +{
> + return 0;
> +}
> +
> +static inline int
> +intel_dp_tunnel_atomic_check_link(struct intel_atomic_state *state,
> + struct intel_link_bw_limits *limits)
> +{
> + return 0;
> +}
> +
> +static inline int
> +intel_dp_tunnel_atomic_check_state(struct intel_atomic_state *state,
> +struct intel_dp *intel_dp,
> +struct intel_connector *connector)
> +{
> + return 0;
> +}
> +
> +static inline void
> +intel_dp_tunnel_atomic_alloc_bw(struct intel_atomic_state *state,
> + struct intel_encoder *encoder,
> + const struct intel_crtc_state *new_crtc_state,
> + const struct drm_connector_state
> *new_conn_state) {}
> +static inline void
> +intel_dp_tunnel_atomic_free_bw(struct intel_atomic_state *state,
> +struct intel_encoder *encoder,
> +const struct intel_crtc_state *old_crtc_state,
> +const struct drm_connector_state
> *old_conn_state) {}
> +
> +static inline int
> +intel_dp_tunnel_mgr_init(struct drm_i915_private *i915)
> +{
> + return 0;
> +}
> +
> +static inline void intel_dp_tunnel_mgr_cleanup(struct drm_i915_private
> *i915) {}
> +
> +#endif /* CONFIG_DRM_I915_DP_TUNNEL */
> +
> +#endif /* __INTEL_DP_TUNNEL_H__ */
> --
> 2.39.2
--
Ville Syrjälä
Intel
ke this "tunnels are magically created by detect
behind our back" approach. IMO in an ideal world we'd only ever create the
tunnels during modeset/sanitize. What was the reason that didn't work again?
I think you explained it to me in person at least once already, but can't
remember anymore...
--
Ville Syrjälä
Intel
On Mon, Feb 05, 2024 at 07:15:17PM +0200, Imre Deak wrote:
> On Mon, Feb 05, 2024 at 06:13:30PM +0200, Ville Syrjälä wrote:
> > On Wed, Jan 31, 2024 at 08:49:16PM +0200, Imre Deak wrote:
> > > On Wed, Jan 31, 2024 at 06:09:04PM +0200, Ville Syrjälä wrote:
> > > > On T
On Wed, Jan 31, 2024 at 08:49:16PM +0200, Imre Deak wrote:
> On Wed, Jan 31, 2024 at 06:09:04PM +0200, Ville Syrjälä wrote:
> > On Tue, Jan 23, 2024 at 12:28:33PM +0200, Imre Deak wrote:
> > > +static void untrack_tunnel_ref(struct drm_dp_tunnel *tunnel,
> > > +
539ba996ddf 100644
> --- a/drivers/gpu/drm/i915/display/intel_link_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_link_bw.c
> @@ -8,6 +8,7 @@
> #include "intel_atomic.h"
> #include "intel_display_types.h"
> #include "intel_dp_mst.h"
> +#include "intel_dp_tunnel.h"
> #include "intel_fdi.h"
> #include "intel_link_bw.h"
>
> @@ -149,6 +150,10 @@ static int check_all_link_config(struct
> intel_atomic_state *state,
> if (ret)
> return ret;
>
> + ret = intel_dp_tunnel_atomic_check_link(state, limits);
> + if (ret)
> + return ret;
> +
> ret = intel_fdi_atomic_check_link(state, limits);
> if (ret)
> return ret;
> --
> 2.39.2
--
Ville Syrjälä
Intel
On Fri, Feb 02, 2024 at 04:59:30PM +0100, Maxime Ripard wrote:
> On Fri, Feb 02, 2024 at 05:40:47PM +0200, Ville Syrjälä wrote:
> > On Fri, Feb 02, 2024 at 02:01:39PM +0100, Maxime Ripard wrote:
> > > Hi,
> > >
> > > On Mon, Jan 15, 2024 at 03
ement
in CTA-861, but some other CTA-861 rule updates are
more or less pointless as you can't in general detect
which version of the spec the sink claims to implement.
Eg. we already had cases where following the new CTA-861-F
rules for the YQ bit when transmitting RGB broke some
displays. And we are now forced to use the presence of
HDMI 2.0+ capabilities as a heuristic to detect CTA-851-F+.
(see drm_hdmi_avi_infoframe_quant_range()). It's pretty
nasty.
And I think there is some other infoframe related issue
(something to do with VICs IIRC) where we'd need to derive
the CTA-861 version eg. from the set of advertised VICs
in the EDID. I might have even written some code for that
at some point but never finished it. So it's still
broken in the current code. Can't recall the specific
details right now unfortunately.
--
Ville Syrjälä
Intel
configured at modeset time to
reflect whether we're about to transmit in MST or SST mode.
>
> Cc: Arun R Murthy
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deleti
; set the topology manager state there.
>
> The main functional difference is that the DP_MSTM_CAP DPCD register is
> now only read once at detect, unconditionally, and the MST support is
> always logged. Everything else should remain the same.
>
> Cc: Arun R Murthy
> Cc: Vi
the value of the property.
The property is literally called "Broadcast *RGB*".
That should explain why it's only affecting RGB.
Full range YCbCr is a much rarer beast so we've never bothered
to enable it. Eg. with DP it only became possible with the
introduction of the VSC SDP (and I don't recall if there's
additional capability checks that are also required). With
DP MSA signalling full range YCbCr is not possible at all.
I don't recall right now what the HDMI requirements are.
--
Ville Syrjälä
Intel
On Fri, Feb 02, 2024 at 04:05:31PM +0200, Jani Nikula wrote:
> Amend drm_dp_read_mst_cap() to return an enum, indicating "none",
> "sideband messaging", or "mst". Modify all call sites to take the new
> return value into account.
>
> Cc: Arun R Murth
astset_check(struct intel_encoder *encoder,
> @@ -5973,6 +5977,8 @@ void intel_dp_encoder_suspend(struct intel_encoder
> *intel_encoder)
> struct intel_dp *intel_dp = enc_to_intel_dp(intel_encoder);
>
> intel_pps_vdd_off_sync(intel_dp);
> +
> + intel_dp_tunnel_suspend(intel_dp);
> }
>
> void intel_dp_encoder_shutdown(struct intel_encoder *intel_encoder)
> --
> 2.39.2
--
Ville Syrjälä
Intel
On Tue, Jan 23, 2024 at 12:28:33PM +0200, Imre Deak wrote:
> Add support for Display Port DP tunneling. For now this includes the
> support for Bandwidth Allocation Mode, leaving adding Panel Replay
> support for later.
>
> BWA allows using displays that share the same (Thunderbolt) link with
> th
On Tue, Jan 30, 2024 at 06:00:18PM -0500, Sasha Levin wrote:
> On Mon, Jan 22, 2024 at 06:50:00PM +0200, Ville Syrjälä wrote:
> >On Mon, Jan 22, 2024 at 10:08:05AM -0500, Sasha Levin wrote:
> >> From: Ville Syrjälä
> >>
> >> [ Upstream commit c6fbb6bca10838485
int intel_power_domains_init(struct drm_i915_private
> *dev_priv)
> */
> void intel_power_domains_cleanup(struct drm_i915_private *dev_priv)
> {
> + intel_power_domains_init_flag = 0;
> intel_display_power_map_cleanup(&dev_priv->display.power.domains);
> }
>
> --
> 2.25.1
--
Ville Syrjälä
Intel
/drm_dp_helper.h
> index 863b2e7add29e..454ae7517419a 100644
> --- a/include/drm/display/drm_dp_helper.h
> +++ b/include/drm/display/drm_dp_helper.h
> @@ -813,4 +813,6 @@ int drm_dp_bw_overhead(int lane_count, int hactive,
> int bpp_x16, unsigned long flags);
> int drm_dp_bw_channel_coding_efficiency(bool is_uhbr);
>
> +int drm_dp_max_dprx_data_rate(int max_link_rate, int max_lanes);
> +
> #endif /* _DRM_DP_HELPER_H_ */
> --
> 2.39.2
--
Ville Syrjälä
Intel
On Wed, Jan 24, 2024 at 11:14:40AM -0300, André Almeida wrote:
> Hi Ville,
>
> Em 19/01/2024 15:25, Ville Syrjälä escreveu:
> > On Fri, Jan 19, 2024 at 03:12:35PM -0300, André Almeida wrote:
> >> AMD GPUs can do async flips with changes on more properties than just
> &
On Mon, Jan 22, 2024 at 10:08:05AM -0500, Sasha Levin wrote:
> From: Ville Syrjälä
>
> [ Upstream commit c6fbb6bca10838485b820e8a26c23996f77ce580 ]
Why is this being backported?
>
> The current implementation of drm_color_lut_extract()
> generates weird results. Eg. if we
funcs = {
> .atomic_duplicate_state = amdgpu_dm_plane_drm_plane_duplicate_state,
> .atomic_destroy_state = amdgpu_dm_plane_drm_plane_destroy_state,
> .format_mod_supported = amdgpu_dm_plane_format_mod_supported,
> + .check_async_props = amdgpu_dm_plane_check_async_props,
> };
>
> int amdgpu_dm_plane_init(struct amdgpu_display_manager *dm,
> --
> 2.43.0
--
Ville Syrjälä
Intel
tion 'drm_color_lut_extract':
> include/drm/drm_color_mgmt.h:45:46: error: implicit declaration of function
> 'mul_u32_u32' [-Werror=implicit-function-declaration]
>45 | return DIV_ROUND_CLOSEST_ULL(mul_u32_u32(user_input,
> (1 << bit_precision) - 1),
> | ^~~
>
> Signed-off-by: Stephen Rothwell
Mea culpa.
I slapped on a
Fixes: c6fbb6bca108 ("drm: Fix color LUT rounding")
and applied this to drm-misc-next-fixes. Thanks.
> ---
> include/drm/drm_color_mgmt.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> index 54b2b2467bfd..ed81741036d7 100644
> --- a/include/drm/drm_color_mgmt.h
> +++ b/include/drm/drm_color_mgmt.h
> @@ -24,6 +24,7 @@
> #define __DRM_COLOR_MGMT_H__
>
> #include
> +#include
> #include
>
> struct drm_crtc;
> --
> 2.40.1
>
> --
> Cheers,
> Stephen Rothwell
--
Ville Syrjälä
Intel
On Fri, Dec 15, 2023 at 12:34:48PM +0100, Javier Martinez Canillas wrote:
> Ville Syrjala writes:
>
> Hello Ville,
>
> > From: Ville Syrjälä
> >
> > The original rationale for
> > commit cd456f8d06d2 ("drm: Restrict stackdepot usage to builtin drm.ko&qu
here.
>
> Reported-by: bbaa
> Closes:
> https://lore.kernel.org/r/930e9b4c7d91fdff+29b34d89-8658-4910-966a-c772f320e...@bbaa.fun
> Fixes: c533b5167c7e ("drm/edid: add separate drm_edid_connector_add_modes()")
> Cc: # v6.3+
> Signed-off-by: Jani Nikula
Rev
On Fri, Dec 01, 2023 at 06:16:16PM +0200, Pekka Paalanen wrote:
> On Fri, 1 Dec 2023 17:00:32 +0200
> Ville Syrjälä wrote:
>
> > On Thu, Nov 30, 2023 at 05:07:40PM -0300, André Almeida wrote:
> > > From: Pekka Paalanen
> > >
> > > Specify how the at
On Wed, Nov 29, 2023 at 12:25:37PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 29, 2023 at 12:12:59PM +0200, Pekka Paalanen wrote:
> > On Tue, 28 Nov 2023 15:49:08 +0200
> > Ville Syrjälä wrote:
> >
> > > Should we perhaps start to use the (arguably hideous)
&
On Fri, Dec 01, 2023 at 10:01:49AM +0100, Maxime Ripard wrote:
> On Wed, Nov 29, 2023 at 11:18:24AM +0200, Ville Syrjälä wrote:
> > On Wed, Nov 29, 2023 at 10:11:26AM +0100, Maxime Ripard wrote:
> > > Hi Ville,
> > >
> > > On Tue, Nov 28, 2023 at 03:49:08PM +0
e display, etc. I suppose we could specify that if no
FB is specified at all then these kind of side effects could be ignored,
but that is certainly not how things are implemented right now.
So for optimal behaviour userspace should be minimizing the commits.
--
Ville Syrjälä
Intel
et applied
>
> ----
> Tvrtko Ursulin (1):
> drm/i915/gsc: Mark internal GSC engine with reserved uabi class
>
> Ville Syrjälä (2):
> drm/i915: Also check for VGA converter in eDP probe
> drm/i915: Call inte
On Wed, Nov 29, 2023 at 12:12:59PM +0200, Pekka Paalanen wrote:
> On Tue, 28 Nov 2023 15:49:08 +0200
> Ville Syrjälä wrote:
>
> > Should we perhaps start to use the (arguably hideous)
> > - void f(struct foo *bar)
> > + void f(struct foo bar[static 1])
> > syn
On Wed, Nov 29, 2023 at 10:11:26AM +0100, Maxime Ripard wrote:
> Hi Ville,
>
> On Tue, Nov 28, 2023 at 03:49:08PM +0200, Ville Syrjälä wrote:
> > On Tue, Nov 28, 2023 at 02:29:40PM +0100, Maxime Ripard wrote:
> > > On Tue, Nov 28, 2023 at 02:54:02PM +0200, Jani Nikula w
that has the same problem as using any
other kind of array syntax in the prototype. That is,
the compiler demands to know the definition of 'struct foo'
even though we're passing in effectively a pointer. Sigh.
--
Ville Syrjälä
Intel
}
>
> @@ -115,7 +123,8 @@ static void panel_bridge_detach(struct drm_bridge *bridge)
> struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
> struct drm_connector *connector = &panel_bridge->connector;
>
> - device_link_del(panel_bridge->link);
> + if (panel_bridge->is_independent)
> + device_link_del(panel_bridge->link);
>
> /*
>* Cleanup the connector if we know it was initialized.
> --
> 2.37.1
--
Ville Syrjälä
Intel
On Tue, Nov 21, 2023 at 11:51:10AM +0100, Maxime Ripard wrote:
> On Mon, Nov 20, 2023 at 04:30:53PM +0200, Ville Syrjälä wrote:
> > On Fri, Oct 13, 2023 at 04:13:58PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > The current LUT rounding
ct intel_dp *intel_dp,
> if (recv_bytes == 0 || recv_bytes > 20) {
> drm_dbg_kms(&i915->drm,
> "%s: Forbidden recv_bytes = %d on aux
> transaction\n",
> - intel_dp->aux.name, recv_bytes);
> + intel_dp->aux.name ? intel_dp->aux.name : "",
> recv_bytes);
> ret = -EBUSY;
> goto out;
> }
> --
> 2.34.1
--
Ville Syrjälä
Intel
should be
rejecting vscan>1 outright. Which driver is this?
Is there an actual usecase where nouveau needs this (and does
it even work?) or could we just rip out the whole thing and
reject vscan>1 globally?
>
> return DIV_ROUND_CLOSEST_ULL(mul_u32_u32(num, 1000), den);
> }
> --
> 2.25.1
--
Ville Syrjälä
Intel
On Fri, Oct 13, 2023 at 04:13:58PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The current LUT rounding is generating weird results. Adjust
> it to follow the OpenGL int<->float conversion rules.
>
> Ville Syrjälä (4):
> drm: Fix color LUT rounding
^
On Mon, Nov 20, 2023 at 01:17:05PM +, Borah, Chaitanya Kumar wrote:
>
>
> > -Original Message-
> > From: Borah, Chaitanya Kumar
> > Sent: Monday, November 20, 2023 6:33 PM
> > To: Ville Syrjälä
> > Cc: intel-...@lists.freedesktop.org; dri-devel@li
; > Cc: dri-devel@lists.freedesktop.org
> > Subject: [PATCH 2/4] drm/i915: Adjust LUT rounding rules
> >
> > From: Ville Syrjälä
> >
> > drm_color_lut_extract() rounding was changed to follow the OpenGL int<-
> > >float conversion rules. Adjust intel_co
ate.
>
> v2:
> - Return the fractional pbn_div value from drm_dp_get_vc_payload_bw().
> v3:
> - Fix rounding up quotient while calculating req_slots. (Ville)
>
> Cc: Ville Syrjälä
> Cc: Lyude Paul
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-
s. (Ville)
> - Add references to the DP Standard tables.
> v3:
> - Sort the testcases properly.
>
> Cc: Ville Syrjälä
> Cc: Lyude Paul
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
> ---
> .../gpu/drm/tests/drm_dp_ms
->lane_count);
> +}
> +
> +KUNIT_ARRAY_PARAM(drm_dp_mst_calc_pbn_div,
> drm_dp_mst_calc_pbn_div_dp1_4_cases,
> + dp_mst_calc_pbn_div_desc);
> +
> static u8 data[] = { 0xff, 0x00, 0xdd };
>
> struct drm_dp_mst_sideband_msg_req_test {
> @@ -416,6 +560,7 @@ KUNIT_ARRAY_PARAM(drm_dp_mst_sideband_msg_req,
> drm_dp_mst_sideband_msg_req_cases
>
> static struct kunit_case drm_dp_mst_helper_tests[] = {
> KUNIT_CASE_PARAM(drm_test_dp_mst_calc_pbn_mode,
> drm_dp_mst_calc_pbn_mode_gen_params),
> + KUNIT_CASE_PARAM(drm_test_dp_mst_calc_pbn_div,
> drm_dp_mst_calc_pbn_div_gen_params),
> KUNIT_CASE_PARAM(drm_test_dp_mst_sideband_msg_req_decode,
>drm_dp_mst_sideband_msg_req_gen_params),
> { }
> --
> 2.39.2
--
Ville Syrjälä
Intel
T_ADJUSTMENT_CAP);
> }
>
> +/**
> + * drm_dp_is_uhbr_rate - Determine if a link rate is UHBR
> + * @link_rate: link rate in 10kbits/s units
> + *
> + * Determine if the provided link rate is an UHBR rate.
> + *
> + * Returns: %True if @link_rate is an UHBR rate.
> + */
> +static inline bool drm_dp_is_uhbr_rate(int link_rate)
> +{
> + return link_rate >= 100;
> +}
> +
> /*
> * DisplayPort AUX channel
> */
> --
> 2.39.2
--
Ville Syrjälä
Intel
t;pbn_div.full =
> dfixed_const(dm_mst_get_pbn_divider(aconnector->mst_root->dc_link));
Why doesn't that dfixed stuff return the correct type?
Anyways looks mostly mechanical
Reviewed-by: Ville Syrjälä
>
> if (!state->duplicated) {
> int max_bpc = con
On Thu, Nov 09, 2023 at 12:01:26PM -0800, Belgaumkar, Vinay wrote:
>
> On 11/9/2023 11:30 AM, Ville Syrjälä wrote:
> > On Thu, Nov 09, 2023 at 11:21:48AM -0800, Vinay Belgaumkar wrote:
> >> We read RENDER_HEAD as a part of the flush. If GT is in
> >> deeper sleep s
> spin_lock_irqsave(&uncore->lock, flags);
> intel_uncore_posting_read_fw(uncore,
> - RING_HEAD(RENDER_RING_BASE));
> + RING_TAIL(RENDER_RING_BASE));
> spin_unlock_irqrestore(&uncore->lock, flags);
> }
> }
> --
> 2.38.1
--
Ville Syrjälä
Intel
On Tue, Nov 07, 2023 at 12:28:24AM +0200, Imre Deak wrote:
> On Mon, Nov 06, 2023 at 11:31:51PM +0200, Ville Syrjälä wrote:
> > On Mon, Oct 30, 2023 at 05:58:22PM +0200, Imre Deak wrote:
> > > Add helpers drivers can use to calculate the BW allocation overhead -
> > > du
with the formula to calculate the total FEC overhead. (Ville)
> v4:
> - Rename DRM_DP_OVERHEAD_SSC to DRM_DP_OVERHEAD_SSC_REF_CLK. (Ville)
>
> Cc: Lyude Paul
> Cc: Ville Syrjälä
> Cc: kernel test robot
> Cc: dri-devel@lists.freedesktop.org
> Reviewed-by: Stanislav Lisovskiy (v2)
check for
DISPLAY_VER >=9.
> else if (IS_VALLEYVIEW(dev_priv))
> vlv_exec_gpio(connector, gpio_source, gpio_number, value);
> else if (IS_CHERRYVIEW(dev_priv))
> --
> 2.40.0.1.gaa8946217a0b
--
Ville Syrjälä
Intel
that this is racy.
>
> So a better idea would be to unregister the GPIO lookup
> table registered by intel_dsi_vbt_gpio_init() after getting
> the GPIOs there, that would allow instantiating a new one
> from soc_exec_opaque_gpio() as it currently does and that
> would be race free.
The proper solution would likely be be to pre-parse the sequences
to determine which GPIOs are actually needed. That would also get
rid of the bxt_gpio_table[] eyesore.
--
Ville Syrjälä
Intel
_EMULATION
> >> -int intel_fbdev_init(struct drm_device *dev);
> >> -void intel_fbdev_initial_config_async(struct drm_i915_private
> >> *dev_priv);
> >> -void intel_fbdev_unregister(struct drm_i915_private *dev_priv);
> >> -void intel_fbdev_fini(struct drm_i915_private *dev_priv);
> >> +void intel_fbdev_setup(struct drm_i915_private *dev_priv);
> >> void intel_fbdev_set_suspend(struct drm_device *dev, int state, bool
> >> synchronous);
> >> struct intel_framebuffer *intel_fbdev_framebuffer(struct intel_fbdev
> >> *fbdev);
> >> #else
> >> -static inline int intel_fbdev_init(struct drm_device *dev)
> >> -{
> >> - return 0;
> >> -}
> >> -
> >> -static inline void intel_fbdev_initial_config_async(struct
> >> drm_i915_private *dev_priv)
> >> -{
> >> -}
> >> -
> >> -static inline void intel_fbdev_unregister(struct drm_i915_private
> >> *dev_priv)
> >> -{
> >> -}
> >> -
> >> -static inline void intel_fbdev_fini(struct drm_i915_private
> >> *dev_priv)
> >> +static inline void intel_fbdev_setup(struct drm_i915_private
> >> *dev_priv)
> >> {
> >> }
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> >> b/drivers/gpu/drm/i915/i915_driver.c
> >> index 86460cd8167d1..53663c0cc3be4 100644
> >> --- a/drivers/gpu/drm/i915/i915_driver.c
> >> +++ b/drivers/gpu/drm/i915/i915_driver.c
> >> @@ -817,6 +817,8 @@ int i915_driver_probe(struct pci_dev *pdev, const
> >> struct pci_device_id *ent)
> >>
> >> i915->do_release = true;
> >>
> >> + intel_fbdev_setup(i915);
> >> +
> >> return 0;
> >>
> >> out_cleanup_gem:
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstrasse 146, 90461 Nuernberg, Germany
> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
> HRB 36809 (AG Nuernberg)
--
Ville Syrjälä
Intel
omment.
>
> BR,
> Jani.
>
> --
> Jani Nikula, Intel
--
Ville Syrjälä
Intel
(drm_dp_calc_pbn_mode);
>
> diff --git a/include/drm/display/drm_dp_helper.h
> b/include/drm/display/drm_dp_helper.h
> index da94932f4262b..d0f7406c510a8 100644
> --- a/include/drm/display/drm_dp_helper.h
> +++ b/include/drm/display/drm_dp_helper.h
> @@ -788,4 +788,15 @@ bool drm_dp_downstream_rgb_to_ycbcr_conversion(const u8
> dpcd[DP_RECEIVER_CAP_SIZ
> const u8 port_cap[4], u8
> color_spc);
> int drm_dp_pcon_convert_rgb_to_ycbcr(struct drm_dp_aux *aux, u8 color_spc);
>
> +#define DRM_DP_BW_OVERHEAD_MST BIT(0)
> +#define DRM_DP_BW_OVERHEAD_UHBR BIT(1)
> +#define DRM_DP_BW_OVERHEAD_SSC BIT(2)
> +#define DRM_DP_BW_OVERHEAD_FEC BIT(3)
> +#define DRM_DP_BW_OVERHEAD_DSC BIT(4)
> +
> +int drm_dp_bw_overhead(int lane_count, int hactive,
> +int dsc_slice_count,
> +int bpp_x16, unsigned long flags);
> +int drm_dp_bw_channel_coding_efficiency(bool is_uhbr);
> +
> #endif /* _DRM_DP_HELPER_H_ */
> --
> 2.39.2
--
Ville Syrjälä
Intel
+ return -EFAULT;
> + }
>
> for (i = 0; i < info->num_planes; i++) {
> unsigned int width = fb_plane_width(r->width, info, i);
> --
> 2.37.1
--
Ville Syrjälä
Intel
ck_irq(&crtc->dev->event_lock);
> > +
> > + crtc->state->event = NULL;
>
> I think even should be cleared within the lock.
event_lock doesn't protect anything in the crtc state.
But the bigger problem in this code is the prevalent crtc->state
usage. That should pretty much never be done, especially in anything
that can get called from the actual commit phase where you no longer
have the locks held. Instead one should almost always use the
get_{new,old}_state() stuff, or the old/new/oldnew state iterators.
>
> > + }
> > +}
> > +
> > +static void vs_crtc_atomic_begin(struct drm_crtc *crtc,
> > +struct drm_atomic_state *state)
> > +{
> > + struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(state,
> > + crtc);
> > +
> > + struct vs_crtc *vs_crtc = to_vs_crtc(crtc);
> > + struct device *dev = vs_crtc->dev;
> > + struct drm_property_blob *blob = crtc->state->gamma_lut;
Eg. here you are using drm_atomic_get_new_crtc_state() correctly, but
then proceed to directly access crtc->state anyway.
> > + struct drm_color_lut *lut;
> > + struct vs_dc *dc = dev_get_drvdata(dev);
> > +
> > + if (crtc_state->color_mgmt_changed) {
> > + if (blob && blob->length) {
> > + lut = blob->data;
> > + vs_dc_set_gamma(dc, crtc, lut,
> > + blob->length / sizeof(*lut));
> > + vs_dc_enable_gamma(dc, crtc, true);
> > + } else {
> > + vs_dc_enable_gamma(dc, crtc, false);
> > + }
> > + }
> > +}
--
Ville Syrjälä
Intel
On Tue, Oct 24, 2023 at 04:12:34PM +0300, Pekka Paalanen wrote:
> On Tue, 24 Oct 2023 16:03:27 +0300
> Ville Syrjälä wrote:
>
> > On Tue, Oct 24, 2023 at 09:03:22AM +, Simon Ser wrote:
> > > On Tuesday, October 24th, 2023 at 09:36, Pekka Paalanen
> > > w
ould remain the same as long as the
topology didn't change, but I don't think there's anything in the
DP spec that actually guarantees that (eg. some branch device
could in theory reshuffle its port numbers on a whim).
But there is no stable identifier for the corresponding SST
connec
return ret;
> }
>
> - list_del_init(&fb->filp_head);
> - mutex_unlock(&file_priv->fbs_lock);
> -
> - /* drop the reference we picked up in framebuffer lookup */
> - drm_framebuffer_put(f
gt; > alert the user about issues.
>
> Btw, a lot of people (Greg claims it's the majority of Linux users)
> these days have run kernels with panic on warn enabled so that's another
> reason to avoid using WARN_ON() for stuff that it known to be possible.
This is not possible, unless there is a serious bug somewhere else.
--
Ville Syrjälä
Intel
On Mon, Oct 16, 2023 at 10:00:51PM +, Simon Ser wrote:
> On Monday, October 16th, 2023 at 17:10, Ville Syrjälä
> wrote:
>
> > On Mon, Oct 16, 2023 at 05:52:22PM +0300, Pekka Paalanen wrote:
> >
> > > On Mon, 16 Oct 2023 15:42:16 +0200
> > > And
d be like:
> >
> > Flipping to the same FB_ID will result in a immediate flip as if it was
> > changing to a different one, with no effect on the image but effecting
> > the reported frame rate.
>
> Re-setting FB_ID to its current value is a special case regardless of
> PAGE_FLIP_ASYNC, is it not?
No. The rule has so far been that all side effects are observed
even if you flip to the same fb. And that is one of my annoyances
with this proposal. The rules will now be different for async flips
vs. everything else.
The other issues (mainly relating to hardware where not all planes
support async flips) I've already highlighted in some earlier mail.
--
Ville Syrjälä
Intel
On Fri, Oct 13, 2023 at 02:28:21PM +0200, Nirmoy Das wrote:
> Hi Ville,
>
> On 10/13/2023 12:50 PM, Ville Syrjälä wrote:
> > On Fri, Oct 13, 2023 at 12:31:40PM +0200, Nirmoy Das wrote:
> >> gen8_ggtt_invalidate() is only needed for limitted set of platforms
> >>
X_FLSH_CNTL_EN);
> + if (!IS_GEN9_LP(i915) && GRAPHICS_VER(i915) < 11)
> + intel_uncore_write_fw(uncore, GFX_FLSH_CNTL_GEN6,
> GFX_FLSH_CNTL_EN);
> }
>
> static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
> --
> 2.41.0
--
Ville Syrjälä
Intel
ze signed int. Might be
better to add some explicit casts.
> }
>
> static inline int mmio_diff_handler(struct intel_gvt *gvt,
> --
> 2.25.1
--
Ville Syrjälä
Intel
7;, 0, EDID_QUIRK_FORCE_6BPC),
>
> + /* BenQ GW2765 */
> + EDID_QUIRK('B', 'N', 'Q', 0x78d6, EDID_QUIRK_FORCE_8BPC),
> +
> /* BOE model on HP Pavilion 15-n233sl reports 8 bpc, but is a 6 bpc
> panel */
> EDID_QUIRK('B', 'O', 'E', 0x78b, EDID_QUIRK_FORCE_6BPC),
>
> --
> 2.42.0
--
Ville Syrjälä
Intel
on which is a
> >> valid goal here.
> > Okay so let's land his patchset! (assuming it's ready to go in).
> > Ville, is that something you'd want to resend for review?
>
> Well, while Ville patch has at least some justification I would still
> strongly object to move the work into a background thread to prevent
> userspace from being accounted for the work it causes.
Aren't most wayland compositors using nonblocking commits anyway?
If so they would already be bypassing proper CPU time accounting.
Not saying we shouldn't try to fix that, but just pointing out that
it already is an issue with nonblocking commits.
--
Ville Syrjälä
Intel
Yeah, this seems a bit more reasonble at least than then
current behaviour.
>
> See this wlroots issue:
> https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3407
>
> Previous discussion:
> https://lore.kernel.org/intel-gfx/y6gx7z17wmdsk...@ideak-desk.fi.intel.com/
>
S_HASWELL_EARLY_SDV(i915) (IS_HASWELL(i915) && \
> - (INTEL_DEVID(i915) & 0xFF00) == 0x0C00)
> #define IS_BROADWELL_ULT(i915) \
> IS_SUBPLATFORM(i915, INTEL_BROADWELL, INTEL_SUBPLATFORM_ULT)
> #define IS_BROADWELL_ULX(i915) \
> --
> 2.39.2
--
Ville Syrjälä
Intel
the flush.
In my earlier series [1] where I move the flush to happen after dropping
the locks there is a far more subtle issue because currently even
non-blocking commits can actually block due to the mutex. Changing
that might break something, so I preserved that behaviour explicitly.
Full explanation in the first patch there.
[1] https://patchwork.freedesktop.org/series/108668/
--
Ville Syrjälä
Intel
On Thu, Sep 28, 2023 at 03:33:46PM -0400, Ray Strode wrote:
> hI,
>
> On Thu, Sep 28, 2023 at 11:05 AM Ville Syrjälä
> wrote:
> > Here's my earlier take on this:
> > https://patchwork.freedesktop.org/series/108668/
>
> Nice. Was there push back? Why didn&#x
On Wed, Oct 04, 2023 at 07:21:49PM +0300, Jani Nikula wrote:
> Prefer struct drm_edid where possible. With limited users for the
> drm_dp_downstream_*() helpers, this is fairly straightforward.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drive
t so I might be wrong. Or maybe both places should have
one?
> - * persistent error remap it with the l3 remapping tool supplied in
> + * persistent error, remap it with the l3 remapping tool supplied in
> * intel-gpu-tools. The value supplied with the event is always 1.
> *
> * I915_ERROR_UEVENT - Generated upon error detection, currently only via
--
Ville Syrjälä
Intel
gt; - else
> - commit_tail(state);
> + queue_work(system_unbound_wq, &state->commit_work);
> + if (!nonblock)
> + flush_work(&state->commit_work);
Here's my earlier take on this: https://patchwork.freedesktop.org/series/108668/
execpt I went further and moved the flush past the unlock in the end.
--
Ville Syrjälä
Intel
On Wed, Sep 20, 2023 at 08:40:00PM +0300, Jani Nikula wrote:
> On Thu, 14 Sep 2023, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > There are some weird EDIDs floating around that have the sync
> > pulse extending beyond the end of the blanking period.
> >
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 3 +
> drivers/gpu/drm/i915/display/vlv_dsi.c | 124 +++
> 2 files changed, 127 insertions(+)
>
> --
> 2.41.0
--
Ville Syrjälä
Intel
On Thu, May 25, 2023 at 11:09:30AM +0300, Luca Coelho wrote:
> On Tue, 2023-05-02 at 17:39 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > ICL doesn't support FEC with a x1 DP link. Make sure
> > we don't try to enable FEC in such cases.
On Thu, May 25, 2023 at 12:51:28PM +0300, Luca Coelho wrote:
> On Wed, 2023-05-03 at 14:36 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Track DP enhanced framing properly in the crtc state instead
> > of relying just on the cached DPCD everywhere, and ho
On Tue, Aug 29, 2023 at 02:39:08PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Populate connector->ddc for all output types that don't already
> do so, and clean up a bunch of code as a result of having the
> ddc i2c adapter in easy reach. And this also pr
On Mon, Sep 04, 2023 at 01:22:27PM +0300, Imre Deak wrote:
> On Mon, Sep 04, 2023 at 05:53:11AM +0300, Ville Syrjälä wrote:
> > On Thu, Aug 24, 2023 at 11:05:04AM +0300, Imre Deak wrote:
> > > For fractional bpp values passed to the function in a .4 fixed point
> > > for
; - .bpp = 24,
> + .bpp = 24 << 4,
> .dsc = true,
> - .expected = 50
> + .expected = 1191
> },
> {
> .clock = 324540,
> - .bpp = 24,
> + .bpp = 24 << 4,
> .dsc = true,
> - .expected = 49
> + .expected = 1161
> },
> };
>
> --
> 2.37.2
--
Ville Syrjälä
Intel
"CRT not detected via DDC:0x50 [EDID
> reports a digital panel]\n");
> + "CRT detected via DDC:0x50 [EDID]\n");
> + ret = true;
Inverting the check made the diff a bit confusing, but looks
corr
On Thu, Aug 24, 2023 at 04:46:02PM +0300, Jani Nikula wrote:
> Checking edid->input & DRM_EDID_INPUT_DIGITAL is common enough to
> deserve a helper that also lets us abstract the raw EDID a bit better.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
>
s one option would be to quirk the bogus EDIDs, or maybe just
ignore bogus sync flags for the eDP preferred mode. But maybe needs a
bit more thinking, so
Acked-by: Ville Syrjälä
>
> Rejecting modes with analog composite sync was the part that fixed the
> gitlab issue 8146 [1]. We&#x
On Fri, Jul 14, 2023 at 08:56:15AM +0200, Christian König wrote:
> Am 13.07.23 um 21:47 schrieb Ville Syrjala:
> > From: Ville Syrjälä
> >
> > Currently dma_resv_get_fences() will leak the previously
> > allocated array if the fence iteration got restarted and
>
@lists.freedesktop.org
> > Subject: [Intel-gfx] [PATCH v2 6/7] drm/i915: No 10bit gamma on desktop
> > gen3 parts
> >
> > From: Ville Syrjälä
> >
> > Apparently desktop gen3 parts don't support the 10bit gamma mode at all.
> > Stop
> > claimi
sts.freedesktop.org
> > Subject: [PATCH v2 3/7] drm/i915: Fix CHV CGM CSC coefficient sign handling
> >
> > From: Ville Syrjälä
> >
> > The CHV CGM CSC coefficients are in s4.12 two's complement format. Fix the
> > CTM-
> > >CGM conversion to ha
On Wed, May 24, 2023 at 03:59:47PM +0300, Lisovskiy, Stanislav wrote:
> On Wed, May 24, 2023 at 03:38:42PM +0300, Ville Syrjälä wrote:
> > On Tue, May 23, 2023 at 12:01:34PM +0300, Lisovskiy, Stanislav wrote:
> > > On Tue, May 16, 2023 at 02:40:27PM +0300, Ville Syrjälä wrote:
&
On Tue, May 23, 2023 at 12:01:34PM +0300, Lisovskiy, Stanislav wrote:
> On Tue, May 16, 2023 at 02:40:27PM +0300, Ville Syrjälä wrote:
> > On Tue, May 16, 2023 at 01:43:44PM +0300, Lisovskiy, Stanislav wrote:
> > > On Fri, May 12, 2023 at 11:54:16AM +0530, Ankit Nautiyal wrote:
gt; allowing it to be built without CONFIG_HAS_IOPORT.
>
> Link: https://lore.kernel.org/all/zbx5alo5h546b...@intel.com/
> Suggested-by: Ville Syrjälä
> Signed-off-by: Niklas Schnelle
Reviewed-by: Ville Syrjälä
> ---
> Note: The HAS_IOPORT Kconfig option was added in v6.4-rc1
> > pipe_config->lane_count,
> > -
> > adjusted_mode->crtc_clock,
> > -
> > adjusted_mode->crtc_hdisplay,
> > -
> > pipe_config->bigjoiner_pipes,
> > -
> > pipe_config->output_format,
> > -
> > pipe_config->pipe_bpp,
> > - timeslots);
> > - /*
> > -* According to DSC 1.2a Section 4.1.1 Table 4.1 the
> > maximum
> > -* supported PPS value can be 63.9375 and with the
> > further
> > -* mention that bpp should be programmed double the
> > target bpp
> > -* restricting our target bpp to be 31.9375 at max
> > -*/
> > - if (pipe_config->output_format ==
> > INTEL_OUTPUT_FORMAT_YCBCR420)
> > - dsc_max_compressed_bpp = min_t(u16,
> > -
> > dsc_max_compressed_bpp,
> > - 31);
> > -
> > - if (!dsc_max_compressed_bpp) {
> > - drm_dbg_kms(&dev_priv->drm,
> > - "Compressed BPP not supported\n");
> > - return -EINVAL;
> > - }
> > - }
> > dsc_dp_slice_count =
> > intel_dp_dsc_get_slice_count(intel_dp,
> > adjusted_mode->crtc_clock,
> > @@ -1759,20 +1958,6 @@ int intel_dp_dsc_compute_config(struct intel_dp
> > *intel_dp,
> > return -EINVAL;
> > }
> >
> > - /*
> > -* compute pipe bpp is set to false for DP MST DSC case
> > -* and compressed_bpp is calculated same time once
> > -* vpci timeslots are allocated, because overall bpp
> > -* calculation procedure is bit different for MST case.
> > -*/
> > - if (compute_pipe_bpp) {
> > - u16 output_bpp =
> > intel_dp_output_bpp(pipe_config->output_format,
> > -
> > pipe_config->pipe_bpp);
> > -
> > - pipe_config->dsc.compressed_bpp = min_t(u16,
> > -
> > dsc_max_compressed_bpp,
> > - output_bpp);
> > - }
> > pipe_config->dsc.slice_count = dsc_dp_slice_count;
> > }
> > /*
> > --
> > 2.25.1
> >
--
Ville Syrjälä
Intel
use only one VDSC engine, since
> - * each VDSC operates with 1 ppc throughput, pixel clock
> - * cannot be higher than the VDSC clock (cdclk)
> - */
> - if (crtc_state->dsc.compression_enable && !crtc_state->dsc.dsc_split)
> - min_cdclk = max(min_cdclk, (int)crtc_state->pixel_rate);
> + if (crtc_state->dsc.compression_enable)
> + min_cdclk = max(min_cdclk, intel_vdsc_min_cdclk(crtc_state));
>
> /*
>* HACK. Currently for TGL/DG2 platforms we calculate
> --
> 2.25.1
--
Ville Syrjälä
Intel
; if (bigjoiner) {
> + int bigjoiner_interface_bits = DISPLAY_VER(i915) > 13 ? 36 : 24;
'x >= 14' is the usual convention.
with that
Reviewed-by: Ville Syrjälä
> u32 max_bpp_bigjoiner =
> - i915->d
B output format only, so continue
> using RGB while computing compressed bpp for MST case.
>
> v2: Use output_bpp instead for pipe_bpp to clamp compressed_bpp. (Ville)
>
> Signed-off-by: Ankit Nautiyal
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/
if (dev->mode_config.poll_running)
> + drm_kms_helper_disable_hpd(dev);
> +
> + cancel_delayed_work_sync(&dev->mode_config.output_poll_work);
> +
> + dev->mode_config.poll_running = false;
> }
> EXPORT_SYMBOL(drm_kms_helper_poll_disable);
>
> @@ -900,7 +895,12 @@ EXPORT_SYMBOL(drm_kms_helper_poll_init);
> */
> void drm_kms_helper_poll_fini(struct drm_device *dev)
> {
> - drm_kms_helper_poll_disable_fini(dev, true);
> + if (!dev->mode_config.poll_enabled)
> + return;
> +
> + drm_kms_helper_poll_disable(dev);
> +
> + dev->mode_config.poll_enabled = false;
> }
> EXPORT_SYMBOL(drm_kms_helper_poll_fini);
>
> --
> 2.39.0
--
Ville Syrjälä
Intel
be const. The word "calculate" seems pretty much redundant.
> +{
> + return 2 << (dsc->bits_per_component - 8);
> +}
> +
> #endif /* _DRM_DSC_HELPER_H_ */
>
>
> --
> 2.40.1
--
Ville Syrjälä
Intel
On Wed, May 03, 2023 at 10:36:42AM +0300, Lisovskiy, Stanislav wrote:
> On Tue, May 02, 2023 at 05:38:57PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The MST DSC code has a myriad of issues:
> > - Platform checks are wrong (MST+DSC is TGL+ only I
On Fri, Apr 28, 2023 at 12:31:10AM +0200, Xaver Hugl wrote:
> I can't say anything about the other commits in this series, but
> "Document in which order the CTM matrix elements are stored" is
> Reviewed-by: Xaver Hugl
Thanks for the review+ack. Pushed to drm-misc-next.
--
Ville Syrjälä
Intel
a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -1336,6 +1336,8 @@ nv50_mstm_service(struct nouveau_drm *drm,
> if (!handled)
> break;
>
> + /* MSG_RDY ack is done in drm*/
> + esi[1] &= ~(DP_DOWN_REP_MSG_RDY | DP_UP_REQ_MSG_RDY);
> rc = drm_dp_dpcd_write(aux, DP_SINK_COUNT_ESI + 1, &esi[1],
> 3);
> if (rc != 3) {
> --
> 2.37.3
--
Ville Syrjälä
Intel
On Fri, Apr 14, 2023 at 02:53:55PM -0300, Maíra Canal wrote:
> On 4/14/23 11:46, Ville Syrjälä wrote:
> > On Fri, Apr 14, 2023 at 11:37:17AM -0300, Maíra Canal wrote:
> >> On 4/14/23 11:24, Ville Syrjälä wrote:
> >>> On Fri, Apr 14, 2023 at 10:51:50AM -0300, Maíra
On Fri, Apr 14, 2023 at 11:37:17AM -0300, Maíra Canal wrote:
> On 4/14/23 11:24, Ville Syrjälä wrote:
> > On Fri, Apr 14, 2023 at 10:51:50AM -0300, Maíra Canal wrote:
> >> Currently, vkms only support the reflect-x property. Therefore, add the
> >> reflect-y property
101 - 200 of 1403 matches
Mail list logo
