fbdev: tag by scantype in sysfs

PATCH In review Daniel THOMPSON 5 participants 9 messages Jun 20, 2006 – Jun 23, 2006 Framebuffer layer

Share & tools

Daniel THOMPSON

author

2006-06-20 07:58 UTC #0 lore raw

PATCH 1/1 fbdev: tag by scantype in sysfs

There has been no further comment since this was posted in early May. This either means is uncontentious or useless ... I hope the former.

Signature · 4 lines

Daniel Thompson (STMicroelectronics) <[email protected]>
1000 Aztec West, Almondsbury, Bristol, BS32 4SQ. 01454 462659

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

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 <[email protected]>

drivers/video/fbsysfs.c +10 -1

Index: linux-2.6.17-rc6-mm2/drivers/video/fbsysfs.c
===================================================================
@@ -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,

_______________________________________________
Linux-fbdev-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Antonino A. Daplas

2006-06-20 08:42 UTC #1 lore raw

Quoted 3 lines · Daniel THOMPSON

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

Daniel THOMPSON

author

2006-06-20 09:42 UTC #2 lore raw

Quoted 6 lines · Antonino A. Daplas

Quoted 3 lines · Daniel THOMPSON
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.

Quoted 3 lines

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

Signature · 4 lines

Daniel Thompson (STMicroelectronics) <[email protected]>
1000 Aztec West, Almondsbury, Bristol, BS32 4SQ. 01454 462659

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

Antonino A. Daplas

2006-06-20 10:30 UTC #3 lore raw

Quoted 9 lines · Daniel THOMPSON

Quoted 5 lines · Antonino A. Daplas
Quoted 3 lines · Daniel THOMPSON
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.

Quoted 9 lines

Quoted 3 lines
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

Daniel THOMPSON

author

2006-06-23 08:06 UTC #4 lore raw

Quoted 13 lines · Antonino A. Daplas

Quoted 2 lines
I shared this worry which is why my original patch only tagged the, comparatively rare, interlaced modes. However the current approach
(no
Quoted 3 lines
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?

Quoted 5 lines

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

Quoted 4 lines

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?

Quoted 11 lines

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

Signature · 10 lines

Daniel Thompson (STMicroelectronics) <[email protected]>
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

Geert Uytterhoeven

2006-06-23 09:16 UTC #5 lore raw

Quoted 13 lines · Daniel THOMPSON

Quoted 11 lines · Antonino A. Daplas

/sys/class/graphics---fb0

                    :
                    --fb1
                    :
                    --fbn
                    :
                    --mode0---640x480@60
                    :       :
                    :       --1024x768@60
                    :  
                    --mode1

Quoted 2 lines

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 -- [email protected]

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

Daniel THOMPSON

author

2006-06-23 09:54 UTC #6 lore raw

Quoted 13 lines · Geert Uytterhoeven

Quoted 12 lines · Daniel THOMPSON

Quoted 11 lines · Antonino A. Daplas

/sys/class/graphics---fb0

                    :
                    --fb1
                    :
                    --fbn
                    :
                    --mode0---640x480@60
                    :       :
                    :       --1024x768@60
                    :  
                    --mode1

Quoted 5 lines

Quoted 2 lines
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.

Signature · 9 lines

Daniel Thompson (STMicroelectronics) <[email protected]>
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

Antonino A. Daplas

2006-06-23 12:00 UTC #7 lore raw

Quoted 16 lines · Daniel THOMPSON

Quoted 15 lines · Geert Uytterhoeven
Quoted 14 lines · Daniel THOMPSON
Quoted 11 lines · Antonino A. Daplas
/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?

Quoted 9 lines

Quoted 2 lines
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.

Quoted 2 lines

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

Luca

2006-06-23 20:23 UTC #8 lore raw

In reply to Daniel THOMPSON

Il Fri, Jun 23, 2006 at 09:04:41AM +0100, Daniel THOMPSON ha scritto:

Quoted 11 lines

Quoted 4 lines
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 ...

Quoted 6 lines

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

Signature · 8 lines

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