[4/9] fb: export fb mode db table
diff mbox series

Message ID 1291902441-24712-5-git-send-email-s.hauer@pengutronix.de
State New, archived
Headers show
Series
  • [RFC] i.MX51 Framebuffer support
Related show

Commit Message

Sascha Hauer Dec. 9, 2010, 1:47 p.m. UTC
The different modes can be useful for drivers. Currently there is
no way to expose the modes to sysfs, so export them.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 drivers/video/modedb.c |    7 ++++++-
 include/linux/fb.h     |    3 +++
 2 files changed, 9 insertions(+), 1 deletions(-)

Comments

Paul Mundt Jan. 6, 2011, 7:26 a.m. UTC | #1
On Thu, Dec 09, 2010 at 02:47:16PM +0100, Sascha Hauer wrote:
> The different modes can be useful for drivers. Currently there is
> no way to expose the modes to sysfs, so export them.
> 
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

I'll admit I don't really like the idea of exposing the modedb to drivers
in this way, but given that we're already doing it for the vesa and cea
modes, allowing drivers to copy ranges in to their modelist from the
standard db is probably something we can live with.

The mode list dumping is basically a blatant sysfs abuse already though,
and it would be much cleaner simply to back the mode store with an
fb_find/try_mode() pair that grovels all the right places in addition to
doing a pass over the fb_info's modelist.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Sascha Hauer Jan. 6, 2011, 10:04 a.m. UTC | #2
On Thu, Jan 06, 2011 at 04:26:58PM +0900, Paul Mundt wrote:
> On Thu, Dec 09, 2010 at 02:47:16PM +0100, Sascha Hauer wrote:
> > The different modes can be useful for drivers. Currently there is
> > no way to expose the modes to sysfs, so export them.
> > 
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> 
> I'll admit I don't really like the idea of exposing the modedb to drivers
> in this way, but given that we're already doing it for the vesa and cea
> modes, allowing drivers to copy ranges in to their modelist from the
> standard db is probably something we can live with.
> 
> The mode list dumping is basically a blatant sysfs abuse already though,

You mean the available modes should not be exposed to sysfs? I found it
quite convenient to have during development. Exporting the modedb seemed
to be the only way to populate sysfs with a sane set of modes.

> and it would be much cleaner simply to back the mode store with an
> fb_find/try_mode() pair that grovels all the right places in addition to
> doing a pass over the fb_info's modelist.

The kernel provides no way to query the modelist other than sysfs. So
when the modelist dumping is a sysfs abuse, what purpose does the
modelist have anyway?

Right now the behaviour is quite strange. Each time a new (formerly
unknown) mode is selected the modelist magically gets a new entry. So
the kernel normally starts with an empty (or one entry from startup)
modelist and gets populated over time with the modes the user used.

I could understand when we say: "We do not keep the modelist in kernel,
do this in userspace". I could also understand when we say "we keep a
list of sane modes in the kernel, use fbset to switch to exotic modes".
ATM we do the worst of both: We keep a list but we do not populate it
with sane modes. Even worse, we use it to store the history of modes.

I know much of this comes from the fact that the fb subsystem does not
have a maintainer and nowadays the big desktop guys are not using the fb
subsystem at all, but it's really hard to find a way through and every
driver seems to have it's own idea of how things should work.

Sascha

Patch
diff mbox series

diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
index 0a4dbdc..82122a9 100644
--- a/drivers/video/modedb.c
+++ b/drivers/video/modedb.c
@@ -36,7 +36,7 @@  EXPORT_SYMBOL_GPL(fb_mode_option);
      *  Standard video mode definitions (taken from XFree86)
      */
 
-static const struct fb_videomode modedb[] = {
+const struct fb_videomode modedb[] = {
     {
 	/* 640x400 @ 70 Hz, 31.5 kHz hsync */
 	NULL, 70, 640, 400, 39721, 40, 24, 39, 9, 96, 2,
@@ -277,6 +277,11 @@  static const struct fb_videomode modedb[] = {
     },
 };
 
+const struct fb_videomode *fb_modes = modedb;
+EXPORT_SYMBOL(fb_modes);
+const int num_fb_modes = ARRAY_SIZE(modedb);
+EXPORT_SYMBOL(num_fb_modes);
+
 #ifdef CONFIG_FB_MODE_HELPERS
 const struct fb_videomode vesa_modes[] = {
 	/* 0 640x350-85 VESA */
diff --git a/include/linux/fb.h b/include/linux/fb.h
index d1631d3..e006172 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -1151,6 +1151,9 @@  struct fb_videomode {
 extern const char *fb_mode_option;
 extern const struct fb_videomode vesa_modes[];
 
+extern const struct fb_videomode *fb_modes;
+extern const int num_fb_modes;
+
 struct fb_modelist {
 	struct list_head list;
 	struct fb_videomode mode;