Reworking sysfs attributes for fbdev

Reworking sysfs attributes for fbdev

[Jon Smirl]

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

Re: Reworking sysfs attributes for fbdev

[Antonino A. Daplas]

On Tuesday 15 March 2005 11:43, Jon Smirl wrote:
> 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

We can do that, vesa's mode id's are like that. Although I prefer that mode
setting should be separated from the framebuffer format setting (ie, depth), it's
currently difficult to make this work safely the reason being that not all
check_var() functions can be relied upon.

> mode/depth that has too much bandwidth just select a lower bandwidth
> mode automatically?

It is hard to determine if the mode/depth combination is illegal unless
the check_var() function, as mentioned, can be relied upon.

> Adding the depth to the modelist will triple the
> number of entries.

That is the downside. Plus, combining parameters that describe the
display with those that describe the framebuffer seems ugly to me.

Also, depth might not be a good enough descriptor. We can have
ARGB1555/RGB565 (depth = 16),  ARGB8888/ARGB2101010 (depth 32).
Then you have directcolor, truecolor, pseudocolor.  To fully describe
a modeline, one just have to look at VESA's modeinfoblock structure to
see how complicated this can be.

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

The refresh rate can also be added.  If the refresh rate is not specified, choose
the highest refresh. We already have a function for this:

fb_find_nearest_mode()
 
>
> 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

Yep, this is more descriptive.  Or just include the entire set of timings
(ala X modeline), but one may argue that this is too much data.
 
Tony




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

Re: Reworking sysfs attributes for fbdev

[Geert Uytterhoeven]

On Tue, 15 Mar 2005, Antonino A. Daplas wrote:
> On Tuesday 15 March 2005 11:43, Jon Smirl wrote:
> > 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
> 
> We can do that, vesa's mode id's are like that. Although I prefer that mode
> setting should be separated from the framebuffer format setting (ie, depth), it's
> currently difficult to make this work safely the reason being that not all
> check_var() functions can be relied upon.

So should we separate into geometry, timings, visual (cfr. fbutils)?

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


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

Re: Reworking sysfs attributes for fbdev

[Antonino A. Daplas]

On Tuesday 15 March 2005 16:55, Geert Uytterhoeven wrote:
> On Tue, 15 Mar 2005, Antonino A. Daplas wrote:
> > On Tuesday 15 March 2005 11:43, Jon Smirl wrote:
> > > 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
> >
> > We can do that, vesa's mode id's are like that. Although I prefer that
> > mode setting should be separated from the framebuffer format setting (ie,
> > depth), it's currently difficult to make this work safely the reason
> > being that not all check_var() functions can be relied upon.
>
> So should we separate into geometry, timings, visual (cfr. fbutils)?

Ideally, yes, but the problem with fbsysfs is that a regular user can change
the mode. Once we do the separation, combinations will exist that can be 
illegal.

ie echo 1024x768@60 > fb0/mode
   echo 32 > fb0/depth

The second set may not be compatible with the preceeding one.  Although
drivers do have a check_var(), I don't think all are robust enough to 
screen out illegal combinations.

Tony




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