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

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

[Daniel THOMPSON]

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

There has been no further comment since this was posted in early May.
This either means is uncontentious or useless ... I hope the former.
-- 
Daniel Thompson (STMicroelectronics) <daniel.thompson@st.com>
1000 Aztec West, Almondsbury, Bristol, BS32 4SQ. 01454 462659

If a car is a horseless carriage then is a motorcycle a horseless horse?

[-- Attachment #2: linux-2.6.17-rc6-mm2-fbdev_tag_by_scantype_in_sysfs.patch --]
[-- Type: text/x-patch, Size: 1366 bytes --]

Subject: fbdev: tag by scantype in sysfs
Modify the sysfs description of a video mode such that modes are tagged
with their scan type, (p)rogessive, (i)nterlaced, (d)ouble scan. For example,
U:1920x1080i-50. This is useful to disambiguate some of the 'consumer'
video timings found in CEA-861 (especially those for EDTV).

Signed-off-by: Daniel R Thompson <daniel.thompson@st.com>
Index: linux-2.6.17-rc6-mm2/drivers/video/fbsysfs.c
===================================================================
--- linux-2.6.17-rc6-mm2.orig/drivers/video/fbsysfs.c	2006-03-20 05:53:29.000000000 +0000
+++ linux-2.6.17-rc6-mm2/drivers/video/fbsysfs.c	2006-06-20 08:52:57.000000000 +0100
@@ -95,13 +95,22 @@
 		       const struct fb_videomode *mode)
 {
 	char m = 'U';
+	char v = 'p';
+
 	if (mode->flag & FB_MODE_IS_DETAILED)
 		m = 'D';
 	if (mode->flag & FB_MODE_IS_VESA)
 		m = 'V';
 	if (mode->flag & FB_MODE_IS_STANDARD)
 		m = 'S';
-	return snprintf(&buf[offset], PAGE_SIZE - offset, "%c:%dx%d-%d\n", m, mode->xres, mode->yres, mode->refresh);
+
+	if (mode->vmode & FB_VMODE_INTERLACED)
+		v = 'i';
+	if (mode->vmode & FB_VMODE_DOUBLE)
+		v = 'd';
+
+	return snprintf(&buf[offset], PAGE_SIZE - offset, "%c:%dx%d%c-%d\n",
+	                m, mode->xres, mode->yres, v, mode->refresh);
 }
 
 static ssize_t store_mode(struct class_device *class_device, const char * buf,

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



[-- Attachment #4: Type: text/plain, Size: 182 bytes --]

_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

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

[Antonino A. Daplas]

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 :-)

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.

Tony

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

[Daniel THOMPSON]

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 ...

-- 
Daniel Thompson (STMicroelectronics) <daniel.thompson@st.com>
1000 Aztec West, Almondsbury, Bristol, BS32 4SQ. 01454 462659

If a car is a horseless carriage then is a motorcycle a horseless horse?

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

[Antonino A. Daplas]

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

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

[Daniel THOMPSON]

On Tue, 2006-06-20 at 18:29 +0800, Antonino A. Daplas wrote:
> > 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      */

Any suggestions about how these should be added to the mode string?

> 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?

Strictly speaking so does the mode string. This is, in fact, why adding
information to it has the potential to break existing applications.

Ideally each mode should itself be a directory containing files like
hsize, vsize, scantype, vfreq ...

Given each mode directory would have a unique name we could then use
that to switch display modes (i.e. write an enumerated name rather than
a mode string).

The problem with this approach is I can't think of any way to do the
work currently performed by store_modes(). I would however like to know
if anyone actually uses this?

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

So the directory mode0 contains all the modes that fb0 is capable of
displaying? Can't that go inside fb0?

Presumably fb0's existing mode file is replaced with a soft link to the
currently selected mode and a new file is introduced to change modes?

-- 
Daniel Thompson (STMicroelectronics) <daniel.thompson@st.com>
1000 Aztec West, Almondsbury, Bristol, BS32 4SQ. 01454 462659

If a car is a horseless carriage then is a motorcycle a horseless horse?


Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

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

[Geert Uytterhoeven]

On Fri, 23 Jun 2006, Daniel THOMPSON wrote:
> On Tue, 2006-06-20 at 18:29 +0800, Antonino A. Daplas wrote:
> >  /sys/class/graphics---fb0
> >                     :
> >                     --fb1
> >                     :
> >                     --fbn
> >                     :
> >                     --mode0---640x480@60
> >                     :       :
> >                     :       --1024x768@60
> >                     :  
> >                     --mode1
> 
> So the directory mode0 contains all the modes that fb0 is capable of
> displaying? Can't that go inside fb0?

Let's hope not, as most machines/fb combos don't have enough RAM to store all
modes the fb is capable of.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

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

[Daniel THOMPSON]

Geert Uytterhoeven wrote:
> On Fri, 23 Jun 2006, Daniel THOMPSON wrote:
>> On Tue, 2006-06-20 at 18:29 +0800, Antonino A. Daplas wrote:
>>>  /sys/class/graphics---fb0
>>>                     :
>>>                     --fb1
>>>                     :
>>>                     --fbn
>>>                     :
>>>                     --mode0---640x480@60
>>>                     :       :
>>>                     :       --1024x768@60
>>>                     :  
>>>                     --mode1
>> So the directory mode0 contains all the modes that fb0 is capable of
>> displaying? Can't that go inside fb0?
> 
> Let's hope not, as most machines/fb combos don't have enough RAM to store all
> modes the fb is capable of.

Fair point.

By default the existing modes includes only the VESA standard modes,
although I would expect drivers for TV-like hardware to override the
mode list to get the supportable CEA-851 standards instead.

I confess I'm having a great deal of difficulty trying to think of any
way to update the mode list while sticking to one file, one value.

-- 
Daniel Thompson (STMicroelectronics) <daniel.thompson@st.com>
1000 Aztec West, Almondsbury, Bristol, BS32 4SQ. 01454 462659

If a car is a horseless carriage then is a motorcycle a horseless horse?

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

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

[Antonino A. Daplas]

Daniel THOMPSON wrote:
> Geert Uytterhoeven wrote:
>> On Fri, 23 Jun 2006, Daniel THOMPSON wrote:
>>> On Tue, 2006-06-20 at 18:29 +0800, Antonino A. Daplas wrote:
>>>>  /sys/class/graphics---fb0
>>>>                     :
>>>>                     --fb1
>>>>                     :
>>>>                     --fbn
>>>>                     :
>>>>                     --mode0---640x480@60
>>>>                     :       :
>>>>                     :       --1024x768@60
>>>>                     :  
>>>>                     --mode1
>>> So the directory mode0 contains all the modes that fb0 is capable of
>>> displaying? Can't that go inside fb0?
>> Let's hope not, as most machines/fb combos don't have enough RAM to store all
>> modes the fb is capable of.
> 
> Fair point.
> 
> By default the existing modes includes only the VESA standard modes,
> although I would expect drivers for TV-like hardware to override the
> mode list to get the supportable CEA-851 standards instead.
>

It only includes modes that are in the driver's private mode list. For
most drivers, that's one entry, for others with EDID, it can be as
much as 40 (near-maximum the EDID block is capable of), but typically
less than 10.
 
> I confess I'm having a great deal of difficulty trying to think of any
> way to update the mode list while sticking to one file, one value.

We can unbind fb[n] from display[n], echo the mode we want added to an 'x'
file one by one, and the modes we don't want into a 'y' file. Finally,
we can bind fb[n] back to display[n]. It's ugly, but can work.

After giving it some thought, sysfs is just not appropriate to serve the
needs of the framebuffer system. So I'll leave fbsysfs untouched for now and
just find/invent more appropriate interfaces.

Tony

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

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

[Luca]

Il Fri, Jun 23, 2006 at 09:04:41AM +0100, Daniel THOMPSON ha scritto: 
> > 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?
> 
> Strictly speaking so does the mode string. This is, in fact, why adding
> information to it has the potential to break existing applications.
> 
> Ideally each mode should itself be a directory containing files like
> hsize, vsize, scantype, vfreq ...
> 
> Given each mode directory would have a unique name we could then use
> that to switch display modes (i.e. write an enumerated name rather than
> a mode string).
> 
> The problem with this approach is I can't think of any way to do the
> work currently performed by store_modes().

I think that configfs is able to deal with this using commitable items.
But having half of the framebuffer configured using sysfs and the other
half using configfs is a bit ugly :|

Luca
-- 
Home: http://kronoz.cjb.net
"Accadono cose che sono come domande. Passa un minuto, oppure anni, e
 poi la vita risponde."

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642