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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
