Re: [PATCH 1/2] drm/edid: adjust double-clocked cea modes

[Adam Jackson <ajax@redhat.com>]

On 5/14/12 3:43 PM, Paulo Zanoni wrote:

> Also, I think flag DRM_MODE_FLAG_DBLCLK does not sound correct for
> them, so we would need to create flags:
> - DRM_MODE_FLAG_PR_1_to_10
> - DRM_MODE_FLAG_PR_1_or_2
> - DRM_MODE_FLAG_PR_1_or_2_or_4
>
> Or any other more creative names. And then we should cross our fingers
> in the hope that they don't start creating modes with other possible
> variations of PR :)
> Anyway, how will the user be able to choose the wanted PR? What about
> the aspect ratio? Yet Another Connector Property?

Well, one thing at a time.

Right now we don't have the concept of a mode property.  Therefore, 
modes exposed to userspace should all be unique.  Exposing the pixel 
repeat to userspace as a connector property is wrong because it doesn't 
apply to all modes for a connector.

So my initial inclination would be to do something like this in the 
flags field:

--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -58,6 +58,9 @@
  #define DRM_MODE_FLAG_PIXMUX   (1<<11)
  #define DRM_MODE_FLAG_DBLCLK   (1<<12)
  #define DRM_MODE_FLAG_CLKDIV2  (1<<13)
+/* begin non-xorg definitions */
+#define DRM_PIXREP_MASK                (15 << 14)
+#define DRM_MODE_FLAG_PIXREP(x) (((x) << 14) & DRM_PIXMULT_MASK)

  /* DPMS flags */
  /* bit compatible with the xorg definitions. */

The timings for the variably-repeated modes won't change (right?) so 
this is the only way to get the desired pixel repeat passed into the 
modesettinng path.  And then the "one to ten" and "one two or four" 
modes simply need to be added to the list multiple times, once for each 
possible pixel replication, and with varying names depending on the 
effective framebuffer size.

Problems with this approach are that it means rewriting the CEA mode 
list or the VIC table walk or both, and that it means creating a class 
of modes that userspace can set but not create (which means, if your X 
driver is parsing EDID itself instead of just using the damn kernel mode 
list, that many of the modes will be inaccessible to X).  Neither is 
insoluble, just nngh.

The dual-aspect-ratio modes are, well, ugly.  Ideally we'd have scaler 
hardware on all digital output routes so we could just make that a 
connector property, and then hide the choice of mechanism inside the drm 
(either in the monitor if the infoframe says so / if it's controllable 
with DDC/CI or something, or in the GPU if not).  I don't know if all 
the digital outputs in the world live up to that lofty goal.  Failing 
that we could encode the widescreen-ness in the mode name?  All quite 
horrible.  TVs really are the worst thing.

I think at some point we're going to need to reconsider using xserver's 
data type for the mode so literally.

- ajax