linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jon Smirl <jonsmirl@gmail.com>
To: dri-egl@lists.freedesktop.org,
	fbdev <linux-fbdev-devel@lists.sourceforge.net>
Subject: Reworking sysfs attributes for fbdev
Date: Mon, 14 Mar 2005 22:43:27 -0500	[thread overview]
Message-ID: <9e47339105031419437348829a@mail.gmail.com> (raw)
In-Reply-To: <9e473391050314091173cfbd0d@mail.gmail.com>

Some discussion on the dri-egl list points out that the new mode
setting sysfs attributes for fbdev are too limited. Below is a
proposal I made on the dri-egl list.

To implement this for fbdev I need to know the right set of of
attribute value pairs. Some obvious ones are:

name=string
width=number
height=number
depth=number
refresh=number
interlace= yes | no | double
type = detailed|standard|vesa|user
sync = horizonatal_high | vertical_high | external | composite |
broadcast | green
left=number
right=number
lower=number
upper=number
hsync=number
vsync=number
pixclock=number

Right now fb0/modes is set by passing in an array of fb_videomode
structs. To convert this to attribute value pair I needs the full set
so that no info is lost.

If the mode and depth are independent variables we can end up with a
combo that exceeds monitor or hardware bandwidth. Would it be better
to combine the depth into the modes list? or if you try to set a
mode/depth that has too much bandwidth just select a lower bandwidth
mode automatically? Adding the depth to the modelist will triple the
number of entries.

Now that an attribute/value pair scheme has been proposed I like it a
lot better than what I implemented.

---------- Forwarded message ----------
From: Jon Smirl <jonsmirl@gmail.com>
Date: Mon, 14 Mar 2005 12:11:52 -0500
Subject: Re: Native surface creation
To: Brian Paul <brian.paul@tungstengraphics.com>
Cc: dri-egl@lists.freedesktop.org


On Mon, 14 Mar 2005 09:03:45 -0700, Brian Paul
<brian.paul@tungstengraphics.com> wrote:
> It's clear that you're working at a lower level of implementation
> detail than I am in trying to specify an EGL API extension.

I'm working right at the hardware implementing the modesetting.

A major thing being fixed is to allow normal users to set modes
without being root. Writing arbitrary modelines let you burn up
monitors so it has to be a root operation. To get around the need to
be root a fixed list of modes is exposed and you have to choose from
the list.

Right now the interface for this is very human readable in sysfs:
cat /sys/class/graphics/fb0/modes  --- list of mode names in human readable form
echo name >/sys/class/graphics/fb0/mode -- set one of the modes from the list

This is in current linus bk and it works with fbcon but it isn't
machine friendly, it relies on the human to know what the mode names
mean.

I could alter the attributes to work like this:

echo "width=1000, height=800, depth=32" >/sys/class/graphics/fb0/mode
would pick the closest mode and set it

echo "HDTV 1080i" >/sys/class/graphics/fb0/mode
would search the names since there is no equal sign.

cat /sys/class/graphics/fb0/mode
name="HDTV 720P", width=1024, height=720, depth=32, interlace=no, refresh=60

cat /sys/class/graphics/fb0/modes -- read only
name="v:1024x768", width=1024, height=768, depth=32, interlace=no, refresh=60
name="HDTV 720P", width=1024, height=720, depth=32, interlace=no, refresh=60
name="HDTV 1080i", width=1280, height=1080, depth=32, interlace=yes, refresh=60

I'll also change the root priv attribute that builds the mode list to
take in attribute/value pairs but egl can't change the list.

>
> typedef unsigned int EGLMode;
>
> EGLBoolean eglChooseMode(EGLDisplay dpy, const EGLint *attrib_list,
> EGLMode *modes, EGLint modes_size, EGLint *num_modes);
translates to
open("/sys/class/graphics/fb0/mode")
write("width=1000, height=800, depth=32");
close()
>
> EGLBoolean eglGetModes(EGLDisplay dpy, EGLint screen_number, EGLMode
> *modes, EGLint modes_size, EGLint *num_modes);
translates to
open("/sys/class/graphics/fb0/modes")
read()
close()
>
> EGLBoolean eglGetModeAttribMESA(EGLDisplay dpy, EGLMode mode, EGLint
> attribute, EGLint *value);

I can only do this for the currently active mode.

Note that the list of modes can change due to a monitor hotplug. This
will generate a hal/dbus event.

>
> They mirror the EGL Config functions.  Among the attribute tokens
> would be: EGL_WIDTH, EGL_HEIGHT, EGL_DEPTH, EGL_REFRESH_RATE, etc.
>

>
> -Brian
>

--
Jon Smirl
jonsmirl@gmail.com


-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

       reply	other threads:[~2005-03-15  3:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200503111331.41352.ajax@nwnk.net>
     [not found] ` <9e47339105031114196dbffd88@mail.gmail.com>
     [not found]   ` <42322050.9070206@tungstengraphics.com>
     [not found]     ` <9e47339105031115307868b476@mail.gmail.com>
     [not found]       ` <423230B3.2080202@tungstengraphics.com>
     [not found]         ` <9e4733910503111708d1e6856@mail.gmail.com>
     [not found]           ` <4234C39B.1010702@tungstengraphics.com>
     [not found]             ` <9e473391050313164572435dd4@mail.gmail.com>
     [not found]               ` <4235B5E1.6080406@tungstengraphics.com>
     [not found]                 ` <9e473391050314091173cfbd0d@mail.gmail.com>
2005-03-15  3:43                   ` Jon Smirl [this message]
2005-03-15  6:49                     ` Reworking sysfs attributes for fbdev Antonino A. Daplas
2005-03-15  8:55                       ` Geert Uytterhoeven
2005-03-15 20:27                         ` Antonino A. Daplas

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=9e47339105031419437348829a@mail.gmail.com \
    --to=jonsmirl@gmail.com \
    --cc=dri-egl@lists.freedesktop.org \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    /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).