[PATCHv5][ 1/5] fbdev: Add the lacking FB_SYNC_* for matching the DISPLAY_FLAGS_*
From: Russell King - ARM Linux <hidden>
Date: 2014-01-10 12:46:53
Also in:
linux-devicetree, linux-fbdev
On Fri, Jan 10, 2014 at 02:37:40PM +0200, Tomi Valkeinen wrote:
I don't think this is better than the previous version where FB_SYNC_DE_HIGH_ACT and FB_SYNC_PIXDAT_HIGH_ACT were in include/uapi/linux/fb.h. Now those flag defines are not visible to the userspace, but the actual flags are still visible from the var->sync field. It's true what Russell replied to the previous version, that the userspace has no idea how to handle those new flags. But then again, for LCDs, the userspace has no idea how to handle, say, hsync polarity either. In any case, splitting the FB_SYNC_ defines into uapi and kernel-internal header files, but still giving the kernel-internal values to userspace is surely wrong.
The difference between the sync states and these other flags is that the sync states are part of the mode definition - as per the CEA-861 documentation. However, that does not extend to LCD panels, which generally need to have one set of timings, with the various control signals at certain polarities - and those control signal polarities are a property of the panel itself, not of the displayed mode. So, if you know that you have LCD panel X, and it needs control signals with a certain polarity, that is how you configure the hardware _irrespective_ of what userspace says that the sync states should be. The sync states specified by userspace should of course be used for the sync pulses being sent to a VGA display or HDMI sink. -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was "up to 13.2Mbit".