* Reworking sysfs attributes for fbdev [not found] ` <9e473391050314091173cfbd0d@mail.gmail.com> @ 2005-03-15 3:43 ` Jon Smirl 2005-03-15 6:49 ` Antonino A. Daplas 0 siblings, 1 reply; 4+ messages in thread From: Jon Smirl @ 2005-03-15 3:43 UTC (permalink / raw) To: dri-egl, fbdev 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Reworking sysfs attributes for fbdev 2005-03-15 3:43 ` Reworking sysfs attributes for fbdev Jon Smirl @ 2005-03-15 6:49 ` Antonino A. Daplas 2005-03-15 8:55 ` Geert Uytterhoeven 0 siblings, 1 reply; 4+ messages in thread From: Antonino A. Daplas @ 2005-03-15 6:49 UTC (permalink / raw) To: linux-fbdev-devel, Jon Smirl, dri-egl 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Reworking sysfs attributes for fbdev 2005-03-15 6:49 ` Antonino A. Daplas @ 2005-03-15 8:55 ` Geert Uytterhoeven 2005-03-15 20:27 ` Antonino A. Daplas 0 siblings, 1 reply; 4+ messages in thread From: Geert Uytterhoeven @ 2005-03-15 8:55 UTC (permalink / raw) To: Linux Frame Buffer Device Development; +Cc: Jon Smirl, dri-egl 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Reworking sysfs attributes for fbdev 2005-03-15 8:55 ` Geert Uytterhoeven @ 2005-03-15 20:27 ` Antonino A. Daplas 0 siblings, 0 replies; 4+ messages in thread From: Antonino A. Daplas @ 2005-03-15 20:27 UTC (permalink / raw) To: linux-fbdev-devel, Geert Uytterhoeven; +Cc: Jon Smirl, dri-egl 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-03-15 20:27 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[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 ` Reworking sysfs attributes for fbdev Jon Smirl
2005-03-15 6:49 ` Antonino A. Daplas
2005-03-15 8:55 ` Geert Uytterhoeven
2005-03-15 20:27 ` Antonino A. Daplas
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.