All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] drm: support hotspot for universal plane cursors
@ 2015-11-17 12:10 John Keeping
  2015-11-17 13:13   ` kbuild test robot
  2015-11-17 15:05   ` John Keeping
  0 siblings, 2 replies; 36+ messages in thread
From: John Keeping @ 2015-11-17 12:10 UTC (permalink / raw)
  To: David Airlie; +Cc: dri-devel, linux-kernel, John Keeping

The request's hot_x and hot_y are set correctly for both
DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just need to save
the values and then apply the offset to the cursor plane when the cursor
moves.

Signed-off-by: John Keeping <john@metanate.com>
---
 drivers/gpu/drm/drm_crtc.c | 11 +++++++----
 include/drm/drm_crtc.h     |  4 ++++
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 720a153..40f5b84 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2831,6 +2831,9 @@ static int drm_mode_cursor_universal(struct drm_crtc *crtc,
 				DRM_DEBUG_KMS("failed to wrap cursor buffer in drm framebuffer\n");
 				return PTR_ERR(fb);
 			}
+
+			crtc->hot_x = req->hot_x;
+			crtc->hot_y = req->hot_y;
 		} else {
 			fb = NULL;
 		}
@@ -2841,11 +2844,11 @@ static int drm_mode_cursor_universal(struct drm_crtc *crtc,
 	}
 
 	if (req->flags & DRM_MODE_CURSOR_MOVE) {
-		crtc_x = req->x;
-		crtc_y = req->y;
+		crtc_x = req->x - crtc->hot_x;
+		crtc_y = req->y - crtc->hot_y;
 	} else {
-		crtc_x = crtc->cursor_x;
-		crtc_y = crtc->cursor_y;
+		crtc_x = crtc->cursor_x - crtc->hot_x;
+		crtc_y = crtc->cursor_y - crtc->hot_y;
 	}
 
 	if (fb) {
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 3f0c690..1420145 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -445,6 +445,10 @@ struct drm_crtc {
 	int cursor_x;
 	int cursor_y;
 
+	/* hotspot of cursor */
+	int hot_x;
+	int hot_y;
+
 	bool enabled;
 
 	/* Requested mode from modesetting. */
-- 
2.6.2.400.gcb098da


^ permalink raw reply related	[flat|nested] 36+ messages in thread

* Re: [PATCH] drm: support hotspot for universal plane cursors
  2015-11-17 12:10 [PATCH] drm: support hotspot for universal plane cursors John Keeping
@ 2015-11-17 13:13   ` kbuild test robot
  2015-11-17 15:05   ` John Keeping
  1 sibling, 0 replies; 36+ messages in thread
From: kbuild test robot @ 2015-11-17 13:13 UTC (permalink / raw)
  To: John Keeping
  Cc: kbuild-all, David Airlie, dri-devel, linux-kernel, John Keeping

[-- Attachment #1: Type: text/plain, Size: 25073 bytes --]

Hi John,

[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.4-rc1 next-20151117]

url:    https://github.com/0day-ci/linux/commits/John-Keeping/drm-support-hotspot-for-universal-plane-cursors/20151117-203428
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/i915/i915_irq.c:2584: warning: No description found for parameter 'wedged'
   drivers/gpu/drm/i915/i915_irq.c:2584: warning: No description found for parameter 'fmt'
   include/drm/drm_crtc.h:310: warning: No description found for parameter 'mode_blob'
>> include/drm/drm_crtc.h:481: warning: No description found for parameter 'hot_x'
>> include/drm/drm_crtc.h:481: warning: No description found for parameter 'hot_y'
   include/drm/drm_crtc.h:741: warning: No description found for parameter 'tile_blob_ptr'
   include/drm/drm_crtc.h:780: warning: No description found for parameter 'rotation'
   include/drm/drm_crtc.h:876: warning: No description found for parameter 'mutex'
   include/drm/drm_crtc.h:876: warning: No description found for parameter 'helper_private'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tile_idr'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'delayed_event'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'edid_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'dpms_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'path_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tile_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'plane_type_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'rotation_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'prop_src_x'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'prop_src_y'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'prop_src_w'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'prop_src_h'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'prop_crtc_x'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'prop_crtc_y'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'prop_crtc_w'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'prop_crtc_h'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'prop_fb_id'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'prop_crtc_id'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'prop_active'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'prop_mode_id'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'dvi_i_subconnector_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'dvi_i_select_subconnector_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tv_subconnector_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tv_select_subconnector_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tv_mode_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tv_left_margin_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tv_right_margin_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tv_top_margin_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tv_bottom_margin_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tv_brightness_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tv_contrast_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tv_flicker_reduction_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tv_overscan_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tv_saturation_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tv_hue_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'scaling_mode_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'aspect_ratio_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'dirty_info_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'suggested_x_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'suggested_y_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'allow_fb_modifiers'
   include/drm/drm_fb_helper.h:148: warning: No description found for parameter 'connector_info'
   include/drm/drm_dp_helper.h:713: warning: No description found for parameter 'i2c_nack_count'
   include/drm/drm_dp_helper.h:713: warning: No description found for parameter 'i2c_defer_count'
   drivers/gpu/drm/drm_dp_mst_topology.c:2227: warning: No description found for parameter 'connector'
   include/drm/drm_dp_mst_helper.h:97: warning: No description found for parameter 'cached_edid'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'max_dpcd_transaction_bytes'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'sink_count'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'total_slots'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'avail_slots'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'total_pbn'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'qlock'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'tx_msg_downq'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'tx_msg_upq'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'tx_down_in_progress'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'tx_up_in_progress'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'payload_lock'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'proposed_vcpis'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'payloads'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'payload_mask'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'vcpi_mask'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'tx_waitq'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'work'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'tx_work'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'destroy_connector_list'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'destroy_connector_lock'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'destroy_connector_work'
   drivers/gpu/drm/drm_dp_mst_topology.c:2227: warning: No description found for parameter 'connector'
   drivers/gpu/drm/drm_irq.c:173: warning: No description found for parameter 'flags'
   include/drm/drmP.h:168: warning: No description found for parameter 'fmt'
   include/drm/drmP.h:184: warning: No description found for parameter 'fmt'
   include/drm/drmP.h:202: warning: No description found for parameter 'fmt'
   include/drm/drmP.h:247: warning: No description found for parameter 'dev'
   include/drm/drmP.h:247: warning: No description found for parameter 'data'
   include/drm/drmP.h:247: warning: No description found for parameter 'file_priv'
   include/drm/drmP.h:280: warning: No description found for parameter 'ioctl'
   include/drm/drmP.h:280: warning: No description found for parameter '_func'
   include/drm/drmP.h:280: warning: No description found for parameter '_flags'
   include/drm/drmP.h:353: warning: cannot understand function prototype: 'struct drm_lock_data '
   include/drm/drmP.h:406: warning: cannot understand function prototype: 'struct drm_driver '
   include/drm/drmP.h:656: warning: cannot understand function prototype: 'struct drm_info_list '
   include/drm/drmP.h:666: warning: cannot understand function prototype: 'struct drm_info_node '
   include/drm/drmP.h:676: warning: cannot understand function prototype: 'struct drm_minor '
   include/drm/drmP.h:724: warning: cannot understand function prototype: 'struct drm_device '
   drivers/gpu/drm/i915/i915_irq.c:2584: warning: No description found for parameter 'wedged'
   drivers/gpu/drm/i915/i915_irq.c:2584: warning: No description found for parameter 'fmt'
   drivers/gpu/drm/i915/i915_irq.c:2584: warning: No description found for parameter 'wedged'
   drivers/gpu/drm/i915/i915_irq.c:2584: warning: No description found for parameter 'fmt'
   drivers/gpu/drm/i915/i915_irq.c:2584: warning: No description found for parameter 'wedged'
   drivers/gpu/drm/i915/i915_irq.c:2584: warning: No description found for parameter 'fmt'
   drivers/gpu/drm/i915/i915_irq.c:2584: warning: No description found for parameter 'wedged'
   drivers/gpu/drm/i915/i915_irq.c:2584: warning: No description found for parameter 'fmt'
   drivers/gpu/drm/i915/i915_gem.c:421: warning: No description found for parameter 'dev'
   drivers/gpu/drm/i915/i915_gem.c:421: warning: No description found for parameter 'data'
   drivers/gpu/drm/i915/i915_gem.c:421: warning: No description found for parameter 'file'
   drivers/gpu/drm/i915/i915_gem.c:686: warning: No description found for parameter 'dev'

vim +/hot_x +481 include/drm/drm_crtc.h

99cf4a29f Daniel Stone       2015-05-25  304  	/* blob property to expose current mode to atomic userspace */
99cf4a29f Daniel Stone       2015-05-25  305  	struct drm_property_blob *mode_blob;
99cf4a29f Daniel Stone       2015-05-25  306  
144ecb97c Daniel Vetter      2014-10-27  307  	struct drm_pending_vblank_event *event;
144ecb97c Daniel Vetter      2014-10-27  308  
144ecb97c Daniel Vetter      2014-10-27  309  	struct drm_atomic_state *state;
144ecb97c Daniel Vetter      2014-10-27 @310  };
f453ba046 Dave Airlie        2008-11-07  311  
f453ba046 Dave Airlie        2008-11-07  312  /**
3bf0401cd Daniel Vetter      2014-10-27  313   * struct drm_crtc_funcs - control CRTCs for a given device
f453ba046 Dave Airlie        2008-11-07  314   * @save: save CRTC state
3b02ab889 Laurent Pinchart   2012-05-17  315   * @restore: restore CRTC state
715f59cc2 Christopher Harvey 2013-04-05  316   * @reset: reset CRTC after state has been invalidated (e.g. resume)
3b02ab889 Laurent Pinchart   2012-05-17  317   * @cursor_set: setup the cursor
2c0c33d41 Daniel Vetter      2014-10-27  318   * @cursor_set2: setup the cursor with hotspot, superseeds @cursor_set if set
3b02ab889 Laurent Pinchart   2012-05-17  319   * @cursor_move: move the cursor
f453ba046 Dave Airlie        2008-11-07  320   * @gamma_set: specify color ramp for CRTC
bffd9de02 Paulo Zanoni       2012-05-15  321   * @destroy: deinit and free object
bffd9de02 Paulo Zanoni       2012-05-15  322   * @set_property: called when a property is changed
3b02ab889 Laurent Pinchart   2012-05-17  323   * @set_config: apply a new CRTC configuration
3b02ab889 Laurent Pinchart   2012-05-17  324   * @page_flip: initiate a page flip
144ecb97c Daniel Vetter      2014-10-27  325   * @atomic_duplicate_state: duplicate the atomic state for this CRTC
144ecb97c Daniel Vetter      2014-10-27  326   * @atomic_destroy_state: destroy an atomic state for this CRTC
144ecb97c Daniel Vetter      2014-10-27  327   * @atomic_set_property: set a property on an atomic state for this CRTC
40ecc694e Rob Clark          2014-12-18  328   *    (do not call directly, use drm_atomic_crtc_set_property())
ac9c92561 Rob Clark          2014-12-18  329   * @atomic_get_property: get a property on an atomic state for this CRTC
ac9c92561 Rob Clark          2014-12-18  330   *    (do not call directly, use drm_atomic_crtc_get_property())
f453ba046 Dave Airlie        2008-11-07  331   *
f453ba046 Dave Airlie        2008-11-07  332   * The drm_crtc_funcs structure is the central CRTC management structure
f453ba046 Dave Airlie        2008-11-07  333   * in the DRM.  Each CRTC controls one or more connectors (note that the name
f453ba046 Dave Airlie        2008-11-07  334   * CRTC is simply historical, a CRTC may control LVDS, VGA, DVI, TV out, etc.
f453ba046 Dave Airlie        2008-11-07  335   * connectors, not just CRTs).
f453ba046 Dave Airlie        2008-11-07  336   *
f453ba046 Dave Airlie        2008-11-07  337   * Each driver is responsible for filling out this structure at startup time,
f453ba046 Dave Airlie        2008-11-07  338   * in addition to providing other modesetting features, like i2c and DDC
f453ba046 Dave Airlie        2008-11-07  339   * bus accessors.
f453ba046 Dave Airlie        2008-11-07  340   */
f453ba046 Dave Airlie        2008-11-07  341  struct drm_crtc_funcs {
f453ba046 Dave Airlie        2008-11-07  342  	/* Save CRTC state */
f453ba046 Dave Airlie        2008-11-07  343  	void (*save)(struct drm_crtc *crtc); /* suspend? */
f453ba046 Dave Airlie        2008-11-07  344  	/* Restore CRTC state */
f453ba046 Dave Airlie        2008-11-07  345  	void (*restore)(struct drm_crtc *crtc); /* resume? */
eb0335566 Chris Wilson       2011-01-24  346  	/* Reset CRTC state */
eb0335566 Chris Wilson       2011-01-24  347  	void (*reset)(struct drm_crtc *crtc);
f453ba046 Dave Airlie        2008-11-07  348  
f453ba046 Dave Airlie        2008-11-07  349  	/* cursor controls */
f453ba046 Dave Airlie        2008-11-07  350  	int (*cursor_set)(struct drm_crtc *crtc, struct drm_file *file_priv,
f453ba046 Dave Airlie        2008-11-07  351  			  uint32_t handle, uint32_t width, uint32_t height);
4c813d4d7 Dave Airlie        2013-06-20  352  	int (*cursor_set2)(struct drm_crtc *crtc, struct drm_file *file_priv,
4c813d4d7 Dave Airlie        2013-06-20  353  			   uint32_t handle, uint32_t width, uint32_t height,
4c813d4d7 Dave Airlie        2013-06-20  354  			   int32_t hot_x, int32_t hot_y);
f453ba046 Dave Airlie        2008-11-07  355  	int (*cursor_move)(struct drm_crtc *crtc, int x, int y);
f453ba046 Dave Airlie        2008-11-07  356  
f453ba046 Dave Airlie        2008-11-07  357  	/* Set gamma on the CRTC */
f453ba046 Dave Airlie        2008-11-07  358  	void (*gamma_set)(struct drm_crtc *crtc, u16 *r, u16 *g, u16 *b,
7203425a9 James Simmons      2010-08-03  359  			  uint32_t start, uint32_t size);
f453ba046 Dave Airlie        2008-11-07  360  	/* Object destroy routine */
f453ba046 Dave Airlie        2008-11-07  361  	void (*destroy)(struct drm_crtc *crtc);
f453ba046 Dave Airlie        2008-11-07  362  
f453ba046 Dave Airlie        2008-11-07  363  	int (*set_config)(struct drm_mode_set *set);
d91d8a3f8 Kristian Høgsberg  2009-11-17  364  
d91d8a3f8 Kristian Høgsberg  2009-11-17  365  	/*
d91d8a3f8 Kristian Høgsberg  2009-11-17  366  	 * Flip to the given framebuffer.  This implements the page
25985edce Lucas De Marchi    2011-03-30  367  	 * flip ioctl described in drm_mode.h, specifically, the
d91d8a3f8 Kristian Høgsberg  2009-11-17  368  	 * implementation must return immediately and block all
d91d8a3f8 Kristian Høgsberg  2009-11-17  369  	 * rendering to the current fb until the flip has completed.
d91d8a3f8 Kristian Høgsberg  2009-11-17  370  	 * If userspace set the event flag in the ioctl, the event
d91d8a3f8 Kristian Høgsberg  2009-11-17  371  	 * argument will point to an event to send back when the flip
d91d8a3f8 Kristian Høgsberg  2009-11-17  372  	 * completes, otherwise it will be NULL.
d91d8a3f8 Kristian Høgsberg  2009-11-17  373  	 */
d91d8a3f8 Kristian Høgsberg  2009-11-17  374  	int (*page_flip)(struct drm_crtc *crtc,
d91d8a3f8 Kristian Høgsberg  2009-11-17  375  			 struct drm_framebuffer *fb,
ed8d19756 Keith Packard      2013-07-22  376  			 struct drm_pending_vblank_event *event,
ed8d19756 Keith Packard      2013-07-22  377  			 uint32_t flags);
bffd9de02 Paulo Zanoni       2012-05-15  378  
bffd9de02 Paulo Zanoni       2012-05-15  379  	int (*set_property)(struct drm_crtc *crtc,
bffd9de02 Paulo Zanoni       2012-05-15  380  			    struct drm_property *property, uint64_t val);
144ecb97c Daniel Vetter      2014-10-27  381  
144ecb97c Daniel Vetter      2014-10-27  382  	/* atomic update handling */
144ecb97c Daniel Vetter      2014-10-27  383  	struct drm_crtc_state *(*atomic_duplicate_state)(struct drm_crtc *crtc);
144ecb97c Daniel Vetter      2014-10-27  384  	void (*atomic_destroy_state)(struct drm_crtc *crtc,
cc4ceb484 Daniel Vetter      2014-07-25  385  				     struct drm_crtc_state *state);
144ecb97c Daniel Vetter      2014-10-27  386  	int (*atomic_set_property)(struct drm_crtc *crtc,
144ecb97c Daniel Vetter      2014-10-27  387  				   struct drm_crtc_state *state,
144ecb97c Daniel Vetter      2014-10-27  388  				   struct drm_property *property,
144ecb97c Daniel Vetter      2014-10-27  389  				   uint64_t val);
ac9c92561 Rob Clark          2014-12-18  390  	int (*atomic_get_property)(struct drm_crtc *crtc,
ac9c92561 Rob Clark          2014-12-18  391  				   const struct drm_crtc_state *state,
ac9c92561 Rob Clark          2014-12-18  392  				   struct drm_property *property,
ac9c92561 Rob Clark          2014-12-18  393  				   uint64_t *val);
f453ba046 Dave Airlie        2008-11-07  394  };
f453ba046 Dave Airlie        2008-11-07  395  
f453ba046 Dave Airlie        2008-11-07  396  /**
3bf0401cd Daniel Vetter      2014-10-27  397   * struct drm_crtc - central CRTC control structure
7749163ef Jesse Barnes       2011-11-07  398   * @dev: parent DRM device
2c0c33d41 Daniel Vetter      2014-10-27  399   * @port: OF node used by drm_of_find_possible_crtcs()
7749163ef Jesse Barnes       2011-11-07  400   * @head: list management
51fd371bb Rob Clark          2013-11-19  401   * @mutex: per-CRTC locking
7749163ef Jesse Barnes       2011-11-07  402   * @base: base KMS object for ID tracking etc.
e13161af8 Matt Roper         2014-04-01  403   * @primary: primary plane for this CRTC
e13161af8 Matt Roper         2014-04-01  404   * @cursor: cursor plane for this CRTC
2c0c33d41 Daniel Vetter      2014-10-27  405   * @cursor_x: current x position of the cursor, used for universal cursor planes
2c0c33d41 Daniel Vetter      2014-10-27  406   * @cursor_y: current y position of the cursor, used for universal cursor planes
f453ba046 Dave Airlie        2008-11-07  407   * @enabled: is this CRTC enabled?
7749163ef Jesse Barnes       2011-11-07  408   * @mode: current mode timings
7749163ef Jesse Barnes       2011-11-07  409   * @hwmode: mode timings as programmed to hw regs
f453ba046 Dave Airlie        2008-11-07  410   * @x: x position on screen
f453ba046 Dave Airlie        2008-11-07  411   * @y: y position on screen
f453ba046 Dave Airlie        2008-11-07  412   * @funcs: CRTC control functions
7749163ef Jesse Barnes       2011-11-07  413   * @gamma_size: size of gamma ramp
7749163ef Jesse Barnes       2011-11-07  414   * @gamma_store: gamma ramp values
7749163ef Jesse Barnes       2011-11-07  415   * @helper_private: mid-layer private data
bffd9de02 Paulo Zanoni       2012-05-15  416   * @properties: property tracking for this CRTC
144ecb97c Daniel Vetter      2014-10-27  417   * @state: current atomic state for this CRTC
2c0c33d41 Daniel Vetter      2014-10-27  418   * @acquire_ctx: per-CRTC implicit acquire context used by atomic drivers for
2c0c33d41 Daniel Vetter      2014-10-27  419   * 	legacy ioctls
f453ba046 Dave Airlie        2008-11-07  420   *
f453ba046 Dave Airlie        2008-11-07  421   * Each CRTC may have one or more connectors associated with it.  This structure
f453ba046 Dave Airlie        2008-11-07  422   * allows the CRTC to be controlled.
f453ba046 Dave Airlie        2008-11-07  423   */
f453ba046 Dave Airlie        2008-11-07  424  struct drm_crtc {
f453ba046 Dave Airlie        2008-11-07  425  	struct drm_device *dev;
7e435aad3 Russell King       2014-06-15  426  	struct device_node *port;
f453ba046 Dave Airlie        2008-11-07  427  	struct list_head head;
f453ba046 Dave Airlie        2008-11-07  428  
3bf0401cd Daniel Vetter      2014-10-27  429  	/*
29494c174 Daniel Vetter      2012-12-02  430  	 * crtc mutex
29494c174 Daniel Vetter      2012-12-02  431  	 *
29494c174 Daniel Vetter      2012-12-02  432  	 * This provides a read lock for the overall crtc state (mode, dpms
29494c174 Daniel Vetter      2012-12-02  433  	 * state, ...) and a write lock for everything which can be update
29494c174 Daniel Vetter      2012-12-02  434  	 * without a full modeset (fb, cursor data, ...)
29494c174 Daniel Vetter      2012-12-02  435  	 */
51fd371bb Rob Clark          2013-11-19  436  	struct drm_modeset_lock mutex;
29494c174 Daniel Vetter      2012-12-02  437  
f453ba046 Dave Airlie        2008-11-07  438  	struct drm_mode_object base;
f453ba046 Dave Airlie        2008-11-07  439  
e13161af8 Matt Roper         2014-04-01  440  	/* primary and cursor planes for CRTC */
e13161af8 Matt Roper         2014-04-01  441  	struct drm_plane *primary;
e13161af8 Matt Roper         2014-04-01  442  	struct drm_plane *cursor;
e13161af8 Matt Roper         2014-04-01  443  
161d0dc1d Matt Roper         2014-06-10  444  	/* position of cursor plane on crtc */
161d0dc1d Matt Roper         2014-06-10  445  	int cursor_x;
161d0dc1d Matt Roper         2014-06-10  446  	int cursor_y;
161d0dc1d Matt Roper         2014-06-10  447  
14ecd586d John Keeping       2015-11-17  448  	/* hotspot of cursor */
14ecd586d John Keeping       2015-11-17  449  	int hot_x;
14ecd586d John Keeping       2015-11-17  450  	int hot_y;
14ecd586d John Keeping       2015-11-17  451  
f453ba046 Dave Airlie        2008-11-07  452  	bool enabled;
f453ba046 Dave Airlie        2008-11-07  453  
27641c3f0 Mario Kleiner      2010-10-23  454  	/* Requested mode from modesetting. */
f453ba046 Dave Airlie        2008-11-07  455  	struct drm_display_mode mode;
f453ba046 Dave Airlie        2008-11-07  456  
27641c3f0 Mario Kleiner      2010-10-23  457  	/* Programmed mode in hw, after adjustments for encoders,
27641c3f0 Mario Kleiner      2010-10-23  458  	 * crtc, panel scaling etc. Needed for timestamping etc.
27641c3f0 Mario Kleiner      2010-10-23  459  	 */
27641c3f0 Mario Kleiner      2010-10-23  460  	struct drm_display_mode hwmode;
27641c3f0 Mario Kleiner      2010-10-23  461  
f453ba046 Dave Airlie        2008-11-07  462  	int x, y;
f453ba046 Dave Airlie        2008-11-07  463  	const struct drm_crtc_funcs *funcs;
f453ba046 Dave Airlie        2008-11-07  464  
f453ba046 Dave Airlie        2008-11-07  465  	/* CRTC gamma size for reporting to userspace */
f453ba046 Dave Airlie        2008-11-07  466  	uint32_t gamma_size;
f453ba046 Dave Airlie        2008-11-07  467  	uint16_t *gamma_store;
f453ba046 Dave Airlie        2008-11-07  468  
f453ba046 Dave Airlie        2008-11-07  469  	/* if you are using the helper */
9a436ee6c Jani Nikula        2015-04-13  470  	const void *helper_private;
bffd9de02 Paulo Zanoni       2012-05-15  471  
bffd9de02 Paulo Zanoni       2012-05-15  472  	struct drm_object_properties properties;
d059f652e Daniel Vetter      2014-07-25  473  
144ecb97c Daniel Vetter      2014-10-27  474  	struct drm_crtc_state *state;
144ecb97c Daniel Vetter      2014-10-27  475  
d059f652e Daniel Vetter      2014-07-25  476  	/*
d059f652e Daniel Vetter      2014-07-25  477  	 * For legacy crtc ioctls so that atomic drivers can get at the locking
d059f652e Daniel Vetter      2014-07-25  478  	 * acquire context.
d059f652e Daniel Vetter      2014-07-25  479  	 */
d059f652e Daniel Vetter      2014-07-25  480  	struct drm_modeset_acquire_ctx *acquire_ctx;
f453ba046 Dave Airlie        2008-11-07 @481  };
f453ba046 Dave Airlie        2008-11-07  482  
144ecb97c Daniel Vetter      2014-10-27  483  /**
144ecb97c Daniel Vetter      2014-10-27  484   * struct drm_connector_state - mutable connector state

:::::: The code at line 481 was first introduced by commit
:::::: f453ba0460742ad027ae0c4c7d61e62817b3e7ef DRM: add mode setting support

:::::: TO: Dave Airlie <airlied@redhat.com>
:::::: CC: Dave Airlie <airlied@linux.ie>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 6122 bytes --]

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH] drm: support hotspot for universal plane cursors
@ 2015-11-17 13:13   ` kbuild test robot
  0 siblings, 0 replies; 36+ messages in thread
From: kbuild test robot @ 2015-11-17 13:13 UTC (permalink / raw)
  Cc: John Keeping, kbuild-all, dri-devel, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 25383 bytes --]

Hi John,

[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.4-rc1 next-20151117]

url:    https://github.com/0day-ci/linux/commits/John-Keeping/drm-support-hotspot-for-universal-plane-cursors/20151117-203428
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/i915/i915_irq.c:2584: warning: No description found for parameter 'wedged'
   drivers/gpu/drm/i915/i915_irq.c:2584: warning: No description found for parameter 'fmt'
   include/drm/drm_crtc.h:310: warning: No description found for parameter 'mode_blob'
>> include/drm/drm_crtc.h:481: warning: No description found for parameter 'hot_x'
>> include/drm/drm_crtc.h:481: warning: No description found for parameter 'hot_y'
   include/drm/drm_crtc.h:741: warning: No description found for parameter 'tile_blob_ptr'
   include/drm/drm_crtc.h:780: warning: No description found for parameter 'rotation'
   include/drm/drm_crtc.h:876: warning: No description found for parameter 'mutex'
   include/drm/drm_crtc.h:876: warning: No description found for parameter 'helper_private'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tile_idr'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'delayed_event'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'edid_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'dpms_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'path_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tile_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'plane_type_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'rotation_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'prop_src_x'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'prop_src_y'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'prop_src_w'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'prop_src_h'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'prop_crtc_x'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'prop_crtc_y'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'prop_crtc_w'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'prop_crtc_h'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'prop_fb_id'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'prop_crtc_id'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'prop_active'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'prop_mode_id'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'dvi_i_subconnector_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'dvi_i_select_subconnector_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tv_subconnector_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tv_select_subconnector_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tv_mode_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tv_left_margin_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tv_right_margin_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tv_top_margin_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tv_bottom_margin_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tv_brightness_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tv_contrast_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tv_flicker_reduction_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tv_overscan_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tv_saturation_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'tv_hue_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'scaling_mode_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'aspect_ratio_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'dirty_info_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'suggested_x_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'suggested_y_property'
   include/drm/drm_crtc.h:1161: warning: No description found for parameter 'allow_fb_modifiers'
   include/drm/drm_fb_helper.h:148: warning: No description found for parameter 'connector_info'
   include/drm/drm_dp_helper.h:713: warning: No description found for parameter 'i2c_nack_count'
   include/drm/drm_dp_helper.h:713: warning: No description found for parameter 'i2c_defer_count'
   drivers/gpu/drm/drm_dp_mst_topology.c:2227: warning: No description found for parameter 'connector'
   include/drm/drm_dp_mst_helper.h:97: warning: No description found for parameter 'cached_edid'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'max_dpcd_transaction_bytes'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'sink_count'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'total_slots'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'avail_slots'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'total_pbn'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'qlock'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'tx_msg_downq'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'tx_msg_upq'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'tx_down_in_progress'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'tx_up_in_progress'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'payload_lock'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'proposed_vcpis'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'payloads'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'payload_mask'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'vcpi_mask'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'tx_waitq'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'work'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'tx_work'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'destroy_connector_list'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'destroy_connector_lock'
   include/drm/drm_dp_mst_helper.h:472: warning: No description found for parameter 'destroy_connector_work'
   drivers/gpu/drm/drm_dp_mst_topology.c:2227: warning: No description found for parameter 'connector'
   drivers/gpu/drm/drm_irq.c:173: warning: No description found for parameter 'flags'
   include/drm/drmP.h:168: warning: No description found for parameter 'fmt'
   include/drm/drmP.h:184: warning: No description found for parameter 'fmt'
   include/drm/drmP.h:202: warning: No description found for parameter 'fmt'
   include/drm/drmP.h:247: warning: No description found for parameter 'dev'
   include/drm/drmP.h:247: warning: No description found for parameter 'data'
   include/drm/drmP.h:247: warning: No description found for parameter 'file_priv'
   include/drm/drmP.h:280: warning: No description found for parameter 'ioctl'
   include/drm/drmP.h:280: warning: No description found for parameter '_func'
   include/drm/drmP.h:280: warning: No description found for parameter '_flags'
   include/drm/drmP.h:353: warning: cannot understand function prototype: 'struct drm_lock_data '
   include/drm/drmP.h:406: warning: cannot understand function prototype: 'struct drm_driver '
   include/drm/drmP.h:656: warning: cannot understand function prototype: 'struct drm_info_list '
   include/drm/drmP.h:666: warning: cannot understand function prototype: 'struct drm_info_node '
   include/drm/drmP.h:676: warning: cannot understand function prototype: 'struct drm_minor '
   include/drm/drmP.h:724: warning: cannot understand function prototype: 'struct drm_device '
   drivers/gpu/drm/i915/i915_irq.c:2584: warning: No description found for parameter 'wedged'
   drivers/gpu/drm/i915/i915_irq.c:2584: warning: No description found for parameter 'fmt'
   drivers/gpu/drm/i915/i915_irq.c:2584: warning: No description found for parameter 'wedged'
   drivers/gpu/drm/i915/i915_irq.c:2584: warning: No description found for parameter 'fmt'
   drivers/gpu/drm/i915/i915_irq.c:2584: warning: No description found for parameter 'wedged'
   drivers/gpu/drm/i915/i915_irq.c:2584: warning: No description found for parameter 'fmt'
   drivers/gpu/drm/i915/i915_irq.c:2584: warning: No description found for parameter 'wedged'
   drivers/gpu/drm/i915/i915_irq.c:2584: warning: No description found for parameter 'fmt'
   drivers/gpu/drm/i915/i915_gem.c:421: warning: No description found for parameter 'dev'
   drivers/gpu/drm/i915/i915_gem.c:421: warning: No description found for parameter 'data'
   drivers/gpu/drm/i915/i915_gem.c:421: warning: No description found for parameter 'file'
   drivers/gpu/drm/i915/i915_gem.c:686: warning: No description found for parameter 'dev'

vim +/hot_x +481 include/drm/drm_crtc.h

99cf4a29f Daniel Stone       2015-05-25  304  	/* blob property to expose current mode to atomic userspace */
99cf4a29f Daniel Stone       2015-05-25  305  	struct drm_property_blob *mode_blob;
99cf4a29f Daniel Stone       2015-05-25  306  
144ecb97c Daniel Vetter      2014-10-27  307  	struct drm_pending_vblank_event *event;
144ecb97c Daniel Vetter      2014-10-27  308  
144ecb97c Daniel Vetter      2014-10-27  309  	struct drm_atomic_state *state;
144ecb97c Daniel Vetter      2014-10-27 @310  };
f453ba046 Dave Airlie        2008-11-07  311  
f453ba046 Dave Airlie        2008-11-07  312  /**
3bf0401cd Daniel Vetter      2014-10-27  313   * struct drm_crtc_funcs - control CRTCs for a given device
f453ba046 Dave Airlie        2008-11-07  314   * @save: save CRTC state
3b02ab889 Laurent Pinchart   2012-05-17  315   * @restore: restore CRTC state
715f59cc2 Christopher Harvey 2013-04-05  316   * @reset: reset CRTC after state has been invalidated (e.g. resume)
3b02ab889 Laurent Pinchart   2012-05-17  317   * @cursor_set: setup the cursor
2c0c33d41 Daniel Vetter      2014-10-27  318   * @cursor_set2: setup the cursor with hotspot, superseeds @cursor_set if set
3b02ab889 Laurent Pinchart   2012-05-17  319   * @cursor_move: move the cursor
f453ba046 Dave Airlie        2008-11-07  320   * @gamma_set: specify color ramp for CRTC
bffd9de02 Paulo Zanoni       2012-05-15  321   * @destroy: deinit and free object
bffd9de02 Paulo Zanoni       2012-05-15  322   * @set_property: called when a property is changed
3b02ab889 Laurent Pinchart   2012-05-17  323   * @set_config: apply a new CRTC configuration
3b02ab889 Laurent Pinchart   2012-05-17  324   * @page_flip: initiate a page flip
144ecb97c Daniel Vetter      2014-10-27  325   * @atomic_duplicate_state: duplicate the atomic state for this CRTC
144ecb97c Daniel Vetter      2014-10-27  326   * @atomic_destroy_state: destroy an atomic state for this CRTC
144ecb97c Daniel Vetter      2014-10-27  327   * @atomic_set_property: set a property on an atomic state for this CRTC
40ecc694e Rob Clark          2014-12-18  328   *    (do not call directly, use drm_atomic_crtc_set_property())
ac9c92561 Rob Clark          2014-12-18  329   * @atomic_get_property: get a property on an atomic state for this CRTC
ac9c92561 Rob Clark          2014-12-18  330   *    (do not call directly, use drm_atomic_crtc_get_property())
f453ba046 Dave Airlie        2008-11-07  331   *
f453ba046 Dave Airlie        2008-11-07  332   * The drm_crtc_funcs structure is the central CRTC management structure
f453ba046 Dave Airlie        2008-11-07  333   * in the DRM.  Each CRTC controls one or more connectors (note that the name
f453ba046 Dave Airlie        2008-11-07  334   * CRTC is simply historical, a CRTC may control LVDS, VGA, DVI, TV out, etc.
f453ba046 Dave Airlie        2008-11-07  335   * connectors, not just CRTs).
f453ba046 Dave Airlie        2008-11-07  336   *
f453ba046 Dave Airlie        2008-11-07  337   * Each driver is responsible for filling out this structure at startup time,
f453ba046 Dave Airlie        2008-11-07  338   * in addition to providing other modesetting features, like i2c and DDC
f453ba046 Dave Airlie        2008-11-07  339   * bus accessors.
f453ba046 Dave Airlie        2008-11-07  340   */
f453ba046 Dave Airlie        2008-11-07  341  struct drm_crtc_funcs {
f453ba046 Dave Airlie        2008-11-07  342  	/* Save CRTC state */
f453ba046 Dave Airlie        2008-11-07  343  	void (*save)(struct drm_crtc *crtc); /* suspend? */
f453ba046 Dave Airlie        2008-11-07  344  	/* Restore CRTC state */
f453ba046 Dave Airlie        2008-11-07  345  	void (*restore)(struct drm_crtc *crtc); /* resume? */
eb0335566 Chris Wilson       2011-01-24  346  	/* Reset CRTC state */
eb0335566 Chris Wilson       2011-01-24  347  	void (*reset)(struct drm_crtc *crtc);
f453ba046 Dave Airlie        2008-11-07  348  
f453ba046 Dave Airlie        2008-11-07  349  	/* cursor controls */
f453ba046 Dave Airlie        2008-11-07  350  	int (*cursor_set)(struct drm_crtc *crtc, struct drm_file *file_priv,
f453ba046 Dave Airlie        2008-11-07  351  			  uint32_t handle, uint32_t width, uint32_t height);
4c813d4d7 Dave Airlie        2013-06-20  352  	int (*cursor_set2)(struct drm_crtc *crtc, struct drm_file *file_priv,
4c813d4d7 Dave Airlie        2013-06-20  353  			   uint32_t handle, uint32_t width, uint32_t height,
4c813d4d7 Dave Airlie        2013-06-20  354  			   int32_t hot_x, int32_t hot_y);
f453ba046 Dave Airlie        2008-11-07  355  	int (*cursor_move)(struct drm_crtc *crtc, int x, int y);
f453ba046 Dave Airlie        2008-11-07  356  
f453ba046 Dave Airlie        2008-11-07  357  	/* Set gamma on the CRTC */
f453ba046 Dave Airlie        2008-11-07  358  	void (*gamma_set)(struct drm_crtc *crtc, u16 *r, u16 *g, u16 *b,
7203425a9 James Simmons      2010-08-03  359  			  uint32_t start, uint32_t size);
f453ba046 Dave Airlie        2008-11-07  360  	/* Object destroy routine */
f453ba046 Dave Airlie        2008-11-07  361  	void (*destroy)(struct drm_crtc *crtc);
f453ba046 Dave Airlie        2008-11-07  362  
f453ba046 Dave Airlie        2008-11-07  363  	int (*set_config)(struct drm_mode_set *set);
d91d8a3f8 Kristian Høgsberg  2009-11-17  364  
d91d8a3f8 Kristian Høgsberg  2009-11-17  365  	/*
d91d8a3f8 Kristian Høgsberg  2009-11-17  366  	 * Flip to the given framebuffer.  This implements the page
25985edce Lucas De Marchi    2011-03-30  367  	 * flip ioctl described in drm_mode.h, specifically, the
d91d8a3f8 Kristian Høgsberg  2009-11-17  368  	 * implementation must return immediately and block all
d91d8a3f8 Kristian Høgsberg  2009-11-17  369  	 * rendering to the current fb until the flip has completed.
d91d8a3f8 Kristian Høgsberg  2009-11-17  370  	 * If userspace set the event flag in the ioctl, the event
d91d8a3f8 Kristian Høgsberg  2009-11-17  371  	 * argument will point to an event to send back when the flip
d91d8a3f8 Kristian Høgsberg  2009-11-17  372  	 * completes, otherwise it will be NULL.
d91d8a3f8 Kristian Høgsberg  2009-11-17  373  	 */
d91d8a3f8 Kristian Høgsberg  2009-11-17  374  	int (*page_flip)(struct drm_crtc *crtc,
d91d8a3f8 Kristian Høgsberg  2009-11-17  375  			 struct drm_framebuffer *fb,
ed8d19756 Keith Packard      2013-07-22  376  			 struct drm_pending_vblank_event *event,
ed8d19756 Keith Packard      2013-07-22  377  			 uint32_t flags);
bffd9de02 Paulo Zanoni       2012-05-15  378  
bffd9de02 Paulo Zanoni       2012-05-15  379  	int (*set_property)(struct drm_crtc *crtc,
bffd9de02 Paulo Zanoni       2012-05-15  380  			    struct drm_property *property, uint64_t val);
144ecb97c Daniel Vetter      2014-10-27  381  
144ecb97c Daniel Vetter      2014-10-27  382  	/* atomic update handling */
144ecb97c Daniel Vetter      2014-10-27  383  	struct drm_crtc_state *(*atomic_duplicate_state)(struct drm_crtc *crtc);
144ecb97c Daniel Vetter      2014-10-27  384  	void (*atomic_destroy_state)(struct drm_crtc *crtc,
cc4ceb484 Daniel Vetter      2014-07-25  385  				     struct drm_crtc_state *state);
144ecb97c Daniel Vetter      2014-10-27  386  	int (*atomic_set_property)(struct drm_crtc *crtc,
144ecb97c Daniel Vetter      2014-10-27  387  				   struct drm_crtc_state *state,
144ecb97c Daniel Vetter      2014-10-27  388  				   struct drm_property *property,
144ecb97c Daniel Vetter      2014-10-27  389  				   uint64_t val);
ac9c92561 Rob Clark          2014-12-18  390  	int (*atomic_get_property)(struct drm_crtc *crtc,
ac9c92561 Rob Clark          2014-12-18  391  				   const struct drm_crtc_state *state,
ac9c92561 Rob Clark          2014-12-18  392  				   struct drm_property *property,
ac9c92561 Rob Clark          2014-12-18  393  				   uint64_t *val);
f453ba046 Dave Airlie        2008-11-07  394  };
f453ba046 Dave Airlie        2008-11-07  395  
f453ba046 Dave Airlie        2008-11-07  396  /**
3bf0401cd Daniel Vetter      2014-10-27  397   * struct drm_crtc - central CRTC control structure
7749163ef Jesse Barnes       2011-11-07  398   * @dev: parent DRM device
2c0c33d41 Daniel Vetter      2014-10-27  399   * @port: OF node used by drm_of_find_possible_crtcs()
7749163ef Jesse Barnes       2011-11-07  400   * @head: list management
51fd371bb Rob Clark          2013-11-19  401   * @mutex: per-CRTC locking
7749163ef Jesse Barnes       2011-11-07  402   * @base: base KMS object for ID tracking etc.
e13161af8 Matt Roper         2014-04-01  403   * @primary: primary plane for this CRTC
e13161af8 Matt Roper         2014-04-01  404   * @cursor: cursor plane for this CRTC
2c0c33d41 Daniel Vetter      2014-10-27  405   * @cursor_x: current x position of the cursor, used for universal cursor planes
2c0c33d41 Daniel Vetter      2014-10-27  406   * @cursor_y: current y position of the cursor, used for universal cursor planes
f453ba046 Dave Airlie        2008-11-07  407   * @enabled: is this CRTC enabled?
7749163ef Jesse Barnes       2011-11-07  408   * @mode: current mode timings
7749163ef Jesse Barnes       2011-11-07  409   * @hwmode: mode timings as programmed to hw regs
f453ba046 Dave Airlie        2008-11-07  410   * @x: x position on screen
f453ba046 Dave Airlie        2008-11-07  411   * @y: y position on screen
f453ba046 Dave Airlie        2008-11-07  412   * @funcs: CRTC control functions
7749163ef Jesse Barnes       2011-11-07  413   * @gamma_size: size of gamma ramp
7749163ef Jesse Barnes       2011-11-07  414   * @gamma_store: gamma ramp values
7749163ef Jesse Barnes       2011-11-07  415   * @helper_private: mid-layer private data
bffd9de02 Paulo Zanoni       2012-05-15  416   * @properties: property tracking for this CRTC
144ecb97c Daniel Vetter      2014-10-27  417   * @state: current atomic state for this CRTC
2c0c33d41 Daniel Vetter      2014-10-27  418   * @acquire_ctx: per-CRTC implicit acquire context used by atomic drivers for
2c0c33d41 Daniel Vetter      2014-10-27  419   * 	legacy ioctls
f453ba046 Dave Airlie        2008-11-07  420   *
f453ba046 Dave Airlie        2008-11-07  421   * Each CRTC may have one or more connectors associated with it.  This structure
f453ba046 Dave Airlie        2008-11-07  422   * allows the CRTC to be controlled.
f453ba046 Dave Airlie        2008-11-07  423   */
f453ba046 Dave Airlie        2008-11-07  424  struct drm_crtc {
f453ba046 Dave Airlie        2008-11-07  425  	struct drm_device *dev;
7e435aad3 Russell King       2014-06-15  426  	struct device_node *port;
f453ba046 Dave Airlie        2008-11-07  427  	struct list_head head;
f453ba046 Dave Airlie        2008-11-07  428  
3bf0401cd Daniel Vetter      2014-10-27  429  	/*
29494c174 Daniel Vetter      2012-12-02  430  	 * crtc mutex
29494c174 Daniel Vetter      2012-12-02  431  	 *
29494c174 Daniel Vetter      2012-12-02  432  	 * This provides a read lock for the overall crtc state (mode, dpms
29494c174 Daniel Vetter      2012-12-02  433  	 * state, ...) and a write lock for everything which can be update
29494c174 Daniel Vetter      2012-12-02  434  	 * without a full modeset (fb, cursor data, ...)
29494c174 Daniel Vetter      2012-12-02  435  	 */
51fd371bb Rob Clark          2013-11-19  436  	struct drm_modeset_lock mutex;
29494c174 Daniel Vetter      2012-12-02  437  
f453ba046 Dave Airlie        2008-11-07  438  	struct drm_mode_object base;
f453ba046 Dave Airlie        2008-11-07  439  
e13161af8 Matt Roper         2014-04-01  440  	/* primary and cursor planes for CRTC */
e13161af8 Matt Roper         2014-04-01  441  	struct drm_plane *primary;
e13161af8 Matt Roper         2014-04-01  442  	struct drm_plane *cursor;
e13161af8 Matt Roper         2014-04-01  443  
161d0dc1d Matt Roper         2014-06-10  444  	/* position of cursor plane on crtc */
161d0dc1d Matt Roper         2014-06-10  445  	int cursor_x;
161d0dc1d Matt Roper         2014-06-10  446  	int cursor_y;
161d0dc1d Matt Roper         2014-06-10  447  
14ecd586d John Keeping       2015-11-17  448  	/* hotspot of cursor */
14ecd586d John Keeping       2015-11-17  449  	int hot_x;
14ecd586d John Keeping       2015-11-17  450  	int hot_y;
14ecd586d John Keeping       2015-11-17  451  
f453ba046 Dave Airlie        2008-11-07  452  	bool enabled;
f453ba046 Dave Airlie        2008-11-07  453  
27641c3f0 Mario Kleiner      2010-10-23  454  	/* Requested mode from modesetting. */
f453ba046 Dave Airlie        2008-11-07  455  	struct drm_display_mode mode;
f453ba046 Dave Airlie        2008-11-07  456  
27641c3f0 Mario Kleiner      2010-10-23  457  	/* Programmed mode in hw, after adjustments for encoders,
27641c3f0 Mario Kleiner      2010-10-23  458  	 * crtc, panel scaling etc. Needed for timestamping etc.
27641c3f0 Mario Kleiner      2010-10-23  459  	 */
27641c3f0 Mario Kleiner      2010-10-23  460  	struct drm_display_mode hwmode;
27641c3f0 Mario Kleiner      2010-10-23  461  
f453ba046 Dave Airlie        2008-11-07  462  	int x, y;
f453ba046 Dave Airlie        2008-11-07  463  	const struct drm_crtc_funcs *funcs;
f453ba046 Dave Airlie        2008-11-07  464  
f453ba046 Dave Airlie        2008-11-07  465  	/* CRTC gamma size for reporting to userspace */
f453ba046 Dave Airlie        2008-11-07  466  	uint32_t gamma_size;
f453ba046 Dave Airlie        2008-11-07  467  	uint16_t *gamma_store;
f453ba046 Dave Airlie        2008-11-07  468  
f453ba046 Dave Airlie        2008-11-07  469  	/* if you are using the helper */
9a436ee6c Jani Nikula        2015-04-13  470  	const void *helper_private;
bffd9de02 Paulo Zanoni       2012-05-15  471  
bffd9de02 Paulo Zanoni       2012-05-15  472  	struct drm_object_properties properties;
d059f652e Daniel Vetter      2014-07-25  473  
144ecb97c Daniel Vetter      2014-10-27  474  	struct drm_crtc_state *state;
144ecb97c Daniel Vetter      2014-10-27  475  
d059f652e Daniel Vetter      2014-07-25  476  	/*
d059f652e Daniel Vetter      2014-07-25  477  	 * For legacy crtc ioctls so that atomic drivers can get at the locking
d059f652e Daniel Vetter      2014-07-25  478  	 * acquire context.
d059f652e Daniel Vetter      2014-07-25  479  	 */
d059f652e Daniel Vetter      2014-07-25  480  	struct drm_modeset_acquire_ctx *acquire_ctx;
f453ba046 Dave Airlie        2008-11-07 @481  };
f453ba046 Dave Airlie        2008-11-07  482  
144ecb97c Daniel Vetter      2014-10-27  483  /**
144ecb97c Daniel Vetter      2014-10-27  484   * struct drm_connector_state - mutable connector state

:::::: The code at line 481 was first introduced by commit
:::::: f453ba0460742ad027ae0c4c7d61e62817b3e7ef DRM: add mode setting support

:::::: TO: Dave Airlie <airlied@redhat.com>
:::::: CC: Dave Airlie <airlied@linux.ie>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 6122 bytes --]

[-- Attachment #3: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 36+ messages in thread

* [PATCH v2] drm: support hotspot for universal plane cursors
  2015-11-17 12:10 [PATCH] drm: support hotspot for universal plane cursors John Keeping
@ 2015-11-17 15:05   ` John Keeping
  2015-11-17 15:05   ` John Keeping
  1 sibling, 0 replies; 36+ messages in thread
From: John Keeping @ 2015-11-17 15:05 UTC (permalink / raw)
  To: David Airlie; +Cc: dri-devel, linux-kernel, John Keeping

The request's hot_x and hot_y are set correctly for both
DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just need to save
the values and then apply the offset to the cursor plane when the cursor
moves.

Signed-off-by: John Keeping <john@metanate.com>
---
v2:
  - add kerneldoc for hot_x and hot_y in struct drm_crtc

 drivers/gpu/drm/drm_crtc.c | 11 +++++++----
 include/drm/drm_crtc.h     |  6 ++++++
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 720a153..40f5b84 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2831,6 +2831,9 @@ static int drm_mode_cursor_universal(struct drm_crtc *crtc,
 				DRM_DEBUG_KMS("failed to wrap cursor buffer in drm framebuffer\n");
 				return PTR_ERR(fb);
 			}
+
+			crtc->hot_x = req->hot_x;
+			crtc->hot_y = req->hot_y;
 		} else {
 			fb = NULL;
 		}
@@ -2841,11 +2844,11 @@ static int drm_mode_cursor_universal(struct drm_crtc *crtc,
 	}
 
 	if (req->flags & DRM_MODE_CURSOR_MOVE) {
-		crtc_x = req->x;
-		crtc_y = req->y;
+		crtc_x = req->x - crtc->hot_x;
+		crtc_y = req->y - crtc->hot_y;
 	} else {
-		crtc_x = crtc->cursor_x;
-		crtc_y = crtc->cursor_y;
+		crtc_x = crtc->cursor_x - crtc->hot_x;
+		crtc_y = crtc->cursor_y - crtc->hot_y;
 	}
 
 	if (fb) {
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 3f0c690..2be4414 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -404,6 +404,8 @@ struct drm_crtc_funcs {
  * @cursor: cursor plane for this CRTC
  * @cursor_x: current x position of the cursor, used for universal cursor planes
  * @cursor_y: current y position of the cursor, used for universal cursor planes
+ * @hot_x: x-coordinate of cursor hotspot, used for universal cursor planes
+ * @hot_y: y-coordinate of cursor hotspot, used for universal cursor planes
  * @enabled: is this CRTC enabled?
  * @mode: current mode timings
  * @hwmode: mode timings as programmed to hw regs
@@ -445,6 +447,10 @@ struct drm_crtc {
 	int cursor_x;
 	int cursor_y;
 
+	/* hotspot of cursor */
+	int hot_x;
+	int hot_y;
+
 	bool enabled;
 
 	/* Requested mode from modesetting. */
-- 
2.6.3.462.gbe2c914


^ permalink raw reply related	[flat|nested] 36+ messages in thread

* [PATCH v2] drm: support hotspot for universal plane cursors
@ 2015-11-17 15:05   ` John Keeping
  0 siblings, 0 replies; 36+ messages in thread
From: John Keeping @ 2015-11-17 15:05 UTC (permalink / raw)
  To: David Airlie; +Cc: linux-kernel, dri-devel

The request's hot_x and hot_y are set correctly for both
DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just need to save
the values and then apply the offset to the cursor plane when the cursor
moves.

Signed-off-by: John Keeping <john@metanate.com>
---
v2:
  - add kerneldoc for hot_x and hot_y in struct drm_crtc

 drivers/gpu/drm/drm_crtc.c | 11 +++++++----
 include/drm/drm_crtc.h     |  6 ++++++
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 720a153..40f5b84 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2831,6 +2831,9 @@ static int drm_mode_cursor_universal(struct drm_crtc *crtc,
 				DRM_DEBUG_KMS("failed to wrap cursor buffer in drm framebuffer\n");
 				return PTR_ERR(fb);
 			}
+
+			crtc->hot_x = req->hot_x;
+			crtc->hot_y = req->hot_y;
 		} else {
 			fb = NULL;
 		}
@@ -2841,11 +2844,11 @@ static int drm_mode_cursor_universal(struct drm_crtc *crtc,
 	}
 
 	if (req->flags & DRM_MODE_CURSOR_MOVE) {
-		crtc_x = req->x;
-		crtc_y = req->y;
+		crtc_x = req->x - crtc->hot_x;
+		crtc_y = req->y - crtc->hot_y;
 	} else {
-		crtc_x = crtc->cursor_x;
-		crtc_y = crtc->cursor_y;
+		crtc_x = crtc->cursor_x - crtc->hot_x;
+		crtc_y = crtc->cursor_y - crtc->hot_y;
 	}
 
 	if (fb) {
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 3f0c690..2be4414 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -404,6 +404,8 @@ struct drm_crtc_funcs {
  * @cursor: cursor plane for this CRTC
  * @cursor_x: current x position of the cursor, used for universal cursor planes
  * @cursor_y: current y position of the cursor, used for universal cursor planes
+ * @hot_x: x-coordinate of cursor hotspot, used for universal cursor planes
+ * @hot_y: y-coordinate of cursor hotspot, used for universal cursor planes
  * @enabled: is this CRTC enabled?
  * @mode: current mode timings
  * @hwmode: mode timings as programmed to hw regs
@@ -445,6 +447,10 @@ struct drm_crtc {
 	int cursor_x;
 	int cursor_y;
 
+	/* hotspot of cursor */
+	int hot_x;
+	int hot_y;
+
 	bool enabled;
 
 	/* Requested mode from modesetting. */
-- 
2.6.3.462.gbe2c914

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
  2015-11-17 15:05   ` John Keeping
@ 2015-11-17 15:39     ` Ville Syrjälä
  -1 siblings, 0 replies; 36+ messages in thread
From: Ville Syrjälä @ 2015-11-17 15:39 UTC (permalink / raw)
  To: John Keeping; +Cc: David Airlie, linux-kernel, dri-devel

On Tue, Nov 17, 2015 at 03:05:34PM +0000, John Keeping wrote:
> The request's hot_x and hot_y are set correctly for both
> DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just need to save
> the values and then apply the offset to the cursor plane when the cursor
> moves.
> 
> Signed-off-by: John Keeping <john@metanate.com>
> ---
> v2:
>   - add kerneldoc for hot_x and hot_y in struct drm_crtc
> 
>  drivers/gpu/drm/drm_crtc.c | 11 +++++++----
>  include/drm/drm_crtc.h     |  6 ++++++
>  2 files changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 720a153..40f5b84 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -2831,6 +2831,9 @@ static int drm_mode_cursor_universal(struct drm_crtc *crtc,
>  				DRM_DEBUG_KMS("failed to wrap cursor buffer in drm framebuffer\n");
>  				return PTR_ERR(fb);
>  			}
> +
> +			crtc->hot_x = req->hot_x;
> +			crtc->hot_y = req->hot_y;
>  		} else {
>  			fb = NULL;
>  		}
> @@ -2841,11 +2844,11 @@ static int drm_mode_cursor_universal(struct drm_crtc *crtc,
>  	}
>  
>  	if (req->flags & DRM_MODE_CURSOR_MOVE) {
> -		crtc_x = req->x;
> -		crtc_y = req->y;
> +		crtc_x = req->x - crtc->hot_x;
> +		crtc_y = req->y - crtc->hot_y;
>  	} else {
> -		crtc_x = crtc->cursor_x;
> -		crtc_y = crtc->cursor_y;
> +		crtc_x = crtc->cursor_x - crtc->hot_x;
> +		crtc_y = crtc->cursor_y - crtc->hot_y;

Why does the location of the hotspot affect the plane position?

Naturally there's no documentation in the uapi header for any of this
stuff :( Would be nice if the pople excited about documentation would
fix that part instead of just focusing on the internal stuff.

>  	}
>  
>  	if (fb) {
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 3f0c690..2be4414 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -404,6 +404,8 @@ struct drm_crtc_funcs {
>   * @cursor: cursor plane for this CRTC
>   * @cursor_x: current x position of the cursor, used for universal cursor planes
>   * @cursor_y: current y position of the cursor, used for universal cursor planes
> + * @hot_x: x-coordinate of cursor hotspot, used for universal cursor planes
> + * @hot_y: y-coordinate of cursor hotspot, used for universal cursor planes
>   * @enabled: is this CRTC enabled?
>   * @mode: current mode timings
>   * @hwmode: mode timings as programmed to hw regs
> @@ -445,6 +447,10 @@ struct drm_crtc {
>  	int cursor_x;
>  	int cursor_y;
>  
> +	/* hotspot of cursor */
> +	int hot_x;
> +	int hot_y;
> +
>  	bool enabled;
>  
>  	/* Requested mode from modesetting. */
> -- 
> 2.6.3.462.gbe2c914
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
@ 2015-11-17 15:39     ` Ville Syrjälä
  0 siblings, 0 replies; 36+ messages in thread
From: Ville Syrjälä @ 2015-11-17 15:39 UTC (permalink / raw)
  To: John Keeping; +Cc: linux-kernel, dri-devel

On Tue, Nov 17, 2015 at 03:05:34PM +0000, John Keeping wrote:
> The request's hot_x and hot_y are set correctly for both
> DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just need to save
> the values and then apply the offset to the cursor plane when the cursor
> moves.
> 
> Signed-off-by: John Keeping <john@metanate.com>
> ---
> v2:
>   - add kerneldoc for hot_x and hot_y in struct drm_crtc
> 
>  drivers/gpu/drm/drm_crtc.c | 11 +++++++----
>  include/drm/drm_crtc.h     |  6 ++++++
>  2 files changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 720a153..40f5b84 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -2831,6 +2831,9 @@ static int drm_mode_cursor_universal(struct drm_crtc *crtc,
>  				DRM_DEBUG_KMS("failed to wrap cursor buffer in drm framebuffer\n");
>  				return PTR_ERR(fb);
>  			}
> +
> +			crtc->hot_x = req->hot_x;
> +			crtc->hot_y = req->hot_y;
>  		} else {
>  			fb = NULL;
>  		}
> @@ -2841,11 +2844,11 @@ static int drm_mode_cursor_universal(struct drm_crtc *crtc,
>  	}
>  
>  	if (req->flags & DRM_MODE_CURSOR_MOVE) {
> -		crtc_x = req->x;
> -		crtc_y = req->y;
> +		crtc_x = req->x - crtc->hot_x;
> +		crtc_y = req->y - crtc->hot_y;
>  	} else {
> -		crtc_x = crtc->cursor_x;
> -		crtc_y = crtc->cursor_y;
> +		crtc_x = crtc->cursor_x - crtc->hot_x;
> +		crtc_y = crtc->cursor_y - crtc->hot_y;

Why does the location of the hotspot affect the plane position?

Naturally there's no documentation in the uapi header for any of this
stuff :( Would be nice if the pople excited about documentation would
fix that part instead of just focusing on the internal stuff.

>  	}
>  
>  	if (fb) {
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 3f0c690..2be4414 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -404,6 +404,8 @@ struct drm_crtc_funcs {
>   * @cursor: cursor plane for this CRTC
>   * @cursor_x: current x position of the cursor, used for universal cursor planes
>   * @cursor_y: current y position of the cursor, used for universal cursor planes
> + * @hot_x: x-coordinate of cursor hotspot, used for universal cursor planes
> + * @hot_y: y-coordinate of cursor hotspot, used for universal cursor planes
>   * @enabled: is this CRTC enabled?
>   * @mode: current mode timings
>   * @hwmode: mode timings as programmed to hw regs
> @@ -445,6 +447,10 @@ struct drm_crtc {
>  	int cursor_x;
>  	int cursor_y;
>  
> +	/* hotspot of cursor */
> +	int hot_x;
> +	int hot_y;
> +
>  	bool enabled;
>  
>  	/* Requested mode from modesetting. */
> -- 
> 2.6.3.462.gbe2c914
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
  2015-11-17 15:39     ` Ville Syrjälä
@ 2015-11-17 15:59       ` John Keeping
  -1 siblings, 0 replies; 36+ messages in thread
From: John Keeping @ 2015-11-17 15:59 UTC (permalink / raw)
  To: Ville Syrjälä; +Cc: David Airlie, linux-kernel, dri-devel

On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:

> On Tue, Nov 17, 2015 at 03:05:34PM +0000, John Keeping wrote:
> > The request's hot_x and hot_y are set correctly for both
> > DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just need to
> > save the values and then apply the offset to the cursor plane when
> > the cursor moves.
> > 
> > Signed-off-by: John Keeping <john@metanate.com>
> > ---
> > v2:
> >   - add kerneldoc for hot_x and hot_y in struct drm_crtc
> > 
> >  drivers/gpu/drm/drm_crtc.c | 11 +++++++----
> >  include/drm/drm_crtc.h     |  6 ++++++
> >  2 files changed, 13 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index 720a153..40f5b84 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -2831,6 +2831,9 @@ static int drm_mode_cursor_universal(struct
> > drm_crtc *crtc, DRM_DEBUG_KMS("failed to wrap cursor buffer in drm
> > framebuffer\n"); return PTR_ERR(fb);
> >  			}
> > +
> > +			crtc->hot_x = req->hot_x;
> > +			crtc->hot_y = req->hot_y;
> >  		} else {
> >  			fb = NULL;
> >  		}
> > @@ -2841,11 +2844,11 @@ static int drm_mode_cursor_universal(struct
> > drm_crtc *crtc, }
> >  
> >  	if (req->flags & DRM_MODE_CURSOR_MOVE) {
> > -		crtc_x = req->x;
> > -		crtc_y = req->y;
> > +		crtc_x = req->x - crtc->hot_x;
> > +		crtc_y = req->y - crtc->hot_y;
> >  	} else {
> > -		crtc_x = crtc->cursor_x;
> > -		crtc_y = crtc->cursor_y;
> > +		crtc_x = crtc->cursor_x - crtc->hot_x;
> > +		crtc_y = crtc->cursor_y - crtc->hot_y;  
> 
> Why does the location of the hotspot affect the plane position?

hot_{x,y} specify the location of the active pixel within the cursor
plane and cursor_{x,y} specify the location of the active pixel on the
display so we need to offset the plane position in order for the active
pixel to be in the correct place.

> >  	}
> >  
> >  	if (fb) {
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index 3f0c690..2be4414 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -404,6 +404,8 @@ struct drm_crtc_funcs {
> >   * @cursor: cursor plane for this CRTC
> >   * @cursor_x: current x position of the cursor, used for universal
> > cursor planes
> >   * @cursor_y: current y position of the cursor, used for universal
> > cursor planes
> > + * @hot_x: x-coordinate of cursor hotspot, used for universal
> > cursor planes
> > + * @hot_y: y-coordinate of cursor hotspot, used for universal
> > cursor planes
> >   * @enabled: is this CRTC enabled?
> >   * @mode: current mode timings
> >   * @hwmode: mode timings as programmed to hw regs
> > @@ -445,6 +447,10 @@ struct drm_crtc {
> >  	int cursor_x;
> >  	int cursor_y;
> >  
> > +	/* hotspot of cursor */
> > +	int hot_x;
> > +	int hot_y;
> > +
> >  	bool enabled;
> >  
> >  	/* Requested mode from modesetting. */
> > -- 
> > 2.6.3.462.gbe2c914
> > 
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel  
> 

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
@ 2015-11-17 15:59       ` John Keeping
  0 siblings, 0 replies; 36+ messages in thread
From: John Keeping @ 2015-11-17 15:59 UTC (permalink / raw)
  To: Ville Syrjälä; +Cc: linux-kernel, dri-devel

On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:

> On Tue, Nov 17, 2015 at 03:05:34PM +0000, John Keeping wrote:
> > The request's hot_x and hot_y are set correctly for both
> > DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just need to
> > save the values and then apply the offset to the cursor plane when
> > the cursor moves.
> > 
> > Signed-off-by: John Keeping <john@metanate.com>
> > ---
> > v2:
> >   - add kerneldoc for hot_x and hot_y in struct drm_crtc
> > 
> >  drivers/gpu/drm/drm_crtc.c | 11 +++++++----
> >  include/drm/drm_crtc.h     |  6 ++++++
> >  2 files changed, 13 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index 720a153..40f5b84 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -2831,6 +2831,9 @@ static int drm_mode_cursor_universal(struct
> > drm_crtc *crtc, DRM_DEBUG_KMS("failed to wrap cursor buffer in drm
> > framebuffer\n"); return PTR_ERR(fb);
> >  			}
> > +
> > +			crtc->hot_x = req->hot_x;
> > +			crtc->hot_y = req->hot_y;
> >  		} else {
> >  			fb = NULL;
> >  		}
> > @@ -2841,11 +2844,11 @@ static int drm_mode_cursor_universal(struct
> > drm_crtc *crtc, }
> >  
> >  	if (req->flags & DRM_MODE_CURSOR_MOVE) {
> > -		crtc_x = req->x;
> > -		crtc_y = req->y;
> > +		crtc_x = req->x - crtc->hot_x;
> > +		crtc_y = req->y - crtc->hot_y;
> >  	} else {
> > -		crtc_x = crtc->cursor_x;
> > -		crtc_y = crtc->cursor_y;
> > +		crtc_x = crtc->cursor_x - crtc->hot_x;
> > +		crtc_y = crtc->cursor_y - crtc->hot_y;  
> 
> Why does the location of the hotspot affect the plane position?

hot_{x,y} specify the location of the active pixel within the cursor
plane and cursor_{x,y} specify the location of the active pixel on the
display so we need to offset the plane position in order for the active
pixel to be in the correct place.

> >  	}
> >  
> >  	if (fb) {
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index 3f0c690..2be4414 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -404,6 +404,8 @@ struct drm_crtc_funcs {
> >   * @cursor: cursor plane for this CRTC
> >   * @cursor_x: current x position of the cursor, used for universal
> > cursor planes
> >   * @cursor_y: current y position of the cursor, used for universal
> > cursor planes
> > + * @hot_x: x-coordinate of cursor hotspot, used for universal
> > cursor planes
> > + * @hot_y: y-coordinate of cursor hotspot, used for universal
> > cursor planes
> >   * @enabled: is this CRTC enabled?
> >   * @mode: current mode timings
> >   * @hwmode: mode timings as programmed to hw regs
> > @@ -445,6 +447,10 @@ struct drm_crtc {
> >  	int cursor_x;
> >  	int cursor_y;
> >  
> > +	/* hotspot of cursor */
> > +	int hot_x;
> > +	int hot_y;
> > +
> >  	bool enabled;
> >  
> >  	/* Requested mode from modesetting. */
> > -- 
> > 2.6.3.462.gbe2c914
> > 
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel  
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
  2015-11-17 15:59       ` John Keeping
  (?)
@ 2015-11-17 16:09       ` Ville Syrjälä
  -1 siblings, 0 replies; 36+ messages in thread
From: Ville Syrjälä @ 2015-11-17 16:09 UTC (permalink / raw)
  To: John Keeping; +Cc: David Airlie, linux-kernel, dri-devel

On Tue, Nov 17, 2015 at 03:59:43PM +0000, John Keeping wrote:
> On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
> 
> > On Tue, Nov 17, 2015 at 03:05:34PM +0000, John Keeping wrote:
> > > The request's hot_x and hot_y are set correctly for both
> > > DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just need to
> > > save the values and then apply the offset to the cursor plane when
> > > the cursor moves.
> > > 
> > > Signed-off-by: John Keeping <john@metanate.com>
> > > ---
> > > v2:
> > >   - add kerneldoc for hot_x and hot_y in struct drm_crtc
> > > 
> > >  drivers/gpu/drm/drm_crtc.c | 11 +++++++----
> > >  include/drm/drm_crtc.h     |  6 ++++++
> > >  2 files changed, 13 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > > index 720a153..40f5b84 100644
> > > --- a/drivers/gpu/drm/drm_crtc.c
> > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > @@ -2831,6 +2831,9 @@ static int drm_mode_cursor_universal(struct
> > > drm_crtc *crtc, DRM_DEBUG_KMS("failed to wrap cursor buffer in drm
> > > framebuffer\n"); return PTR_ERR(fb);
> > >  			}
> > > +
> > > +			crtc->hot_x = req->hot_x;
> > > +			crtc->hot_y = req->hot_y;
> > >  		} else {
> > >  			fb = NULL;
> > >  		}
> > > @@ -2841,11 +2844,11 @@ static int drm_mode_cursor_universal(struct
> > > drm_crtc *crtc, }
> > >  
> > >  	if (req->flags & DRM_MODE_CURSOR_MOVE) {
> > > -		crtc_x = req->x;
> > > -		crtc_y = req->y;
> > > +		crtc_x = req->x - crtc->hot_x;
> > > +		crtc_y = req->y - crtc->hot_y;
> > >  	} else {
> > > -		crtc_x = crtc->cursor_x;
> > > -		crtc_y = crtc->cursor_y;
> > > +		crtc_x = crtc->cursor_x - crtc->hot_x;
> > > +		crtc_y = crtc->cursor_y - crtc->hot_y;  
> > 
> > Why does the location of the hotspot affect the plane position?
> 
> hot_{x,y} specify the location of the active pixel within the cursor
> plane and cursor_{x,y} specify the location of the active pixel on the
> display

Does it? Impossible to say without docs, or some reference to the
canonical implementation. Looking at the logs, I guess qxl was the
first to get hotspot support. Unfortunately looking at the qxl driver
isn't much help. But at leeast it seems to just pass the x/y and
hot_x/y straight through without offsetting anything.

> so we need to offset the plane position in order for the active
> pixel to be in the correct place.
> 
> > >  	}
> > >  
> > >  	if (fb) {
> > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > > index 3f0c690..2be4414 100644
> > > --- a/include/drm/drm_crtc.h
> > > +++ b/include/drm/drm_crtc.h
> > > @@ -404,6 +404,8 @@ struct drm_crtc_funcs {
> > >   * @cursor: cursor plane for this CRTC
> > >   * @cursor_x: current x position of the cursor, used for universal
> > > cursor planes
> > >   * @cursor_y: current y position of the cursor, used for universal
> > > cursor planes
> > > + * @hot_x: x-coordinate of cursor hotspot, used for universal
> > > cursor planes
> > > + * @hot_y: y-coordinate of cursor hotspot, used for universal
> > > cursor planes
> > >   * @enabled: is this CRTC enabled?
> > >   * @mode: current mode timings
> > >   * @hwmode: mode timings as programmed to hw regs
> > > @@ -445,6 +447,10 @@ struct drm_crtc {
> > >  	int cursor_x;
> > >  	int cursor_y;
> > >  
> > > +	/* hotspot of cursor */
> > > +	int hot_x;
> > > +	int hot_y;
> > > +
> > >  	bool enabled;
> > >  
> > >  	/* Requested mode from modesetting. */
> > > -- 
> > > 2.6.3.462.gbe2c914
> > > 
> > > _______________________________________________
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/dri-devel  
> > 

-- 
Ville Syrjälä
Intel OTC

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
  2015-11-17 15:59       ` John Keeping
@ 2015-11-17 16:29         ` Daniel Vetter
  -1 siblings, 0 replies; 36+ messages in thread
From: Daniel Vetter @ 2015-11-17 16:29 UTC (permalink / raw)
  To: John Keeping
  Cc: Ville Syrjälä,
	linux-kernel, dri-devel, Michel Dänzer, Alex Deucher

On Tue, Nov 17, 2015 at 03:59:43PM +0000, John Keeping wrote:
> On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
> 
> > On Tue, Nov 17, 2015 at 03:05:34PM +0000, John Keeping wrote:
> > > The request's hot_x and hot_y are set correctly for both
> > > DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just need to
> > > save the values and then apply the offset to the cursor plane when
> > > the cursor moves.
> > > 
> > > Signed-off-by: John Keeping <john@metanate.com>
> > > ---
> > > v2:
> > >   - add kerneldoc for hot_x and hot_y in struct drm_crtc
> > > 
> > >  drivers/gpu/drm/drm_crtc.c | 11 +++++++----
> > >  include/drm/drm_crtc.h     |  6 ++++++
> > >  2 files changed, 13 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > > index 720a153..40f5b84 100644
> > > --- a/drivers/gpu/drm/drm_crtc.c
> > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > @@ -2831,6 +2831,9 @@ static int drm_mode_cursor_universal(struct
> > > drm_crtc *crtc, DRM_DEBUG_KMS("failed to wrap cursor buffer in drm
> > > framebuffer\n"); return PTR_ERR(fb);
> > >  			}
> > > +
> > > +			crtc->hot_x = req->hot_x;
> > > +			crtc->hot_y = req->hot_y;
> > >  		} else {
> > >  			fb = NULL;
> > >  		}
> > > @@ -2841,11 +2844,11 @@ static int drm_mode_cursor_universal(struct
> > > drm_crtc *crtc, }
> > >  
> > >  	if (req->flags & DRM_MODE_CURSOR_MOVE) {
> > > -		crtc_x = req->x;
> > > -		crtc_y = req->y;
> > > +		crtc_x = req->x - crtc->hot_x;
> > > +		crtc_y = req->y - crtc->hot_y;
> > >  	} else {
> > > -		crtc_x = crtc->cursor_x;
> > > -		crtc_y = crtc->cursor_y;
> > > +		crtc_x = crtc->cursor_x - crtc->hot_x;
> > > +		crtc_y = crtc->cursor_y - crtc->hot_y;  
> > 
> > Why does the location of the hotspot affect the plane position?
> 
> hot_{x,y} specify the location of the active pixel within the cursor
> plane and cursor_{x,y} specify the location of the active pixel on the
> display so we need to offset the plane position in order for the active
> pixel to be in the correct place.

Nope, hot_x/y is just for virtual machines to indicate where the logical
cursor position is within the cursor plane. It should have 2 effect on how
something is displayed. And no, I have absolutely no idea why radeon is
pulling some tricks here, which have been added in

commit 78b1a6010b46a69bcd47b723a80f92693f26d17b
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Tue Nov 18 18:00:08 2014 +0900

    drm/radeon: Use cursor_set2 hook for enabling / disabling the HW cursor

Michel/Alex, can you please shed some light onto this? radeon is the only
driver doing this, making this interface inconsistent. Is the ddx doing
something funny compared to -modeseting or weston?

At least a quick look in the -ati sources didn't even show a user for
this, it's still using the old cursor ioctl. And there's no other
indication in the commit of a bug or anything. Can we perhaps just revert
this?

Cheers, Daniel

> 
> > >  	}
> > >  
> > >  	if (fb) {
> > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > > index 3f0c690..2be4414 100644
> > > --- a/include/drm/drm_crtc.h
> > > +++ b/include/drm/drm_crtc.h
> > > @@ -404,6 +404,8 @@ struct drm_crtc_funcs {
> > >   * @cursor: cursor plane for this CRTC
> > >   * @cursor_x: current x position of the cursor, used for universal
> > > cursor planes
> > >   * @cursor_y: current y position of the cursor, used for universal
> > > cursor planes
> > > + * @hot_x: x-coordinate of cursor hotspot, used for universal
> > > cursor planes
> > > + * @hot_y: y-coordinate of cursor hotspot, used for universal
> > > cursor planes
> > >   * @enabled: is this CRTC enabled?
> > >   * @mode: current mode timings
> > >   * @hwmode: mode timings as programmed to hw regs
> > > @@ -445,6 +447,10 @@ struct drm_crtc {
> > >  	int cursor_x;
> > >  	int cursor_y;
> > >  
> > > +	/* hotspot of cursor */
> > > +	int hot_x;
> > > +	int hot_y;
> > > +
> > >  	bool enabled;
> > >  
> > >  	/* Requested mode from modesetting. */
> > > -- 
> > > 2.6.3.462.gbe2c914
> > > 
> > > _______________________________________________
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/dri-devel  
> > 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
@ 2015-11-17 16:29         ` Daniel Vetter
  0 siblings, 0 replies; 36+ messages in thread
From: Daniel Vetter @ 2015-11-17 16:29 UTC (permalink / raw)
  To: John Keeping; +Cc: dri-devel, Michel Dänzer, linux-kernel

On Tue, Nov 17, 2015 at 03:59:43PM +0000, John Keeping wrote:
> On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
> 
> > On Tue, Nov 17, 2015 at 03:05:34PM +0000, John Keeping wrote:
> > > The request's hot_x and hot_y are set correctly for both
> > > DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just need to
> > > save the values and then apply the offset to the cursor plane when
> > > the cursor moves.
> > > 
> > > Signed-off-by: John Keeping <john@metanate.com>
> > > ---
> > > v2:
> > >   - add kerneldoc for hot_x and hot_y in struct drm_crtc
> > > 
> > >  drivers/gpu/drm/drm_crtc.c | 11 +++++++----
> > >  include/drm/drm_crtc.h     |  6 ++++++
> > >  2 files changed, 13 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > > index 720a153..40f5b84 100644
> > > --- a/drivers/gpu/drm/drm_crtc.c
> > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > @@ -2831,6 +2831,9 @@ static int drm_mode_cursor_universal(struct
> > > drm_crtc *crtc, DRM_DEBUG_KMS("failed to wrap cursor buffer in drm
> > > framebuffer\n"); return PTR_ERR(fb);
> > >  			}
> > > +
> > > +			crtc->hot_x = req->hot_x;
> > > +			crtc->hot_y = req->hot_y;
> > >  		} else {
> > >  			fb = NULL;
> > >  		}
> > > @@ -2841,11 +2844,11 @@ static int drm_mode_cursor_universal(struct
> > > drm_crtc *crtc, }
> > >  
> > >  	if (req->flags & DRM_MODE_CURSOR_MOVE) {
> > > -		crtc_x = req->x;
> > > -		crtc_y = req->y;
> > > +		crtc_x = req->x - crtc->hot_x;
> > > +		crtc_y = req->y - crtc->hot_y;
> > >  	} else {
> > > -		crtc_x = crtc->cursor_x;
> > > -		crtc_y = crtc->cursor_y;
> > > +		crtc_x = crtc->cursor_x - crtc->hot_x;
> > > +		crtc_y = crtc->cursor_y - crtc->hot_y;  
> > 
> > Why does the location of the hotspot affect the plane position?
> 
> hot_{x,y} specify the location of the active pixel within the cursor
> plane and cursor_{x,y} specify the location of the active pixel on the
> display so we need to offset the plane position in order for the active
> pixel to be in the correct place.

Nope, hot_x/y is just for virtual machines to indicate where the logical
cursor position is within the cursor plane. It should have 2 effect on how
something is displayed. And no, I have absolutely no idea why radeon is
pulling some tricks here, which have been added in

commit 78b1a6010b46a69bcd47b723a80f92693f26d17b
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Tue Nov 18 18:00:08 2014 +0900

    drm/radeon: Use cursor_set2 hook for enabling / disabling the HW cursor

Michel/Alex, can you please shed some light onto this? radeon is the only
driver doing this, making this interface inconsistent. Is the ddx doing
something funny compared to -modeseting or weston?

At least a quick look in the -ati sources didn't even show a user for
this, it's still using the old cursor ioctl. And there's no other
indication in the commit of a bug or anything. Can we perhaps just revert
this?

Cheers, Daniel

> 
> > >  	}
> > >  
> > >  	if (fb) {
> > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > > index 3f0c690..2be4414 100644
> > > --- a/include/drm/drm_crtc.h
> > > +++ b/include/drm/drm_crtc.h
> > > @@ -404,6 +404,8 @@ struct drm_crtc_funcs {
> > >   * @cursor: cursor plane for this CRTC
> > >   * @cursor_x: current x position of the cursor, used for universal
> > > cursor planes
> > >   * @cursor_y: current y position of the cursor, used for universal
> > > cursor planes
> > > + * @hot_x: x-coordinate of cursor hotspot, used for universal
> > > cursor planes
> > > + * @hot_y: y-coordinate of cursor hotspot, used for universal
> > > cursor planes
> > >   * @enabled: is this CRTC enabled?
> > >   * @mode: current mode timings
> > >   * @hwmode: mode timings as programmed to hw regs
> > > @@ -445,6 +447,10 @@ struct drm_crtc {
> > >  	int cursor_x;
> > >  	int cursor_y;
> > >  
> > > +	/* hotspot of cursor */
> > > +	int hot_x;
> > > +	int hot_y;
> > > +
> > >  	bool enabled;
> > >  
> > >  	/* Requested mode from modesetting. */
> > > -- 
> > > 2.6.3.462.gbe2c914
> > > 
> > > _______________________________________________
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/dri-devel  
> > 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
  2015-11-17 16:29         ` Daniel Vetter
@ 2015-11-17 16:58           ` John Keeping
  -1 siblings, 0 replies; 36+ messages in thread
From: John Keeping @ 2015-11-17 16:58 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Ville Syrjälä,
	linux-kernel, dri-devel, Michel Dänzer, Alex Deucher

On Tue, 17 Nov 2015 17:29:35 +0100, Daniel Vetter wrote:

> On Tue, Nov 17, 2015 at 03:59:43PM +0000, John Keeping wrote:
> > On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
> >   
> > > On Tue, Nov 17, 2015 at 03:05:34PM +0000, John Keeping wrote:  
> > > > The request's hot_x and hot_y are set correctly for both
> > > > DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just
> > > > need to save the values and then apply the offset to the cursor
> > > > plane when the cursor moves.
> > > > 
> > > > Signed-off-by: John Keeping <john@metanate.com>
> > > > ---
> > > > v2:
> > > >   - add kerneldoc for hot_x and hot_y in struct drm_crtc
> > > > 
> > > >  drivers/gpu/drm/drm_crtc.c | 11 +++++++----
> > > >  include/drm/drm_crtc.h     |  6 ++++++
> > > >  2 files changed, 13 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_crtc.c
> > > > b/drivers/gpu/drm/drm_crtc.c index 720a153..40f5b84 100644
> > > > --- a/drivers/gpu/drm/drm_crtc.c
> > > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > > @@ -2831,6 +2831,9 @@ static int
> > > > drm_mode_cursor_universal(struct drm_crtc *crtc,
> > > > DRM_DEBUG_KMS("failed to wrap cursor buffer in drm
> > > > framebuffer\n"); return PTR_ERR(fb); }
> > > > +
> > > > +			crtc->hot_x = req->hot_x;
> > > > +			crtc->hot_y = req->hot_y;
> > > >  		} else {
> > > >  			fb = NULL;
> > > >  		}
> > > > @@ -2841,11 +2844,11 @@ static int
> > > > drm_mode_cursor_universal(struct drm_crtc *crtc, }
> > > >  
> > > >  	if (req->flags & DRM_MODE_CURSOR_MOVE) {
> > > > -		crtc_x = req->x;
> > > > -		crtc_y = req->y;
> > > > +		crtc_x = req->x - crtc->hot_x;
> > > > +		crtc_y = req->y - crtc->hot_y;
> > > >  	} else {
> > > > -		crtc_x = crtc->cursor_x;
> > > > -		crtc_y = crtc->cursor_y;
> > > > +		crtc_x = crtc->cursor_x - crtc->hot_x;
> > > > +		crtc_y = crtc->cursor_y - crtc->hot_y;    
> > > 
> > > Why does the location of the hotspot affect the plane position?  
> > 
> > hot_{x,y} specify the location of the active pixel within the cursor
> > plane and cursor_{x,y} specify the location of the active pixel on
> > the display so we need to offset the plane position in order for
> > the active pixel to be in the correct place.  
> 
> Nope, hot_x/y is just for virtual machines to indicate where the
> logical cursor position is within the cursor plane. It should have 2
> effect on how something is displayed.

Hmm... I've run the same client code on QXL and Rockchip (which uses
universal planes) and without this patch the behaviour is just plain
wrong on Rockchip.

With a 32x32 cursor with the hotspot in the bottom-right using:

    drmModeSetCursor2(..., 0, 32)
    drmModeMoveCursor(..., x, y)

then with QXL when I click I get an event at (x, y) and this is
precisely under the bottom-right of the cursor.

With Rockchip the click appears to happen at the top-left of the cursor
(as if the hotspot were (0, 0)).  This patch makes the behaviour match
that on QXL.

I can't see how the hotspot can be ignored here unless you're saying
that the client code needs to offset the cursor position by the hotspot,
but in that case it will quite clearly be wrong on QXL.

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
@ 2015-11-17 16:58           ` John Keeping
  0 siblings, 0 replies; 36+ messages in thread
From: John Keeping @ 2015-11-17 16:58 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: dri-devel, Michel Dänzer, linux-kernel

On Tue, 17 Nov 2015 17:29:35 +0100, Daniel Vetter wrote:

> On Tue, Nov 17, 2015 at 03:59:43PM +0000, John Keeping wrote:
> > On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
> >   
> > > On Tue, Nov 17, 2015 at 03:05:34PM +0000, John Keeping wrote:  
> > > > The request's hot_x and hot_y are set correctly for both
> > > > DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just
> > > > need to save the values and then apply the offset to the cursor
> > > > plane when the cursor moves.
> > > > 
> > > > Signed-off-by: John Keeping <john@metanate.com>
> > > > ---
> > > > v2:
> > > >   - add kerneldoc for hot_x and hot_y in struct drm_crtc
> > > > 
> > > >  drivers/gpu/drm/drm_crtc.c | 11 +++++++----
> > > >  include/drm/drm_crtc.h     |  6 ++++++
> > > >  2 files changed, 13 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_crtc.c
> > > > b/drivers/gpu/drm/drm_crtc.c index 720a153..40f5b84 100644
> > > > --- a/drivers/gpu/drm/drm_crtc.c
> > > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > > @@ -2831,6 +2831,9 @@ static int
> > > > drm_mode_cursor_universal(struct drm_crtc *crtc,
> > > > DRM_DEBUG_KMS("failed to wrap cursor buffer in drm
> > > > framebuffer\n"); return PTR_ERR(fb); }
> > > > +
> > > > +			crtc->hot_x = req->hot_x;
> > > > +			crtc->hot_y = req->hot_y;
> > > >  		} else {
> > > >  			fb = NULL;
> > > >  		}
> > > > @@ -2841,11 +2844,11 @@ static int
> > > > drm_mode_cursor_universal(struct drm_crtc *crtc, }
> > > >  
> > > >  	if (req->flags & DRM_MODE_CURSOR_MOVE) {
> > > > -		crtc_x = req->x;
> > > > -		crtc_y = req->y;
> > > > +		crtc_x = req->x - crtc->hot_x;
> > > > +		crtc_y = req->y - crtc->hot_y;
> > > >  	} else {
> > > > -		crtc_x = crtc->cursor_x;
> > > > -		crtc_y = crtc->cursor_y;
> > > > +		crtc_x = crtc->cursor_x - crtc->hot_x;
> > > > +		crtc_y = crtc->cursor_y - crtc->hot_y;    
> > > 
> > > Why does the location of the hotspot affect the plane position?  
> > 
> > hot_{x,y} specify the location of the active pixel within the cursor
> > plane and cursor_{x,y} specify the location of the active pixel on
> > the display so we need to offset the plane position in order for
> > the active pixel to be in the correct place.  
> 
> Nope, hot_x/y is just for virtual machines to indicate where the
> logical cursor position is within the cursor plane. It should have 2
> effect on how something is displayed.

Hmm... I've run the same client code on QXL and Rockchip (which uses
universal planes) and without this patch the behaviour is just plain
wrong on Rockchip.

With a 32x32 cursor with the hotspot in the bottom-right using:

    drmModeSetCursor2(..., 0, 32)
    drmModeMoveCursor(..., x, y)

then with QXL when I click I get an event at (x, y) and this is
precisely under the bottom-right of the cursor.

With Rockchip the click appears to happen at the top-left of the cursor
(as if the hotspot were (0, 0)).  This patch makes the behaviour match
that on QXL.

I can't see how the hotspot can be ignored here unless you're saying
that the client code needs to offset the cursor position by the hotspot,
but in that case it will quite clearly be wrong on QXL.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
  2015-11-17 16:29         ` Daniel Vetter
@ 2015-11-17 17:07           ` Alex Deucher
  -1 siblings, 0 replies; 36+ messages in thread
From: Alex Deucher @ 2015-11-17 17:07 UTC (permalink / raw)
  To: John Keeping, Ville Syrjälä,
	LKML, Maling list - DRI developers, Michel Dänzer,
	Alex Deucher

On Tue, Nov 17, 2015 at 11:29 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Nov 17, 2015 at 03:59:43PM +0000, John Keeping wrote:
>> On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
>>
>> > On Tue, Nov 17, 2015 at 03:05:34PM +0000, John Keeping wrote:
>> > > The request's hot_x and hot_y are set correctly for both
>> > > DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just need to
>> > > save the values and then apply the offset to the cursor plane when
>> > > the cursor moves.
>> > >
>> > > Signed-off-by: John Keeping <john@metanate.com>
>> > > ---
>> > > v2:
>> > >   - add kerneldoc for hot_x and hot_y in struct drm_crtc
>> > >
>> > >  drivers/gpu/drm/drm_crtc.c | 11 +++++++----
>> > >  include/drm/drm_crtc.h     |  6 ++++++
>> > >  2 files changed, 13 insertions(+), 4 deletions(-)
>> > >
>> > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> > > index 720a153..40f5b84 100644
>> > > --- a/drivers/gpu/drm/drm_crtc.c
>> > > +++ b/drivers/gpu/drm/drm_crtc.c
>> > > @@ -2831,6 +2831,9 @@ static int drm_mode_cursor_universal(struct
>> > > drm_crtc *crtc, DRM_DEBUG_KMS("failed to wrap cursor buffer in drm
>> > > framebuffer\n"); return PTR_ERR(fb);
>> > >                   }
>> > > +
>> > > +                 crtc->hot_x = req->hot_x;
>> > > +                 crtc->hot_y = req->hot_y;
>> > >           } else {
>> > >                   fb = NULL;
>> > >           }
>> > > @@ -2841,11 +2844,11 @@ static int drm_mode_cursor_universal(struct
>> > > drm_crtc *crtc, }
>> > >
>> > >   if (req->flags & DRM_MODE_CURSOR_MOVE) {
>> > > -         crtc_x = req->x;
>> > > -         crtc_y = req->y;
>> > > +         crtc_x = req->x - crtc->hot_x;
>> > > +         crtc_y = req->y - crtc->hot_y;
>> > >   } else {
>> > > -         crtc_x = crtc->cursor_x;
>> > > -         crtc_y = crtc->cursor_y;
>> > > +         crtc_x = crtc->cursor_x - crtc->hot_x;
>> > > +         crtc_y = crtc->cursor_y - crtc->hot_y;
>> >
>> > Why does the location of the hotspot affect the plane position?
>>
>> hot_{x,y} specify the location of the active pixel within the cursor
>> plane and cursor_{x,y} specify the location of the active pixel on the
>> display so we need to offset the plane position in order for the active
>> pixel to be in the correct place.
>
> Nope, hot_x/y is just for virtual machines to indicate where the logical
> cursor position is within the cursor plane. It should have 2 effect on how
> something is displayed. And no, I have absolutely no idea why radeon is
> pulling some tricks here, which have been added in
>
> commit 78b1a6010b46a69bcd47b723a80f92693f26d17b
> Author: Michel Dänzer <michel.daenzer@amd.com>
> Date:   Tue Nov 18 18:00:08 2014 +0900
>
>     drm/radeon: Use cursor_set2 hook for enabling / disabling the HW cursor
>
> Michel/Alex, can you please shed some light onto this? radeon is the only
> driver doing this, making this interface inconsistent. Is the ddx doing
> something funny compared to -modeseting or weston?
>
> At least a quick look in the -ati sources didn't even show a user for
> this, it's still using the old cursor ioctl. And there's no other
> indication in the commit of a bug or anything. Can we perhaps just revert
> this?

We use this is xf86-video-ati.  See:
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=c9f8f642fd495937400618a4fc25ecae3f8888fc
Our hw cursor has a hotspot register that needs to be programmed for
proper operation.  I don't remember the details of the specific bug.
Michel can provide more info.

Alex

>
> Cheers, Daniel
>
>>
>> > >   }
>> > >
>> > >   if (fb) {
>> > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
>> > > index 3f0c690..2be4414 100644
>> > > --- a/include/drm/drm_crtc.h
>> > > +++ b/include/drm/drm_crtc.h
>> > > @@ -404,6 +404,8 @@ struct drm_crtc_funcs {
>> > >   * @cursor: cursor plane for this CRTC
>> > >   * @cursor_x: current x position of the cursor, used for universal
>> > > cursor planes
>> > >   * @cursor_y: current y position of the cursor, used for universal
>> > > cursor planes
>> > > + * @hot_x: x-coordinate of cursor hotspot, used for universal
>> > > cursor planes
>> > > + * @hot_y: y-coordinate of cursor hotspot, used for universal
>> > > cursor planes
>> > >   * @enabled: is this CRTC enabled?
>> > >   * @mode: current mode timings
>> > >   * @hwmode: mode timings as programmed to hw regs
>> > > @@ -445,6 +447,10 @@ struct drm_crtc {
>> > >   int cursor_x;
>> > >   int cursor_y;
>> > >
>> > > + /* hotspot of cursor */
>> > > + int hot_x;
>> > > + int hot_y;
>> > > +
>> > >   bool enabled;
>> > >
>> > >   /* Requested mode from modesetting. */
>> > > --
>> > > 2.6.3.462.gbe2c914
>> > >
>> > > _______________________________________________
>> > > dri-devel mailing list
>> > > dri-devel@lists.freedesktop.org
>> > > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>> >
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
@ 2015-11-17 17:07           ` Alex Deucher
  0 siblings, 0 replies; 36+ messages in thread
From: Alex Deucher @ 2015-11-17 17:07 UTC (permalink / raw)
  To: John Keeping, Ville Syrjälä,
	LKML, Maling list - DRI developers, Michel Dänzer,
	Alex Deucher

On Tue, Nov 17, 2015 at 11:29 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Nov 17, 2015 at 03:59:43PM +0000, John Keeping wrote:
>> On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
>>
>> > On Tue, Nov 17, 2015 at 03:05:34PM +0000, John Keeping wrote:
>> > > The request's hot_x and hot_y are set correctly for both
>> > > DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just need to
>> > > save the values and then apply the offset to the cursor plane when
>> > > the cursor moves.
>> > >
>> > > Signed-off-by: John Keeping <john@metanate.com>
>> > > ---
>> > > v2:
>> > >   - add kerneldoc for hot_x and hot_y in struct drm_crtc
>> > >
>> > >  drivers/gpu/drm/drm_crtc.c | 11 +++++++----
>> > >  include/drm/drm_crtc.h     |  6 ++++++
>> > >  2 files changed, 13 insertions(+), 4 deletions(-)
>> > >
>> > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> > > index 720a153..40f5b84 100644
>> > > --- a/drivers/gpu/drm/drm_crtc.c
>> > > +++ b/drivers/gpu/drm/drm_crtc.c
>> > > @@ -2831,6 +2831,9 @@ static int drm_mode_cursor_universal(struct
>> > > drm_crtc *crtc, DRM_DEBUG_KMS("failed to wrap cursor buffer in drm
>> > > framebuffer\n"); return PTR_ERR(fb);
>> > >                   }
>> > > +
>> > > +                 crtc->hot_x = req->hot_x;
>> > > +                 crtc->hot_y = req->hot_y;
>> > >           } else {
>> > >                   fb = NULL;
>> > >           }
>> > > @@ -2841,11 +2844,11 @@ static int drm_mode_cursor_universal(struct
>> > > drm_crtc *crtc, }
>> > >
>> > >   if (req->flags & DRM_MODE_CURSOR_MOVE) {
>> > > -         crtc_x = req->x;
>> > > -         crtc_y = req->y;
>> > > +         crtc_x = req->x - crtc->hot_x;
>> > > +         crtc_y = req->y - crtc->hot_y;
>> > >   } else {
>> > > -         crtc_x = crtc->cursor_x;
>> > > -         crtc_y = crtc->cursor_y;
>> > > +         crtc_x = crtc->cursor_x - crtc->hot_x;
>> > > +         crtc_y = crtc->cursor_y - crtc->hot_y;
>> >
>> > Why does the location of the hotspot affect the plane position?
>>
>> hot_{x,y} specify the location of the active pixel within the cursor
>> plane and cursor_{x,y} specify the location of the active pixel on the
>> display so we need to offset the plane position in order for the active
>> pixel to be in the correct place.
>
> Nope, hot_x/y is just for virtual machines to indicate where the logical
> cursor position is within the cursor plane. It should have 2 effect on how
> something is displayed. And no, I have absolutely no idea why radeon is
> pulling some tricks here, which have been added in
>
> commit 78b1a6010b46a69bcd47b723a80f92693f26d17b
> Author: Michel Dänzer <michel.daenzer@amd.com>
> Date:   Tue Nov 18 18:00:08 2014 +0900
>
>     drm/radeon: Use cursor_set2 hook for enabling / disabling the HW cursor
>
> Michel/Alex, can you please shed some light onto this? radeon is the only
> driver doing this, making this interface inconsistent. Is the ddx doing
> something funny compared to -modeseting or weston?
>
> At least a quick look in the -ati sources didn't even show a user for
> this, it's still using the old cursor ioctl. And there's no other
> indication in the commit of a bug or anything. Can we perhaps just revert
> this?

We use this is xf86-video-ati.  See:
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=c9f8f642fd495937400618a4fc25ecae3f8888fc
Our hw cursor has a hotspot register that needs to be programmed for
proper operation.  I don't remember the details of the specific bug.
Michel can provide more info.

Alex

>
> Cheers, Daniel
>
>>
>> > >   }
>> > >
>> > >   if (fb) {
>> > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
>> > > index 3f0c690..2be4414 100644
>> > > --- a/include/drm/drm_crtc.h
>> > > +++ b/include/drm/drm_crtc.h
>> > > @@ -404,6 +404,8 @@ struct drm_crtc_funcs {
>> > >   * @cursor: cursor plane for this CRTC
>> > >   * @cursor_x: current x position of the cursor, used for universal
>> > > cursor planes
>> > >   * @cursor_y: current y position of the cursor, used for universal
>> > > cursor planes
>> > > + * @hot_x: x-coordinate of cursor hotspot, used for universal
>> > > cursor planes
>> > > + * @hot_y: y-coordinate of cursor hotspot, used for universal
>> > > cursor planes
>> > >   * @enabled: is this CRTC enabled?
>> > >   * @mode: current mode timings
>> > >   * @hwmode: mode timings as programmed to hw regs
>> > > @@ -445,6 +447,10 @@ struct drm_crtc {
>> > >   int cursor_x;
>> > >   int cursor_y;
>> > >
>> > > + /* hotspot of cursor */
>> > > + int hot_x;
>> > > + int hot_y;
>> > > +
>> > >   bool enabled;
>> > >
>> > >   /* Requested mode from modesetting. */
>> > > --
>> > > 2.6.3.462.gbe2c914
>> > >
>> > > _______________________________________________
>> > > dri-devel mailing list
>> > > dri-devel@lists.freedesktop.org
>> > > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>> >
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
  2015-11-17 17:07           ` Alex Deucher
@ 2015-11-17 18:31             ` Daniel Vetter
  -1 siblings, 0 replies; 36+ messages in thread
From: Daniel Vetter @ 2015-11-17 18:31 UTC (permalink / raw)
  To: Alex Deucher
  Cc: John Keeping, Ville Syrjälä,
	LKML, Maling list - DRI developers, Michel Dänzer

On Tue, Nov 17, 2015 at 12:07:24PM -0500, Alex Deucher wrote:
> On Tue, Nov 17, 2015 at 11:29 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Tue, Nov 17, 2015 at 03:59:43PM +0000, John Keeping wrote:
> >> On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
> >>
> >> > On Tue, Nov 17, 2015 at 03:05:34PM +0000, John Keeping wrote:
> >> > > The request's hot_x and hot_y are set correctly for both
> >> > > DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just need to
> >> > > save the values and then apply the offset to the cursor plane when
> >> > > the cursor moves.
> >> > >
> >> > > Signed-off-by: John Keeping <john@metanate.com>
> >> > > ---
> >> > > v2:
> >> > >   - add kerneldoc for hot_x and hot_y in struct drm_crtc
> >> > >
> >> > >  drivers/gpu/drm/drm_crtc.c | 11 +++++++----
> >> > >  include/drm/drm_crtc.h     |  6 ++++++
> >> > >  2 files changed, 13 insertions(+), 4 deletions(-)
> >> > >
> >> > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> >> > > index 720a153..40f5b84 100644
> >> > > --- a/drivers/gpu/drm/drm_crtc.c
> >> > > +++ b/drivers/gpu/drm/drm_crtc.c
> >> > > @@ -2831,6 +2831,9 @@ static int drm_mode_cursor_universal(struct
> >> > > drm_crtc *crtc, DRM_DEBUG_KMS("failed to wrap cursor buffer in drm
> >> > > framebuffer\n"); return PTR_ERR(fb);
> >> > >                   }
> >> > > +
> >> > > +                 crtc->hot_x = req->hot_x;
> >> > > +                 crtc->hot_y = req->hot_y;
> >> > >           } else {
> >> > >                   fb = NULL;
> >> > >           }
> >> > > @@ -2841,11 +2844,11 @@ static int drm_mode_cursor_universal(struct
> >> > > drm_crtc *crtc, }
> >> > >
> >> > >   if (req->flags & DRM_MODE_CURSOR_MOVE) {
> >> > > -         crtc_x = req->x;
> >> > > -         crtc_y = req->y;
> >> > > +         crtc_x = req->x - crtc->hot_x;
> >> > > +         crtc_y = req->y - crtc->hot_y;
> >> > >   } else {
> >> > > -         crtc_x = crtc->cursor_x;
> >> > > -         crtc_y = crtc->cursor_y;
> >> > > +         crtc_x = crtc->cursor_x - crtc->hot_x;
> >> > > +         crtc_y = crtc->cursor_y - crtc->hot_y;
> >> >
> >> > Why does the location of the hotspot affect the plane position?
> >>
> >> hot_{x,y} specify the location of the active pixel within the cursor
> >> plane and cursor_{x,y} specify the location of the active pixel on the
> >> display so we need to offset the plane position in order for the active
> >> pixel to be in the correct place.
> >
> > Nope, hot_x/y is just for virtual machines to indicate where the logical
> > cursor position is within the cursor plane. It should have 2 effect on how
> > something is displayed. And no, I have absolutely no idea why radeon is
> > pulling some tricks here, which have been added in
> >
> > commit 78b1a6010b46a69bcd47b723a80f92693f26d17b
> > Author: Michel Dänzer <michel.daenzer@amd.com>
> > Date:   Tue Nov 18 18:00:08 2014 +0900
> >
> >     drm/radeon: Use cursor_set2 hook for enabling / disabling the HW cursor
> >
> > Michel/Alex, can you please shed some light onto this? radeon is the only
> > driver doing this, making this interface inconsistent. Is the ddx doing
> > something funny compared to -modeseting or weston?
> >
> > At least a quick look in the -ati sources didn't even show a user for
> > this, it's still using the old cursor ioctl. And there's no other
> > indication in the commit of a bug or anything. Can we perhaps just revert
> > this?
> 
> We use this is xf86-video-ati.  See:
> http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=c9f8f642fd495937400618a4fc25ecae3f8888fc
> Our hw cursor has a hotspot register that needs to be programmed for
> proper operation.  I don't remember the details of the specific bug.
> Michel can provide more info.

Yeah I was blind and didn't spot this. But I can't find your hotspot
cursor reg - it's only used to adjust the x/y offsets (similar to John's
patch). And amdgpu doesn't do this at all, it's only radoen.ko. Still
confused.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
@ 2015-11-17 18:31             ` Daniel Vetter
  0 siblings, 0 replies; 36+ messages in thread
From: Daniel Vetter @ 2015-11-17 18:31 UTC (permalink / raw)
  To: Alex Deucher; +Cc: Michel Dänzer, Maling list - DRI developers, LKML

On Tue, Nov 17, 2015 at 12:07:24PM -0500, Alex Deucher wrote:
> On Tue, Nov 17, 2015 at 11:29 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Tue, Nov 17, 2015 at 03:59:43PM +0000, John Keeping wrote:
> >> On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
> >>
> >> > On Tue, Nov 17, 2015 at 03:05:34PM +0000, John Keeping wrote:
> >> > > The request's hot_x and hot_y are set correctly for both
> >> > > DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just need to
> >> > > save the values and then apply the offset to the cursor plane when
> >> > > the cursor moves.
> >> > >
> >> > > Signed-off-by: John Keeping <john@metanate.com>
> >> > > ---
> >> > > v2:
> >> > >   - add kerneldoc for hot_x and hot_y in struct drm_crtc
> >> > >
> >> > >  drivers/gpu/drm/drm_crtc.c | 11 +++++++----
> >> > >  include/drm/drm_crtc.h     |  6 ++++++
> >> > >  2 files changed, 13 insertions(+), 4 deletions(-)
> >> > >
> >> > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> >> > > index 720a153..40f5b84 100644
> >> > > --- a/drivers/gpu/drm/drm_crtc.c
> >> > > +++ b/drivers/gpu/drm/drm_crtc.c
> >> > > @@ -2831,6 +2831,9 @@ static int drm_mode_cursor_universal(struct
> >> > > drm_crtc *crtc, DRM_DEBUG_KMS("failed to wrap cursor buffer in drm
> >> > > framebuffer\n"); return PTR_ERR(fb);
> >> > >                   }
> >> > > +
> >> > > +                 crtc->hot_x = req->hot_x;
> >> > > +                 crtc->hot_y = req->hot_y;
> >> > >           } else {
> >> > >                   fb = NULL;
> >> > >           }
> >> > > @@ -2841,11 +2844,11 @@ static int drm_mode_cursor_universal(struct
> >> > > drm_crtc *crtc, }
> >> > >
> >> > >   if (req->flags & DRM_MODE_CURSOR_MOVE) {
> >> > > -         crtc_x = req->x;
> >> > > -         crtc_y = req->y;
> >> > > +         crtc_x = req->x - crtc->hot_x;
> >> > > +         crtc_y = req->y - crtc->hot_y;
> >> > >   } else {
> >> > > -         crtc_x = crtc->cursor_x;
> >> > > -         crtc_y = crtc->cursor_y;
> >> > > +         crtc_x = crtc->cursor_x - crtc->hot_x;
> >> > > +         crtc_y = crtc->cursor_y - crtc->hot_y;
> >> >
> >> > Why does the location of the hotspot affect the plane position?
> >>
> >> hot_{x,y} specify the location of the active pixel within the cursor
> >> plane and cursor_{x,y} specify the location of the active pixel on the
> >> display so we need to offset the plane position in order for the active
> >> pixel to be in the correct place.
> >
> > Nope, hot_x/y is just for virtual machines to indicate where the logical
> > cursor position is within the cursor plane. It should have 2 effect on how
> > something is displayed. And no, I have absolutely no idea why radeon is
> > pulling some tricks here, which have been added in
> >
> > commit 78b1a6010b46a69bcd47b723a80f92693f26d17b
> > Author: Michel Dänzer <michel.daenzer@amd.com>
> > Date:   Tue Nov 18 18:00:08 2014 +0900
> >
> >     drm/radeon: Use cursor_set2 hook for enabling / disabling the HW cursor
> >
> > Michel/Alex, can you please shed some light onto this? radeon is the only
> > driver doing this, making this interface inconsistent. Is the ddx doing
> > something funny compared to -modeseting or weston?
> >
> > At least a quick look in the -ati sources didn't even show a user for
> > this, it's still using the old cursor ioctl. And there's no other
> > indication in the commit of a bug or anything. Can we perhaps just revert
> > this?
> 
> We use this is xf86-video-ati.  See:
> http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=c9f8f642fd495937400618a4fc25ecae3f8888fc
> Our hw cursor has a hotspot register that needs to be programmed for
> proper operation.  I don't remember the details of the specific bug.
> Michel can provide more info.

Yeah I was blind and didn't spot this. But I can't find your hotspot
cursor reg - it's only used to adjust the x/y offsets (similar to John's
patch). And amdgpu doesn't do this at all, it's only radoen.ko. Still
confused.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
  2015-11-17 16:58           ` John Keeping
@ 2015-11-17 18:40             ` Daniel Vetter
  -1 siblings, 0 replies; 36+ messages in thread
From: Daniel Vetter @ 2015-11-17 18:40 UTC (permalink / raw)
  To: John Keeping
  Cc: Daniel Vetter, Ville Syrjälä,
	linux-kernel, dri-devel, Michel Dänzer, Alex Deucher

On Tue, Nov 17, 2015 at 04:58:06PM +0000, John Keeping wrote:
> On Tue, 17 Nov 2015 17:29:35 +0100, Daniel Vetter wrote:
> 
> > On Tue, Nov 17, 2015 at 03:59:43PM +0000, John Keeping wrote:
> > > On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
> > >   
> > > > On Tue, Nov 17, 2015 at 03:05:34PM +0000, John Keeping wrote:  
> > > > > The request's hot_x and hot_y are set correctly for both
> > > > > DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just
> > > > > need to save the values and then apply the offset to the cursor
> > > > > plane when the cursor moves.
> > > > > 
> > > > > Signed-off-by: John Keeping <john@metanate.com>
> > > > > ---
> > > > > v2:
> > > > >   - add kerneldoc for hot_x and hot_y in struct drm_crtc
> > > > > 
> > > > >  drivers/gpu/drm/drm_crtc.c | 11 +++++++----
> > > > >  include/drm/drm_crtc.h     |  6 ++++++
> > > > >  2 files changed, 13 insertions(+), 4 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/drm_crtc.c
> > > > > b/drivers/gpu/drm/drm_crtc.c index 720a153..40f5b84 100644
> > > > > --- a/drivers/gpu/drm/drm_crtc.c
> > > > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > > > @@ -2831,6 +2831,9 @@ static int
> > > > > drm_mode_cursor_universal(struct drm_crtc *crtc,
> > > > > DRM_DEBUG_KMS("failed to wrap cursor buffer in drm
> > > > > framebuffer\n"); return PTR_ERR(fb); }
> > > > > +
> > > > > +			crtc->hot_x = req->hot_x;
> > > > > +			crtc->hot_y = req->hot_y;
> > > > >  		} else {
> > > > >  			fb = NULL;
> > > > >  		}
> > > > > @@ -2841,11 +2844,11 @@ static int
> > > > > drm_mode_cursor_universal(struct drm_crtc *crtc, }
> > > > >  
> > > > >  	if (req->flags & DRM_MODE_CURSOR_MOVE) {
> > > > > -		crtc_x = req->x;
> > > > > -		crtc_y = req->y;
> > > > > +		crtc_x = req->x - crtc->hot_x;
> > > > > +		crtc_y = req->y - crtc->hot_y;
> > > > >  	} else {
> > > > > -		crtc_x = crtc->cursor_x;
> > > > > -		crtc_y = crtc->cursor_y;
> > > > > +		crtc_x = crtc->cursor_x - crtc->hot_x;
> > > > > +		crtc_y = crtc->cursor_y - crtc->hot_y;    
> > > > 
> > > > Why does the location of the hotspot affect the plane position?  
> > > 
> > > hot_{x,y} specify the location of the active pixel within the cursor
> > > plane and cursor_{x,y} specify the location of the active pixel on
> > > the display so we need to offset the plane position in order for
> > > the active pixel to be in the correct place.  
> > 
> > Nope, hot_x/y is just for virtual machines to indicate where the
> > logical cursor position is within the cursor plane. It should have 2
> > effect on how something is displayed.
> 
> Hmm... I've run the same client code on QXL and Rockchip (which uses
> universal planes) and without this patch the behaviour is just plain
> wrong on Rockchip.
> 
> With a 32x32 cursor with the hotspot in the bottom-right using:
> 
>     drmModeSetCursor2(..., 0, 32)
>     drmModeMoveCursor(..., x, y)
> 
> then with QXL when I click I get an event at (x, y) and this is
> precisely under the bottom-right of the cursor.
> 
> With Rockchip the click appears to happen at the top-left of the cursor
> (as if the hotspot were (0, 0)).  This patch makes the behaviour match
> that on QXL.
> 
> I can't see how the hotspot can be ignored here unless you're saying
> that the client code needs to offset the cursor position by the hotspot,
> but in that case it will quite clearly be wrong on QXL.

I checked a bunch of X drivers and none of them adjust for the hotspot.
Also i915.ko always used x/y directly and never adjusted for the hotspot.
And as far as generic kms interfaces go i915 is pretty much the standard,
and that is what's been implemented in universal planes.

The only exception really seems to be radeon.ko, which does adjust the x/y
position of the cursor in the crtc space like your patch does above.

How can I test cursor hotspots? In the end we want a) something consistent
b) that doesn't break existing code and unfortunately b) trumps a). So I'd
like to figure out what's going on on the amd/intel hw I have here.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
@ 2015-11-17 18:40             ` Daniel Vetter
  0 siblings, 0 replies; 36+ messages in thread
From: Daniel Vetter @ 2015-11-17 18:40 UTC (permalink / raw)
  To: John Keeping; +Cc: Michel Dänzer, linux-kernel, dri-devel

On Tue, Nov 17, 2015 at 04:58:06PM +0000, John Keeping wrote:
> On Tue, 17 Nov 2015 17:29:35 +0100, Daniel Vetter wrote:
> 
> > On Tue, Nov 17, 2015 at 03:59:43PM +0000, John Keeping wrote:
> > > On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
> > >   
> > > > On Tue, Nov 17, 2015 at 03:05:34PM +0000, John Keeping wrote:  
> > > > > The request's hot_x and hot_y are set correctly for both
> > > > > DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just
> > > > > need to save the values and then apply the offset to the cursor
> > > > > plane when the cursor moves.
> > > > > 
> > > > > Signed-off-by: John Keeping <john@metanate.com>
> > > > > ---
> > > > > v2:
> > > > >   - add kerneldoc for hot_x and hot_y in struct drm_crtc
> > > > > 
> > > > >  drivers/gpu/drm/drm_crtc.c | 11 +++++++----
> > > > >  include/drm/drm_crtc.h     |  6 ++++++
> > > > >  2 files changed, 13 insertions(+), 4 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/drm_crtc.c
> > > > > b/drivers/gpu/drm/drm_crtc.c index 720a153..40f5b84 100644
> > > > > --- a/drivers/gpu/drm/drm_crtc.c
> > > > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > > > @@ -2831,6 +2831,9 @@ static int
> > > > > drm_mode_cursor_universal(struct drm_crtc *crtc,
> > > > > DRM_DEBUG_KMS("failed to wrap cursor buffer in drm
> > > > > framebuffer\n"); return PTR_ERR(fb); }
> > > > > +
> > > > > +			crtc->hot_x = req->hot_x;
> > > > > +			crtc->hot_y = req->hot_y;
> > > > >  		} else {
> > > > >  			fb = NULL;
> > > > >  		}
> > > > > @@ -2841,11 +2844,11 @@ static int
> > > > > drm_mode_cursor_universal(struct drm_crtc *crtc, }
> > > > >  
> > > > >  	if (req->flags & DRM_MODE_CURSOR_MOVE) {
> > > > > -		crtc_x = req->x;
> > > > > -		crtc_y = req->y;
> > > > > +		crtc_x = req->x - crtc->hot_x;
> > > > > +		crtc_y = req->y - crtc->hot_y;
> > > > >  	} else {
> > > > > -		crtc_x = crtc->cursor_x;
> > > > > -		crtc_y = crtc->cursor_y;
> > > > > +		crtc_x = crtc->cursor_x - crtc->hot_x;
> > > > > +		crtc_y = crtc->cursor_y - crtc->hot_y;    
> > > > 
> > > > Why does the location of the hotspot affect the plane position?  
> > > 
> > > hot_{x,y} specify the location of the active pixel within the cursor
> > > plane and cursor_{x,y} specify the location of the active pixel on
> > > the display so we need to offset the plane position in order for
> > > the active pixel to be in the correct place.  
> > 
> > Nope, hot_x/y is just for virtual machines to indicate where the
> > logical cursor position is within the cursor plane. It should have 2
> > effect on how something is displayed.
> 
> Hmm... I've run the same client code on QXL and Rockchip (which uses
> universal planes) and without this patch the behaviour is just plain
> wrong on Rockchip.
> 
> With a 32x32 cursor with the hotspot in the bottom-right using:
> 
>     drmModeSetCursor2(..., 0, 32)
>     drmModeMoveCursor(..., x, y)
> 
> then with QXL when I click I get an event at (x, y) and this is
> precisely under the bottom-right of the cursor.
> 
> With Rockchip the click appears to happen at the top-left of the cursor
> (as if the hotspot were (0, 0)).  This patch makes the behaviour match
> that on QXL.
> 
> I can't see how the hotspot can be ignored here unless you're saying
> that the client code needs to offset the cursor position by the hotspot,
> but in that case it will quite clearly be wrong on QXL.

I checked a bunch of X drivers and none of them adjust for the hotspot.
Also i915.ko always used x/y directly and never adjusted for the hotspot.
And as far as generic kms interfaces go i915 is pretty much the standard,
and that is what's been implemented in universal planes.

The only exception really seems to be radeon.ko, which does adjust the x/y
position of the cursor in the crtc space like your patch does above.

How can I test cursor hotspots? In the end we want a) something consistent
b) that doesn't break existing code and unfortunately b) trumps a). So I'd
like to figure out what's going on on the amd/intel hw I have here.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
  2015-11-17 18:31             ` Daniel Vetter
@ 2015-11-17 18:47               ` John Keeping
  -1 siblings, 0 replies; 36+ messages in thread
From: John Keeping @ 2015-11-17 18:47 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Alex Deucher, Ville Syrjälä,
	LKML, Maling list - DRI developers, Michel Dänzer

On Tue, 17 Nov 2015 19:31:32 +0100, Daniel Vetter wrote:

> On Tue, Nov 17, 2015 at 12:07:24PM -0500, Alex Deucher wrote:
> > On Tue, Nov 17, 2015 at 11:29 AM, Daniel Vetter <daniel@ffwll.ch>
> > wrote:  
> > > On Tue, Nov 17, 2015 at 03:59:43PM +0000, John Keeping wrote:  
> > >> On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
> > >>  
> > >> > On Tue, Nov 17, 2015 at 03:05:34PM +0000, John Keeping wrote:  
> > >> > > The request's hot_x and hot_y are set correctly for both
> > >> > > DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just
> > >> > > need to save the values and then apply the offset to the
> > >> > > cursor plane when the cursor moves.
> > >> > >
> > >> > > Signed-off-by: John Keeping <john@metanate.com>
> > >> > > ---
> > >> > > v2:
> > >> > >   - add kerneldoc for hot_x and hot_y in struct drm_crtc
> > >> > >
> > >> > >  drivers/gpu/drm/drm_crtc.c | 11 +++++++----
> > >> > >  include/drm/drm_crtc.h     |  6 ++++++
> > >> > >  2 files changed, 13 insertions(+), 4 deletions(-)
> > >> > >
> > >> > > diff --git a/drivers/gpu/drm/drm_crtc.c
> > >> > > b/drivers/gpu/drm/drm_crtc.c index 720a153..40f5b84 100644
> > >> > > --- a/drivers/gpu/drm/drm_crtc.c
> > >> > > +++ b/drivers/gpu/drm/drm_crtc.c
> > >> > > @@ -2831,6 +2831,9 @@ static int
> > >> > > drm_mode_cursor_universal(struct drm_crtc *crtc,
> > >> > > DRM_DEBUG_KMS("failed to wrap cursor buffer in drm
> > >> > > framebuffer\n"); return PTR_ERR(fb); }
> > >> > > +
> > >> > > +                 crtc->hot_x = req->hot_x;
> > >> > > +                 crtc->hot_y = req->hot_y;
> > >> > >           } else {
> > >> > >                   fb = NULL;
> > >> > >           }
> > >> > > @@ -2841,11 +2844,11 @@ static int
> > >> > > drm_mode_cursor_universal(struct drm_crtc *crtc, }
> > >> > >
> > >> > >   if (req->flags & DRM_MODE_CURSOR_MOVE) {
> > >> > > -         crtc_x = req->x;
> > >> > > -         crtc_y = req->y;
> > >> > > +         crtc_x = req->x - crtc->hot_x;
> > >> > > +         crtc_y = req->y - crtc->hot_y;
> > >> > >   } else {
> > >> > > -         crtc_x = crtc->cursor_x;
> > >> > > -         crtc_y = crtc->cursor_y;
> > >> > > +         crtc_x = crtc->cursor_x - crtc->hot_x;
> > >> > > +         crtc_y = crtc->cursor_y - crtc->hot_y;  
> > >> >
> > >> > Why does the location of the hotspot affect the plane
> > >> > position?  
> > >>
> > >> hot_{x,y} specify the location of the active pixel within the
> > >> cursor plane and cursor_{x,y} specify the location of the active
> > >> pixel on the display so we need to offset the plane position in
> > >> order for the active pixel to be in the correct place.  
> > >
> > > Nope, hot_x/y is just for virtual machines to indicate where the
> > > logical cursor position is within the cursor plane. It should
> > > have 2 effect on how something is displayed. And no, I have
> > > absolutely no idea why radeon is pulling some tricks here, which
> > > have been added in
> > >
> > > commit 78b1a6010b46a69bcd47b723a80f92693f26d17b
> > > Author: Michel Dänzer <michel.daenzer@amd.com>
> > > Date:   Tue Nov 18 18:00:08 2014 +0900
> > >
> > >     drm/radeon: Use cursor_set2 hook for enabling / disabling the
> > > HW cursor
> > >
> > > Michel/Alex, can you please shed some light onto this? radeon is
> > > the only driver doing this, making this interface inconsistent.
> > > Is the ddx doing something funny compared to -modeseting or
> > > weston?
> > >
> > > At least a quick look in the -ati sources didn't even show a user
> > > for this, it's still using the old cursor ioctl. And there's no
> > > other indication in the commit of a bug or anything. Can we
> > > perhaps just revert this?  
> > 
> > We use this is xf86-video-ati.  See:
> > http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=c9f8f642fd495937400618a4fc25ecae3f8888fc
> > Our hw cursor has a hotspot register that needs to be programmed for
> > proper operation.  I don't remember the details of the specific bug.
> > Michel can provide more info.  
> 
> Yeah I was blind and didn't spot this. But I can't find your hotspot
> cursor reg - it's only used to adjust the x/y offsets (similar to
> John's patch). And amdgpu doesn't do this at all, it's only
> radoen.ko. Still confused.

Having investigated a bit more, I think xserver handles the hotspot
itself without using the kernel hotspot handling and xorg-video-qxl
carefully reverses this in order to take advantage of
drmModeSetCursor2(), so with X11 drivers you don't notice that the
kernel handling of this is broken in nearly all drivers.

Here's a small test program that demonstrates whether or not cursor
hotspots work.  There should be a single colored pixel immediately to
the left of the pointer but with a broken driver the white pixel will be
64 pixels to the left of the pointer.

Compile with:

    cc -o test -I/usr/include/libdrm test.c -lkms -ldrm

-- >8 --
#include <err.h>
#include <poll.h>
#include <string.h>

#include <sys/mman.h>

#include <libkms/libkms.h>
#include <xf86drm.h>
#include <xf86drmMode.h>


static int drm_fd;
static int crtc_id = -1;
static drmModeModeInfo mode_info;
static struct kms_driver *kms;

static struct {
	int id;
	size_t size;
	unsigned char *data;
} framebuffer;

static struct {
	int x, y;
	struct kms_bo *buffer;
} cursor;

#define CURSOR_WIDTH	21
#define CURSOR_HEIGHT	21
#define CURSOR_HOT_X	21
#define CURSOR_HOT_Y	0
unsigned char cursor_data[] =
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\0\0\0\377\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377"
  "\377\377\377\377\377\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377\377\377\377"
  "\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377"
  "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\0\0\0\377"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377"
  "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\0\0\0\377\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377\377"
  "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\0\0\0\377\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377\377\377"
  "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377"
  "\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377\377"
  "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377"
  "\377\377\377\377\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377"
  "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377"
  "\377\377\377\377\377\377\377\377\377\377\377\377\0\0\0\377\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\0\0"
  "\0\377\0\0\0\377\0\0\0\377\0\0\0\377\377\377\377\377\377\377\377\377\377"
  "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\0\0\0\377\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377"
  "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\0\0\0\377"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377"
  "\0\0\0\377\0\0\0\377\377\377\377\377\377\377\377\377\0\0\0\377\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377\0\0\0\377\0\0\0"
  "\0\0\0\0\0\0\0\0\377\377\377\377\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\377\377\377\377\377\377\377\377\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377"
  "\377\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377\0\0\0\377\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377"
  "\377\377\377\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\377\0\0\0\377\377\377\377\377\0\0\0\377\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0";


static void draw_cursor(void)
{
	void *result;
	unsigned char *ptr;
	int x, y;
	if (kms_bo_map(cursor.buffer, &result))
		err(1, "kms_bo_map");

	ptr = result;
	memset(ptr, 0, 64 * 64 * 4);

	for (y = 0; y < CURSOR_HEIGHT; y++)
		memcpy(ptr + 64 * 4 * y, cursor_data + 4 * CURSOR_WIDTH * y, CURSOR_WIDTH * 4);

	kms_bo_unmap(cursor.buffer);
}

static void setup_cursor(void)
{
	const unsigned int attr[] = {
		KMS_BO_TYPE, KMS_BO_TYPE_CURSOR_64X64_A8R8G8B8,
		KMS_WIDTH, 64,
		KMS_HEIGHT, 64,
		KMS_TERMINATE_PROP_LIST
	};
	unsigned int handle;
	if (kms_bo_create(kms, attr, &cursor.buffer))
		err(1, "kms_bo_create");

	draw_cursor();

	if (kms_bo_get_prop(cursor.buffer, KMS_HANDLE, &handle))
		err(1, "kms_bo_get_prop");

	if (drmModeSetCursor2(drm_fd, crtc_id, handle, 64, 64, CURSOR_HOT_X, CURSOR_HOT_Y))
		err(1, "drmModeSetCursor2");

	if (drmModeMoveCursor(drm_fd, crtc_id, cursor.x, cursor.y))
		err(1, "drmModeMoveCursor");
}

static void create_framebuffer(void)
{
	struct drm_mode_create_dumb creq = {
		.width = mode_info.hdisplay,
		.height = mode_info.vdisplay,
		.bpp = 32,
		.flags = 0,
	};
	struct drm_mode_map_dumb mreq = { 0 };
	if (drmIoctl(drm_fd, DRM_IOCTL_MODE_CREATE_DUMB, &creq))
		err(1, "DRM_IOCTL_MODE_CREATE_DUMB");

	if (drmModeAddFB(drm_fd, creq.width, creq.height, 24, 32, creq.pitch, creq.handle, &framebuffer.id))
		err(1, "drmModeAddFB");

	mreq.handle = creq.handle;
	if (drmIoctl(drm_fd, DRM_IOCTL_MODE_MAP_DUMB, &mreq))
		err(1, "DRM_IOCTL_MODE_MAP_DUMB");

	framebuffer.data = mmap(0, creq.size, PROT_READ | PROT_WRITE, MAP_SHARED, drm_fd, mreq.offset);
	if (framebuffer.data == MAP_FAILED)
		err(1, "mmap");

	framebuffer.size = creq.size;
	memset(framebuffer.data, 0, framebuffer.size);

	/* Paint cursor location with a single colored pixel. */
	framebuffer.data[1 + cursor.x * 4 + cursor.y * creq.pitch] = '\xff';
	framebuffer.data[2 + cursor.x * 4 + cursor.y * creq.pitch] = '\xff';
}

static int setup_connector(drmModeConnector *conn, drmModeRes *res)
{
	drmModeModeInfo *mode = NULL;
	int i;

	if (conn->connection != DRM_MODE_CONNECTED)
		return -1;

	for (int j = 0; j < conn->count_modes; j++) {
		if (!mode || (conn->modes[j].type & DRM_MODE_TYPE_PREFERRED)) {
			mode = &conn->modes[j];
			if (conn->modes[j].type & DRM_MODE_TYPE_PREFERRED)
				break;
		}
	}

	if (!mode)
		return -1;

	for (i = 0; i < conn->count_encoders; i++) {
		int j;
		drmModeEncoder *enc = drmModeGetEncoder(drm_fd, conn->encoders[j]);
		if (!enc)
			continue;

		for (j = 0; j < res->count_crtcs; j++) {
			if (enc->possible_crtcs & (1u << j)) {
				crtc_id = res->crtcs[j];
				break;
			}
		}

		drmModeFreeEncoder(enc);
		if (crtc_id >= 0)
			break;
	}

	memcpy(&mode_info, mode, sizeof(mode_info));
	cursor.x = mode->hdisplay / 2;
	cursor.y = mode->vdisplay / 2;
	create_framebuffer();

	if (drmModeSetCrtc(drm_fd, crtc_id, framebuffer.id, 0, 0, &conn->connector_id, 1, mode))
		err(1, "drmModeSetCrtc");

	return 0;
}

static void setup_screen(drmModeRes *res)
{
	int i;

	for (i = 0; i < res->count_connectors; i++) {
		int result;
		drmModeConnector *conn = drmModeGetConnector(drm_fd, res->connectors[i]);
		if (!conn)
			continue;
		result = setup_connector(conn, res);
		drmModeFreeConnector(conn);
		if (!result)
			break;
	}

	if (crtc_id < 0)
		errx(1, "no screen found");
}

static void setup_drm(const char *module)
{
	drmModeRes *res;

	drm_fd = drmOpen(module, NULL);
	if (drm_fd < 0)
		err(1, "drmOpen");

	if (kms_create(drm_fd, &kms) < 0)
		err(1, "kms_create");

	res = drmModeGetResources(drm_fd);
	if (!res)
		err(1, "drmModeGetResources");

	setup_screen(res);
}

static void wait_for_input(void)
{
	struct pollfd pfd = {
		.fd = 0,
		.events = POLLIN,
	};

	poll(&pfd, 1, -1);
}

int main(int argc, char *argv[])
{
	const char *module = "qxl";
	if (argc > 1)
		module = argv[1];

	setup_drm(module);
	setup_cursor();

	wait_for_input();

	return 0;
}

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
@ 2015-11-17 18:47               ` John Keeping
  0 siblings, 0 replies; 36+ messages in thread
From: John Keeping @ 2015-11-17 18:47 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: Maling list - DRI developers, Michel Dänzer, LKML

On Tue, 17 Nov 2015 19:31:32 +0100, Daniel Vetter wrote:

> On Tue, Nov 17, 2015 at 12:07:24PM -0500, Alex Deucher wrote:
> > On Tue, Nov 17, 2015 at 11:29 AM, Daniel Vetter <daniel@ffwll.ch>
> > wrote:  
> > > On Tue, Nov 17, 2015 at 03:59:43PM +0000, John Keeping wrote:  
> > >> On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
> > >>  
> > >> > On Tue, Nov 17, 2015 at 03:05:34PM +0000, John Keeping wrote:  
> > >> > > The request's hot_x and hot_y are set correctly for both
> > >> > > DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just
> > >> > > need to save the values and then apply the offset to the
> > >> > > cursor plane when the cursor moves.
> > >> > >
> > >> > > Signed-off-by: John Keeping <john@metanate.com>
> > >> > > ---
> > >> > > v2:
> > >> > >   - add kerneldoc for hot_x and hot_y in struct drm_crtc
> > >> > >
> > >> > >  drivers/gpu/drm/drm_crtc.c | 11 +++++++----
> > >> > >  include/drm/drm_crtc.h     |  6 ++++++
> > >> > >  2 files changed, 13 insertions(+), 4 deletions(-)
> > >> > >
> > >> > > diff --git a/drivers/gpu/drm/drm_crtc.c
> > >> > > b/drivers/gpu/drm/drm_crtc.c index 720a153..40f5b84 100644
> > >> > > --- a/drivers/gpu/drm/drm_crtc.c
> > >> > > +++ b/drivers/gpu/drm/drm_crtc.c
> > >> > > @@ -2831,6 +2831,9 @@ static int
> > >> > > drm_mode_cursor_universal(struct drm_crtc *crtc,
> > >> > > DRM_DEBUG_KMS("failed to wrap cursor buffer in drm
> > >> > > framebuffer\n"); return PTR_ERR(fb); }
> > >> > > +
> > >> > > +                 crtc->hot_x = req->hot_x;
> > >> > > +                 crtc->hot_y = req->hot_y;
> > >> > >           } else {
> > >> > >                   fb = NULL;
> > >> > >           }
> > >> > > @@ -2841,11 +2844,11 @@ static int
> > >> > > drm_mode_cursor_universal(struct drm_crtc *crtc, }
> > >> > >
> > >> > >   if (req->flags & DRM_MODE_CURSOR_MOVE) {
> > >> > > -         crtc_x = req->x;
> > >> > > -         crtc_y = req->y;
> > >> > > +         crtc_x = req->x - crtc->hot_x;
> > >> > > +         crtc_y = req->y - crtc->hot_y;
> > >> > >   } else {
> > >> > > -         crtc_x = crtc->cursor_x;
> > >> > > -         crtc_y = crtc->cursor_y;
> > >> > > +         crtc_x = crtc->cursor_x - crtc->hot_x;
> > >> > > +         crtc_y = crtc->cursor_y - crtc->hot_y;  
> > >> >
> > >> > Why does the location of the hotspot affect the plane
> > >> > position?  
> > >>
> > >> hot_{x,y} specify the location of the active pixel within the
> > >> cursor plane and cursor_{x,y} specify the location of the active
> > >> pixel on the display so we need to offset the plane position in
> > >> order for the active pixel to be in the correct place.  
> > >
> > > Nope, hot_x/y is just for virtual machines to indicate where the
> > > logical cursor position is within the cursor plane. It should
> > > have 2 effect on how something is displayed. And no, I have
> > > absolutely no idea why radeon is pulling some tricks here, which
> > > have been added in
> > >
> > > commit 78b1a6010b46a69bcd47b723a80f92693f26d17b
> > > Author: Michel Dänzer <michel.daenzer@amd.com>
> > > Date:   Tue Nov 18 18:00:08 2014 +0900
> > >
> > >     drm/radeon: Use cursor_set2 hook for enabling / disabling the
> > > HW cursor
> > >
> > > Michel/Alex, can you please shed some light onto this? radeon is
> > > the only driver doing this, making this interface inconsistent.
> > > Is the ddx doing something funny compared to -modeseting or
> > > weston?
> > >
> > > At least a quick look in the -ati sources didn't even show a user
> > > for this, it's still using the old cursor ioctl. And there's no
> > > other indication in the commit of a bug or anything. Can we
> > > perhaps just revert this?  
> > 
> > We use this is xf86-video-ati.  See:
> > http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=c9f8f642fd495937400618a4fc25ecae3f8888fc
> > Our hw cursor has a hotspot register that needs to be programmed for
> > proper operation.  I don't remember the details of the specific bug.
> > Michel can provide more info.  
> 
> Yeah I was blind and didn't spot this. But I can't find your hotspot
> cursor reg - it's only used to adjust the x/y offsets (similar to
> John's patch). And amdgpu doesn't do this at all, it's only
> radoen.ko. Still confused.

Having investigated a bit more, I think xserver handles the hotspot
itself without using the kernel hotspot handling and xorg-video-qxl
carefully reverses this in order to take advantage of
drmModeSetCursor2(), so with X11 drivers you don't notice that the
kernel handling of this is broken in nearly all drivers.

Here's a small test program that demonstrates whether or not cursor
hotspots work.  There should be a single colored pixel immediately to
the left of the pointer but with a broken driver the white pixel will be
64 pixels to the left of the pointer.

Compile with:

    cc -o test -I/usr/include/libdrm test.c -lkms -ldrm

-- >8 --
#include <err.h>
#include <poll.h>
#include <string.h>

#include <sys/mman.h>

#include <libkms/libkms.h>
#include <xf86drm.h>
#include <xf86drmMode.h>


static int drm_fd;
static int crtc_id = -1;
static drmModeModeInfo mode_info;
static struct kms_driver *kms;

static struct {
	int id;
	size_t size;
	unsigned char *data;
} framebuffer;

static struct {
	int x, y;
	struct kms_bo *buffer;
} cursor;

#define CURSOR_WIDTH	21
#define CURSOR_HEIGHT	21
#define CURSOR_HOT_X	21
#define CURSOR_HOT_Y	0
unsigned char cursor_data[] =
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\0\0\0\377\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377"
  "\377\377\377\377\377\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377\377\377\377"
  "\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377"
  "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\0\0\0\377"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377"
  "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\0\0\0\377\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377\377"
  "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\0\0\0\377\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377\377\377"
  "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377"
  "\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377\377"
  "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377"
  "\377\377\377\377\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377"
  "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377"
  "\377\377\377\377\377\377\377\377\377\377\377\377\0\0\0\377\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\0\0"
  "\0\377\0\0\0\377\0\0\0\377\0\0\0\377\377\377\377\377\377\377\377\377\377"
  "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\0\0\0\377\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377"
  "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\0\0\0\377"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377"
  "\0\0\0\377\0\0\0\377\377\377\377\377\377\377\377\377\0\0\0\377\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377\0\0\0\377\0\0\0"
  "\0\0\0\0\0\0\0\0\377\377\377\377\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\377\377\377\377\377\377\377\377\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377"
  "\377\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377\0\0\0\377\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377"
  "\377\377\377\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\377\0\0\0\377\377\377\377\377\0\0\0\377\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
  "\0\0\0\0\0\0\0\0\0\0\0\0\0";


static void draw_cursor(void)
{
	void *result;
	unsigned char *ptr;
	int x, y;
	if (kms_bo_map(cursor.buffer, &result))
		err(1, "kms_bo_map");

	ptr = result;
	memset(ptr, 0, 64 * 64 * 4);

	for (y = 0; y < CURSOR_HEIGHT; y++)
		memcpy(ptr + 64 * 4 * y, cursor_data + 4 * CURSOR_WIDTH * y, CURSOR_WIDTH * 4);

	kms_bo_unmap(cursor.buffer);
}

static void setup_cursor(void)
{
	const unsigned int attr[] = {
		KMS_BO_TYPE, KMS_BO_TYPE_CURSOR_64X64_A8R8G8B8,
		KMS_WIDTH, 64,
		KMS_HEIGHT, 64,
		KMS_TERMINATE_PROP_LIST
	};
	unsigned int handle;
	if (kms_bo_create(kms, attr, &cursor.buffer))
		err(1, "kms_bo_create");

	draw_cursor();

	if (kms_bo_get_prop(cursor.buffer, KMS_HANDLE, &handle))
		err(1, "kms_bo_get_prop");

	if (drmModeSetCursor2(drm_fd, crtc_id, handle, 64, 64, CURSOR_HOT_X, CURSOR_HOT_Y))
		err(1, "drmModeSetCursor2");

	if (drmModeMoveCursor(drm_fd, crtc_id, cursor.x, cursor.y))
		err(1, "drmModeMoveCursor");
}

static void create_framebuffer(void)
{
	struct drm_mode_create_dumb creq = {
		.width = mode_info.hdisplay,
		.height = mode_info.vdisplay,
		.bpp = 32,
		.flags = 0,
	};
	struct drm_mode_map_dumb mreq = { 0 };
	if (drmIoctl(drm_fd, DRM_IOCTL_MODE_CREATE_DUMB, &creq))
		err(1, "DRM_IOCTL_MODE_CREATE_DUMB");

	if (drmModeAddFB(drm_fd, creq.width, creq.height, 24, 32, creq.pitch, creq.handle, &framebuffer.id))
		err(1, "drmModeAddFB");

	mreq.handle = creq.handle;
	if (drmIoctl(drm_fd, DRM_IOCTL_MODE_MAP_DUMB, &mreq))
		err(1, "DRM_IOCTL_MODE_MAP_DUMB");

	framebuffer.data = mmap(0, creq.size, PROT_READ | PROT_WRITE, MAP_SHARED, drm_fd, mreq.offset);
	if (framebuffer.data == MAP_FAILED)
		err(1, "mmap");

	framebuffer.size = creq.size;
	memset(framebuffer.data, 0, framebuffer.size);

	/* Paint cursor location with a single colored pixel. */
	framebuffer.data[1 + cursor.x * 4 + cursor.y * creq.pitch] = '\xff';
	framebuffer.data[2 + cursor.x * 4 + cursor.y * creq.pitch] = '\xff';
}

static int setup_connector(drmModeConnector *conn, drmModeRes *res)
{
	drmModeModeInfo *mode = NULL;
	int i;

	if (conn->connection != DRM_MODE_CONNECTED)
		return -1;

	for (int j = 0; j < conn->count_modes; j++) {
		if (!mode || (conn->modes[j].type & DRM_MODE_TYPE_PREFERRED)) {
			mode = &conn->modes[j];
			if (conn->modes[j].type & DRM_MODE_TYPE_PREFERRED)
				break;
		}
	}

	if (!mode)
		return -1;

	for (i = 0; i < conn->count_encoders; i++) {
		int j;
		drmModeEncoder *enc = drmModeGetEncoder(drm_fd, conn->encoders[j]);
		if (!enc)
			continue;

		for (j = 0; j < res->count_crtcs; j++) {
			if (enc->possible_crtcs & (1u << j)) {
				crtc_id = res->crtcs[j];
				break;
			}
		}

		drmModeFreeEncoder(enc);
		if (crtc_id >= 0)
			break;
	}

	memcpy(&mode_info, mode, sizeof(mode_info));
	cursor.x = mode->hdisplay / 2;
	cursor.y = mode->vdisplay / 2;
	create_framebuffer();

	if (drmModeSetCrtc(drm_fd, crtc_id, framebuffer.id, 0, 0, &conn->connector_id, 1, mode))
		err(1, "drmModeSetCrtc");

	return 0;
}

static void setup_screen(drmModeRes *res)
{
	int i;

	for (i = 0; i < res->count_connectors; i++) {
		int result;
		drmModeConnector *conn = drmModeGetConnector(drm_fd, res->connectors[i]);
		if (!conn)
			continue;
		result = setup_connector(conn, res);
		drmModeFreeConnector(conn);
		if (!result)
			break;
	}

	if (crtc_id < 0)
		errx(1, "no screen found");
}

static void setup_drm(const char *module)
{
	drmModeRes *res;

	drm_fd = drmOpen(module, NULL);
	if (drm_fd < 0)
		err(1, "drmOpen");

	if (kms_create(drm_fd, &kms) < 0)
		err(1, "kms_create");

	res = drmModeGetResources(drm_fd);
	if (!res)
		err(1, "drmModeGetResources");

	setup_screen(res);
}

static void wait_for_input(void)
{
	struct pollfd pfd = {
		.fd = 0,
		.events = POLLIN,
	};

	poll(&pfd, 1, -1);
}

int main(int argc, char *argv[])
{
	const char *module = "qxl";
	if (argc > 1)
		module = argv[1];

	setup_drm(module);
	setup_cursor();

	wait_for_input();

	return 0;
}
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
  2015-11-17 18:47               ` John Keeping
@ 2015-11-17 19:11                 ` Daniel Vetter
  -1 siblings, 0 replies; 36+ messages in thread
From: Daniel Vetter @ 2015-11-17 19:11 UTC (permalink / raw)
  To: John Keeping
  Cc: Daniel Vetter, Alex Deucher, Ville Syrjälä,
	LKML, Maling list - DRI developers, Michel Dänzer

On Tue, Nov 17, 2015 at 06:47:28PM +0000, John Keeping wrote:
> On Tue, 17 Nov 2015 19:31:32 +0100, Daniel Vetter wrote:
> 
> > On Tue, Nov 17, 2015 at 12:07:24PM -0500, Alex Deucher wrote:
> > > On Tue, Nov 17, 2015 at 11:29 AM, Daniel Vetter <daniel@ffwll.ch>
> > > wrote:  
> > > > On Tue, Nov 17, 2015 at 03:59:43PM +0000, John Keeping wrote:  
> > > >> On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
> > > >>  
> > > >> > On Tue, Nov 17, 2015 at 03:05:34PM +0000, John Keeping wrote:  
> > > >> > > The request's hot_x and hot_y are set correctly for both
> > > >> > > DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just
> > > >> > > need to save the values and then apply the offset to the
> > > >> > > cursor plane when the cursor moves.
> > > >> > >
> > > >> > > Signed-off-by: John Keeping <john@metanate.com>
> > > >> > > ---
> > > >> > > v2:
> > > >> > >   - add kerneldoc for hot_x and hot_y in struct drm_crtc
> > > >> > >
> > > >> > >  drivers/gpu/drm/drm_crtc.c | 11 +++++++----
> > > >> > >  include/drm/drm_crtc.h     |  6 ++++++
> > > >> > >  2 files changed, 13 insertions(+), 4 deletions(-)
> > > >> > >
> > > >> > > diff --git a/drivers/gpu/drm/drm_crtc.c
> > > >> > > b/drivers/gpu/drm/drm_crtc.c index 720a153..40f5b84 100644
> > > >> > > --- a/drivers/gpu/drm/drm_crtc.c
> > > >> > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > >> > > @@ -2831,6 +2831,9 @@ static int
> > > >> > > drm_mode_cursor_universal(struct drm_crtc *crtc,
> > > >> > > DRM_DEBUG_KMS("failed to wrap cursor buffer in drm
> > > >> > > framebuffer\n"); return PTR_ERR(fb); }
> > > >> > > +
> > > >> > > +                 crtc->hot_x = req->hot_x;
> > > >> > > +                 crtc->hot_y = req->hot_y;
> > > >> > >           } else {
> > > >> > >                   fb = NULL;
> > > >> > >           }
> > > >> > > @@ -2841,11 +2844,11 @@ static int
> > > >> > > drm_mode_cursor_universal(struct drm_crtc *crtc, }
> > > >> > >
> > > >> > >   if (req->flags & DRM_MODE_CURSOR_MOVE) {
> > > >> > > -         crtc_x = req->x;
> > > >> > > -         crtc_y = req->y;
> > > >> > > +         crtc_x = req->x - crtc->hot_x;
> > > >> > > +         crtc_y = req->y - crtc->hot_y;
> > > >> > >   } else {
> > > >> > > -         crtc_x = crtc->cursor_x;
> > > >> > > -         crtc_y = crtc->cursor_y;
> > > >> > > +         crtc_x = crtc->cursor_x - crtc->hot_x;
> > > >> > > +         crtc_y = crtc->cursor_y - crtc->hot_y;  
> > > >> >
> > > >> > Why does the location of the hotspot affect the plane
> > > >> > position?  
> > > >>
> > > >> hot_{x,y} specify the location of the active pixel within the
> > > >> cursor plane and cursor_{x,y} specify the location of the active
> > > >> pixel on the display so we need to offset the plane position in
> > > >> order for the active pixel to be in the correct place.  
> > > >
> > > > Nope, hot_x/y is just for virtual machines to indicate where the
> > > > logical cursor position is within the cursor plane. It should
> > > > have 2 effect on how something is displayed. And no, I have
> > > > absolutely no idea why radeon is pulling some tricks here, which
> > > > have been added in
> > > >
> > > > commit 78b1a6010b46a69bcd47b723a80f92693f26d17b
> > > > Author: Michel Dänzer <michel.daenzer@amd.com>
> > > > Date:   Tue Nov 18 18:00:08 2014 +0900
> > > >
> > > >     drm/radeon: Use cursor_set2 hook for enabling / disabling the
> > > > HW cursor
> > > >
> > > > Michel/Alex, can you please shed some light onto this? radeon is
> > > > the only driver doing this, making this interface inconsistent.
> > > > Is the ddx doing something funny compared to -modeseting or
> > > > weston?
> > > >
> > > > At least a quick look in the -ati sources didn't even show a user
> > > > for this, it's still using the old cursor ioctl. And there's no
> > > > other indication in the commit of a bug or anything. Can we
> > > > perhaps just revert this?  
> > > 
> > > We use this is xf86-video-ati.  See:
> > > http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=c9f8f642fd495937400618a4fc25ecae3f8888fc
> > > Our hw cursor has a hotspot register that needs to be programmed for
> > > proper operation.  I don't remember the details of the specific bug.
> > > Michel can provide more info.  
> > 
> > Yeah I was blind and didn't spot this. But I can't find your hotspot
> > cursor reg - it's only used to adjust the x/y offsets (similar to
> > John's patch). And amdgpu doesn't do this at all, it's only
> > radoen.ko. Still confused.
> 
> Having investigated a bit more, I think xserver handles the hotspot
> itself without using the kernel hotspot handling and xorg-video-qxl
> carefully reverses this in order to take advantage of
> drmModeSetCursor2(), so with X11 drivers you don't notice that the
> kernel handling of this is broken in nearly all drivers.

Where did you spot this code in -qxl? Afaics it has the exact same copy of
the usual drmmode.c code as everyone else. No adjustments of x/yhot seems
to be going on there, nor in the qxl.ko kernel driver. Or at least I
didn't find it.

> Here's a small test program that demonstrates whether or not cursor
> hotspots work.  There should be a single colored pixel immediately to
> the left of the pointer but with a broken driver the white pixel will be
> 64 pixels to the left of the pointer.

Is there also a way to test this with X? In the end that's what will
matter for most end users, and if there's difference in behaviour in the
various X drivers we're really screwed (since essentially we can't ever
fix it properly for the legacy ioctl).
-Daniel

> 
> Compile with:
> 
>     cc -o test -I/usr/include/libdrm test.c -lkms -ldrm
> 
> -- >8 --
> #include <err.h>
> #include <poll.h>
> #include <string.h>
> 
> #include <sys/mman.h>
> 
> #include <libkms/libkms.h>
> #include <xf86drm.h>
> #include <xf86drmMode.h>
> 
> 
> static int drm_fd;
> static int crtc_id = -1;
> static drmModeModeInfo mode_info;
> static struct kms_driver *kms;
> 
> static struct {
> 	int id;
> 	size_t size;
> 	unsigned char *data;
> } framebuffer;
> 
> static struct {
> 	int x, y;
> 	struct kms_bo *buffer;
> } cursor;
> 
> #define CURSOR_WIDTH	21
> #define CURSOR_HEIGHT	21
> #define CURSOR_HOT_X	21
> #define CURSOR_HOT_Y	0
> unsigned char cursor_data[] =
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\0\0\0\377\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377"
>   "\377\377\377\377\377\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377\377\377\377"
>   "\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377"
>   "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\0\0\0\377"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377"
>   "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\0\0\0\377\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377\377"
>   "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\0\0\0\377\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377\377\377"
>   "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377"
>   "\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377\377"
>   "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377"
>   "\377\377\377\377\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377"
>   "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377"
>   "\377\377\377\377\377\377\377\377\377\377\377\377\0\0\0\377\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\0\0"
>   "\0\377\0\0\0\377\0\0\0\377\0\0\0\377\377\377\377\377\377\377\377\377\377"
>   "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\0\0\0\377\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377"
>   "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\0\0\0\377"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377"
>   "\0\0\0\377\0\0\0\377\377\377\377\377\377\377\377\377\0\0\0\377\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377\0\0\0\377\0\0\0"
>   "\0\0\0\0\0\0\0\0\377\377\377\377\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\377\377\377\377\377\377\377\377\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377"
>   "\377\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377\0\0\0\377\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377"
>   "\377\377\377\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\377\0\0\0\377\377\377\377\377\0\0\0\377\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0";
> 
> 
> static void draw_cursor(void)
> {
> 	void *result;
> 	unsigned char *ptr;
> 	int x, y;
> 	if (kms_bo_map(cursor.buffer, &result))
> 		err(1, "kms_bo_map");
> 
> 	ptr = result;
> 	memset(ptr, 0, 64 * 64 * 4);
> 
> 	for (y = 0; y < CURSOR_HEIGHT; y++)
> 		memcpy(ptr + 64 * 4 * y, cursor_data + 4 * CURSOR_WIDTH * y, CURSOR_WIDTH * 4);
> 
> 	kms_bo_unmap(cursor.buffer);
> }
> 
> static void setup_cursor(void)
> {
> 	const unsigned int attr[] = {
> 		KMS_BO_TYPE, KMS_BO_TYPE_CURSOR_64X64_A8R8G8B8,
> 		KMS_WIDTH, 64,
> 		KMS_HEIGHT, 64,
> 		KMS_TERMINATE_PROP_LIST
> 	};
> 	unsigned int handle;
> 	if (kms_bo_create(kms, attr, &cursor.buffer))
> 		err(1, "kms_bo_create");
> 
> 	draw_cursor();
> 
> 	if (kms_bo_get_prop(cursor.buffer, KMS_HANDLE, &handle))
> 		err(1, "kms_bo_get_prop");
> 
> 	if (drmModeSetCursor2(drm_fd, crtc_id, handle, 64, 64, CURSOR_HOT_X, CURSOR_HOT_Y))
> 		err(1, "drmModeSetCursor2");
> 
> 	if (drmModeMoveCursor(drm_fd, crtc_id, cursor.x, cursor.y))
> 		err(1, "drmModeMoveCursor");
> }
> 
> static void create_framebuffer(void)
> {
> 	struct drm_mode_create_dumb creq = {
> 		.width = mode_info.hdisplay,
> 		.height = mode_info.vdisplay,
> 		.bpp = 32,
> 		.flags = 0,
> 	};
> 	struct drm_mode_map_dumb mreq = { 0 };
> 	if (drmIoctl(drm_fd, DRM_IOCTL_MODE_CREATE_DUMB, &creq))
> 		err(1, "DRM_IOCTL_MODE_CREATE_DUMB");
> 
> 	if (drmModeAddFB(drm_fd, creq.width, creq.height, 24, 32, creq.pitch, creq.handle, &framebuffer.id))
> 		err(1, "drmModeAddFB");
> 
> 	mreq.handle = creq.handle;
> 	if (drmIoctl(drm_fd, DRM_IOCTL_MODE_MAP_DUMB, &mreq))
> 		err(1, "DRM_IOCTL_MODE_MAP_DUMB");
> 
> 	framebuffer.data = mmap(0, creq.size, PROT_READ | PROT_WRITE, MAP_SHARED, drm_fd, mreq.offset);
> 	if (framebuffer.data == MAP_FAILED)
> 		err(1, "mmap");
> 
> 	framebuffer.size = creq.size;
> 	memset(framebuffer.data, 0, framebuffer.size);
> 
> 	/* Paint cursor location with a single colored pixel. */
> 	framebuffer.data[1 + cursor.x * 4 + cursor.y * creq.pitch] = '\xff';
> 	framebuffer.data[2 + cursor.x * 4 + cursor.y * creq.pitch] = '\xff';
> }
> 
> static int setup_connector(drmModeConnector *conn, drmModeRes *res)
> {
> 	drmModeModeInfo *mode = NULL;
> 	int i;
> 
> 	if (conn->connection != DRM_MODE_CONNECTED)
> 		return -1;
> 
> 	for (int j = 0; j < conn->count_modes; j++) {
> 		if (!mode || (conn->modes[j].type & DRM_MODE_TYPE_PREFERRED)) {
> 			mode = &conn->modes[j];
> 			if (conn->modes[j].type & DRM_MODE_TYPE_PREFERRED)
> 				break;
> 		}
> 	}
> 
> 	if (!mode)
> 		return -1;
> 
> 	for (i = 0; i < conn->count_encoders; i++) {
> 		int j;
> 		drmModeEncoder *enc = drmModeGetEncoder(drm_fd, conn->encoders[j]);
> 		if (!enc)
> 			continue;
> 
> 		for (j = 0; j < res->count_crtcs; j++) {
> 			if (enc->possible_crtcs & (1u << j)) {
> 				crtc_id = res->crtcs[j];
> 				break;
> 			}
> 		}
> 
> 		drmModeFreeEncoder(enc);
> 		if (crtc_id >= 0)
> 			break;
> 	}
> 
> 	memcpy(&mode_info, mode, sizeof(mode_info));
> 	cursor.x = mode->hdisplay / 2;
> 	cursor.y = mode->vdisplay / 2;
> 	create_framebuffer();
> 
> 	if (drmModeSetCrtc(drm_fd, crtc_id, framebuffer.id, 0, 0, &conn->connector_id, 1, mode))
> 		err(1, "drmModeSetCrtc");
> 
> 	return 0;
> }
> 
> static void setup_screen(drmModeRes *res)
> {
> 	int i;
> 
> 	for (i = 0; i < res->count_connectors; i++) {
> 		int result;
> 		drmModeConnector *conn = drmModeGetConnector(drm_fd, res->connectors[i]);
> 		if (!conn)
> 			continue;
> 		result = setup_connector(conn, res);
> 		drmModeFreeConnector(conn);
> 		if (!result)
> 			break;
> 	}
> 
> 	if (crtc_id < 0)
> 		errx(1, "no screen found");
> }
> 
> static void setup_drm(const char *module)
> {
> 	drmModeRes *res;
> 
> 	drm_fd = drmOpen(module, NULL);
> 	if (drm_fd < 0)
> 		err(1, "drmOpen");
> 
> 	if (kms_create(drm_fd, &kms) < 0)
> 		err(1, "kms_create");
> 
> 	res = drmModeGetResources(drm_fd);
> 	if (!res)
> 		err(1, "drmModeGetResources");
> 
> 	setup_screen(res);
> }
> 
> static void wait_for_input(void)
> {
> 	struct pollfd pfd = {
> 		.fd = 0,
> 		.events = POLLIN,
> 	};
> 
> 	poll(&pfd, 1, -1);
> }
> 
> int main(int argc, char *argv[])
> {
> 	const char *module = "qxl";
> 	if (argc > 1)
> 		module = argv[1];
> 
> 	setup_drm(module);
> 	setup_cursor();
> 
> 	wait_for_input();
> 
> 	return 0;
> }

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
@ 2015-11-17 19:11                 ` Daniel Vetter
  0 siblings, 0 replies; 36+ messages in thread
From: Daniel Vetter @ 2015-11-17 19:11 UTC (permalink / raw)
  To: John Keeping; +Cc: Michel Dänzer, LKML, Maling list - DRI developers

On Tue, Nov 17, 2015 at 06:47:28PM +0000, John Keeping wrote:
> On Tue, 17 Nov 2015 19:31:32 +0100, Daniel Vetter wrote:
> 
> > On Tue, Nov 17, 2015 at 12:07:24PM -0500, Alex Deucher wrote:
> > > On Tue, Nov 17, 2015 at 11:29 AM, Daniel Vetter <daniel@ffwll.ch>
> > > wrote:  
> > > > On Tue, Nov 17, 2015 at 03:59:43PM +0000, John Keeping wrote:  
> > > >> On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
> > > >>  
> > > >> > On Tue, Nov 17, 2015 at 03:05:34PM +0000, John Keeping wrote:  
> > > >> > > The request's hot_x and hot_y are set correctly for both
> > > >> > > DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just
> > > >> > > need to save the values and then apply the offset to the
> > > >> > > cursor plane when the cursor moves.
> > > >> > >
> > > >> > > Signed-off-by: John Keeping <john@metanate.com>
> > > >> > > ---
> > > >> > > v2:
> > > >> > >   - add kerneldoc for hot_x and hot_y in struct drm_crtc
> > > >> > >
> > > >> > >  drivers/gpu/drm/drm_crtc.c | 11 +++++++----
> > > >> > >  include/drm/drm_crtc.h     |  6 ++++++
> > > >> > >  2 files changed, 13 insertions(+), 4 deletions(-)
> > > >> > >
> > > >> > > diff --git a/drivers/gpu/drm/drm_crtc.c
> > > >> > > b/drivers/gpu/drm/drm_crtc.c index 720a153..40f5b84 100644
> > > >> > > --- a/drivers/gpu/drm/drm_crtc.c
> > > >> > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > >> > > @@ -2831,6 +2831,9 @@ static int
> > > >> > > drm_mode_cursor_universal(struct drm_crtc *crtc,
> > > >> > > DRM_DEBUG_KMS("failed to wrap cursor buffer in drm
> > > >> > > framebuffer\n"); return PTR_ERR(fb); }
> > > >> > > +
> > > >> > > +                 crtc->hot_x = req->hot_x;
> > > >> > > +                 crtc->hot_y = req->hot_y;
> > > >> > >           } else {
> > > >> > >                   fb = NULL;
> > > >> > >           }
> > > >> > > @@ -2841,11 +2844,11 @@ static int
> > > >> > > drm_mode_cursor_universal(struct drm_crtc *crtc, }
> > > >> > >
> > > >> > >   if (req->flags & DRM_MODE_CURSOR_MOVE) {
> > > >> > > -         crtc_x = req->x;
> > > >> > > -         crtc_y = req->y;
> > > >> > > +         crtc_x = req->x - crtc->hot_x;
> > > >> > > +         crtc_y = req->y - crtc->hot_y;
> > > >> > >   } else {
> > > >> > > -         crtc_x = crtc->cursor_x;
> > > >> > > -         crtc_y = crtc->cursor_y;
> > > >> > > +         crtc_x = crtc->cursor_x - crtc->hot_x;
> > > >> > > +         crtc_y = crtc->cursor_y - crtc->hot_y;  
> > > >> >
> > > >> > Why does the location of the hotspot affect the plane
> > > >> > position?  
> > > >>
> > > >> hot_{x,y} specify the location of the active pixel within the
> > > >> cursor plane and cursor_{x,y} specify the location of the active
> > > >> pixel on the display so we need to offset the plane position in
> > > >> order for the active pixel to be in the correct place.  
> > > >
> > > > Nope, hot_x/y is just for virtual machines to indicate where the
> > > > logical cursor position is within the cursor plane. It should
> > > > have 2 effect on how something is displayed. And no, I have
> > > > absolutely no idea why radeon is pulling some tricks here, which
> > > > have been added in
> > > >
> > > > commit 78b1a6010b46a69bcd47b723a80f92693f26d17b
> > > > Author: Michel Dänzer <michel.daenzer@amd.com>
> > > > Date:   Tue Nov 18 18:00:08 2014 +0900
> > > >
> > > >     drm/radeon: Use cursor_set2 hook for enabling / disabling the
> > > > HW cursor
> > > >
> > > > Michel/Alex, can you please shed some light onto this? radeon is
> > > > the only driver doing this, making this interface inconsistent.
> > > > Is the ddx doing something funny compared to -modeseting or
> > > > weston?
> > > >
> > > > At least a quick look in the -ati sources didn't even show a user
> > > > for this, it's still using the old cursor ioctl. And there's no
> > > > other indication in the commit of a bug or anything. Can we
> > > > perhaps just revert this?  
> > > 
> > > We use this is xf86-video-ati.  See:
> > > http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=c9f8f642fd495937400618a4fc25ecae3f8888fc
> > > Our hw cursor has a hotspot register that needs to be programmed for
> > > proper operation.  I don't remember the details of the specific bug.
> > > Michel can provide more info.  
> > 
> > Yeah I was blind and didn't spot this. But I can't find your hotspot
> > cursor reg - it's only used to adjust the x/y offsets (similar to
> > John's patch). And amdgpu doesn't do this at all, it's only
> > radoen.ko. Still confused.
> 
> Having investigated a bit more, I think xserver handles the hotspot
> itself without using the kernel hotspot handling and xorg-video-qxl
> carefully reverses this in order to take advantage of
> drmModeSetCursor2(), so with X11 drivers you don't notice that the
> kernel handling of this is broken in nearly all drivers.

Where did you spot this code in -qxl? Afaics it has the exact same copy of
the usual drmmode.c code as everyone else. No adjustments of x/yhot seems
to be going on there, nor in the qxl.ko kernel driver. Or at least I
didn't find it.

> Here's a small test program that demonstrates whether or not cursor
> hotspots work.  There should be a single colored pixel immediately to
> the left of the pointer but with a broken driver the white pixel will be
> 64 pixels to the left of the pointer.

Is there also a way to test this with X? In the end that's what will
matter for most end users, and if there's difference in behaviour in the
various X drivers we're really screwed (since essentially we can't ever
fix it properly for the legacy ioctl).
-Daniel

> 
> Compile with:
> 
>     cc -o test -I/usr/include/libdrm test.c -lkms -ldrm
> 
> -- >8 --
> #include <err.h>
> #include <poll.h>
> #include <string.h>
> 
> #include <sys/mman.h>
> 
> #include <libkms/libkms.h>
> #include <xf86drm.h>
> #include <xf86drmMode.h>
> 
> 
> static int drm_fd;
> static int crtc_id = -1;
> static drmModeModeInfo mode_info;
> static struct kms_driver *kms;
> 
> static struct {
> 	int id;
> 	size_t size;
> 	unsigned char *data;
> } framebuffer;
> 
> static struct {
> 	int x, y;
> 	struct kms_bo *buffer;
> } cursor;
> 
> #define CURSOR_WIDTH	21
> #define CURSOR_HEIGHT	21
> #define CURSOR_HOT_X	21
> #define CURSOR_HOT_Y	0
> unsigned char cursor_data[] =
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\0\0\0\377\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377"
>   "\377\377\377\377\377\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377\377\377\377"
>   "\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377"
>   "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\0\0\0\377"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377"
>   "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\0\0\0\377\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377\377"
>   "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\0\0\0\377\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377\377\377"
>   "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377"
>   "\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377\377"
>   "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377"
>   "\377\377\377\377\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377"
>   "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377"
>   "\377\377\377\377\377\377\377\377\377\377\377\377\0\0\0\377\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\0\0"
>   "\0\377\0\0\0\377\0\0\0\377\0\0\0\377\377\377\377\377\377\377\377\377\377"
>   "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\0\0\0\377\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377"
>   "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\0\0\0\377"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377"
>   "\0\0\0\377\0\0\0\377\377\377\377\377\377\377\377\377\0\0\0\377\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377\0\0\0\377\0\0\0"
>   "\0\0\0\0\0\0\0\0\377\377\377\377\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\377\377\377\377\377\377\377\377\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377"
>   "\377\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\377\0\0\0\377\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377"
>   "\377\377\377\377\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\377\0\0\0\377\377\377\377\377\0\0\0\377\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>   "\0\0\0\0\0\0\0\0\0\0\0\0\0";
> 
> 
> static void draw_cursor(void)
> {
> 	void *result;
> 	unsigned char *ptr;
> 	int x, y;
> 	if (kms_bo_map(cursor.buffer, &result))
> 		err(1, "kms_bo_map");
> 
> 	ptr = result;
> 	memset(ptr, 0, 64 * 64 * 4);
> 
> 	for (y = 0; y < CURSOR_HEIGHT; y++)
> 		memcpy(ptr + 64 * 4 * y, cursor_data + 4 * CURSOR_WIDTH * y, CURSOR_WIDTH * 4);
> 
> 	kms_bo_unmap(cursor.buffer);
> }
> 
> static void setup_cursor(void)
> {
> 	const unsigned int attr[] = {
> 		KMS_BO_TYPE, KMS_BO_TYPE_CURSOR_64X64_A8R8G8B8,
> 		KMS_WIDTH, 64,
> 		KMS_HEIGHT, 64,
> 		KMS_TERMINATE_PROP_LIST
> 	};
> 	unsigned int handle;
> 	if (kms_bo_create(kms, attr, &cursor.buffer))
> 		err(1, "kms_bo_create");
> 
> 	draw_cursor();
> 
> 	if (kms_bo_get_prop(cursor.buffer, KMS_HANDLE, &handle))
> 		err(1, "kms_bo_get_prop");
> 
> 	if (drmModeSetCursor2(drm_fd, crtc_id, handle, 64, 64, CURSOR_HOT_X, CURSOR_HOT_Y))
> 		err(1, "drmModeSetCursor2");
> 
> 	if (drmModeMoveCursor(drm_fd, crtc_id, cursor.x, cursor.y))
> 		err(1, "drmModeMoveCursor");
> }
> 
> static void create_framebuffer(void)
> {
> 	struct drm_mode_create_dumb creq = {
> 		.width = mode_info.hdisplay,
> 		.height = mode_info.vdisplay,
> 		.bpp = 32,
> 		.flags = 0,
> 	};
> 	struct drm_mode_map_dumb mreq = { 0 };
> 	if (drmIoctl(drm_fd, DRM_IOCTL_MODE_CREATE_DUMB, &creq))
> 		err(1, "DRM_IOCTL_MODE_CREATE_DUMB");
> 
> 	if (drmModeAddFB(drm_fd, creq.width, creq.height, 24, 32, creq.pitch, creq.handle, &framebuffer.id))
> 		err(1, "drmModeAddFB");
> 
> 	mreq.handle = creq.handle;
> 	if (drmIoctl(drm_fd, DRM_IOCTL_MODE_MAP_DUMB, &mreq))
> 		err(1, "DRM_IOCTL_MODE_MAP_DUMB");
> 
> 	framebuffer.data = mmap(0, creq.size, PROT_READ | PROT_WRITE, MAP_SHARED, drm_fd, mreq.offset);
> 	if (framebuffer.data == MAP_FAILED)
> 		err(1, "mmap");
> 
> 	framebuffer.size = creq.size;
> 	memset(framebuffer.data, 0, framebuffer.size);
> 
> 	/* Paint cursor location with a single colored pixel. */
> 	framebuffer.data[1 + cursor.x * 4 + cursor.y * creq.pitch] = '\xff';
> 	framebuffer.data[2 + cursor.x * 4 + cursor.y * creq.pitch] = '\xff';
> }
> 
> static int setup_connector(drmModeConnector *conn, drmModeRes *res)
> {
> 	drmModeModeInfo *mode = NULL;
> 	int i;
> 
> 	if (conn->connection != DRM_MODE_CONNECTED)
> 		return -1;
> 
> 	for (int j = 0; j < conn->count_modes; j++) {
> 		if (!mode || (conn->modes[j].type & DRM_MODE_TYPE_PREFERRED)) {
> 			mode = &conn->modes[j];
> 			if (conn->modes[j].type & DRM_MODE_TYPE_PREFERRED)
> 				break;
> 		}
> 	}
> 
> 	if (!mode)
> 		return -1;
> 
> 	for (i = 0; i < conn->count_encoders; i++) {
> 		int j;
> 		drmModeEncoder *enc = drmModeGetEncoder(drm_fd, conn->encoders[j]);
> 		if (!enc)
> 			continue;
> 
> 		for (j = 0; j < res->count_crtcs; j++) {
> 			if (enc->possible_crtcs & (1u << j)) {
> 				crtc_id = res->crtcs[j];
> 				break;
> 			}
> 		}
> 
> 		drmModeFreeEncoder(enc);
> 		if (crtc_id >= 0)
> 			break;
> 	}
> 
> 	memcpy(&mode_info, mode, sizeof(mode_info));
> 	cursor.x = mode->hdisplay / 2;
> 	cursor.y = mode->vdisplay / 2;
> 	create_framebuffer();
> 
> 	if (drmModeSetCrtc(drm_fd, crtc_id, framebuffer.id, 0, 0, &conn->connector_id, 1, mode))
> 		err(1, "drmModeSetCrtc");
> 
> 	return 0;
> }
> 
> static void setup_screen(drmModeRes *res)
> {
> 	int i;
> 
> 	for (i = 0; i < res->count_connectors; i++) {
> 		int result;
> 		drmModeConnector *conn = drmModeGetConnector(drm_fd, res->connectors[i]);
> 		if (!conn)
> 			continue;
> 		result = setup_connector(conn, res);
> 		drmModeFreeConnector(conn);
> 		if (!result)
> 			break;
> 	}
> 
> 	if (crtc_id < 0)
> 		errx(1, "no screen found");
> }
> 
> static void setup_drm(const char *module)
> {
> 	drmModeRes *res;
> 
> 	drm_fd = drmOpen(module, NULL);
> 	if (drm_fd < 0)
> 		err(1, "drmOpen");
> 
> 	if (kms_create(drm_fd, &kms) < 0)
> 		err(1, "kms_create");
> 
> 	res = drmModeGetResources(drm_fd);
> 	if (!res)
> 		err(1, "drmModeGetResources");
> 
> 	setup_screen(res);
> }
> 
> static void wait_for_input(void)
> {
> 	struct pollfd pfd = {
> 		.fd = 0,
> 		.events = POLLIN,
> 	};
> 
> 	poll(&pfd, 1, -1);
> }
> 
> int main(int argc, char *argv[])
> {
> 	const char *module = "qxl";
> 	if (argc > 1)
> 		module = argv[1];
> 
> 	setup_drm(module);
> 	setup_cursor();
> 
> 	wait_for_input();
> 
> 	return 0;
> }

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
  2015-11-17 18:40             ` Daniel Vetter
@ 2015-11-17 19:11               ` Alex Deucher
  -1 siblings, 0 replies; 36+ messages in thread
From: Alex Deucher @ 2015-11-17 19:11 UTC (permalink / raw)
  To: John Keeping, Ville Syrjälä,
	LKML, Maling list - DRI developers, Michel Dänzer,
	Alex Deucher
  Cc: Daniel Vetter

On Tue, Nov 17, 2015 at 1:40 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Nov 17, 2015 at 04:58:06PM +0000, John Keeping wrote:
>> On Tue, 17 Nov 2015 17:29:35 +0100, Daniel Vetter wrote:
>>
>> > On Tue, Nov 17, 2015 at 03:59:43PM +0000, John Keeping wrote:
>> > > On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
>> > >
>> > > > On Tue, Nov 17, 2015 at 03:05:34PM +0000, John Keeping wrote:
>> > > > > The request's hot_x and hot_y are set correctly for both
>> > > > > DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just
>> > > > > need to save the values and then apply the offset to the cursor
>> > > > > plane when the cursor moves.
>> > > > >
>> > > > > Signed-off-by: John Keeping <john@metanate.com>
>> > > > > ---
>> > > > > v2:
>> > > > >   - add kerneldoc for hot_x and hot_y in struct drm_crtc
>> > > > >
>> > > > >  drivers/gpu/drm/drm_crtc.c | 11 +++++++----
>> > > > >  include/drm/drm_crtc.h     |  6 ++++++
>> > > > >  2 files changed, 13 insertions(+), 4 deletions(-)
>> > > > >
>> > > > > diff --git a/drivers/gpu/drm/drm_crtc.c
>> > > > > b/drivers/gpu/drm/drm_crtc.c index 720a153..40f5b84 100644
>> > > > > --- a/drivers/gpu/drm/drm_crtc.c
>> > > > > +++ b/drivers/gpu/drm/drm_crtc.c
>> > > > > @@ -2831,6 +2831,9 @@ static int
>> > > > > drm_mode_cursor_universal(struct drm_crtc *crtc,
>> > > > > DRM_DEBUG_KMS("failed to wrap cursor buffer in drm
>> > > > > framebuffer\n"); return PTR_ERR(fb); }
>> > > > > +
>> > > > > +                     crtc->hot_x = req->hot_x;
>> > > > > +                     crtc->hot_y = req->hot_y;
>> > > > >               } else {
>> > > > >                       fb = NULL;
>> > > > >               }
>> > > > > @@ -2841,11 +2844,11 @@ static int
>> > > > > drm_mode_cursor_universal(struct drm_crtc *crtc, }
>> > > > >
>> > > > >       if (req->flags & DRM_MODE_CURSOR_MOVE) {
>> > > > > -             crtc_x = req->x;
>> > > > > -             crtc_y = req->y;
>> > > > > +             crtc_x = req->x - crtc->hot_x;
>> > > > > +             crtc_y = req->y - crtc->hot_y;
>> > > > >       } else {
>> > > > > -             crtc_x = crtc->cursor_x;
>> > > > > -             crtc_y = crtc->cursor_y;
>> > > > > +             crtc_x = crtc->cursor_x - crtc->hot_x;
>> > > > > +             crtc_y = crtc->cursor_y - crtc->hot_y;
>> > > >
>> > > > Why does the location of the hotspot affect the plane position?
>> > >
>> > > hot_{x,y} specify the location of the active pixel within the cursor
>> > > plane and cursor_{x,y} specify the location of the active pixel on
>> > > the display so we need to offset the plane position in order for
>> > > the active pixel to be in the correct place.
>> >
>> > Nope, hot_x/y is just for virtual machines to indicate where the
>> > logical cursor position is within the cursor plane. It should have 2
>> > effect on how something is displayed.
>>
>> Hmm... I've run the same client code on QXL and Rockchip (which uses
>> universal planes) and without this patch the behaviour is just plain
>> wrong on Rockchip.
>>
>> With a 32x32 cursor with the hotspot in the bottom-right using:
>>
>>     drmModeSetCursor2(..., 0, 32)
>>     drmModeMoveCursor(..., x, y)
>>
>> then with QXL when I click I get an event at (x, y) and this is
>> precisely under the bottom-right of the cursor.
>>
>> With Rockchip the click appears to happen at the top-left of the cursor
>> (as if the hotspot were (0, 0)).  This patch makes the behaviour match
>> that on QXL.
>>
>> I can't see how the hotspot can be ignored here unless you're saying
>> that the client code needs to offset the cursor position by the hotspot,
>> but in that case it will quite clearly be wrong on QXL.
>
> I checked a bunch of X drivers and none of them adjust for the hotspot.
> Also i915.ko always used x/y directly and never adjusted for the hotspot.
> And as far as generic kms interfaces go i915 is pretty much the standard,
> and that is what's been implemented in universal planes.
>
> The only exception really seems to be radeon.ko, which does adjust the x/y
> position of the cursor in the crtc space like your patch does above.

radeon hw has had the hotspot register since r5xx.
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/radeon/radeon_cursor.c#n204

amdgpu programs it as well:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c#n2440

Alex


>
> How can I test cursor hotspots? In the end we want a) something consistent
> b) that doesn't break existing code and unfortunately b) trumps a). So I'd
> like to figure out what's going on on the amd/intel hw I have here.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
@ 2015-11-17 19:11               ` Alex Deucher
  0 siblings, 0 replies; 36+ messages in thread
From: Alex Deucher @ 2015-11-17 19:11 UTC (permalink / raw)
  To: John Keeping, Ville Syrjälä,
	LKML, Maling list - DRI developers, Michel Dänzer,
	Alex Deucher

On Tue, Nov 17, 2015 at 1:40 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Nov 17, 2015 at 04:58:06PM +0000, John Keeping wrote:
>> On Tue, 17 Nov 2015 17:29:35 +0100, Daniel Vetter wrote:
>>
>> > On Tue, Nov 17, 2015 at 03:59:43PM +0000, John Keeping wrote:
>> > > On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
>> > >
>> > > > On Tue, Nov 17, 2015 at 03:05:34PM +0000, John Keeping wrote:
>> > > > > The request's hot_x and hot_y are set correctly for both
>> > > > > DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just
>> > > > > need to save the values and then apply the offset to the cursor
>> > > > > plane when the cursor moves.
>> > > > >
>> > > > > Signed-off-by: John Keeping <john@metanate.com>
>> > > > > ---
>> > > > > v2:
>> > > > >   - add kerneldoc for hot_x and hot_y in struct drm_crtc
>> > > > >
>> > > > >  drivers/gpu/drm/drm_crtc.c | 11 +++++++----
>> > > > >  include/drm/drm_crtc.h     |  6 ++++++
>> > > > >  2 files changed, 13 insertions(+), 4 deletions(-)
>> > > > >
>> > > > > diff --git a/drivers/gpu/drm/drm_crtc.c
>> > > > > b/drivers/gpu/drm/drm_crtc.c index 720a153..40f5b84 100644
>> > > > > --- a/drivers/gpu/drm/drm_crtc.c
>> > > > > +++ b/drivers/gpu/drm/drm_crtc.c
>> > > > > @@ -2831,6 +2831,9 @@ static int
>> > > > > drm_mode_cursor_universal(struct drm_crtc *crtc,
>> > > > > DRM_DEBUG_KMS("failed to wrap cursor buffer in drm
>> > > > > framebuffer\n"); return PTR_ERR(fb); }
>> > > > > +
>> > > > > +                     crtc->hot_x = req->hot_x;
>> > > > > +                     crtc->hot_y = req->hot_y;
>> > > > >               } else {
>> > > > >                       fb = NULL;
>> > > > >               }
>> > > > > @@ -2841,11 +2844,11 @@ static int
>> > > > > drm_mode_cursor_universal(struct drm_crtc *crtc, }
>> > > > >
>> > > > >       if (req->flags & DRM_MODE_CURSOR_MOVE) {
>> > > > > -             crtc_x = req->x;
>> > > > > -             crtc_y = req->y;
>> > > > > +             crtc_x = req->x - crtc->hot_x;
>> > > > > +             crtc_y = req->y - crtc->hot_y;
>> > > > >       } else {
>> > > > > -             crtc_x = crtc->cursor_x;
>> > > > > -             crtc_y = crtc->cursor_y;
>> > > > > +             crtc_x = crtc->cursor_x - crtc->hot_x;
>> > > > > +             crtc_y = crtc->cursor_y - crtc->hot_y;
>> > > >
>> > > > Why does the location of the hotspot affect the plane position?
>> > >
>> > > hot_{x,y} specify the location of the active pixel within the cursor
>> > > plane and cursor_{x,y} specify the location of the active pixel on
>> > > the display so we need to offset the plane position in order for
>> > > the active pixel to be in the correct place.
>> >
>> > Nope, hot_x/y is just for virtual machines to indicate where the
>> > logical cursor position is within the cursor plane. It should have 2
>> > effect on how something is displayed.
>>
>> Hmm... I've run the same client code on QXL and Rockchip (which uses
>> universal planes) and without this patch the behaviour is just plain
>> wrong on Rockchip.
>>
>> With a 32x32 cursor with the hotspot in the bottom-right using:
>>
>>     drmModeSetCursor2(..., 0, 32)
>>     drmModeMoveCursor(..., x, y)
>>
>> then with QXL when I click I get an event at (x, y) and this is
>> precisely under the bottom-right of the cursor.
>>
>> With Rockchip the click appears to happen at the top-left of the cursor
>> (as if the hotspot were (0, 0)).  This patch makes the behaviour match
>> that on QXL.
>>
>> I can't see how the hotspot can be ignored here unless you're saying
>> that the client code needs to offset the cursor position by the hotspot,
>> but in that case it will quite clearly be wrong on QXL.
>
> I checked a bunch of X drivers and none of them adjust for the hotspot.
> Also i915.ko always used x/y directly and never adjusted for the hotspot.
> And as far as generic kms interfaces go i915 is pretty much the standard,
> and that is what's been implemented in universal planes.
>
> The only exception really seems to be radeon.ko, which does adjust the x/y
> position of the cursor in the crtc space like your patch does above.

radeon hw has had the hotspot register since r5xx.
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/radeon/radeon_cursor.c#n204

amdgpu programs it as well:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c#n2440

Alex


>
> How can I test cursor hotspots? In the end we want a) something consistent
> b) that doesn't break existing code and unfortunately b) trumps a). So I'd
> like to figure out what's going on on the amd/intel hw I have here.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
  2015-11-17 16:29         ` Daniel Vetter
@ 2015-11-18  8:39           ` Michel Dänzer
  -1 siblings, 0 replies; 36+ messages in thread
From: Michel Dänzer @ 2015-11-18  8:39 UTC (permalink / raw)
  To: John Keeping, Ville Syrjälä, Alex Deucher
  Cc: linux-kernel, dri-devel

On 18.11.2015 01:29, Daniel Vetter wrote:
> On Tue, Nov 17, 2015 at 03:59:43PM +0000, John Keeping wrote:
>> On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
>>
>>> On Tue, Nov 17, 2015 at 03:05:34PM +0000, John Keeping wrote:
>>>> The request's hot_x and hot_y are set correctly for both
>>>> DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just need to
>>>> save the values and then apply the offset to the cursor plane when
>>>> the cursor moves.
>>>>
>>>> Signed-off-by: John Keeping <john@metanate.com>
>>>> ---
>>>> v2:
>>>>   - add kerneldoc for hot_x and hot_y in struct drm_crtc
>>>>
>>>>  drivers/gpu/drm/drm_crtc.c | 11 +++++++----
>>>>  include/drm/drm_crtc.h     |  6 ++++++
>>>>  2 files changed, 13 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>>>> index 720a153..40f5b84 100644
>>>> --- a/drivers/gpu/drm/drm_crtc.c
>>>> +++ b/drivers/gpu/drm/drm_crtc.c
>>>> @@ -2831,6 +2831,9 @@ static int drm_mode_cursor_universal(struct
>>>> drm_crtc *crtc, DRM_DEBUG_KMS("failed to wrap cursor buffer in drm
>>>> framebuffer\n"); return PTR_ERR(fb);
>>>>  			}
>>>> +
>>>> +			crtc->hot_x = req->hot_x;
>>>> +			crtc->hot_y = req->hot_y;
>>>>  		} else {
>>>>  			fb = NULL;
>>>>  		}
>>>> @@ -2841,11 +2844,11 @@ static int drm_mode_cursor_universal(struct
>>>> drm_crtc *crtc, }
>>>>  
>>>>  	if (req->flags & DRM_MODE_CURSOR_MOVE) {
>>>> -		crtc_x = req->x;
>>>> -		crtc_y = req->y;
>>>> +		crtc_x = req->x - crtc->hot_x;
>>>> +		crtc_y = req->y - crtc->hot_y;
>>>>  	} else {
>>>> -		crtc_x = crtc->cursor_x;
>>>> -		crtc_y = crtc->cursor_y;
>>>> +		crtc_x = crtc->cursor_x - crtc->hot_x;
>>>> +		crtc_y = crtc->cursor_y - crtc->hot_y;  
>>>
>>> Why does the location of the hotspot affect the plane position?
>>
>> hot_{x,y} specify the location of the active pixel within the cursor
>> plane and cursor_{x,y} specify the location of the active pixel on the
>> display so we need to offset the plane position in order for the active
>> pixel to be in the correct place.
> 
> Nope, hot_x/y is just for virtual machines to indicate where the logical
> cursor position is within the cursor plane. It should have 2 effect on how
> something is displayed.

Agreed: Since the DRM_IOCTL_MODE_CURSOR ioctl doesn't contain any
information about the hotspot, the x/y coordinates passed in the
DRM_IOCTL_MODE_CURSOR(2) ioctls can only refer to the position of the
top left corner of the cursor.


> And no, I have absolutely no idea why radeon is pulling some tricks here,
> which have been added in
> 
> commit 78b1a6010b46a69bcd47b723a80f92693f26d17b
> Author: Michel Dänzer <michel.daenzer@amd.com>
> Date:   Tue Nov 18 18:00:08 2014 +0900
> 
>     drm/radeon: Use cursor_set2 hook for enabling / disabling the HW cursor
> 
> Michel/Alex, can you please shed some light onto this?

As described in the rest of the commit log, the intention was to avoid
the cursor intermittently appearing in the wrong location with existing
userspace which sets the cursor BO in one ioctl call and the new
position in another ioctl call.


> radeon is the only driver doing this, making this interface inconsistent.

It's only inconsistent in the case that userspace updates the cursor
position to account for the new hotspot position in one ioctl call
first, and only then sets the new BO in another ioctl call. In all other
cases, the cursor position passed in by userspace is preserved.

Anyway, in the meantime it has become apparent that this change didn't
fully fix the problem, so feel free to revert it.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
@ 2015-11-18  8:39           ` Michel Dänzer
  0 siblings, 0 replies; 36+ messages in thread
From: Michel Dänzer @ 2015-11-18  8:39 UTC (permalink / raw)
  To: John Keeping, Ville Syrjälä, Alex Deucher
  Cc: linux-kernel, dri-devel

On 18.11.2015 01:29, Daniel Vetter wrote:
> On Tue, Nov 17, 2015 at 03:59:43PM +0000, John Keeping wrote:
>> On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
>>
>>> On Tue, Nov 17, 2015 at 03:05:34PM +0000, John Keeping wrote:
>>>> The request's hot_x and hot_y are set correctly for both
>>>> DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just need to
>>>> save the values and then apply the offset to the cursor plane when
>>>> the cursor moves.
>>>>
>>>> Signed-off-by: John Keeping <john@metanate.com>
>>>> ---
>>>> v2:
>>>>   - add kerneldoc for hot_x and hot_y in struct drm_crtc
>>>>
>>>>  drivers/gpu/drm/drm_crtc.c | 11 +++++++----
>>>>  include/drm/drm_crtc.h     |  6 ++++++
>>>>  2 files changed, 13 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>>>> index 720a153..40f5b84 100644
>>>> --- a/drivers/gpu/drm/drm_crtc.c
>>>> +++ b/drivers/gpu/drm/drm_crtc.c
>>>> @@ -2831,6 +2831,9 @@ static int drm_mode_cursor_universal(struct
>>>> drm_crtc *crtc, DRM_DEBUG_KMS("failed to wrap cursor buffer in drm
>>>> framebuffer\n"); return PTR_ERR(fb);
>>>>  			}
>>>> +
>>>> +			crtc->hot_x = req->hot_x;
>>>> +			crtc->hot_y = req->hot_y;
>>>>  		} else {
>>>>  			fb = NULL;
>>>>  		}
>>>> @@ -2841,11 +2844,11 @@ static int drm_mode_cursor_universal(struct
>>>> drm_crtc *crtc, }
>>>>  
>>>>  	if (req->flags & DRM_MODE_CURSOR_MOVE) {
>>>> -		crtc_x = req->x;
>>>> -		crtc_y = req->y;
>>>> +		crtc_x = req->x - crtc->hot_x;
>>>> +		crtc_y = req->y - crtc->hot_y;
>>>>  	} else {
>>>> -		crtc_x = crtc->cursor_x;
>>>> -		crtc_y = crtc->cursor_y;
>>>> +		crtc_x = crtc->cursor_x - crtc->hot_x;
>>>> +		crtc_y = crtc->cursor_y - crtc->hot_y;  
>>>
>>> Why does the location of the hotspot affect the plane position?
>>
>> hot_{x,y} specify the location of the active pixel within the cursor
>> plane and cursor_{x,y} specify the location of the active pixel on the
>> display so we need to offset the plane position in order for the active
>> pixel to be in the correct place.
> 
> Nope, hot_x/y is just for virtual machines to indicate where the logical
> cursor position is within the cursor plane. It should have 2 effect on how
> something is displayed.

Agreed: Since the DRM_IOCTL_MODE_CURSOR ioctl doesn't contain any
information about the hotspot, the x/y coordinates passed in the
DRM_IOCTL_MODE_CURSOR(2) ioctls can only refer to the position of the
top left corner of the cursor.


> And no, I have absolutely no idea why radeon is pulling some tricks here,
> which have been added in
> 
> commit 78b1a6010b46a69bcd47b723a80f92693f26d17b
> Author: Michel Dänzer <michel.daenzer@amd.com>
> Date:   Tue Nov 18 18:00:08 2014 +0900
> 
>     drm/radeon: Use cursor_set2 hook for enabling / disabling the HW cursor
> 
> Michel/Alex, can you please shed some light onto this?

As described in the rest of the commit log, the intention was to avoid
the cursor intermittently appearing in the wrong location with existing
userspace which sets the cursor BO in one ioctl call and the new
position in another ioctl call.


> radeon is the only driver doing this, making this interface inconsistent.

It's only inconsistent in the case that userspace updates the cursor
position to account for the new hotspot position in one ioctl call
first, and only then sets the new BO in another ioctl call. In all other
cases, the cursor position passed in by userspace is preserved.

Anyway, in the meantime it has become apparent that this change didn't
fully fix the problem, so feel free to revert it.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
  2015-11-18  8:39           ` Michel Dänzer
@ 2015-11-18  8:51             ` Daniel Vetter
  -1 siblings, 0 replies; 36+ messages in thread
From: Daniel Vetter @ 2015-11-18  8:51 UTC (permalink / raw)
  To: Michel Dänzer
  Cc: John Keeping, Ville Syrjälä,
	Alex Deucher, linux-kernel, dri-devel

On Wed, Nov 18, 2015 at 05:39:39PM +0900, Michel Dänzer wrote:
> On 18.11.2015 01:29, Daniel Vetter wrote:
> > On Tue, Nov 17, 2015 at 03:59:43PM +0000, John Keeping wrote:
> >> On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
> >>
> >>> On Tue, Nov 17, 2015 at 03:05:34PM +0000, John Keeping wrote:
> >>>> The request's hot_x and hot_y are set correctly for both
> >>>> DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just need to
> >>>> save the values and then apply the offset to the cursor plane when
> >>>> the cursor moves.
> >>>>
> >>>> Signed-off-by: John Keeping <john@metanate.com>
> >>>> ---
> >>>> v2:
> >>>>   - add kerneldoc for hot_x and hot_y in struct drm_crtc
> >>>>
> >>>>  drivers/gpu/drm/drm_crtc.c | 11 +++++++----
> >>>>  include/drm/drm_crtc.h     |  6 ++++++
> >>>>  2 files changed, 13 insertions(+), 4 deletions(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> >>>> index 720a153..40f5b84 100644
> >>>> --- a/drivers/gpu/drm/drm_crtc.c
> >>>> +++ b/drivers/gpu/drm/drm_crtc.c
> >>>> @@ -2831,6 +2831,9 @@ static int drm_mode_cursor_universal(struct
> >>>> drm_crtc *crtc, DRM_DEBUG_KMS("failed to wrap cursor buffer in drm
> >>>> framebuffer\n"); return PTR_ERR(fb);
> >>>>  			}
> >>>> +
> >>>> +			crtc->hot_x = req->hot_x;
> >>>> +			crtc->hot_y = req->hot_y;
> >>>>  		} else {
> >>>>  			fb = NULL;
> >>>>  		}
> >>>> @@ -2841,11 +2844,11 @@ static int drm_mode_cursor_universal(struct
> >>>> drm_crtc *crtc, }
> >>>>  
> >>>>  	if (req->flags & DRM_MODE_CURSOR_MOVE) {
> >>>> -		crtc_x = req->x;
> >>>> -		crtc_y = req->y;
> >>>> +		crtc_x = req->x - crtc->hot_x;
> >>>> +		crtc_y = req->y - crtc->hot_y;
> >>>>  	} else {
> >>>> -		crtc_x = crtc->cursor_x;
> >>>> -		crtc_y = crtc->cursor_y;
> >>>> +		crtc_x = crtc->cursor_x - crtc->hot_x;
> >>>> +		crtc_y = crtc->cursor_y - crtc->hot_y;  
> >>>
> >>> Why does the location of the hotspot affect the plane position?
> >>
> >> hot_{x,y} specify the location of the active pixel within the cursor
> >> plane and cursor_{x,y} specify the location of the active pixel on the
> >> display so we need to offset the plane position in order for the active
> >> pixel to be in the correct place.
> > 
> > Nope, hot_x/y is just for virtual machines to indicate where the logical
> > cursor position is within the cursor plane. It should have 2 effect on how
> > something is displayed.
> 
> Agreed: Since the DRM_IOCTL_MODE_CURSOR ioctl doesn't contain any
> information about the hotspot, the x/y coordinates passed in the
> DRM_IOCTL_MODE_CURSOR(2) ioctls can only refer to the position of the
> top left corner of the cursor.
> 
> 
> > And no, I have absolutely no idea why radeon is pulling some tricks here,
> > which have been added in
> > 
> > commit 78b1a6010b46a69bcd47b723a80f92693f26d17b
> > Author: Michel Dänzer <michel.daenzer@amd.com>
> > Date:   Tue Nov 18 18:00:08 2014 +0900
> > 
> >     drm/radeon: Use cursor_set2 hook for enabling / disabling the HW cursor
> > 
> > Michel/Alex, can you please shed some light onto this?
> 
> As described in the rest of the commit log, the intention was to avoid
> the cursor intermittently appearing in the wrong location with existing
> userspace which sets the cursor BO in one ioctl call and the new
> position in another ioctl call.
> 
> 
> > radeon is the only driver doing this, making this interface inconsistent.
> 
> It's only inconsistent in the case that userspace updates the cursor
> position to account for the new hotspot position in one ioctl call
> first, and only then sets the new BO in another ioctl call. In all other
> cases, the cursor position passed in by userspace is preserved.
> 
> Anyway, in the meantime it has become apparent that this change didn't
> fully fix the problem, so feel free to revert it.

Yeah I read the commit message but didn't understand what it's doing.
After some discussion with Alex on irc I realized that the fixup is only
applied in when updating the cursor bo and changing the hotspot to avoid
that kind of flickering. That problem is solved though on the kernel side
with universal planes (where we don't artificially split up the cursor
update into a move + bo-update for the driver interface any more). And
it's fixable in userspace even with legacy cursor interfaces since the
ioctl allows you to move + update at the same time too. It's just that X
doesn't provide that interface to the driver in a useful way.

Anyway, conclusion is that radeon implements exactly the same behaviour as
every other hw driver, with x/y pointing at the top-left corner of the
cursor image (not the hotspot), in CRTC coordinates. I still have no idea
what John is seeing though exactly, and why there's a difference between
rockchip and qxl for him.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
@ 2015-11-18  8:51             ` Daniel Vetter
  0 siblings, 0 replies; 36+ messages in thread
From: Daniel Vetter @ 2015-11-18  8:51 UTC (permalink / raw)
  To: Michel Dänzer; +Cc: dri-devel, linux-kernel

On Wed, Nov 18, 2015 at 05:39:39PM +0900, Michel Dänzer wrote:
> On 18.11.2015 01:29, Daniel Vetter wrote:
> > On Tue, Nov 17, 2015 at 03:59:43PM +0000, John Keeping wrote:
> >> On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
> >>
> >>> On Tue, Nov 17, 2015 at 03:05:34PM +0000, John Keeping wrote:
> >>>> The request's hot_x and hot_y are set correctly for both
> >>>> DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just need to
> >>>> save the values and then apply the offset to the cursor plane when
> >>>> the cursor moves.
> >>>>
> >>>> Signed-off-by: John Keeping <john@metanate.com>
> >>>> ---
> >>>> v2:
> >>>>   - add kerneldoc for hot_x and hot_y in struct drm_crtc
> >>>>
> >>>>  drivers/gpu/drm/drm_crtc.c | 11 +++++++----
> >>>>  include/drm/drm_crtc.h     |  6 ++++++
> >>>>  2 files changed, 13 insertions(+), 4 deletions(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> >>>> index 720a153..40f5b84 100644
> >>>> --- a/drivers/gpu/drm/drm_crtc.c
> >>>> +++ b/drivers/gpu/drm/drm_crtc.c
> >>>> @@ -2831,6 +2831,9 @@ static int drm_mode_cursor_universal(struct
> >>>> drm_crtc *crtc, DRM_DEBUG_KMS("failed to wrap cursor buffer in drm
> >>>> framebuffer\n"); return PTR_ERR(fb);
> >>>>  			}
> >>>> +
> >>>> +			crtc->hot_x = req->hot_x;
> >>>> +			crtc->hot_y = req->hot_y;
> >>>>  		} else {
> >>>>  			fb = NULL;
> >>>>  		}
> >>>> @@ -2841,11 +2844,11 @@ static int drm_mode_cursor_universal(struct
> >>>> drm_crtc *crtc, }
> >>>>  
> >>>>  	if (req->flags & DRM_MODE_CURSOR_MOVE) {
> >>>> -		crtc_x = req->x;
> >>>> -		crtc_y = req->y;
> >>>> +		crtc_x = req->x - crtc->hot_x;
> >>>> +		crtc_y = req->y - crtc->hot_y;
> >>>>  	} else {
> >>>> -		crtc_x = crtc->cursor_x;
> >>>> -		crtc_y = crtc->cursor_y;
> >>>> +		crtc_x = crtc->cursor_x - crtc->hot_x;
> >>>> +		crtc_y = crtc->cursor_y - crtc->hot_y;  
> >>>
> >>> Why does the location of the hotspot affect the plane position?
> >>
> >> hot_{x,y} specify the location of the active pixel within the cursor
> >> plane and cursor_{x,y} specify the location of the active pixel on the
> >> display so we need to offset the plane position in order for the active
> >> pixel to be in the correct place.
> > 
> > Nope, hot_x/y is just for virtual machines to indicate where the logical
> > cursor position is within the cursor plane. It should have 2 effect on how
> > something is displayed.
> 
> Agreed: Since the DRM_IOCTL_MODE_CURSOR ioctl doesn't contain any
> information about the hotspot, the x/y coordinates passed in the
> DRM_IOCTL_MODE_CURSOR(2) ioctls can only refer to the position of the
> top left corner of the cursor.
> 
> 
> > And no, I have absolutely no idea why radeon is pulling some tricks here,
> > which have been added in
> > 
> > commit 78b1a6010b46a69bcd47b723a80f92693f26d17b
> > Author: Michel Dänzer <michel.daenzer@amd.com>
> > Date:   Tue Nov 18 18:00:08 2014 +0900
> > 
> >     drm/radeon: Use cursor_set2 hook for enabling / disabling the HW cursor
> > 
> > Michel/Alex, can you please shed some light onto this?
> 
> As described in the rest of the commit log, the intention was to avoid
> the cursor intermittently appearing in the wrong location with existing
> userspace which sets the cursor BO in one ioctl call and the new
> position in another ioctl call.
> 
> 
> > radeon is the only driver doing this, making this interface inconsistent.
> 
> It's only inconsistent in the case that userspace updates the cursor
> position to account for the new hotspot position in one ioctl call
> first, and only then sets the new BO in another ioctl call. In all other
> cases, the cursor position passed in by userspace is preserved.
> 
> Anyway, in the meantime it has become apparent that this change didn't
> fully fix the problem, so feel free to revert it.

Yeah I read the commit message but didn't understand what it's doing.
After some discussion with Alex on irc I realized that the fixup is only
applied in when updating the cursor bo and changing the hotspot to avoid
that kind of flickering. That problem is solved though on the kernel side
with universal planes (where we don't artificially split up the cursor
update into a move + bo-update for the driver interface any more). And
it's fixable in userspace even with legacy cursor interfaces since the
ioctl allows you to move + update at the same time too. It's just that X
doesn't provide that interface to the driver in a useful way.

Anyway, conclusion is that radeon implements exactly the same behaviour as
every other hw driver, with x/y pointing at the top-left corner of the
cursor image (not the hotspot), in CRTC coordinates. I still have no idea
what John is seeing though exactly, and why there's a difference between
rockchip and qxl for him.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
  2015-11-18  8:51             ` Daniel Vetter
@ 2015-11-18  8:59               ` Michel Dänzer
  -1 siblings, 0 replies; 36+ messages in thread
From: Michel Dänzer @ 2015-11-18  8:59 UTC (permalink / raw)
  To: John Keeping, Ville Syrjälä,
	Alex Deucher, linux-kernel, dri-devel

On 18.11.2015 17:51, Daniel Vetter wrote:
> On Wed, Nov 18, 2015 at 05:39:39PM +0900, Michel Dänzer wrote:
>> On 18.11.2015 01:29, Daniel Vetter wrote:
>>>
>>> And no, I have absolutely no idea why radeon is pulling some tricks here,
>>> which have been added in
>>>
>>> commit 78b1a6010b46a69bcd47b723a80f92693f26d17b
>>> Author: Michel Dänzer <michel.daenzer@amd.com>
>>> Date:   Tue Nov 18 18:00:08 2014 +0900
>>>
>>>     drm/radeon: Use cursor_set2 hook for enabling / disabling the HW cursor
>>>
>>> Michel/Alex, can you please shed some light onto this?
>>
>> As described in the rest of the commit log, the intention was to avoid
>> the cursor intermittently appearing in the wrong location with existing
>> userspace which sets the cursor BO in one ioctl call and the new
>> position in another ioctl call.
>>
>>
>>> radeon is the only driver doing this, making this interface inconsistent.
>>
>> It's only inconsistent in the case that userspace updates the cursor
>> position to account for the new hotspot position in one ioctl call
>> first, and only then sets the new BO in another ioctl call. In all other
>> cases, the cursor position passed in by userspace is preserved.
>>
>> Anyway, in the meantime it has become apparent that this change didn't
>> fully fix the problem, so feel free to revert it.
> 
> Yeah I read the commit message but didn't understand what it's doing.
> After some discussion with Alex on irc I realized that the fixup is only
> applied in when updating the cursor bo and changing the hotspot to avoid
> that kind of flickering. That problem is solved though on the kernel side
> with universal planes (where we don't artificially split up the cursor
> update into a move + bo-update for the driver interface any more). And
> it's fixable in userspace even with legacy cursor interfaces since the
> ioctl allows you to move + update at the same time too. It's just that X
> doesn't provide that interface to the driver in a useful way.

Well, the legacy cursor interfaces currently don't allow the driver to
prevent the hardware from updating the cursor between the cursor_set /
cursor_move calls. Anyway, I tried adding a cursor_lock hook for that
purpose and adapting userspace accordingly, but it still doesn't seem to
fully fix the problem. So I'm leaving it to somebody else / another day. :)


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
@ 2015-11-18  8:59               ` Michel Dänzer
  0 siblings, 0 replies; 36+ messages in thread
From: Michel Dänzer @ 2015-11-18  8:59 UTC (permalink / raw)
  To: John Keeping, Ville Syrjälä,
	Alex Deucher, linux-kernel, dri-devel

On 18.11.2015 17:51, Daniel Vetter wrote:
> On Wed, Nov 18, 2015 at 05:39:39PM +0900, Michel Dänzer wrote:
>> On 18.11.2015 01:29, Daniel Vetter wrote:
>>>
>>> And no, I have absolutely no idea why radeon is pulling some tricks here,
>>> which have been added in
>>>
>>> commit 78b1a6010b46a69bcd47b723a80f92693f26d17b
>>> Author: Michel Dänzer <michel.daenzer@amd.com>
>>> Date:   Tue Nov 18 18:00:08 2014 +0900
>>>
>>>     drm/radeon: Use cursor_set2 hook for enabling / disabling the HW cursor
>>>
>>> Michel/Alex, can you please shed some light onto this?
>>
>> As described in the rest of the commit log, the intention was to avoid
>> the cursor intermittently appearing in the wrong location with existing
>> userspace which sets the cursor BO in one ioctl call and the new
>> position in another ioctl call.
>>
>>
>>> radeon is the only driver doing this, making this interface inconsistent.
>>
>> It's only inconsistent in the case that userspace updates the cursor
>> position to account for the new hotspot position in one ioctl call
>> first, and only then sets the new BO in another ioctl call. In all other
>> cases, the cursor position passed in by userspace is preserved.
>>
>> Anyway, in the meantime it has become apparent that this change didn't
>> fully fix the problem, so feel free to revert it.
> 
> Yeah I read the commit message but didn't understand what it's doing.
> After some discussion with Alex on irc I realized that the fixup is only
> applied in when updating the cursor bo and changing the hotspot to avoid
> that kind of flickering. That problem is solved though on the kernel side
> with universal planes (where we don't artificially split up the cursor
> update into a move + bo-update for the driver interface any more). And
> it's fixable in userspace even with legacy cursor interfaces since the
> ioctl allows you to move + update at the same time too. It's just that X
> doesn't provide that interface to the driver in a useful way.

Well, the legacy cursor interfaces currently don't allow the driver to
prevent the hardware from updating the cursor between the cursor_set /
cursor_move calls. Anyway, I tried adding a cursor_lock hook for that
purpose and adapting userspace accordingly, but it still doesn't seem to
fully fix the problem. So I'm leaving it to somebody else / another day. :)


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
  2015-11-17 19:11                 ` Daniel Vetter
@ 2015-11-18 10:12                   ` John Keeping
  -1 siblings, 0 replies; 36+ messages in thread
From: John Keeping @ 2015-11-18 10:12 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Alex Deucher, Ville Syrjälä,
	LKML, Maling list - DRI developers, Michel Dänzer

On Tue, 17 Nov 2015 20:11:23 +0100, Daniel Vetter wrote:

> On Tue, Nov 17, 2015 at 06:47:28PM +0000, John Keeping wrote:
> > On Tue, 17 Nov 2015 19:31:32 +0100, Daniel Vetter wrote:
> >   
> > > On Tue, Nov 17, 2015 at 12:07:24PM -0500, Alex Deucher wrote:  
> > > > On Tue, Nov 17, 2015 at 11:29 AM, Daniel Vetter
> > > > <daniel@ffwll.ch> wrote:    
> > > > > On Tue, Nov 17, 2015 at 03:59:43PM +0000, John Keeping
> > > > > wrote:    
> > > > >> On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
> > > > >>    
> > > > >> > On Tue, Nov 17, 2015 at 03:05:34PM +0000, John Keeping
> > > > >> > wrote:    
> > > > >> > > The request's hot_x and hot_y are set correctly for both
> > > > >> > > DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we
> > > > >> > > just need to save the values and then apply the offset
> > > > >> > > to the cursor plane when the cursor moves.
> > > > >> > >
> > > > >> > > Signed-off-by: John Keeping <john@metanate.com>
> > > > >> > > ---
> > > > >> > > v2:
> > > > >> > >   - add kerneldoc for hot_x and hot_y in struct drm_crtc
> > > > >> > >
> > > > >> > >  drivers/gpu/drm/drm_crtc.c | 11 +++++++----
> > > > >> > >  include/drm/drm_crtc.h     |  6 ++++++
> > > > >> > >  2 files changed, 13 insertions(+), 4 deletions(-)
> > > > >> > >
> > > > >> > > diff --git a/drivers/gpu/drm/drm_crtc.c
> > > > >> > > b/drivers/gpu/drm/drm_crtc.c index 720a153..40f5b84
> > > > >> > > 100644 --- a/drivers/gpu/drm/drm_crtc.c
> > > > >> > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > > >> > > @@ -2831,6 +2831,9 @@ static int
> > > > >> > > drm_mode_cursor_universal(struct drm_crtc *crtc,
> > > > >> > > DRM_DEBUG_KMS("failed to wrap cursor buffer in drm
> > > > >> > > framebuffer\n"); return PTR_ERR(fb); }
> > > > >> > > +
> > > > >> > > +                 crtc->hot_x = req->hot_x;
> > > > >> > > +                 crtc->hot_y = req->hot_y;
> > > > >> > >           } else {
> > > > >> > >                   fb = NULL;
> > > > >> > >           }
> > > > >> > > @@ -2841,11 +2844,11 @@ static int
> > > > >> > > drm_mode_cursor_universal(struct drm_crtc *crtc, }
> > > > >> > >
> > > > >> > >   if (req->flags & DRM_MODE_CURSOR_MOVE) {
> > > > >> > > -         crtc_x = req->x;
> > > > >> > > -         crtc_y = req->y;
> > > > >> > > +         crtc_x = req->x - crtc->hot_x;
> > > > >> > > +         crtc_y = req->y - crtc->hot_y;
> > > > >> > >   } else {
> > > > >> > > -         crtc_x = crtc->cursor_x;
> > > > >> > > -         crtc_y = crtc->cursor_y;
> > > > >> > > +         crtc_x = crtc->cursor_x - crtc->hot_x;
> > > > >> > > +         crtc_y = crtc->cursor_y - crtc->hot_y;    
> > > > >> >
> > > > >> > Why does the location of the hotspot affect the plane
> > > > >> > position?    
> > > > >>
> > > > >> hot_{x,y} specify the location of the active pixel within the
> > > > >> cursor plane and cursor_{x,y} specify the location of the
> > > > >> active pixel on the display so we need to offset the plane
> > > > >> position in order for the active pixel to be in the correct
> > > > >> place.    
> > > > >
> > > > > Nope, hot_x/y is just for virtual machines to indicate where
> > > > > the logical cursor position is within the cursor plane. It
> > > > > should have 2 effect on how something is displayed. And no, I
> > > > > have absolutely no idea why radeon is pulling some tricks
> > > > > here, which have been added in
> > > > >
> > > > > commit 78b1a6010b46a69bcd47b723a80f92693f26d17b
> > > > > Author: Michel Dänzer <michel.daenzer@amd.com>
> > > > > Date:   Tue Nov 18 18:00:08 2014 +0900
> > > > >
> > > > >     drm/radeon: Use cursor_set2 hook for enabling / disabling
> > > > > the HW cursor
> > > > >
> > > > > Michel/Alex, can you please shed some light onto this? radeon
> > > > > is the only driver doing this, making this interface
> > > > > inconsistent. Is the ddx doing something funny compared to
> > > > > -modeseting or weston?
> > > > >
> > > > > At least a quick look in the -ati sources didn't even show a
> > > > > user for this, it's still using the old cursor ioctl. And
> > > > > there's no other indication in the commit of a bug or
> > > > > anything. Can we perhaps just revert this?    
> > > > 
> > > > We use this is xf86-video-ati.  See:
> > > > http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=c9f8f642fd495937400618a4fc25ecae3f8888fc
> > > > Our hw cursor has a hotspot register that needs to be
> > > > programmed for proper operation.  I don't remember the details
> > > > of the specific bug. Michel can provide more info.    
> > > 
> > > Yeah I was blind and didn't spot this. But I can't find your
> > > hotspot cursor reg - it's only used to adjust the x/y offsets
> > > (similar to John's patch). And amdgpu doesn't do this at all,
> > > it's only radoen.ko. Still confused.  
> > 
> > Having investigated a bit more, I think xserver handles the hotspot
> > itself without using the kernel hotspot handling and xorg-video-qxl
> > carefully reverses this in order to take advantage of
> > drmModeSetCursor2(), so with X11 drivers you don't notice that the
> > kernel handling of this is broken in nearly all drivers.  
> 
> Where did you spot this code in -qxl? Afaics it has the exact same
> copy of the usual drmmode.c code as everyone else. No adjustments of
> x/yhot seems to be going on there, nor in the qxl.ko kernel driver.
> Or at least I didn't find it.
> 
> > Here's a small test program that demonstrates whether or not cursor
> > hotspots work.  There should be a single colored pixel immediately
> > to the left of the pointer but with a broken driver the white pixel
> > will be 64 pixels to the left of the pointer.  
> 
> Is there also a way to test this with X? In the end that's what will
> matter for most end users, and if there's difference in behaviour in
> the various X drivers we're really screwed (since essentially we
> can't ever fix it properly for the legacy ioctl).

I've now tested with X and QXL and it seems that the bug is in the QXL
DRM driver, since the cursor appears in the wrong place when using both
xorg-video-qxl and xorg-video-modesetting.

I think what's happening is that X and the DRM cursor ioctls always use
cursor_{x,y} as the location of the top-left of the cursor image, but
the SPICE protocol uses cursor_{x,y} as the location of the active pixel
in the cursor image (the specification [1] uses the term "position of
the mouse pointer").  So this patch is wrong and I withdraw it.

This means that the QXL driver needs to apply the hotspot offset to the
location whenever it generated QXL_CURSOR_SET and QXL_CURSOR_MOVE
commands.

[1] http://www.spice-space.org/docs/spice_protocol.pdf

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
@ 2015-11-18 10:12                   ` John Keeping
  0 siblings, 0 replies; 36+ messages in thread
From: John Keeping @ 2015-11-18 10:12 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: Maling list - DRI developers, Michel Dänzer, LKML

On Tue, 17 Nov 2015 20:11:23 +0100, Daniel Vetter wrote:

> On Tue, Nov 17, 2015 at 06:47:28PM +0000, John Keeping wrote:
> > On Tue, 17 Nov 2015 19:31:32 +0100, Daniel Vetter wrote:
> >   
> > > On Tue, Nov 17, 2015 at 12:07:24PM -0500, Alex Deucher wrote:  
> > > > On Tue, Nov 17, 2015 at 11:29 AM, Daniel Vetter
> > > > <daniel@ffwll.ch> wrote:    
> > > > > On Tue, Nov 17, 2015 at 03:59:43PM +0000, John Keeping
> > > > > wrote:    
> > > > >> On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
> > > > >>    
> > > > >> > On Tue, Nov 17, 2015 at 03:05:34PM +0000, John Keeping
> > > > >> > wrote:    
> > > > >> > > The request's hot_x and hot_y are set correctly for both
> > > > >> > > DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we
> > > > >> > > just need to save the values and then apply the offset
> > > > >> > > to the cursor plane when the cursor moves.
> > > > >> > >
> > > > >> > > Signed-off-by: John Keeping <john@metanate.com>
> > > > >> > > ---
> > > > >> > > v2:
> > > > >> > >   - add kerneldoc for hot_x and hot_y in struct drm_crtc
> > > > >> > >
> > > > >> > >  drivers/gpu/drm/drm_crtc.c | 11 +++++++----
> > > > >> > >  include/drm/drm_crtc.h     |  6 ++++++
> > > > >> > >  2 files changed, 13 insertions(+), 4 deletions(-)
> > > > >> > >
> > > > >> > > diff --git a/drivers/gpu/drm/drm_crtc.c
> > > > >> > > b/drivers/gpu/drm/drm_crtc.c index 720a153..40f5b84
> > > > >> > > 100644 --- a/drivers/gpu/drm/drm_crtc.c
> > > > >> > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > > >> > > @@ -2831,6 +2831,9 @@ static int
> > > > >> > > drm_mode_cursor_universal(struct drm_crtc *crtc,
> > > > >> > > DRM_DEBUG_KMS("failed to wrap cursor buffer in drm
> > > > >> > > framebuffer\n"); return PTR_ERR(fb); }
> > > > >> > > +
> > > > >> > > +                 crtc->hot_x = req->hot_x;
> > > > >> > > +                 crtc->hot_y = req->hot_y;
> > > > >> > >           } else {
> > > > >> > >                   fb = NULL;
> > > > >> > >           }
> > > > >> > > @@ -2841,11 +2844,11 @@ static int
> > > > >> > > drm_mode_cursor_universal(struct drm_crtc *crtc, }
> > > > >> > >
> > > > >> > >   if (req->flags & DRM_MODE_CURSOR_MOVE) {
> > > > >> > > -         crtc_x = req->x;
> > > > >> > > -         crtc_y = req->y;
> > > > >> > > +         crtc_x = req->x - crtc->hot_x;
> > > > >> > > +         crtc_y = req->y - crtc->hot_y;
> > > > >> > >   } else {
> > > > >> > > -         crtc_x = crtc->cursor_x;
> > > > >> > > -         crtc_y = crtc->cursor_y;
> > > > >> > > +         crtc_x = crtc->cursor_x - crtc->hot_x;
> > > > >> > > +         crtc_y = crtc->cursor_y - crtc->hot_y;    
> > > > >> >
> > > > >> > Why does the location of the hotspot affect the plane
> > > > >> > position?    
> > > > >>
> > > > >> hot_{x,y} specify the location of the active pixel within the
> > > > >> cursor plane and cursor_{x,y} specify the location of the
> > > > >> active pixel on the display so we need to offset the plane
> > > > >> position in order for the active pixel to be in the correct
> > > > >> place.    
> > > > >
> > > > > Nope, hot_x/y is just for virtual machines to indicate where
> > > > > the logical cursor position is within the cursor plane. It
> > > > > should have 2 effect on how something is displayed. And no, I
> > > > > have absolutely no idea why radeon is pulling some tricks
> > > > > here, which have been added in
> > > > >
> > > > > commit 78b1a6010b46a69bcd47b723a80f92693f26d17b
> > > > > Author: Michel Dänzer <michel.daenzer@amd.com>
> > > > > Date:   Tue Nov 18 18:00:08 2014 +0900
> > > > >
> > > > >     drm/radeon: Use cursor_set2 hook for enabling / disabling
> > > > > the HW cursor
> > > > >
> > > > > Michel/Alex, can you please shed some light onto this? radeon
> > > > > is the only driver doing this, making this interface
> > > > > inconsistent. Is the ddx doing something funny compared to
> > > > > -modeseting or weston?
> > > > >
> > > > > At least a quick look in the -ati sources didn't even show a
> > > > > user for this, it's still using the old cursor ioctl. And
> > > > > there's no other indication in the commit of a bug or
> > > > > anything. Can we perhaps just revert this?    
> > > > 
> > > > We use this is xf86-video-ati.  See:
> > > > http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=c9f8f642fd495937400618a4fc25ecae3f8888fc
> > > > Our hw cursor has a hotspot register that needs to be
> > > > programmed for proper operation.  I don't remember the details
> > > > of the specific bug. Michel can provide more info.    
> > > 
> > > Yeah I was blind and didn't spot this. But I can't find your
> > > hotspot cursor reg - it's only used to adjust the x/y offsets
> > > (similar to John's patch). And amdgpu doesn't do this at all,
> > > it's only radoen.ko. Still confused.  
> > 
> > Having investigated a bit more, I think xserver handles the hotspot
> > itself without using the kernel hotspot handling and xorg-video-qxl
> > carefully reverses this in order to take advantage of
> > drmModeSetCursor2(), so with X11 drivers you don't notice that the
> > kernel handling of this is broken in nearly all drivers.  
> 
> Where did you spot this code in -qxl? Afaics it has the exact same
> copy of the usual drmmode.c code as everyone else. No adjustments of
> x/yhot seems to be going on there, nor in the qxl.ko kernel driver.
> Or at least I didn't find it.
> 
> > Here's a small test program that demonstrates whether or not cursor
> > hotspots work.  There should be a single colored pixel immediately
> > to the left of the pointer but with a broken driver the white pixel
> > will be 64 pixels to the left of the pointer.  
> 
> Is there also a way to test this with X? In the end that's what will
> matter for most end users, and if there's difference in behaviour in
> the various X drivers we're really screwed (since essentially we
> can't ever fix it properly for the legacy ioctl).

I've now tested with X and QXL and it seems that the bug is in the QXL
DRM driver, since the cursor appears in the wrong place when using both
xorg-video-qxl and xorg-video-modesetting.

I think what's happening is that X and the DRM cursor ioctls always use
cursor_{x,y} as the location of the top-left of the cursor image, but
the SPICE protocol uses cursor_{x,y} as the location of the active pixel
in the cursor image (the specification [1] uses the term "position of
the mouse pointer").  So this patch is wrong and I withdraw it.

This means that the QXL driver needs to apply the hotspot offset to the
location whenever it generated QXL_CURSOR_SET and QXL_CURSOR_MOVE
commands.

[1] http://www.spice-space.org/docs/spice_protocol.pdf
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
  2015-11-18 10:12                   ` John Keeping
@ 2015-11-18 11:08                     ` Daniel Vetter
  -1 siblings, 0 replies; 36+ messages in thread
From: Daniel Vetter @ 2015-11-18 11:08 UTC (permalink / raw)
  To: John Keeping
  Cc: Daniel Vetter, Alex Deucher, Ville Syrjälä,
	LKML, Maling list - DRI developers, Michel Dänzer

On Wed, Nov 18, 2015 at 10:12:16AM +0000, John Keeping wrote:
> On Tue, 17 Nov 2015 20:11:23 +0100, Daniel Vetter wrote:
> 
> > On Tue, Nov 17, 2015 at 06:47:28PM +0000, John Keeping wrote:
> > > On Tue, 17 Nov 2015 19:31:32 +0100, Daniel Vetter wrote:
> > >   
> > > > On Tue, Nov 17, 2015 at 12:07:24PM -0500, Alex Deucher wrote:  
> > > > > On Tue, Nov 17, 2015 at 11:29 AM, Daniel Vetter
> > > > > <daniel@ffwll.ch> wrote:    
> > > > > > On Tue, Nov 17, 2015 at 03:59:43PM +0000, John Keeping
> > > > > > wrote:    
> > > > > >> On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
> > > > > >>    
> > > > > >> > On Tue, Nov 17, 2015 at 03:05:34PM +0000, John Keeping
> > > > > >> > wrote:    
> > > > > >> > > The request's hot_x and hot_y are set correctly for both
> > > > > >> > > DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we
> > > > > >> > > just need to save the values and then apply the offset
> > > > > >> > > to the cursor plane when the cursor moves.
> > > > > >> > >
> > > > > >> > > Signed-off-by: John Keeping <john@metanate.com>
> > > > > >> > > ---
> > > > > >> > > v2:
> > > > > >> > >   - add kerneldoc for hot_x and hot_y in struct drm_crtc
> > > > > >> > >
> > > > > >> > >  drivers/gpu/drm/drm_crtc.c | 11 +++++++----
> > > > > >> > >  include/drm/drm_crtc.h     |  6 ++++++
> > > > > >> > >  2 files changed, 13 insertions(+), 4 deletions(-)
> > > > > >> > >
> > > > > >> > > diff --git a/drivers/gpu/drm/drm_crtc.c
> > > > > >> > > b/drivers/gpu/drm/drm_crtc.c index 720a153..40f5b84
> > > > > >> > > 100644 --- a/drivers/gpu/drm/drm_crtc.c
> > > > > >> > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > > > >> > > @@ -2831,6 +2831,9 @@ static int
> > > > > >> > > drm_mode_cursor_universal(struct drm_crtc *crtc,
> > > > > >> > > DRM_DEBUG_KMS("failed to wrap cursor buffer in drm
> > > > > >> > > framebuffer\n"); return PTR_ERR(fb); }
> > > > > >> > > +
> > > > > >> > > +                 crtc->hot_x = req->hot_x;
> > > > > >> > > +                 crtc->hot_y = req->hot_y;
> > > > > >> > >           } else {
> > > > > >> > >                   fb = NULL;
> > > > > >> > >           }
> > > > > >> > > @@ -2841,11 +2844,11 @@ static int
> > > > > >> > > drm_mode_cursor_universal(struct drm_crtc *crtc, }
> > > > > >> > >
> > > > > >> > >   if (req->flags & DRM_MODE_CURSOR_MOVE) {
> > > > > >> > > -         crtc_x = req->x;
> > > > > >> > > -         crtc_y = req->y;
> > > > > >> > > +         crtc_x = req->x - crtc->hot_x;
> > > > > >> > > +         crtc_y = req->y - crtc->hot_y;
> > > > > >> > >   } else {
> > > > > >> > > -         crtc_x = crtc->cursor_x;
> > > > > >> > > -         crtc_y = crtc->cursor_y;
> > > > > >> > > +         crtc_x = crtc->cursor_x - crtc->hot_x;
> > > > > >> > > +         crtc_y = crtc->cursor_y - crtc->hot_y;    
> > > > > >> >
> > > > > >> > Why does the location of the hotspot affect the plane
> > > > > >> > position?    
> > > > > >>
> > > > > >> hot_{x,y} specify the location of the active pixel within the
> > > > > >> cursor plane and cursor_{x,y} specify the location of the
> > > > > >> active pixel on the display so we need to offset the plane
> > > > > >> position in order for the active pixel to be in the correct
> > > > > >> place.    
> > > > > >
> > > > > > Nope, hot_x/y is just for virtual machines to indicate where
> > > > > > the logical cursor position is within the cursor plane. It
> > > > > > should have 2 effect on how something is displayed. And no, I
> > > > > > have absolutely no idea why radeon is pulling some tricks
> > > > > > here, which have been added in
> > > > > >
> > > > > > commit 78b1a6010b46a69bcd47b723a80f92693f26d17b
> > > > > > Author: Michel Dänzer <michel.daenzer@amd.com>
> > > > > > Date:   Tue Nov 18 18:00:08 2014 +0900
> > > > > >
> > > > > >     drm/radeon: Use cursor_set2 hook for enabling / disabling
> > > > > > the HW cursor
> > > > > >
> > > > > > Michel/Alex, can you please shed some light onto this? radeon
> > > > > > is the only driver doing this, making this interface
> > > > > > inconsistent. Is the ddx doing something funny compared to
> > > > > > -modeseting or weston?
> > > > > >
> > > > > > At least a quick look in the -ati sources didn't even show a
> > > > > > user for this, it's still using the old cursor ioctl. And
> > > > > > there's no other indication in the commit of a bug or
> > > > > > anything. Can we perhaps just revert this?    
> > > > > 
> > > > > We use this is xf86-video-ati.  See:
> > > > > http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=c9f8f642fd495937400618a4fc25ecae3f8888fc
> > > > > Our hw cursor has a hotspot register that needs to be
> > > > > programmed for proper operation.  I don't remember the details
> > > > > of the specific bug. Michel can provide more info.    
> > > > 
> > > > Yeah I was blind and didn't spot this. But I can't find your
> > > > hotspot cursor reg - it's only used to adjust the x/y offsets
> > > > (similar to John's patch). And amdgpu doesn't do this at all,
> > > > it's only radoen.ko. Still confused.  
> > > 
> > > Having investigated a bit more, I think xserver handles the hotspot
> > > itself without using the kernel hotspot handling and xorg-video-qxl
> > > carefully reverses this in order to take advantage of
> > > drmModeSetCursor2(), so with X11 drivers you don't notice that the
> > > kernel handling of this is broken in nearly all drivers.  
> > 
> > Where did you spot this code in -qxl? Afaics it has the exact same
> > copy of the usual drmmode.c code as everyone else. No adjustments of
> > x/yhot seems to be going on there, nor in the qxl.ko kernel driver.
> > Or at least I didn't find it.
> > 
> > > Here's a small test program that demonstrates whether or not cursor
> > > hotspots work.  There should be a single colored pixel immediately
> > > to the left of the pointer but with a broken driver the white pixel
> > > will be 64 pixels to the left of the pointer.  
> > 
> > Is there also a way to test this with X? In the end that's what will
> > matter for most end users, and if there's difference in behaviour in
> > the various X drivers we're really screwed (since essentially we
> > can't ever fix it properly for the legacy ioctl).
> 
> I've now tested with X and QXL and it seems that the bug is in the QXL
> DRM driver, since the cursor appears in the wrong place when using both
> xorg-video-qxl and xorg-video-modesetting.
> 
> I think what's happening is that X and the DRM cursor ioctls always use
> cursor_{x,y} as the location of the top-left of the cursor image, but
> the SPICE protocol uses cursor_{x,y} as the location of the active pixel
> in the cursor image (the specification [1] uses the term "position of
> the mouse pointer").  So this patch is wrong and I withdraw it.

Yup, x/y being the top-left corner of the cursor image is how all other
drivers work.

> This means that the QXL driver needs to apply the hotspot offset to the
> location whenever it generated QXL_CURSOR_SET and QXL_CURSOR_MOVE
> commands.
> 
> [1] http://www.spice-space.org/docs/spice_protocol.pdf

Excellent that we've figured this out. Care to write a patch for qxl since
you've figured this all out?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 36+ messages in thread

* Re: [PATCH v2] drm: support hotspot for universal plane cursors
@ 2015-11-18 11:08                     ` Daniel Vetter
  0 siblings, 0 replies; 36+ messages in thread
From: Daniel Vetter @ 2015-11-18 11:08 UTC (permalink / raw)
  To: John Keeping; +Cc: Michel Dänzer, LKML, Maling list - DRI developers

On Wed, Nov 18, 2015 at 10:12:16AM +0000, John Keeping wrote:
> On Tue, 17 Nov 2015 20:11:23 +0100, Daniel Vetter wrote:
> 
> > On Tue, Nov 17, 2015 at 06:47:28PM +0000, John Keeping wrote:
> > > On Tue, 17 Nov 2015 19:31:32 +0100, Daniel Vetter wrote:
> > >   
> > > > On Tue, Nov 17, 2015 at 12:07:24PM -0500, Alex Deucher wrote:  
> > > > > On Tue, Nov 17, 2015 at 11:29 AM, Daniel Vetter
> > > > > <daniel@ffwll.ch> wrote:    
> > > > > > On Tue, Nov 17, 2015 at 03:59:43PM +0000, John Keeping
> > > > > > wrote:    
> > > > > >> On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
> > > > > >>    
> > > > > >> > On Tue, Nov 17, 2015 at 03:05:34PM +0000, John Keeping
> > > > > >> > wrote:    
> > > > > >> > > The request's hot_x and hot_y are set correctly for both
> > > > > >> > > DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we
> > > > > >> > > just need to save the values and then apply the offset
> > > > > >> > > to the cursor plane when the cursor moves.
> > > > > >> > >
> > > > > >> > > Signed-off-by: John Keeping <john@metanate.com>
> > > > > >> > > ---
> > > > > >> > > v2:
> > > > > >> > >   - add kerneldoc for hot_x and hot_y in struct drm_crtc
> > > > > >> > >
> > > > > >> > >  drivers/gpu/drm/drm_crtc.c | 11 +++++++----
> > > > > >> > >  include/drm/drm_crtc.h     |  6 ++++++
> > > > > >> > >  2 files changed, 13 insertions(+), 4 deletions(-)
> > > > > >> > >
> > > > > >> > > diff --git a/drivers/gpu/drm/drm_crtc.c
> > > > > >> > > b/drivers/gpu/drm/drm_crtc.c index 720a153..40f5b84
> > > > > >> > > 100644 --- a/drivers/gpu/drm/drm_crtc.c
> > > > > >> > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > > > >> > > @@ -2831,6 +2831,9 @@ static int
> > > > > >> > > drm_mode_cursor_universal(struct drm_crtc *crtc,
> > > > > >> > > DRM_DEBUG_KMS("failed to wrap cursor buffer in drm
> > > > > >> > > framebuffer\n"); return PTR_ERR(fb); }
> > > > > >> > > +
> > > > > >> > > +                 crtc->hot_x = req->hot_x;
> > > > > >> > > +                 crtc->hot_y = req->hot_y;
> > > > > >> > >           } else {
> > > > > >> > >                   fb = NULL;
> > > > > >> > >           }
> > > > > >> > > @@ -2841,11 +2844,11 @@ static int
> > > > > >> > > drm_mode_cursor_universal(struct drm_crtc *crtc, }
> > > > > >> > >
> > > > > >> > >   if (req->flags & DRM_MODE_CURSOR_MOVE) {
> > > > > >> > > -         crtc_x = req->x;
> > > > > >> > > -         crtc_y = req->y;
> > > > > >> > > +         crtc_x = req->x - crtc->hot_x;
> > > > > >> > > +         crtc_y = req->y - crtc->hot_y;
> > > > > >> > >   } else {
> > > > > >> > > -         crtc_x = crtc->cursor_x;
> > > > > >> > > -         crtc_y = crtc->cursor_y;
> > > > > >> > > +         crtc_x = crtc->cursor_x - crtc->hot_x;
> > > > > >> > > +         crtc_y = crtc->cursor_y - crtc->hot_y;    
> > > > > >> >
> > > > > >> > Why does the location of the hotspot affect the plane
> > > > > >> > position?    
> > > > > >>
> > > > > >> hot_{x,y} specify the location of the active pixel within the
> > > > > >> cursor plane and cursor_{x,y} specify the location of the
> > > > > >> active pixel on the display so we need to offset the plane
> > > > > >> position in order for the active pixel to be in the correct
> > > > > >> place.    
> > > > > >
> > > > > > Nope, hot_x/y is just for virtual machines to indicate where
> > > > > > the logical cursor position is within the cursor plane. It
> > > > > > should have 2 effect on how something is displayed. And no, I
> > > > > > have absolutely no idea why radeon is pulling some tricks
> > > > > > here, which have been added in
> > > > > >
> > > > > > commit 78b1a6010b46a69bcd47b723a80f92693f26d17b
> > > > > > Author: Michel Dänzer <michel.daenzer@amd.com>
> > > > > > Date:   Tue Nov 18 18:00:08 2014 +0900
> > > > > >
> > > > > >     drm/radeon: Use cursor_set2 hook for enabling / disabling
> > > > > > the HW cursor
> > > > > >
> > > > > > Michel/Alex, can you please shed some light onto this? radeon
> > > > > > is the only driver doing this, making this interface
> > > > > > inconsistent. Is the ddx doing something funny compared to
> > > > > > -modeseting or weston?
> > > > > >
> > > > > > At least a quick look in the -ati sources didn't even show a
> > > > > > user for this, it's still using the old cursor ioctl. And
> > > > > > there's no other indication in the commit of a bug or
> > > > > > anything. Can we perhaps just revert this?    
> > > > > 
> > > > > We use this is xf86-video-ati.  See:
> > > > > http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=c9f8f642fd495937400618a4fc25ecae3f8888fc
> > > > > Our hw cursor has a hotspot register that needs to be
> > > > > programmed for proper operation.  I don't remember the details
> > > > > of the specific bug. Michel can provide more info.    
> > > > 
> > > > Yeah I was blind and didn't spot this. But I can't find your
> > > > hotspot cursor reg - it's only used to adjust the x/y offsets
> > > > (similar to John's patch). And amdgpu doesn't do this at all,
> > > > it's only radoen.ko. Still confused.  
> > > 
> > > Having investigated a bit more, I think xserver handles the hotspot
> > > itself without using the kernel hotspot handling and xorg-video-qxl
> > > carefully reverses this in order to take advantage of
> > > drmModeSetCursor2(), so with X11 drivers you don't notice that the
> > > kernel handling of this is broken in nearly all drivers.  
> > 
> > Where did you spot this code in -qxl? Afaics it has the exact same
> > copy of the usual drmmode.c code as everyone else. No adjustments of
> > x/yhot seems to be going on there, nor in the qxl.ko kernel driver.
> > Or at least I didn't find it.
> > 
> > > Here's a small test program that demonstrates whether or not cursor
> > > hotspots work.  There should be a single colored pixel immediately
> > > to the left of the pointer but with a broken driver the white pixel
> > > will be 64 pixels to the left of the pointer.  
> > 
> > Is there also a way to test this with X? In the end that's what will
> > matter for most end users, and if there's difference in behaviour in
> > the various X drivers we're really screwed (since essentially we
> > can't ever fix it properly for the legacy ioctl).
> 
> I've now tested with X and QXL and it seems that the bug is in the QXL
> DRM driver, since the cursor appears in the wrong place when using both
> xorg-video-qxl and xorg-video-modesetting.
> 
> I think what's happening is that X and the DRM cursor ioctls always use
> cursor_{x,y} as the location of the top-left of the cursor image, but
> the SPICE protocol uses cursor_{x,y} as the location of the active pixel
> in the cursor image (the specification [1] uses the term "position of
> the mouse pointer").  So this patch is wrong and I withdraw it.

Yup, x/y being the top-left corner of the cursor image is how all other
drivers work.

> This means that the QXL driver needs to apply the hotspot offset to the
> location whenever it generated QXL_CURSOR_SET and QXL_CURSOR_MOVE
> commands.
> 
> [1] http://www.spice-space.org/docs/spice_protocol.pdf

Excellent that we've figured this out. Care to write a patch for qxl since
you've figured this all out?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 36+ messages in thread

end of thread, other threads:[~2015-11-18 11:08 UTC | newest]

Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-17 12:10 [PATCH] drm: support hotspot for universal plane cursors John Keeping
2015-11-17 13:13 ` kbuild test robot
2015-11-17 13:13   ` kbuild test robot
2015-11-17 15:05 ` [PATCH v2] " John Keeping
2015-11-17 15:05   ` John Keeping
2015-11-17 15:39   ` Ville Syrjälä
2015-11-17 15:39     ` Ville Syrjälä
2015-11-17 15:59     ` John Keeping
2015-11-17 15:59       ` John Keeping
2015-11-17 16:09       ` Ville Syrjälä
2015-11-17 16:29       ` Daniel Vetter
2015-11-17 16:29         ` Daniel Vetter
2015-11-17 16:58         ` John Keeping
2015-11-17 16:58           ` John Keeping
2015-11-17 18:40           ` Daniel Vetter
2015-11-17 18:40             ` Daniel Vetter
2015-11-17 19:11             ` Alex Deucher
2015-11-17 19:11               ` Alex Deucher
2015-11-17 17:07         ` Alex Deucher
2015-11-17 17:07           ` Alex Deucher
2015-11-17 18:31           ` Daniel Vetter
2015-11-17 18:31             ` Daniel Vetter
2015-11-17 18:47             ` John Keeping
2015-11-17 18:47               ` John Keeping
2015-11-17 19:11               ` Daniel Vetter
2015-11-17 19:11                 ` Daniel Vetter
2015-11-18 10:12                 ` John Keeping
2015-11-18 10:12                   ` John Keeping
2015-11-18 11:08                   ` Daniel Vetter
2015-11-18 11:08                     ` Daniel Vetter
2015-11-18  8:39         ` Michel Dänzer
2015-11-18  8:39           ` Michel Dänzer
2015-11-18  8:51           ` Daniel Vetter
2015-11-18  8:51             ` Daniel Vetter
2015-11-18  8:59             ` Michel Dänzer
2015-11-18  8:59               ` Michel Dänzer

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.