Re: [PATCH 2.6.17-rc6-mm2] fbdev: tag by scantype in sysfs

["Antonino A. Daplas" <adaplas@gmail.com>]

Daniel THOMPSON wrote:
> Antonino A. Daplas wrote:
>> Daniel THOMPSON wrote:
>>> There has been no further comment since this was posted in early May.
>>> This either means is uncontentious or useless ... I hope the former.
>>>
>> I thought you were still in 'discussion' mode with Geert :-)
> 
> I was, but there was no further discussion so I brought it back to you.
> 
>> Anyway, this should be fine, I'm just a bit worried that it might
>> break existing user apps that might be used to having modes without
>> the scan type specified.
> 
> I shared this worry which is why my original patch only tagged the,
> comparatively rare, interlaced modes. However the current approach (no
> optional fields) is slightly cleaner and I took the view that since
> no-one on fbdev-devel seems to object ...
> 

Okay.  But if we are going to break this, let's break it with finality.
Does anyone believe that the above format is final? How about including
sync signals too?  

#define FB_SYNC_HOR_HIGH_ACT	1	/* horizontal sync high active	*/
#define FB_SYNC_VERT_HIGH_ACT	2	/* vertical sync high active	*/
#define FB_SYNC_EXT		4	/* external sync		*/
#define FB_SYNC_COMP_HIGH_ACT	8	/* composite sync high active   */
#define FB_SYNC_BROADCAST	16	/* broadcast video timings      */

Secondly, that attribute 'modes' violate the 'one file, one value' rule of
sysfs (and that includes 'virtual_size', and 'pan').  We need to clean
these up.  How about something like this?

/sys/class/graphics---fb0
                    :
                    --fb1
                    :
                    --fbn
                    :
                    --mode0---640x480@60
                    :       :
                    :       --1024x768@60
                    :  
                    --mode1

where mode[n] represents the currently attached display to fb[n]

Tony