linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@nokia.com>
To: ext Geert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-fbdev-devel@lists.sourceforge.net, linux-omap@vger.kernel.org
Subject: Re: [Linux-fbdev-devel] [REVIEW PATCH 1/9] DSS: Documentation for OMAP2/3 display subsystem
Date: Wed, 05 Nov 2008 12:12:41 +0200	[thread overview]
Message-ID: <1225879961.8052.12.camel@tubuntu> (raw)
In-Reply-To: <Pine.LNX.4.64.0811050855180.15985@anakin>

On Wed, 2008-11-05 at 08:56 +0100, ext Geert Uytterhoeven wrote:
> On Tue, 4 Nov 2008, Tomi Valkeinen wrote:
> > +Sysfs
> > +-----
> > +The sysfs interface is a hack, but works for testing. I don't think sysfs
> > +interface is the best for this in the final version, but I don't quite know
> > +what would be the best interfaces for these things.
> > +
> > +In /sys/devices/platform/omapfb we have four files: framebuffers,
> > +overlays, managers and displays. You can read them so see the current
> > +setup, and change them by writing to it in the form of
> > +"<item-id> <opt1>:<val1> <opt2>:<val2>..."
> > +
> > +"framebuffers" lists all framebuffers. Its format is:
> > +	<fb number>
> > +	t:<target overlay>
> > +
> > +"overlays" lists all overlays. Its format is:
> > +	<overlay name>
> > +	t:<target manager>
> > +	x:<xpos>
> > +	y:<ypos>
> > +	iw:<input width, read only>
> > +	ih:<input height, read only>
> > +	w:<output width>
> > +	h:<output height>
> > +	e:<enabled>
> > +
> > +"managers" lists all overlay managers. Its format is:
> > +	<manager name>
> > +	t:<target display>
> > +
> > +"displays" lists all displays. Its format is:
> > +	<display name>
> > +	w:<width>
> > +	h:<height>
> > +	e:<enabled>
> > +	u:<update mode>
> > +	t:<tear sync on/off>
> 
> As all of these contain lists of sections (one for each
> fb/overlay/manager/display), what about making them directories, with each
> section an individual file?

I've thought that also. The reason for the current form is that it was
simpler to implement, and is not meant to be in the final version. If
the sysfs interface stays there, then I agree that they files have to be
divided.

> 
> Gr{oetje,eeting}s,
> 
> 						Geert

 Tomi


  reply	other threads:[~2008-11-05 10:12 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-04 16:09 [REVIEW PATCH 0/9] DSS: Series description Tomi Valkeinen
2008-11-04 16:09 ` [REVIEW PATCH 1/9] DSS: Documentation for OMAP2/3 display subsystem Tomi Valkeinen
2008-11-05  7:56   ` [Linux-fbdev-devel] " Geert Uytterhoeven
2008-11-05 10:12     ` Tomi Valkeinen [this message]
2008-11-04 16:09 ` [REVIEW PATCH 2/9] DSS: New display subsystem driver for OMAP2/3 Tomi Valkeinen
2008-11-04 16:10 ` [REVIEW PATCH 3/9] DSS: RFBI support for OMAP2/3 DSS Tomi Valkeinen
2008-11-04 16:10 ` [REVIEW PATCH 4/9] DSS: TV-out " Tomi Valkeinen
2008-11-05 10:27   ` Jarkko Nikula
2008-11-04 16:10 ` [REVIEW PATCH 5/9] DSS: DSI " Tomi Valkeinen
2008-11-04 16:10 ` [REVIEW PATCH 6/9] DSS: OMAPFB: fb driver for new display subsystem Tomi Valkeinen
2008-11-04 16:10 ` [REVIEW PATCH 7/9] DSS: Add generic DVI panel Tomi Valkeinen
2008-11-04 16:10 ` [REVIEW PATCH 8/9] DSS: support for Beagle Board Tomi Valkeinen
2008-11-04 17:28   ` Koen Kooi
2008-11-05 10:05     ` Tomi Valkeinen
2008-11-05 21:15       ` Koen Kooi
2008-11-04 18:24   ` [Linux-fbdev-devel] " Tony Lindgren
2008-11-05 10:09     ` Tomi Valkeinen
2008-11-05 10:27   ` Jarkko Nikula
2008-11-05 23:21     ` David Brownell
2008-11-06  8:23       ` Tomi Valkeinen
2008-11-06  8:30         ` Koen Kooi
2008-11-04 16:10 ` [REVIEW PATCH 9/9] DSS: support for OMAP3 SDP board Tomi Valkeinen
2008-11-05 10:54   ` Jarkko Nikula
2008-11-10  4:03 ` [Linux-fbdev-devel] [REVIEW PATCH 0/9] DSS: Series description Shah, Hardik
2008-11-10 11:31   ` Tomi Valkeinen
2008-11-10 12:03     ` Shah, Hardik
2008-11-18  6:40 ` Shah, Hardik
2008-11-18 12:06   ` Tomi Valkeinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1225879961.8052.12.camel@tubuntu \
    --to=tomi.valkeinen@nokia.com \
    --cc=geert@linux-m68k.org \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=linux-omap@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).